Many authorities have undertaken to lay out the one right way to engineer system requirements. Although there are similarities among them, what is most striking is the diversity in approaches and, in some cases, conflicting philosophies. What are we to make of these dueling authorities and their competing guidelines?
Don't Expect There Is One Right Way!
Many authorities have undertaken to lay out the one right way to engineer system requirements. Though there are similarities among them, what is most striking is the diversity in approaches, and in some cases, conflicting philosophies. What are we to make of these dueling authorities and their competing guidelines?
Each of the approaches has supporters and adherents because each works (at least in specific circumstances). From this, we can derive our most important lesson about requirements engineering; that there is not one right way to engineer requirements.
The one right way to achieve high-quality requirements is to start by identifying the requirements challenges that you will face on the specific project and then choose the technique that best addresses those specific challenges. In this column, we will explore three representative approaches: PMBOK ® , the CMMI ®, and the Agile.
The PMBOK Approach and When to Use It
The project management body of knowledge (PMBOK) doesn't really talk about requirements. It begins with project scope management and talks about agreeing with the customer about boundaries. This includes both the boundaries around project activities and around the product that will be produced. It then continues with scope management by ensuring that project changes do not affect scope, and by performing explicit change management when project scope is affected. This approach is predicated on the assumption that the customer has a clear understanding of his or her needs and is able to articulate those needs to the project team. It goes on to assume that when scope-related conflicts occur, resolving them is a matter of reconciling the perspectives of the project's key stakeholders.
When embarking on a project with a well-versed customer who is willing and able to fully articulate the project requirements, the PMBOK approach can work quite well.
The CMMI Approach and When to Use It
The capability maturity model integration (CMMI), being a model of engineering practices, focuses more fully than the PMBOK on requirements. Indeed, it is not so much different from the PMBOK approach as it is an expansion of it. This is natural, as the requirements for engineering projects tend not to be straightforward or easy to manage. The CMMI approach is predicated on the assumption that carefully orchestrated activities with the customer are necessary to uncover and formalize all of the nuances of their requirements.
The CMMI includes process areas (PA) for both requirements engineering (RE) and requirements management (RM). The RE process area assumes that the customer will need help in fully articulating their requirements. For this reason it includes a variety of practices designed to help the customer and technical team to collaboratively converge on a clear and complete statement of requirements. In spite of the challenges in defining requirements, CMMI assumes that a relatively complete and accurate set of requirements can be achieved early in the project. The RM process area expects that as the project moves forward, changes to the requirements could be necessary. In addition to actively managing the project requirements, RM also includes practices for controlling change and incorporating changes into the project.
In engineering projects, or any other projects in which the complete requirements are not immediately apparent but can be determined and in which requirements changes are likely, the CMMI's approach can make sense. It involves a significant up-front investment of time and effort in an attempt to achieve better stability as the project moves forward.
The Agile Approach and When to Use It
The Agile methods (eXtreme Programming or XP, and Scrum, among others) are