Requirements are (or should be) the foundation for every project. Put most simply, a requirement is a need. This problem, this need, leads to the requirements, and everything else in the project builds off these business requirements.

Importance of Requirements

Requirements are considered by many experts to be the major non-management, non-business reason projects don't achieve the "magic triangle" of on-time, on-budget and high quality. Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies, have shown that requirements are the biggest problem in projects. Projects fail due to requirements problems. The most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality software on-time and on-budget.

Furthermore, requirements errors compound as you move through a project. The earlier requirements problems are found, the less expensive they are to fix. Therefore, the best time to fix them is right when you are involved with gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The hardest requirements problems to fix are those that are omitted. This really becomes the requirements analyst's dilemma. The analyst often doesn't know what questions to ask, and the stakeholder doesn't know what information the analyst needs. Since the analyst doesn't ask, the stakeholder doesn't state requirements.

The requirements phase is also considered by many experts to be the most difficult part of any project due to the following:

• The requirements phase is where business meets (IT) information technology.
• Business people and IT people tend to speak different "languages."
• Business: "It has been determined that if we convolute the thingamajig or maybe retroactive the thatamathing, our profitability may, if we are extremely lucky, rise beyond the stratospheric atomic fundermuldering."

In other words, English is an ambiguous language, and we tend to speak and write in a manner that makes it even more ambiguous, convoluted and unclear.

Building Valid Requirements

The requirements analyst truly is responsible for the failure or success of the requirements on a project. With that at stake, building valid requirements up front is crucial. The four steps to this goal are: elicitation, analysis, specification and validation.

Elicitation

The term elicitation is the industry-accepted term for getting the requirements from the stakeholders. Elicitation, however, implies much more than just capturing or gathering the requirements from users.

The truth is, one of the surest ways to fail in requirements is to say to your users, "Give me your requirements," then stand back and "catch" them.

Why doesn't this work? The stakeholders are experts in their domains. While the analyst probably has more expertise in the IT domain, the two speak different languages. The stakeholders truly don't understand exactly what IT needs to be able to develop an effective system for them.

So the only way for a project to obtain comprehensive, correct and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them.

The reality is that the quality of the requirements depends on the quality of the solicitation of them by the analysts.

Analysis

Analysis involves refining (or analyzing) the stakeholder requirements into system, then software requirements. Analysis is a critical step, which is too often omitted or bypassed in projects.

Analysis is the important transition from stakeholder or business terminology, to system or IT terminology. For example, stakeholders talk about "Monthly Marketing Report," while systems talk about file "MoMktRpt.doc."

Analysis involves brainwork, but it isn't a magic process (nor is any other part of software engineering, for that matter). Analysis is usually done in conjunction with various modeling techniques. Modeling --creating diagrams using standard notations -- allows analysts to more fully understand processes and data in a rigorous manner. This understanding allows them to convert the often non-rigid stakeholder requirements into more concise, rigid system and software requirements.

Common modeling techniques include the following:

• Traditional systems
• Dataflow diagrams to understand processes and activities
• Entity-relationship diagrams to understand data
• Object-oriented systems:
• UML (Unified Modeling Language) diagrams, especially class diagrams for analysis, but also possibly collaboration diagrams

Specification

The specification sub-phase involves documenting the requirements into a well-formatted, well-organized document. Numerous resources are available to help with writing and formatting good requirements and good documents. For general writing assistance, books on technical (not general) writing should be used. A major resource is the set of IEEE Software Engineering Standards.

Validation

Once a requirements specification is completed in draft form, it must be reviewed both by peers of the author and by the project stakeholders in most cases. If detailed stakeholder requirements were written and signed off by the stakeholders, they may not need to participate in reviews of more technical system and software requirements. This presumes good traceability matrices are in place.

The specifications are reviewed by a group of people to ensure technical correctness, completeness and various other things. Often checklists are used to ensure all requirements in all possible categories have been elicited and documented correctly.

Validation is actually a quality assurance topic. All documents produced throughout a project should undergo validation reviews.

This information was drawn from Global Knowledge's Requirements Development and Management course. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training.

Copyright © Global Knowledge Training LLC. All rights reserved

David Egan, PMP, is a Global Knowledge instructor who has spent 20 years in the IT industry. A management consultant to many Fortune 500 companies his background spans all areas of industry and government. David holds an MBA from McGill University as well as MCSE, MCT, and RHCX certification.