From Open Sustainability
| Overall Content Model
|
| Where Activities Reside
|
|
|
Activity: Detailed Business Requirements
Objective
This activity refines the Detailed Business Requirements for a particular increment. The resulting specifications should be detailed enough to begin the design for the particular increment. On subsequent increments this activity revisits the key business and sustainability requirements out of the Blueprint as a starting point for strategic priorities.
The purpose of this Activity is to validate, refine, categorize and prioritise business requirements for this particular increment. It involves reviewing the existing documentation from Phases 1 and 2 and conducting additional interviews to define the purpose, goals/drivers, objectives, CSFs, KPIs and risks of the increment(s).
Major Deliverables
- Detailed Business Requirements
- Changes to initial set of Strategic Requirements
Tasks
Validate Strategic Business Requirements
Objective:
Validate the Business and Technology Requirements from the overall Blueprint vision and ensure that they are still valid. Working off a list of prioritised requirements, define the functional capabilities that will be delivered as part of this release.
Input:
- Overall Release Functionality
- High Level Sustainability Requirements
Output:
- Validated Strategic Business Requirements
Refine Strategic Business Requirements to Detailed Requirements
Objective:
Refine the Requirements to a level of detail from which more detaile design can be conducted. This may involve a going to a lower level of granularity through sets of interviews to clarify specific points with users. The focus, however, should be on "drilling-down" on Blueprint requirements (where required) as opposed to adding new requirements not included in the vision.
Input:
- Overall Release Functionality
- Validated Strategic Sustainability Requirements
Output:
• Detailed Business Requirements
Categorise Detailed Business Requirements
Objective:
Requirements will already be categorised across from the initial strategic assessment. Ensure these categorisations are still valid before assigning them to team members for design. Also review requirements to make sure areas of overlap and dependencies are well-understood. When requirements are categorised they may overlap into multiple areas, this is fine as long as it is clearly understood that there is ownership of a particular requirement for the different design and testing teams.
Input:
- Detailed Business Requirements
Output:
- Categorised, Detailed Business Requirements
Prioritise Detailed Business Requirements
Objective:
For all requirements that are to be implemented as part of this increment, prioritise those that are most important. This will help set importance levels with the team and make sure that focus is put of the most critical areas. Importance should be set based on 3 factors:
- An important business requirement is a "must have" in terms of functionality for the business
- An important technical requirement must be implemented to ensure the reliability or integrity of the system
- An important dependency means that this capability must be implemented as there is a large degree of functionality dependent on the implementation of this specific requirement.
Importance levels should then influence timing of project plan and resourcing.
Input:
- Categorised, Detailed Business Requirements
Output:
- Prioritised, Categorised, Detailed Business Requirements
Core Supporting Assets
Yellow Flags
- Completed requirements are too high level to begin appropriate design
- Business staff are not available to assist with requirements definition – IT plays too large a role
Key Resource Requirements
