This part covers the requirements' review process.
The review cycle process approach for organizing requirements:
A few years back we updated our approach for organizing requirements and added review cycles (handshakes) between different stakeholders. To achieve this we differentiated between business, product and technical requirements.
The intent of this method is to organize requirements. This approach doesn’t replace requirements coverage (trace matrix).
The objectives of the review process are the followings:
1. To improve alignment between stakeholders and making sure the entire team understands and agrees on the developed product.
2. It allows the main shareholders to be involved in the process and clarify issues at the beginning of the product development process.
3. It’s an opportunity for the project’s stakeholders to share their comments and ask questions.
In short: let’s discuss the product expectations before we start developing it.
Let’s start by with a short definition for each type of requirement and who are the shareholders I product development. In a nutshell, the Business Requirements detail the business solution describing what the customer needs. This list of requirements includes high-level industrial design (size, color), product price, time to market and a list of countries where this product will be sold. The business requirements are created by the business team (sponsor) based on customer needs.
Example: “The product shall be named "AirForce X42".
The Product requirements describe the usability of the product, form, fit and function. This includes user experience, industrial design, warranty, serviceability (documentation, technical support), regulatory requirements, installation and CoGS (cost of goods sold). The product requirements are developed by the product/program manager.
Example: “The product CoGS shall be $400 or less.
The Technical Requirements include detailed, low-level requirements, by different functional groups. This list of requirements includes electrical engineering, environmental compliance, software and firmware, mechanical, operation, regulatory compliance, reliability, and any other system engineering requirements. The technical requirements are developed by the functional team members.
Example: “The connectors shall be separated by, or have a clearance of, at least 1.00 inch.”
The Shareholders in project development are the people who are invested in the project and will be affected by the project such as the business side (sponsors), the management, the functional managers and the development team. Example for shareholders of a typical review cycle (conducted by the PM): the business team member that represents the customer, the product manager that is assigned to the project, functional manages (Mechanical, Electrical, Software, System…) and the product development team members.
The review cycle:
The review cycle process is the handshake between the different stakeholders, the business team, the product team, and the technical team. As showing in the image below, on step 1- the product team approves the business requirements. On step 2- the business team approves the product requirements. On step 3- the technical team approves the product requirements and on step 4 the product team approves the technical requirements.
This review process approach generates commitment and understanding of what products will be developed to meet customer needs. The best practice is to complete these steps before starting the development phase. Changes/updates after the development stage start require change requests to maintain alignment with stakeholders.
Comments