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

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

Linda Westfall (Westfall Team, Inc., USA)
DOI: 10.4018/978-1-4666-6026-7.ch001
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

If software requirements are not right, companies will not end up with the software they need. This chapter discusses the various levels and types of requirements that need to be defined, the benefits of having the right software requirements, the stakeholders of the software requirements and getting them involved in the process, requirements activities throughout the software development life cycle, and techniques for eliciting, analyzing, specifying, and validating software requirements.
Chapter Preview
Top

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.

Key Terms in this Chapter

Requirements Validation: All of the activities involved in ensuring that the requirements are well written, complete, maintainable, measureable, unambiguous, finite and will satisfy the stakeholder and business objectives.

Requirements Management: All of the activities involved in ensuring that the requirements are built into the software product, in maintaining consistency between the requirements, other software work product and the project plans, and performing change control on the baselined requirements.

Requirements Development: All of the involved in requirements elicitation, analysis, specification and validation.

Requirements Elicitation: All of the activities involved in gathering the information upon which the requirements are based including identifying the requirement’s stakeholders, selecting stakeholder representatives and determining the needs of each class of stakeholders.

Requirements Specification: All of the activities involved in formally documenting the requirements so that they can be communicated to customers, users, development, and other stakeholders.

Requirements Analysis: All of the activities involved in identifying and resolving gaps and conflicts in the stakeholder requirements and refining those stakeholder requirements into the detailed product requirements.

Complete Chapter List

Search this Book:
Reset