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 predicated on a completely different assumption. They assume that a clear definition of the project requirements is unlikely to be achieved early in the project. They establish only a broad vision of the product and include regular collaboration of the customer with the technical team throughout the project to work out the details.

The Agile methods are structured to be tolerant of requirements changes, and to encourage change. "Welcome change" is a principle on which these methods are based. The idea is that as the customer and the technical team progress through the project, they will learn about what they are trying to achieve. As a result, that learning will create change. So, change is good! It is a symptom of learning and it means that we are nearer to the best solution than we were before. The Agile methods work best in projects with many unknowns. They were designed to discover the customer's requirements as the project progresses, but they also can make other unknowns more tractable. For example, technical unknowns or business practice uncertainty can be accommodated more comfortably in the Agile methods than in the more traditional approaches.

The One Right Way and When to Use It
The one right way to ensure the quality of the requirements on your project is a simple three-step process:

·       Determine how well the requirements can be known at the beginning of the project. How well does the customer understand their needs? How well can they articulate those needs to the technical team? How likely is it that those requirements (or some other key attribute of the project) will change before the project is complete?

·       Choose a requirements approach that is designed to address the kind of project you are undertaking. Well-understood = PMBOK. Difficult but definable and manageable = CMMI. Unknown or subject to change = Agile.

·       Apply the practices of the chosen approach to yield the most stable and successful project you can achieve.

The requirements of your project need not be an intractable problem. There are methods available to engineer and manage your project requirements, regardless of the nature of your situation and challenges. 

Success in managing projects is a matter of choosing an approach that is suited to your project, then using that approach to its greatest effect. Garbage in equals garbage out, but appropriate requirements methods will being success.

^®PMBOK and Project Management Body of Knowledge are registered trademarks of the Project Management Institute.

^®Capability Maturity Model, CMM, Capability Maturity Model Integration, and CMMI are registered in the U.S. Patent and Trademark Office.