2. Requirements and objectives of the project is
well defined.
These Requirements and Objectives should be
prioritised as well so to determine which is
most important and which is least.
Several methods (e.g The Number System)have
been devised to prioritise these, but all of them
are flawed.
3. Sometimes requirements are not developed
and left behind on the list and eventually they
get lost.
Features ordered by numbers 1,2,3…… appears
logical but once development is started all
features become number 1 which creates huge
confusion.
4. It is a prioritisation method.
Uses four key steps(MoSCoW)
1. M – MUST have this
2. S – SHOULD have this at all possible
3. C – COULD have this if it does not
affect anything else
4. W – WON‟T have this time but
WOULD like in the future.
Alternatively WANT.
5. „Must‟ Requirements are “non negotiable”
without which project is a complete failure.
MUST requirements should be finalised taking
consideration :
1. Agreement over requirements with all
stakeholders.
2. Consider carefully the scope and aim of the
project.
3. Whether requirements match with the purpose of
the project
6. Requirements that are important but not
critical to the success of the project.
It is on second position in the priority list ( It
comes just after MUST).
It is as important as a MUST requirement but
its delivery can be postponed for later durig the
development life cycle.
7. These are lesss critical ones.
„COULD‟ requirements are often described as
features that are nice to have e.g colourful user
interface.
It is nt a necessary factor for the success of the
project
But including it in a project can increase
customer satisfaction for just little development
cost.
8. Least critical requirements that do not affect
success of project
Lowest payback items
They are not included in the in the schedule
They are normally dropped are reconsidered
whether to be included or not.
But sometimes its inclusion helps for future
use.