Requirements

A requirements specification is a collection of artifactsdocuments, database records, modelsthat attempt to unambiguously describe a software system to be built. Each document usually includes a description of the document's purpose, version number, contributors, and other administrative information, in addition to a list of specific system requirements. The specification can be a single document for small systems or can be distributed over multiple documents and databases. A system's requirements must always be available to nearly everyone connected to the project. An excellent way to do this is to make them available on an intranet via a Web server. If the application is going to be a Web application, the infrastructure for doing this is probably already in place.

A requirement is a constraint that the system must observe and is typically expressed as a statement that begins with a phrase like "The system shall . . . ." The purpose of a requirements statement is to express a behavior or a property that the system should have. More important than the phrasing, however, is the goal: to express the need for one very specific system behavior, in clear and easy-to-understand language. Requirements need to be understood by the development team and validated by the stakeholder and user community. A difficult-to-understand requirement doesn't help anyone.

One important quality of a good requirements statement is that it can be verified by the testing team when delivered. Only requirements that are objective and have clearly determined pass/fail criteria can be verified. Every requirement has the potential to be verified through a collection of test cases. Each test case formally defines a specific set of inputs, execution conditions, and expected results. A requirement that cannot be verified with a test case doesn't belong in the requirements specification.

In general, requirements can be categorized as either functional or nonfunctional. Functional requirements describe an action that the system should perform. They usually define both the stimulus and the response, or input and output. Functional requirements, the most common type of requirement, identify the things that the system can do, usually in response to external input. Examples of functional requirements are "The system should be able to compute international shipping charges for all products available for sale" or "The system shall automatically produce a summary report of all sales made for each week."

Nonfunctional requirements can be categorized to make them easier to understand and keep track of. Some common requirement categories are

This list is by no means complete. Depending on the system's purpose, other categories might be appropriate as well. With so many categories, it is common for some requirements to naturally fit into more than one category. Because this is the reality for most applications, you should not place too much importance on how any individual requirement item gets categorized. Requirements should stand on their own, and categorizing them is a way to organize them, nothing more. Development team members should make a thorough review of all a system's requirements, even if they haven't been categorized in the area of their specialty.

An additional way to classify requirements is to define attributes that can hold extra information about a requirement, or metainformation. This metainformation can help categorize a requirement, provide an estimate of cost, establish a time frame for development, or even point to a reference source. Most tools for requirements management allow metainformation to be defined for requirements.

Another important property about requirements is their relationships with one another. A requirement, like a feature, is a parent requirement to a set of discrete and detailed requirements. This hierarchy of requirements makes it easier to manage them. For example, if a feature is scoped out of a particular release, all its child requirements can be easily taken out of scope. Of even more use are requirements that depend on other requirements. Before a feature is scoped out of a release, an automated check can ensure that the removal of the feature's requirements will not affect the remaining requirements of the system.

Take as an example one system feature to provide a native XML interface for browsers and use XSL (Extensible Stylesheet Language) for formatting. One of the child requirements is the creation of an XML subsystem and interface to the entity tier. For one reason or another, this feature is scoped out of the next release. The impact analysis, as required by the change management procedures for the project, identifies that another requirement of the systemthe legacy system interfacedepends on the XML subsystem for access to the entity tier. The decision to scope out the XML interface now needs to be reevaluated in light of its other dependencies.

For small projects, most scoping decisions can be made and quickly evaluated. However, as the project team gets larger and the architecture more complex, having a well-structured requirements model is essential to ensuring the integrity of the development project.

It would be nice if it were possible to unambiguously specify a real system completely. In practice, however, some requirements are likely missing, overstated, or even wrong. This stems, in part, from an "impedance mismatch" between the problem spacethe world of the domainand the solution spacethe world of the software system. Whenever you attempt to translate from one language or domain to another, there is always some information loss.

A system's requirements comprise a contract that binds the stakeholders to accept a system that meets the specified criteria and the development team that agrees to build that system. This sounds simple, and it can be. But the realities of software development always lead to changes downstream that affect nearly every aspect of the process and its artifacts. In an iterative and incremental development process, a system's requirements are living artifacts that evolve with the rest of the system artifacts.

Nonetheless, we write requirements expecting and hoping that they will not change. If the requirements team has done a good job, there should be very little change in the requirements of the system throughout the process. In fact, a very important metric of the process is the amount of change made to the requirements. If the requirements change significantly or waffle throughout the process, the requirements-gathering process is in need of some help.

• Usability. Usability requirements refer to those general aspects of the interface between the user and the system. These types of requirements are often related to look-and-feel user interface standards. For example, a common usability requirement defines the maximum number of clicks a user must make to complete a function of the application. Other requirements may constrain the Web page design: "The system interface shall not use HTML frames" or "The system shall be accessible by any browser that is forms capable and supports the use of the
  tag."
• Performance. Performance requirements describe system execution performance and are usually related to time. A common requirement for Web application specifies a maximum load time for a page. For example, "Web pages should not take longer than 15 seconds to load in the browser during normal system usage."
• Robustness/reliability. All mission-critical applications need to clearly state the degree to which the application must be available. Most of these requirements affect only the architecture decisions. It would be nice if we could say that the system needs to be fully functional 24/7/5224 hours a day, 7 days a week, 52 weeks a yearbut building in that level of reliability is costly. What is more likely is a realistic expectation of maximum acceptable down time. It is not unreasonable for most applications to schedule 1 hour a week of down time for maintenance and upgrades. Robustness and reliability are also concerned with backup and storage issues. For example, a requirement of the system might be something like "The system should enable access to data on weekly backup tapes within a 2-hour window."
• Security. Security requirements tend to specify levels of access to the system and often map to human roles of the business. Security requirements should include access to the system by other "external" systems, if used. Security requirements are best described in the context of standard countermeasure mechanisms: access control, authentication, encryption, audit, and intrusion detection.
• Hardware. Hardware requirements often state the minimal hardware required to implement the system. These requirements should address hardware for each tier of the system: client, presentation, entity, and data.
• Deployment. Deployment requirements describe how the application is delivered to the end users. This element constrains how the system is to be installed, maintained, and accessed by maintenance staff. If scalability is important, the deployment requirements should address how hardware is added to running systems.