Understanding what it is that the client needs is an integral part of software development. The client will usually help you out by telling you what they need the system to do. What you will generally have is a big list of the things that the system should do. Rather than explain the difference between the terms "function requirements" and "non-functional requirements" to the client, you can save time by using MoSCoW. This is an abbreviation for Must, Should, Could, Won't and can also be written as MSCW or a number of different ways. I prefer the addition of the o's as it makes it more easy to communicate the idea to clients. The idea behind MoSCoW is to go through everything that the client wants the system to do and applying one of the four terms to that feature.
Must- These are things that the system simply must have or it will be useless or unusable. Must requirements will form the central basis of your plan as you work towards making sure these requirements are met. As an example, a blogging application is not much use if you can't post blogs.
Should- This is a secondary requirement that, while not critical to the project, should be included in the overall build. It might be possible to leave a should requirement out, but only if there is another way of doing what is expected.
Could - Could requirements are things that have no impact on the function of the system, but which might, for example, save time in the operation of the program at a later date. These are usually things like export scripts, or nice looking widgets that increase the usability of the system.
Won't - Not really won't, these requirements should be considered as things the the system won't have this time around. These are features that are the least critical to the projects success, but which can be incorporated into future versions. This might be something like having a mobile version, or a feature to integrate with a phone system.
You should remember that all requirements are important, but prioritizing them makes planning the project out that little bit easier, and also allows your clients to know what it is that the system will do. A project plan should initially try to deliver the Must's and Should's, whilst the Could's can be moved to different versions if the delivery timescale looks threatened. It is generally easy to tell what type each requirement is just by the way that the client has written it. They will generally use words like must, should, could, desirable, essential and nice features when writing out what it is that they need the system to do. It should be noted, however, that whilst some features seem like a good idea to the client, the cost involved in actually creating that product might be prohibitive.
Additionally, telling the client what the system won't do is just as important as telling them what it will do. Certain functionality (especially in website based applications) tends to be assumed and by stating exactly what the functionality won't contain you can prevent feature creaping. I have also seen won't in MoSCoW being written as would, which means that the system would do something, if the timescale allows.
As an example, lets take a few random system requirements for an imaginary system and give them a priority with the MoSCoW system.
- Users can log onto the system. - Must
- Users should be able to request a new password via email if they forget it. - Should
- Users can create tasks. - Must
- A user can send an email to the system, which will then be logged to the correct task. - Could
- The user will be able to change the order of a list of tasks by dragging and dropping them. - Won't
- When a user clicks on a phone number on the system their telephone should ring that number. - Won't
MoSCoW is more important that just a list of requirements though. The fundamental backbone of MoSCoW is to not allow the project to have more functionality than you have capacity to create. Clients will generally have a certain amount of budget, and you will have a certain amount of time available. By using MoSCoW you can keep the cost of features within that amount.
To employ a neat metaphore, you can think of the components of MoSCoW like stones of different weights (with Must being the heaviest), and the capacity of either the client or yourself as a bucket. This way it is easy to see that as more stones are added the Must's will sink to the bottom and the Could's will float to the top. There will come a point where you will add a Must or a Should and one or more Could's will overflow from the top of the bucket.
Add new comment