Gathering and Prioritizing Requirements

Requirements gathering is typically done in groups. It is not recommended that one person define the requirements of a particular part of the system, even if that person is the undisputed authority on the subject. Having varied skill sets in the team is also a plus. In Figure 8-3, the requirements team is responsible for developing most of the requirements artifacts, whereas project management and the architecture team are responsible for prioritizing them.

Figure 8-3. Developing requirements

A requirements team is made up of at least one representative of the user or stakeholder community and a technical member of the development staff. The requirements are, after all, a contract between these two groups, and proper representation of both sides is important. Additional skill sets can complement the team. If the team has been appointed to examine the reporting and data-mining aspects of the system, a database expert should join the team.

The formatting of the documents is not of much concern, but the ability to tag, or identify, each requirement is important. Each specific requirement of the system should have a unique identifier that is used for traceability. The identifier might be something as simple as the chapter, section, and subsection numbers in an outline-formatted document. Requirements management tools provide a unique identifier for each and every requirement in a project and sometimes across projects.

The following example shows what a simplified fragment of a small system's requirements document might look like:

3. Performance Requirements

This section describes the system's performance requirements. These requirements usually relate to the execution speed and capacity of each component of the system.

3.1 Web server performance

The Web server performance section describes the expected performance of the Web server and network of the system.

3.1.1 Each Web server in the system shall be able to handle at least 150 simultaneous user sessions.

3.1.2 The system shall require no more than 3 seconds to retrieve and to respond to a client's request for a static Web page.

3.1.3 The system shall require no more than 8 seconds to respond to a dynamic page.

Note that in this fragment, descriptive text introduces the sections and subsections. A requirements document should be self-explanatory, a document that can be given without additional explanation to any member outside the development team. Each requirement is by default assigned a unique ID. For instance, the "3-second page response" requirement would have an ID of 3.1.2. This ID is part of the traceability of the model. As the process goes on and the system gets designed, each element in the model traces back to at least one requirement. This is a key aspect of the entire process. Each and every element in the model must be able to point to a requirements item to support its existence.

I remember one project in which an engineer on a requirements team introduced a requirement that the system be constructed such that at runtime, additional attributes could be associated with certain entities, such as customers and purchase orders. The idea was that administrators of that system could easily add properties without redesigning or recoding the system.[1]

[1] Yes, this happened on a project I was on. The funny thing is that the architect at the time thought it was a good idea too, and we implemented the system this way. Of course, I can only speculate on the delay, if any, this type of architecture might have caused.

The feature is nice, and the design pretty slick, but the additional development costs were high, and unless it supports one of the system's key features, it should be questioned whether this is a real requirement. This is an example of how requirements get manufactured to support engineering interests, not necessarily business ones.

Later in the process, during design reviews, design model elementsclasses and packagesare checked with the requirements to ensure that they point to at least one requirement and that they really capture the spirit of the requirements they point to. A reviewer might look at the requirement for dynamic entity attributes and compare it to other requirements in the system. Those features and requirements might simply state that the system needs to capture customer demographic information and even explicitly state the information to be captured. The reviewer then must ask, "Is this requirement necessary?"

Of course, it is entirely possible that the designer has realized something that the requirements team has missed. Perhaps the design team's experience in the domain has noted similar situations in the past and has a workable solution. In this situation, discussions between the analysis/design team and the requirements team need to take place. If this feature is desirable and the additional effort to implement it is minimal, the change control process kicks in. This process ensures that the appropriate people or departments are notified and consulted about the pending change. Depending on the scope of the change, this may affect a large number of people, and its impact needs to be examined and scheduled by the project manager.

The requirements fragment mentioned earlier contains some pretty specific knowledge about the architecture. For example, it references Web servers and the use of Web pages explicitly. Unless the use of a Web application was stated elsewhere in the requirements, these sets of Web-specific requirements probably evolved from others or were introduced during a later increment. For example, the usability section in the requirements for the first increment might have mentioned that the user interface response time should be less than 3 seconds. In a later increment, when it was realized that a Web architecture was going to be applied, the requirements might have been refined to include those items specific to Web applications.

Whenever it is determined that Web applications are involved, you will probably find new sets of requirements, especially in the hardware section. Once the architecture has been tentatively settled on a Web application, refinements and additions can be made to the requirements documents. Remember that artifacts in an incremental and iterative development process change, and we have to get used to the idea. The key, of course, is expecting, managing, and minimizing changes.

When writing a requirements statement, you should keep a few things in mind.

• Each requirement should be clear and concise. Avoid wordy descriptions that can be interpreted in a variety of ways.
• A requirements statement should focus on one point. The finer granularity enables better traceability through the model.
• Every requirement must be verifiable. "The UI must be intuitive" cannot be objectively tested and so is not verifiable.

Before the requirements can be used in any downstream phase of the process, they must be prioritized. It would be nice if all the requirements specified in the requirements documents were built into the system exactly as requested, but the realities of software development often force compromises between functionality and time to delivery. By prioritizing a system's requirements, both the stakeholders and the development staff know where it is important to spend valuable effort. Prioritizing also helps resolve conflicting requirements. For example, one requirement of the system might specify that the application must be functional on client computers with only a monochrome 640 x 480 pixel display. Another requirement might be for all invalid field validations to be identified with a red background. Clearly, if the system were used with a monochrome client, invalid fields would never be identified.

The requirements team would probably have made the screen resolution requirement relatively high, since another goal of the system is to leverage existing computing equipment in the organization. Using red to display invalid field values would probably have a lower priority because the use of specific colors in a user interface is often problematic. During the requirements review process, these inconsistencies would be noted. Having them prioritized makes it easier to decide how to handle the conflict.

Most systems can prioritize requirements with a few levels such as low, medium, and high. A high-priority requirement would be a "must-have" requirement. The system would not be functional unless it was met. A medium-priority requirement might mean that it is strongly desired but could be put off until the second release of the product. A low-priority requirement, of course, might mean that it is desired but optional. The system would be functional without it but would be a better system with it. Of course, the definition and number of priority levels vary with each development organization.

Determining the priority structure is not as difficult as determining individual requirement priorities. This part of the process is probably one of the most stressful activities of the process, and some words on human nature need to be said. One can get a rather powerful feeling when defining requirements for a system. With seemingly little effort, our ideas can become pseudoreality. We can see it in our heads, and everything is perfect. These requirements or features of the system, in a subconscious way, become owned by their creators. When it comes time to prioritize the requirements, their creators tend to rate them high, whereas others think otherwise. The psychological battles ensue.

I can remember my first "real" object-oriented (OO) project. We were gathering the requirements for the customer demographics section of the application. The system was to replace an older DOS and file serverbased system. I had suggested that instead of capturing a customer's street address in three separate attributesline 1, line 2, and line 3we could use a multiline edit box. Multiline addresses would be entered in the same control, by just pressing the Enter key to create a second line. From the system's point of view, it was just a single attribute of the Address object that, optionally, had line feeds in it. It caught on with my fellow requirements team members at the time, and we all agreed that the application might be simpler that way. That was my only unique contribution to the team's efforts, and I was prepared to defend it. Eventually, the team reversed the requirement, and we ended up using three separate street address attributes, owing in part to my junior status and in part to other, higher-prioritized requirements for deployment and legacy system compatibility. In retrospect, it was the best outcome for the system, and I learned a little about myself and the politics of requirements.

Even experience alone is not enough to ensure proper prioritization of requirements. In another personal experience, the project manager and the chief architect of a Web-based application had defined two requirements: that all users of the system would use browsers for system access and that there would be a common source code repository across all platforms. These two requirements were prioritized as the two most important ones of the entire system, even over every functional and usability requirement! It became a problem only when applied to the offline component of the system. Part of the system needed to be implemented with laptops and palm-top computers that would be temporarily disconnected from the main Web server. Because being a Web application and having a common source code repository were the top two requirements, a fully functional Web server had to be put on the portable devices. It was another case of envisioning the technology before the full scope of the problem was understood. Despite the arguments of nearly every other member of the development team, these two requirements remained a top priority. In the end, the application was never created. The constraints placed on the development team by these two seemingly laudable requirements meant, in the end, the death of the application.

It is important to objectively prioritize every requirement. If necessary, refer to the original vision statement of the project. Ask how important this requirement is in realizing the original vision of the system. Most requirements of a system are good and should be worked toward; however, tradeoffs often need to be considered: development time, complexity, compatibility, and so on. Requirements need to be weighed against the benefit that they add to the system. For example, one requirement might improve data entry speed significantly but increase the development time and complexity. Look at the vision statement for the project. If it emphasizes or discusses the importance of speeding up the process, it just might be a high-priority requirement. If the vision statement doesn't mention the need for fast data entry, prioritize it lower, and let it become part of the system without endangering other parts.

When dealing with requirements, especially the prioritization of requirements, we need to keep the human factor in mind. A good team is able bring these issues out early, when there is still time to accommodate everyone. Improper prioritization of requirements can lead to disastrous results. Proper prioritization of requirements can mean the difference between meeting or missing the delivery date.