In a previous blog on Systems Engineering Principles and Practices, I discussed the need for planning analysis and requirements definition. The requirements are the specific who, what, where and when for the product, service or system. With a clear understanding of the systems engineering requirements process, we can demonstrate how this process fits in with our current projects. A Guide to the Project Management Body of Knowledge: (Pmbok Guide,4e)
Figure 1. PMBOK Project Management Process Groups
After reviewing how each of these processes fits into the overall project, we can start to understand where the requirements process fits into the project. As we will demonstrate later, the work on the project cannot begin until the requirements have been defined. The Requirements process is included in the planning for the project and are therefore included in the Planning Process Group.
In addition to the five PMBOK process groups, there are nine specific knowledge areas as shown in Figure 2. When mapping out the Project Management Process Groups and Knowledge Areas, there are 42 project management processes that include everything from developing the project charter to closing the project. The Project Scope Management Knowledge Area includes three processes in the Planning Process Group. One of these processes is Collect Requirements, which is defined as the process of defining and documenting stakeholders’ needs to meet project objectives (PMBOK, 4th Edition). This shows us where the requirements process fits into the overall project and we can now look at the details of the process itself.
Figure 2. PMBOK Knowledge Areas
We all know that we need requirements for the project, but how do we know if we have the correct requirements for the project. The PMBOK defines a requirement as a condition or capability that must be met or possessed by a system, product, service, result or component to satisfy a contract, standard, specification or other formally imposed document (PMBOK, 4th Edition). They go on to say that requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer and other stakeholders. There is some good information here that cannot be overlooked. These requirements need to be met to satisfy something in the contract. On a technical project, these requirements become an important part of the contract. These requirements will be how the project sponsor (customer) ensures that the contract has been met. The technical team may build a spectacular system, but if it does not meet the requirements, the contract has not been complete. This is why the Project Manager will work very closely with the technical team to ensure the requirements processes are followed correctly. They will also oversee the validation of these requirements, work to prevent additional requirements that are not part of the contract and ensure that any necessary changes to the requirements are processed through the applicable change management system.
With an understanding of what requirements are, the next step is to look at why these requirements are so important to the project’s success. Requirements are the basis for every project, defining what the stakeholders – users, customers, suppliers, developers, businesses – in a potential new system need from it, and also what the system must do in order to satisfy that need (Hull, Jackson, Dick, 2011). Stated another way, if the requirements are incorrect, so follows everything else on the project. The requirements ensure that the project team understands the need, or problem to be solved.
When looking at the various aspects to project failure or success, we can see the evidence of the importance of requirements on the overall project. Figure 3 shows the reasons for project failure. This graphic clearly shows that two aspects related to requirements, incomplete requirements and changing requirements, have a considerable impact on the failure for the project. Incomplete requirements account for 13.1% of the reasons for project failure. On the other hand, if we look at the reasons for project success in Figure 4, we see that a clear statement of requirements account for 13% of the project’s success.
Figure 3. Reasons for Project Failure
(Requirements Engineering, 2011)
Figure 4. Reasons for Project Success
(Requirements Engineering, 2011)
The requirements will also drive other aspects of the project. The requirements have a substantial impact to the cost and schedule for the project. The quality management on the project will be directly related to how the system will be tested to verify and validate the deliverables. The requirements can also have an impact to the risk for the project and poorly defined requirements can drive the potential risks for the project beyond the mitigation capabilities of the organization. In extreme cases, bad requirements management can kill a project.
Figure 5. Collect Requirements Inputs, Tools & Techniques, and Outputs
(PMBOK, 4th Edition)
One of the components of the Project Management Plan will be the Requirements Management Plan. This is an output of the Collect Requirements process, along with the Requirements Documentation and the Requirements Traceability Matrix, as shown in Figure 5. The Requirements Management Plan is required to describe the activities, processes, and tools for managing requirements on the project. The plan is necessary to describe the requirements management processes over the system development lifecycle, project or project phase.
We know that poorly defined requirements can have a significantly negative impact on our project, but how do we define “good” requirements. Good requirements define the critical capabilities, characteristics, constraints and quality for the service, product or system. They must be stated in a simple matter and not be ambiguous or have multiple ways of interpreting them. There can be no possible way to introduce objectivity or judgment. The language used to describe the requirement is complete and contains everything that is applicable to that requirement. The requirement must be possible or feasible and it must be technically possible including the cost and schedule constraints. Each requirement for the project must be consistent and not in conflict with the other requirements for the project. Finally, and perhaps most importantly, the requirements must be verifiable. There must be a clear way that the requirement has a way to show it was satisfied as part of the Verify Deliverables process.
Continue Reading – Requirements Part 2
References
- Hull, Elizabeth; Jackson, Ken; Dick, Jeremy (2011) Requirements Engineering
, Third Edition. Published by Springer.
- Institute of Electrical and Electronics Engineers (IEEE) 1220: Standard for Application and Management of the Systems Engineering Process
- International Organization for Standardization (ISO) 15288: Systems and software engineering — System life cycle processes
- Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK Guide) Fourth Edition.
- Systems Engineering Fundamentals (1999) Published by Defense Management College Press.
Edward J. Leydon, MBA, PMP, SPC 
2 thoughts on “Systems Engineering Process – Requirements Part 1”