All stakeholder input is required for requirements collection, this can be done in a one to one bases but it is preferred to bring all of the stake holders together for a group requirements gathering session. This group requirements gathering sessions provides three benefits:
- Collects requirements for the project plan
- Gives stakeholders a common understanding of the requirements
- Resolves competing and/or conflicting requirements
Requirements will generally fall into the following list:
- Product technical or functional requirements
- Project process/management requirements
- Quality or performance requirements (for the project and product)
- Business or organizational requirements (for the project and product)
- Support or operational requirements (for the product)
- Profitability or sales/Marketing requirements (for the product)
All requirements are collected, documented, reviewed, prioritized and approved by the stakeholders. these requirements are the basis from which the work activities/tasks are defined. These requirements are often documented in a "Requirements Tractability Matrix"; it's a grid that links product requirements from their origin to the deliverables that satisfy them.
Requirements map directly to deliverables or objectives, each requirement must support an objective or deliverable directly. If a requirement doesn't support an objective or deliverable then there is a problem that needs to be addressed, either you're missing an objective/deliverable, or the requirement is not valid.
The main deliverable is comprised of smaller ancillary deliverables that build up to support the project purpose and objectives; the main deliverable, the successful completion of the project.
Requirements should be traceable to deliverables which in turn support the Project Objectives. in this way requirements are connected to work items that produce deliverables which support objectives.
Requirements need to be measurable and testable to show the customer that they where successfully completed as defined in the project plan to gain customer approval. All assumptions and limitations should be tracked by the project manager as discussions with stakeholders take place, these items need to be documented in the project scope statement.
Prioritizing Requirements
Not all requirements are of equal importants, some are essential while other a nice to haves. A popular method for prioritizing requirements is the MoSCoW method which breaks requirements down into:
- Must Have: critical have to meet project Objectives
- Should Have: important and should be included in final deliverable if time and budget permits, otherwise need to be delivered at a later date or in a subsequent version.
- Could Have: nice to have, but the project objective can still be met without these requirements.
- Wont Have: will not be included in the current iteration of the product, these are agreed upon with the stakeholder in the outset of the project that they will not be included, but can be revisited in the future.
Stakeholders need to be involved in the prioritization process of requirements this helps the PM and team understand the most critical requirements that need to be delivered. It is normal to move some requirements to the wont have prioritization as the project plan progresses to facilitate the budget and time restrictions of the project. as the project progress the PM with stakeholder approval can move could have and should have requirements out of scope to deliver the project on time and budget. Since it was decided with the stakeholder that these requirements are not essential to project success getting approval to de-scope them is usually straight forward.
The PM must ensure that the Requirements Traceability matrix is maintained throughout the lifespan of the project to track which requirements are within the scope of the project.
