James Rivera is an IT Director in the telecommunications industry. He has more than 16 years experience as a Business Analyst and Project Manager in the manufacturing and high-tech industries. He has authored requirements engineering courses and taught them in both university and business settings.
Project success—delivering the right product at the right time for the promised cost—is intimately tied to developing a clear agreement about the features and performance of the product or service being produced. Equally important is maintaining agreement on this product vision throughout the project and actually delivering it. The techniques and processes associated with developing this shared product vision and delivering on that promise comprise requirements engineering.
Despite this intimate relationship, requirements engineering is rarely considered within the scope of project management. Rather, it is its own discipline that can be completely understood only in the context of what's being produced. For example, the exact processes and techniques for documenting the desired features and performance of an office building will differ from those associated with developing an accounting software package or a space shuttle.
Certain requirements engineering principles transcend industries, so the framework in this chapter should be useful to everyone. However, since the projects that most consistently suffer from requirements failure are information technology and software development, the examples and techniques in this chapter are directed at these projects.
Requirements engineering is a large topic and the subject of entire books. The goal of this chapter is to introduce readers to the discipline; you'll understand what it is, why it is important, and be able to identify possible steps for improving your requirements engineering activities.
When and where do these two disciplines intersect? In every phase of the project.
At the most basic level, customer satisfaction (or better yet, customer delight) is rooted in producing a product or service that fulfills the customer's purpose in an ideal fashion. Although we've previously stated that the quality component of the triple constraints is defined by requirements, in truth, the cost and schedule elements are also a function of completely understanding the customer's ideal project outcome. Requirements form a key component of a project proposal because they describe the ideal outcome of the project and because they drive the project scope. To the extent that requirements are uncertain or to be determined, the cost and schedule estimates lose their accuracy.
It seems more than obvious that the project stakeholders must have agreement on the requirements if the project is to be a success. Consequently, one could assume there would be an intense focus by all involved to accurately document and manage requirements and that cursory attention to requirements, vague requirements, or undocumented requirements would be as rare as rain in the desert. Unfortunately, that is not true. The incidence of project failure that is directly related to failed requirements engineering is staggering. In fact, it's safe to say that every person who has worked on projects for more than a few years has personally experienced the pain of requirements failures. And how painful that can be! At a minimum, discovering that requirements were incorrectly understood causes rework. It can take 10 to 1, 000 times as much effort to fix a problem as it would have taken to accurately understand the requirement![52] Here are a few more examples of the pain of requirements failure:
According to Dean Leffingwell, "As much as 75% to 85% of overall project rework costs can be directly attributed to requirements errors."[53]
Poorly defined or poorly managed requirements make it difficult to fully satisfy the original product intentions and result in a product that sacrifices product features and quality in an attempt to deliver on time and within budget. According to the 1995 Standish CHAOS report, "For challenged projects, more than a quarter were completed with only 25% to 49% of originally specified features and functions. On average, only 61% of originally specified features and functions were available on these projects."
Tip
The Business Analyst Plays a Key Role
Who is responsible for interacting with customers and other stakeholders to extract and document requirements? This key role is filled in different ways depending on the kind of project. For residential and commercial construction, architects fulfill this role. For software and information technology projects, an old role is gaining new attention: the business analyst. Proof of this is the newly formed International Institute for Business Analysis (IIBA). Formed in 2003, the IIBA provides a focal point for developing standards for gathering, documenting, and managing requirements for software development and IT projects. Every project manager would do well to make sure whoever fulfills this key role is experienced and understands his or her own industry's best practices for requirements engineering.
It is appropriate at this point to more precisely define requirement. This term itself has been defined in many ways, but the IIBA definition should suit any project (IIBA 1.6, p. 9). A requirement is:
A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
A documented representation of a condition or capability as in (1) or (2).
Requirements form as the vision for the product evolves from an abstract understanding of a problem or an opportunity to a specific feature set. At each stage of evolution, the requirements serve a different purpose and can take a different form. Figure 16.1 illustrates this evolution. The product development process should contain methods for documenting each of the following types of requirements.
Enterprise Requirements
Also known as business requirements or mission requirements, these requirements form the justification for the project and are included in the project proposal. They describe the problem being solved and the difference between the current state and the desired future state. For example, why even have a space shuttle? What services do we expect it to perform for us? If a kitchenware retail store wants to change the way it manages inventory, what new inventory management capabilities do the owners want?
Enterprise requirements are necessarily too high a level and too abstract for building a specific product. Their purpose is to establish the ultimate goals for the product: If the project teams can meet these requirements, then the product will have succeeded. They form the what; subsequent requirements will establish the how. Notice that in the product evolution process in Figure 16.1, the enterprise requirements form the basis for evaluating possible solutions to the original problem or opportunity.
User Requirements
User requirements describe the solution from the perspective of the end user. User requirements document everyday tasks performed by the end user as features to be provided by the solution. For example, an online course registration system at a community college might include the features "register for class" and "manage student grades," among others.
A common method for documenting user requirements is use case specification. Use cases are effective in documenting user tasks because they use a natural language style to describe the user tasks as a series of steps performed in reaching a prescribed goal. When effectively written, a use case linguistically simulates the user performing a task and allows the end user to experience successfully achieving a desired goal by reading the use case.
Functional Requirements
Functional requirements describe the solution from the perspective of the system. Functional requirements are documented as capabilities the system is required to provide to allow the user to perform a user task. For example, the feature for course registration may have the following functions: login, search, add course, delete course, copy course, submit payment, logout. Unlike user requirements that are written in a natural language, functional requirements are written in the form of declarative statements. Also, functional requirements are not written in a conversational form like user requirements; instead, functional requirements are written like a list of demands. For example, a comparison of user requirements to functional requirements can be seen in Table 16.1.
Table 16.1. USER REQUIREMENTS COMPARED TO FUNCTIONAL REQUIREMENTS
Use Case Statement (User Requirement) | Declarative Statement (Functional Requirement) |
|---|---|
The system provides the student the option to create a new schedule, modify a schedule, copy a schedule, and delete a schedule. The student chooses to create a new schedule. | The system must allow the user to create an existing schedule. The system must allow the user to modify an existing schedule. The system must allow the user to copy an existing schedule. The system must allow the user to delete an existing schedule. |
Requirements engineering can generally be broken into two major groups of activities: requirements development and requirements management. Table 16.2 places these activities in the context of product development phases. The simple product development life cycle we introduced in Chapter 2 used four phases: requirements, design, construct, and operate. (As we noted in Chapter 2, this model represents a high level of abstraction—and would be broken into more specific phases for many kinds of product development effort.) That simplistic view of a development life cycle rightly begins with a focus on requirements. Table 16.2, however, points out how requirements engineering activities continue to drive development all the way through product acceptance.
The linear product development model shown in Table 16.2 is applied on some IT projects, but many others have evolved to iterative development methodologies. These methods don't assume that all requirements can be known up front, before design commences. Rather, they repeat the cycle of requirements-design-construct over and over, discovering new requirements as they develop the architecture and features of the new product. Using iterative development methods does not mean requirements engineering won't work—in fact, it makes it all the more challenging because new requirements are added over and over again.
Table 16.2. REQUIREMENTS ENGINEERING ACTIVITIES IN THE PRODUCT DEVELOPMENT LIFE CYCLE
Product Development Phase | ||||
|---|---|---|---|---|
Requirements | Design | Construct | Operate | |
Requirements development activities |
|
|
| |
Requirements management activities |
|
|
|
|
The reason requirements failures occur is that the process of gathering requirements is complicated by several factors:
Requirements are not known by the end user or the customer. The project team (more specifically, the business analyst) may be asking for information the user just doesn't have or hasn't considered.
There is not agreement on the proper way to document requirements, so it is easier to just charge ahead, designing and building the "obvious" product.
Generating and documenting requirements is hard work, expensive, abstract, and just doesn't feel like progress to some people. It's tempting to get on with the "real work" of building the product.
In requirements engineering, change is the only constant. Changing requirements are a way of life, and many organizations are not equipped to deal with this frequent need for realignment of product vision with business needs.
Software is inherently intangible, immaterial, and very difficult to conceptualize in a written form.
Breaking down the process of requirements development will shed light on how to overcome some of these challenges.
Elicitation: Collecting information
Customers live in a "symptomatic world" and sometimes cannot distinguish between the symptoms of the perceived issues and the real cause of their pain. As a result, elicitation can be more art than science, demanding business analysts to be adept at wading through the white noise to get to the nuggets of requirements.
Elicitation includes identifying sources of requirements and collecting requirements information from project stakeholders. During elicitation, the business analyst discovers and collects information from multiple sources and includes stakeholder needs, user requirements, constraints, risks, performance goals, and success criteria.
The most common techniques for requirements elicitation range from one-on-one interviews to group elicitation sessions such as joint application development (JAD) workshops and focus groups. Other techniques rely on existing sources such as benchmarks of existing processes or products, observing users performing real-time business tasks, or reviewing existing documentation.
Analysis: Transforming Information into Requirements
Analysis is a process that involves studying, examining, investigating, and dissecting the elicitation results to discern the true requirements. To perform this analysis, the business analyst must be skilled in abstract thinking, problem solving, communication, and data analysis. Modeling plays a key role in analysis.
Modeling techniques visually represent and analyze the requirements and become the means of communicating abstract ideas in a concrete form. Modeling includes process flow diagrams for mapping existing processes and identifying potential gaps and bottlenecks, system diagramming to visually represent the interfaces between people and systems and capture the information that flows between them, and data flow diagrams to visually translate information flow into its component data parts.
Specification: Documentation for Communicating and Managing Requirements
Specification produces the requirements in a format that enables stakeholders to review, modify, and approve them. The precise format of the specification varies depending on the purpose and audience (i.e., user requirements take a different form than enterprise requirements).
Validation and Verification: Did We Build the Right Thing and Did We Build the Thing Right?
Well-written requirements provide the basis for testing whether the product was correctly built. But how do we test the requirements? Validation and verification are the terms we use for making sure the requirements are correct and that the product meets requirements.
Validation is primarily focused on ensuring the requirements deliverables are correct and complete. During the requirements analysis phase the requirements are reviewed with the stakeholders using a static review process such as an inspection, walk-through, or ad hoc review. Several dynamic approaches to validating (during the requirements analysis phase) are prototyping, demonstrations, or conducting a pilot—which validate the requirements against a product simulation or partially functioning product.
Verification is primarily focused on ensuring that the product was built correctly and is functioning as designed. Verification is typically performed during the construction phase through testing. These activities are typically performed by the analyst, designers, developers, and testers.
Once a common vision for the product has been established, the work transitions to maintaining that vision and ensuring that downstream work is performed in accordance with that vision. For example, despite everyone's best efforts to get it right the first time, the requirements will change. As that happens, it's necessary to know how those changes will affect other requirements or previous design decisions. (In Chapter 11 we referred to this as change management and configuration management.) In addition, the product design process and the product acceptance process must include methods for ensuring that all requirements have been met.
Requirements management activities are most successful when they are intentional and consistent—planned in advance and performed systematically following organizational standards. If every project team is required to invent its own requirements management processes, none will ever reach maturity. The three examples that follow demonstrate how much energy and discipline it takes to manage requirements.
Baseline Requirements and Manage Changes
A baseline is a snapshot of the set of requirements documentation at a specific point in time for a given solution. For a baseline to be valid, the requirements artifacts must be verified as accurate and complete, approved by all stakeholders, and placed under version control in a requirements repository. An example set of requirements artifacts for a software project includes use cases, software requirements specifications, infrastructure requirements specifications, application designs, infrastructure designs, test cases, project schedule, change requests, and user documentation.
Managing change means maintaining a stable and consistent baseline over time. To achieve this, the business analysts must consistently monitor the product's progress against the baseline and proactively determine when change has occurred. For any product, there may be more than one baseline, each representing a particular stage of product development.
As mentioned earlier, a common practice in software engineering is iterative development, where multiple phases of the project progress simultaneously. While the developers are coding the application for release one requirements, the architects are completing the design specifications for release two. This approach requires very disciplined processes for creating and managing stable baselines, because it is expected that frequent change will occur.
Traceability enables the team to assess the impact of a change against the baseline. It means that we should be able to trace every requirement to design elements, to test cases, to other requirements, and to the code that produces the feature fulfilling the requirement. Traceability is important because changes from defects, scope reductions, or enhancement requests have a ripple effect and typically require updates to one or more dependent requirement artifacts. For example, adding a new type of acceptable payment method to an online bookstore requires updated use cases, interface diagrams, design specifications, user documentation, test cases, and schedule. Traceability examines the baseline and identifies these dependencies as "links" between the requirements artifacts.
In traceability, the baseline is tracked in a requirements database, and these links are documented as attributes assigned to each requirement artifact. The links between requirements are complex, many-to-many relationships and represent a web; therefore, managing the traceability links becomes even more challenging as the project experiences frequent change. Requirements management software is designed to keep track of these myriad relationships and is essential on large projects.
Manage Requirements Performance
To manage the requirements engineering process requires effective measurement, and a common measure is requirements stability. Requirements stability measures requirements change over time and how frequently the baseline is updated. Requirements stability assumes that a certain variance is acceptable on a periodic basis. For example, in a requirements baseline with 100 requirements artifacts, it is acceptable to have five (5) requirements added, removed, or changed on a weekly basis.
Monitoring requirements stability provides an early warning mechanism, revealing problems with the initial requirements gathering and documenting processes. Unstable conditions are an indication that the quality of the final product may be in jeopardy. This is just one example of establishing metrics for managing the requirements process.
Since the very first computer programs were written, users have complained that the results have not met requirements. As a result, many different requirements documentation techniques have been proposed. Some have caught on and matured. All reflect the challenge of trying to document the detailed rules and logic that describe an activity that will eventually be performed by a computer.
There are such a variety of requirements documentation techniques that introducing them is beyond the scope of this chapter. However, it must be emphasized that a common characteristic of any technique is the blending of graphic models to illustrate the relationships of system components and detailed text to describe the rules for a specific component. These graphics and text combine to create complex models that represent proposed systems. It takes education and practice to effectively apply these techniques.
This chapter has provided an overview of the discipline of requirements engineering. It should be clear by now that having a thorough understanding of requirements is essential and far from easy to accomplish. Here are some first steps for getting serious about this discipline:
- Train business analysts.
Good business analysts understand the software development process, can use modeling techniques to lead a group to solve business problems, and can communicate effectively with end users and developers. They can write test cases, establish traceability systems, and document, baseline, and manage changes to requirements. These are all skills that are developed through training and practice. Business analyst is every bit as much a profession and skill set as is project management.
- Formalize requirements engineering.
Techniques like process modeling, use cases, and context diagrams exist in a variety of forms. That means every firm needs to standardize a specific set of modeling techniques. Further, distinguishing between enterprise requirements, user requirements, and functional requirements requires using a consistent format for documenting these as well. Review Table 16.2 and realize there are many processes and techniques that provide an opportunity for standardization.
- Match the requirements techniques to your development approach.
The classic waterfall system development life cycle is still appropriate on some kinds of projects. But other development methods are equally appropriate and well established, namely, incremental and iterative methods. Each of these approaches changes the requirements-design-code relationship, which means the methods of requirements elicitation, documentation, and requirements management change as well. Recognizing that requirements techniques should change depending on the development approach is consistent with our assertion at the beginning of this chapter:
Requirements engineering is necessary no matter what is being built—buildings, telephones, highways, or software—and the methods for documenting requirements are driven by the product being built.
- Consider automating requirements management.
Generating and tracking requirements means managing lots of detailed information. Software applications designed for requirements engineering improve the integrity of the requirements. These products are databases designed specifically for managing requirements. They encourage consistency in recording the requirements, and they make it possible to establish traceability and monitor stability. Without a requirements management application, the activities associated with baselining and tracking requirements become far too complex for all but the simplest projects.
Project success means delivering the right product when the customer expects it and for the promised cost. Delivering the right product relies on the project team and the customer having a clear, common vision of that product. Requirements engineering is the discipline that provides the techniques and processes for discerning and documenting the product vision, and then managing the updates and changes to that vision as it is built.
Requirements engineering complements project management; both are necessary to develop solid estimates and to manage changes. Every project, no matter what industry, must have a reliable process for understanding requirements and integrating those requirements into the product development process.
Information technology and software development projects have been particularly challenged with establishing and managing requirements. These projects too often have requirements that are difficult to discern, and their complexity is difficult to manage. Many methods have been developed to address this challenge, including software development approaches that allow for discovery of requirements as the software is developed. All of these techniques have one thing in common: They require disciplined practice.