Software Requirements by K.Wiegers, J.Beatty, 3rd edition, 2013

TABLE 1-1 Some types of requirements information

• Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.
  
• Term Definition Business requirement A high-level business objective of the organization that builds a product or of a customer who procures it. Business rule A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements. Constraint A restriction that is imposed on the choices available to the developer for the design and construction of a product. External interface requirement A description of a connection between a software system and a user, another software system, or a hardware device. Feature One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. Functional requirement A description of a behavior that a system will exhibit under specific conditions. Nonfunctional requirement A description of a property or characteristic that a system must exhibit or a constraint that it must respect. Quality attribute A kind of nonfunctional requirement that describes a service or performance characteristic of a product. System requirement A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware. User requirement A goal or task that specific classes of users must or a desired product attribute.
  
• FIGURE 1-1 Relationships among several types of requirements information. Solid arrows mean “are stored in”; dotted arrows mean “are the origin of” or “influence.”
  
  
• Business requirements describe why the organization is implementing the system—the business benefits the organization hopes to achieve.
  
• We like to record the business requirements in a vision and scope document.
  
• User requirements describe goals or tasks the users must be able to perform with the product that will provide value to someone. The domain of user requirements also includes descriptions of product attributes or characteristics that are important to user satisfaction. Ways to represent user requirements include use cases (Kulak and Guiney 2004), user stories (Cohn 2004), and event-response tables.
  
• Functional requirements specify the behaviors the product will exhibit under specific conditions. They describe what the developers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements.
  
• The business analyst (BA)1 documents functional requirements in a software requirements specification (SRS), which describes as fully as necessary the expected behavior of the software system.
  
• System requirements describe the requirements for a product that is composed of multiple components or subsystems (ISO/IEC/IEEE 2011).
  
• Business rules include corporate policies, government regulations, industry standards, and computational algorithms.
  
• Sometimes, as with corporate security policies, business rules are the origin of specific quality attributes that are then implemented in functionality.
  
• Other classes of nonfunctional requirements describe external interfaces between the system and the outside world.
  
• Other-than-functional requirements might specify not what the system does, but rather how well it does those things.
  
• Other-than-functional requirements might specify not what the system does, but rather how well it does those things.
  
• Some people consider nonfunctional requirements to be synonymous with quality attributes, but that is overly restrictive. For example, design and implementation constraints are also nonfunctional requirements, as are external interface requirements.
  
• A feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. A customer’s list of desired product features is not equivalent to a description of the user’s task-related needs. Web browser bookmarks, spelling checkers, the ability to define a custom workout program for a piece of exercise equipment, and automatic virus signature updating in an anti-malware product are examples of features. A feature can encompass multiple user requirements, each of which implies that certain functional requirements must be implemented to allow the user to perform the task described by each user requirement.
  
• FIGURE 1-2 Relationships among features, user requirements, and functional requirements.
  
  
• To illustrate some of these various kinds of requirements, consider a project to develop the next version of a text editor program. A business requirement might be “Increase non-US sales by 25 percent within 6 months.” Marketing realizes that the competitive products only have English-language spelling checkers, so they decide that the new version will include a multilanguage spelling checker feature. Corresponding user requirements might include tasks such as “Select language for spelling checker,” “Find spelling errors,” and “Add a word to a dictionary.” The spelling checker has many individual functional requirements, which deal with operations such as highlighting misspelled words, autocorrect, displaying suggested replacements, and globally replacing misspelled words with corrected words. Usability requirements specify how the software is to be localized for use with specific languages and character sets.
  
• FIGURE 1-3 An example of how different stakeholders participate in requirements development.
  
  
• Figure 1-1, shown earlier in this chapter, identified three major requirements deliverables: a vision and scope document, a user requirements document, and a software requirements specification.
  

FIGURE 2-1 Frequent customer engagement reduces the expectation gap.

FIGURE 2-2 Potential stakeholders within the project team, within the developing organization, and outside the organization.

TABLE 3-1 Requirements engineering good practices

FIGURE 3-1 Requirements development is an iterative process.

TABLE 3-2 Implementing requirements engineering good practices

The business analyst is the individual who has the primary responsibility to elicit, analyze, document, and validate the needs of the project stakeholders. The analyst serves as the principal interpreter through which requirements flow between the customer community and the software development team, as shown in Figure 4-1. Many other communication pathways also are used, so the analyst isn’t solely responsible for information exchange on the project. The BA plays a central role in collecting and disseminating product information, whereas the project manager takes the lead in communicating project information.