Assignment: The MoSCoW Approach

Assignment: The MoSCoW Approach

NOW FOR AN ORIGINAL PAPER ASSIGNMENT:Assignment: The MoSCoW Approach

The MoSCoW approach is then used to prioritize the requirements within each section; the requirements are the only variables because the schedule and budget are set. If a project is running out of time or money, the team can easily omit the requirements that have been identified as the lowest priority to meet their schedule and budget obligations. This does not mean that the final deliverable, the actual system, would be flawed or incomplete. Instead, because the team has already determined the “must have” or “should have” items, it still meets the business needs. According to Haughey ( 2010 ), the 80/20 rule, or Pareto principle, can be applied to nearly everything. The Pareto principle states that 80% of the project comes from 20% of the system requirements; therefore, the 20% of requirements must be the crucial requirements or those with the highest priority. One also must consider the pancake principle: The first pancake is not as good as the rest, and one should know that the first development will not be perfect. This is why it is extremely important to clearly identify the “must have” and “should have” requirements.

In the third step of the project life cycle phase, known as functional model iteration, the deliverables are a functional model and prototype ready for user testing. Once the requirements are identified, the next step is to translate them into a functional model with a functioning prototype that can be evaluated by users. This could take several iterations to develop the desired functionality and incorporate the users’ input. At this stage, the team should examine the quality of the product and revise the list requirements and risk log. The requirements are adjusted, the ones that have been realized are deleted, and the remaining requirements are prioritized. The risk log is revised based on the risk analysis completed during and after prototype development.

The design and build iteration step focuses on integrating functional components and identifying the nonfunctional requirements that need to be in the tested system. Testing is crucial; the team will develop a system that the end users can safely use on a daily basis. The team will garner user feedback and generate user documentation. These efforts provide this step’s deliverable, a tested system with documentation for the next and final phase of the development process.