Below diagram is a representation that indicates the various Business Analysis Knowledge Areas and the various sections in them. The numbers are the section numbers in the Business Analysis Body of Knowledge (BABoK(R))
Prioritization of Requirements - MoSCoW
The four capitalized letters in the MoSCoW prioritization scheme stand for four possible priority classifications for the requirements in a set (IIBA 2009):
Must: The requirement must be satisfied for the solution to be considered a success.
Should: The requirement is important and should be included in the solution if possible, but it’s not mandatory to success.
Could: It’s a desirable capability, but one that could be deferred or eliminated. Implement it only if time and resources permit.
Won’t: This indicates a requirement that will not be implemented at this time but could be included in a future release.
Prioritization of Requirements - A Quantitative Method
Organizations come up with various frameworks to score each requirement and objectively rank them.
Priority is a function of below items – primarily on Value delivered through implementation & Penalty of not implementing, Cost to implement and Risks involved.
- Business Value (to Organization; User)
- Product differentiation
- Penalty of not implementing (to Organization; User)
- Is it a Compliance requirement?
- Is there a workaround?
- # of users using or impacted
- Time sensitivity of the feature (Time Window)
- Lack of stability of the feature definition
- Dependencies of some features with others;
- Time to Implement.
- Cost to Implement
- Complexity and Technical Feasibility
- Risk to Implement
Here is an objective method for prioritization of requirements as provided in Reference: Software Requirements, Karl E. Wiegers, Microsoft Press.
Multipass Requirement Prioritization
Teams go about prioritizing requirements in to High Medium and Low priorities. This is depicted in the picture below. Normal tendency is to retain many requirements in the High Priority category in the first pass. Hence, the subsequent passes help in breaking this.
Pareto Principle
Pareto principle can be applied suitably while prioritizing requirements by ranking them in the order of their contribution to addressing the issue on hnad (or) enabling the realization of the opportunity being tapped.
Traceability of Requirements
Analyze and maintain relationships between requirements, designs, solution components, and other work products. Traceability can be both Upwards (all the way to the business need identified by stakeholder) and Downwards (all the way to the lowest detailing of requirements and testing).
Levels of traceability: [Requirements] -> Design -> Code -> Test Cases
References
Software Requirements, Karl E. Wiegers, Microsoft Press.
Dr. Selvaraj Vadivelu 