“How do I keep too much design from being embedded in the requirements?” (I heard this question again the day before I wrote these words.)
“When should I baseline my requirements?”
“How can I convince my managers that we need to do a better job on our project requirements?”
“What are some good questions to ask in requirements interviews?”
“Are use cases all I need for documenting the requirements?”
“We can’t get our customers to review the requirements specification. What should I do?”
“What are some good metrics our organization should collect about our requirements?”
“We’re collecting requirements for multiple releases concurrently. How should I store those?”
“How can I use requirements to estimate how long it will take to finish the project?”
“How can I write better requirements?”
Business Requirements
Business requirements represent a kind of “why” information. Business requirements describe why the organization is undertaking the project. They state some benefits that the developing organization or its customers expect to receive from the product. I like to record business requirements in a vision and scope document. Some organizations create a project charter, business case, or marketing requirements document for this purpose.
User Requirements
User requirements constitute one type of “what” information. User requirements describe what the user will be able to do with the product, such as goals or tasks that users must be able to perform. Use cases, scenarios, user stories, and event-response tables are some ways to represent user requirements (Alexander and Maiden 2004; Wiegers 2003a). If you’re developing use cases, you might store them in a use case document. Some analysts prefer to include their use case descriptions in the software requirements specification (SRS).
Functional Requirements
Functional requirements represent another kind of “what” information. They describe what the developer is supposed to build. Sometimes called behavioral requirements, these are the traditional “shall” statements that describe what the system “shall do” or what the system “shall let the user do.” The functional requirements and various other types of requirements information find a home in the software requirements specification. The SRS is the principal deliverable that analysts use to communicate detailed requirements information to developers, testers, and other project stakeholders.
Specifying the correct set of functionality to build into the product enables users to accomplish their tasks or to achieve their goals, thereby satisfying the business requirements.
System Requirements
In this context, system requirements don’t mean the requirements for any old information system. I use the term system requirements (or product requirements) to describe the top-level requirements for a product that contains multiple subsystems. The requirements analyst might derive certain functional requirements directly from an understanding of the high-level requirements for the system as a whole. A system could contain only software components, or it could incorporate both software and hardware subsystems. People are a part of a system, too, so certain system functions might be allocated to human beings. Software requirements, then, represent the portion of a system’s functional and nonfunctional requirements that are allocated to software components of the system.
A good example of a system in this sense is a cashier’s workstation at a supermarket. The workstation includes a bar code scanner, often integrated with a scale. It has a keyboard and one or two displays. There’s a card reader for customer credit or debit cards, and often a change dispenser is included. I’ve seen as many as three printers for customer sales receipts, credit card charge slips, and coupons. These components interact with each other, and each component implements a particular subset of the whole system’s functionality.
People sometimes describe system requirements in the form of product features. I define a feature as a set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective (Wiegers 2003a). Exploring features is a very different perspective from considering user requirements based on user goals. Ideally, the features built into a product will be exactly those that let users perform their known and anticipated activities with the product. Sometimes, though, features are included in a commercial product because of perceived marketplace or competitive demands, not just because of expected usage patterns.
Business Rules
Business rules include corporate policies, government regulations, industry standards (such as accounting practices), and computational algorithms. Business rules are not themselves software requirements. They typically have an existence outside the boundaries of any specific software system and therefore should be regarded as an enterprise-level asset. However, business rules often require that specific functionality be implemented to ensure that the system enforces or complies with those rules. Business rules might restrict who can perform certain use cases, and they can influence quality attributes, such as security. Some business rules might be used to control internal system processing based on specific combinations of data values, system states, conditions, or other user-defined criteria. You can trace the origin of certain functional requirements back to the particular business rule from which it was derived.
Quality Attributes
Quality attributes describe the product’s characteristics in various dimensions that are important either to users or to developers and maintainers. These characteristics include availability, performance, usability, portability, integrity, efficiency, robustness, and many others (Lauesen 2002). Sometimes these characteristics are called quality factors or quality of service requirements.
External Interfaces
External interfaces between the system and the outside world constitute another class of nonfunctional requirements. These encompass interfaces to other software components, to hardware devices, and to human users, as well as communications interfaces and protocols used to exchange information with other systems.
djital
