MANAGEMENT

6 - REQUIREMENTS ANALYSIS
6.3.1.1 MoSCoW
MoSCoW, a prioritization technique, provides four possible classifications to prioritize requirements and
derives its name from the first letter of each classification: must, should, could, or won’t. “must have” means the
requirement is fundamental to the success of the solution. “should have” defines the requirement as important, but
project success does not rely on it. “could have” means the requirement can be eliminated without impacting the
project. “won’t have” means the requirement will not be delivered during the current release or iteration.
6.3.1.2 Voting
Voting is a participatory decision model that allows participants to distribute a predetermined number of votes
to a list of requirements. The votes allocated are then used to compare the relative weight or importance of
requirements to one another to establish order. There are many methods of voting available to gain active support
and participation from stakeholders. Regardless of the method used, voting provides a systematic process for
identifying requirements that are deemed higher-priority than others.
6.3.1.3 Timeboxing
Timeboxing ranks requirements based on the capacity of work that can be accomplished within a specified
period of time. It is most often used for projects with tight schedule constraints and allows for control of the project
schedule at the lowest level. If fixed cost is a concern, this technique can be modified to use money instead of time.
This variation is used to determine the requirements that can be delivered within the budget constraints.
6.3.2 Modeling
The types of models used should be determined by the particular information that needs to be communicated
and the audience that will receive the information. Models are used to determine what is important and valuable so
that the right requirements are created. These techniques can be organized into categories, which are defined by
the information that is conveyed, as described in Sections 6.3.2.1 through 6.3.2.6.
6.3.2.1 Scope Models
Scope models identify the boundaries of the project, program, product, or system under analysis. These models
are used to express the features, functions, capabilities, and boundaries of the domain being analyzed. Techniques
within this category are described as follows:
• Context diagram. A system context diagram depicts the product scope by showing the direct interactions
that occur between the system, people, and other systems in a solution. It provides the inputs, outputs,
and flow of information for each entity involved, which may reveal interface requirements that need to
be elicited. This diagram may be represented as an architectural view within an architecture framework.
• Ecosystem map. An ecosystem map illustrates the components of the system, including the relationships
that exist among the people, data, hardware, and software, for example. It provides a high-level depiction
38 ©2016 Project Management Institute. Requirements Management: A Practice Guide