Chapter 9: Managing Systems Requirements
Polly Perryman Kuver
OVERVIEW
Requirements management is composed of four major activities: capturing the requirements, organizing them, reviewing them, and controlling them. Each of these activities provides benefits to both the customer and developer in ensuring the project is moving in the right direction. All of these activities occur in conjunction with the requirement definition and analysis phase of the software development life cycle (SDLC). This includes establishing and implementing a process for maintaining control of the requirements for the remainder of the SDLC.
The working definition of each of the four activities in this section provides a starting place for understanding requirements management. Further sections of this chapter present a more detailed discussion of each of the activities.
Capturing Requirements
To take a product from concept to reality, the expertise and desires of the client are conveyed to the system analyst. The system analyst in turn must assess the information in relationship to the desired technology and then prepare a feasible customer and developer plan for product development. The feasibility plan is used as the basis for discussions. The requirements are the output product from these discussions wherein the customer and development experts expose the must have vs.
the it would be nice to have items while considering the available schedule and budget.
Organizing Requirements
Organizing the requirements by project, system, and subsystem gives both the customer and the developer clear requirements that should be tracked during the development effort. Organizing the requirements in this manner supports simultaneous development work in multiple functional areas, which increases productivity and improves quality. Organizing requirements within these classifications additionally ensures that potential risks to the project can be identified and assigned more easily to the right people, ensuring that viable mitigation of the risks are planned. Organizing the requirements by project, system, and subsystem also helps control change, provides a better definition of what must be tested, and makes sure necessary functionality does not fall through the cracks.
Reviewing Requirements
It is important that the requirements be reviewed by the right personnel to ensure that all of the necessary items have been included and planned for development.
When the requirements are organized, the selection of review groups is easier and the review will be better because the right people are assigned to evaluate and approve the requirements. It is during the review of the requirements that the
customer gains significant insight as to the developer’
s true understanding of the
properties the product must possess to ensure success in the marketplace. Skewed perceptions can be corrected at minimal cost at this point in the project.
Controlling Requirements
Once the initial set of requirements has been evaluated and approved, the course of action for moving the project to completion can be planned meaningfully. Impacts to the project plan are minimized by controlling changes to the requirements. The value in controlling changes to the requirements is that the project stays on course, thereby reducing or eliminating cost overruns and schedule delays. The other significant benefit occurs as the system is tested because everyone who has been involved in the project has been able to understand what requirements will be tested and what the product will have, do, and use. In other words, the boundaries established by the requirements can be used to measure the success of the development effort.
CAPTURING REQUIREMENTS
In March 1996, Frank McGrath addressed the problem of capturing requirements at a meeting of the Project Management Association in Tysons Corner, Virginia. In summary, McGrath pointed to the software community as being simply arrogant in starting development work without having requirements nailed. By example, he pointed to the building trades. What general contractor would start construction of a building with a requirement that states, “It will be a big building with offices inside?”
What does that mean? What is the requirement for a manufacturing plant in which airplanes will be made or a skyscraper where many businesses will reside?
McGrath continued using the general contractor example, pointing to the fact that the general contractor finds out not only what type of building, but also what materials need to be used in the construction of the building. The general contractor then finds out what tolerances are needed in the materials and so on and so forth.
Given some thought, it is easy to see how important clarifications are in defining requirements in the building trades. They are no less important in the software business, but all too often software developers wrongly feel that they deal in the creative zone where it is far more difficult to articulate and capture requirements effectively.
It may not be as hard as it seems. Software developers must first remember that they are capturing people’
s dreams, not what they need — though they may need it
— not what they want — though they may want it. Software developers are capturing their dreams, their true desires. In this respect it is very personal for each person participating in the requirements definition process. They may argue over minor points and fail to communicate what is going on in their mind. A leader of the requirements definition process can overcome this by:
1. Conducting regularly scheduled meetings with a previously distributed agenda so that the right people attend and the attendees know what will be covered and what is expected of them.
2. Structuring each meeting to ensure that previously identified requirements are documented for review and analysis, allowing new requireme nts to be submitted and recorded for review at a future meeting and making sure that requirements that are out-of-scope for a specific project or release of a project are identified and tabled.
3. Making sure that each person at the meeting has an opportunity to speak and be heard without criticism or fear of being laughed at or made to feel dumb or stupid.
4. Spending time to make certain the information communicated as a requirement is meaningful; that is, make sure everyone understands that the big building is a tall skyscraper and not a warehouse or a manufacturing plant.
Although it may appear that a significant effort is being spent to capture and review requirements, there is a big pay-back if the requirements are identified correctly up front. The cost of correcting software for missing or incorrect requirements goes up significantly the later in the development process the error is found.
These unattractive and very costly statistics can be brought down significantly when the ambiguities common enough to everyday conversation and exaggerated by the separate areas of expertise brought to the table by the customer and the developers are eliminated. Use the helpful hints and techniques proven over time by software professionals such as Donald Gause and Gerald Weinberg, who are noted in the field of requirements definition. The result will be a negotiated understanding of the customer’
s desire and a certainty that everyone involved in the project is working toward completion of the same system. Start by removing ambiguities at the statement level.
Clarifying Ambiguous Requirements
Ambiguity at the statement level is tested through verbalization of visualizations. For example, if the requirement is to build a structure to protect a human against wind and rain and snow and ice is given to five people, each of the five people may have a different visualization. One might visualize a kiosk at a bus station, another a three-bedroom ranch house, and someone else a nice shiny Rolls Royce. As people at the meeting explain their visual image of what has been stated, clarification can be made, and agreement can be reached.
So, how does one visualize the following requirement statement: The user will be able to store one or more windows in a scrapbook, and how does one express that vision. The visualization here may not be as obvious, but one certainly would want to know if anyone around the conference table is getting the impression that they will be able to store windows into a scrapbook the way files can be stored in directories for indefinite periods of time. So, test the statement:
§ What is the customer interpreting the statement to mean?
§ What does the developer intend the capability, i.e., a brief functional description of what will be implemented to satisfy the requirement, to be?
§ What are the system requirements, i.e., How many windows will be stored?
How long are they required to be stored? What are the retrieval time requirements for different types of storage?
Document the negotiated understanding that is reached between the customer and the developers regarding the requirement(s) and how it (they) will be implemented.
At the word level, use synonyms and comparisons to clarify and ensure the correct interpretation of what is being said. For example, if the requirement is initially stated as:
A big clock will be displayed …
It should be restated as:
A large clock will be displayed …
Start by using the synonym large for the word big. Then, clarify the use of the word large again using a specific comparison, i.e., does large mean it fills the entire screen or just half of the screen? Finally, restate the requirement to spell out the specific size or range of sizes to which the customer and the developers have agreed. In this way, the understanding by both the customer and the developer are consistent.