## 4.4 Requirements In general, requirements represent a **description of product or service features that are required to satisfy the stakeholders' needs**. If requirements could be agreed and fixed early in the project life cycle, that would allow the team to effectively: - document exactly what will be delivered; - estimate the human-resource requirements; - develop the project budget; - build a complete project work schedule so resources can be committed. If both the requestor and the provider are certain that the solution is completely described by the requirements specification, then the traditional upfront planning approach can be used. However, when the requirements are not entirely known or if the rate of changes is high, Agile and Lean UX approaches yield better results. Agile project organisation, if managed well, creates the conditions for requestor and provider co-evolution by being regularly exposed to the interpretation of their agreements. Therefore, the next instalment of requirements definitions can be adapted to the lessons learnt. However, the identification of requirements is itself prone to some strategic risks. - Requirements may be derived from some knowledge of possible solutions. As such, they represent the ‘how’, rather than the ‘what’, thus limiting the possibility to discover the most appropriate solution. - Requirements represent investment items. Meeting and maintaining each new requirement is a regular additional expense. Furthermore, these IT investments can represent duplications if requirements are for building or buying capabilities that are already available. To minimise this risk, it is important to analyse the available capabilities, components, and services and their feasibility for reuse. - An important first step is to identify requirements by clarifying the problem to be solved or the needs to be addressed. Without this effort, problem-solving opportunities may be missed or the consequences of implementation on the entire enterprise architecture may be underestimated. Therefore, it is important to fully document the problem or need in the PM2 Business Case before gathering requirements. Then once the solution architecture is clearer, it’s then necessary to evaluate the impact of implementing it. In order to ensure proper requirements’ management, implementation and monitoring, PM2-Agile considers two very important dimensions to describe a solution’s behaviour: - **Abstraction Level** –There are several different levels of abstraction to identify requirements. PM2- Agile acknowledges the key role of Features and Stories to describe the solution’s behaviour. - **Implementation Perspective** – The implementation perspective of a solution cannot be restricted to a business point of view. To have a solution built, it’s of paramount importance acknowledging and understanding all the underlying work that needs to be done to support the implementation of the business features. That is the key role of PM2-Agile Business and Enabler Items. **Features and Stories** A Feature is a proposed service, within the context of a solution, that exists to address the needs of the business, the customer and the user. The PM2 Project Charter foresees a more detailed description of the proposed solution through the identification and description of the features and the corresponding needs they will target. Features are described in the Project Charter with a high level of abstraction to ensure all layers in the project’s organisation clearly understand the scope of the solution. When described, features should provide information about their context and the benefit hypothesis that must be verified upon delivery. To execute a predefined Release strategy in the most effective way, features must be prioritised. This activity should involve key stakeholders such as the Business Manager (BM), the Project Owner (PO) and the Business Implementation Group (BIG). To help with prioritisation activities, PM2-Agile strongly recommends the use of combined elements like Business Value and the “Size” of a feature. Features that deliver the highest business value with the shortest turn-around time will be delivered first. Additionally, projects with a higher risk level should also take into account the risk reduction factor of each feature. Features with higher risk factor should have higher priority. A feature is developed and delivered in the context of a release throughout several iterations. Because the Agile Project Core Team’s (A-PCT) cadence is based on iterations (smaller cycles), the features (functional units) must be decomposed in a set of stories (working units) so that they can be planned and implemented within each iteration. By evaluating the output of each iteration in terms of completed stories, one can easily measure the progress of each feature or release and make any necessary adjustments when needed. A story is a piece of functionality that is written using a language focused on the user. Implemented by the Agile Project Core Team (A-PCT) within an iteration, the story represents a small, vertical slice of system behaviour that supports incremental development. Stories provide just enough information for both business and technical people to understand the intent. Details are deferred until the story is ready to be implemented. Through acceptance criteria and acceptance tests, stories become more specific, helping to ensure system quality. The main consumer of stories is the Agile Project Core Team (A-PCT) though other stakeholders like the Business Manager (BM) or the User Representatives in the Business Implementation Group (BIG) can also use them. Stories are a simple and straightforward way to identify and keep track of requirements. Because they are brief, the overhead is low for creating and updating them when requirements change. Focusing on delivering value, stories are a good basis for prioritising and implementing requirements. Stories in PM2-Agile are referred as Work Units or Work Items and collected in a prioritised Work Items List10. **Business and Enabler Items** Implementing a solution focuses on satisfying the needs identified by the stakeholders. When defining the solution scope and identifying the desired features, the adopted perspective is almost exclusively focused on the business. However, when defining and developing a solution, one must look beyond this business perspective and focus also on the non-business effort that will enable the implementation of the required features. In PM2-Agile, this non-business focused effort is referred as Enablement Work and it includes Architecture, Infrastructure, evaluating options, legal compliance, continuous improvement and other non- functional requirements. ![[4.4 Features and Stories relationship.png]] A Feature that has a business perspective is known as a Business Feature while a Feature that has an enablement perspective is known as an Enabler Feature. Because enablement elements compose the solution to be planned and built, they must be always visible. Although the business and enablement concepts were mentioned as related to features, they also apply to stories. A business perspective story is known as a User Story while an enablement perspective story is known as an Enabler Story. Due to their importance, enabler items must be considered when prioritising the Work Items List (WIL). The Architecture Owner (ArOw) plays a very important role, helping the Product Owner (PrOw) finding the right balance between business and enabler work. Putting the focus exclusively on building business items may yield good initial results. However, the Agile Project Core Team (A-PCT) will struggle to deliver once the lack of a solid architecture becomes obvious and dramatically impacts their velocity. Putting the focus exclusively on building enabler items will produce a robust architecture solution but without delivering the functionalities that users are expecting. For more information about Features and Stories, please refer to the PM2-Agile Tools & Techniques guide.