What, Why, Who, When, and How of Software Requirements

What

Requirements are the agreement between the supplier of the software and its customers, users, and other stakeholders about capabilities and attributes of the software product. The requirements define the “what” of a software product:

• •

  What the software must do to add value or utility for its stakeholders. These functional requirements define the capabilities of the software product.

• •

  What the software must be to add value for its stakeholders. These quality attributes and nonfunctional requirements define the characteristics, properties, or qualities that the software product must possess. They also define how well the product performs its functions.

• •

  What limitations there are on the choices that developers have when implementing the software. The external interface definitions and other design constraints define these limitations.

Types of Requirements: Most software practitioners just talk about “the requirements”. However, by recognizing that there are different levels and types of requirements, as illustrated in Figure 1, we can gain a better understanding of what information we need to elicit, analyze, specify, and validate when we define our software requirements.

Figure 1.

Levels and types of requirements

Business Requirements define the business problems to be solved or the business opportunities to be addressed by the software product. In general, the business requirements define why the software product is being developed. Business requirements are typically stated in terms of the objectives of the customer or organization requesting the development of the software. For example, a business requirement for an automated gas station system might state “Drivers can pay for their gas purchases at the pump without interaction with the Gas Station Attendant”.

Stakeholder Requirements look at the functionality of the software product from the stakeholder’s perspective. They define what the software has to do in order for the users and other stakeholders to accomplish their objectives (or in the case of “unfriendly” stakeholders, such as hackers, to keep them from accomplishing their objectives). Multiple stakeholder-level requirements may be needed in order to fulfill a single business requirement.

For example, the business requirement that allows the Driver to pay for gas at the pump might translate into multiple stakeholder requirements from different stakeholder perspectives:

• •

  Driver’s Perspective:

  • o

    The Driver can swipe a credit or debit card.

  • o

    The Driver can enter a security PIN number.

  • o

    The Driver can request/receive a receipt at the pump.

• •

  Gas Station Owner’s Perspective:

  • o

    The Owner can have the credit or debit card validated by the bank before gas is dispensed.

  • o

    The Owner can have the final purchase price credited to their merchant account.

  • o

    The Owner can change the price of gas.

• •

  Gas Station Attendant’s Perspective:

  • o

    The Attendant can poll each pump from inside the station to determine the amount and price of gas pumped on the current transaction.

  • o

    The Attendant is alerted of any errors during the pumping process.