Software Requirements: A More Rigorous Look

1
Software RequirementsA More Rigorous Look
2
Features and Use Cases at a High Level of
Abstraction

• Helps to better understand the main
  characteristics of the system and how they
  fulfill the user needs.
• Helps in assessing the system for completeness,
  consistency, and its fit within the environment.
• Helps in determining feasibility and managing
  system scope before investing significant
  resources.

3
What is a Software Requirement (Reminder)

• A software capability needed by the user to solve
  a problem or to achieve an objective.
• A software capability that must be met or
  possessed by a system or a system component to
  satisfy a contract, standard, specification, or
  other formally imposed documentation.

4
Things Needed to Fully Describe the Behavior of a
System

• Inputs to the systemnot only the content of the
  input but also the details of input devices and
  the form, look, and feelprotocolof the input.
• Outputs from the systema description of the
  output devices that must be supported, as well as
  the protocol and formats of the information
  generated by the system.

5
Things Needed to Fully Describe the Behavior of a
System (Contd)

• Functions of the systemthe mapping of inputs to
  outputs, and their various combinations.
• Attributes of the systemthe non-behavioral
  requirements such as reliability,
  maintainability, availability, and throughput.
• Attributes of the system environmentadditional
  non-behavioral requirements as the ability to
  operate with other applications, loads, and
  operating systems.

6
Relationship between Use Cases and Software
Requirements

• Use cases are a convenient way for expressing
  many requirements.
• Use cases are not the only way to express
  requirements.
• Many requirements can not easily be expressed
  with use cases.

7
Relationship between Features and Software
Requirements

• Features are simple descriptions of system
  services.
• Features help us understand and communicate at a
  high level of abstraction.
• Software requirements express features in more
  detailed terms.
• Software requirements are specific enough that we
  can code from them.

8
The What versus How Dilemma

• Requirements tell developers what the system must
  do.
• But they should avoid stipulating any unnecessary
  design or implementation details, information
  relating to project management, or information
  about how the system will be tested.
• The focus is on the behavior of the system.

9
Excluding Project Information

• Information regarding schedules, configuration
  management plans, verification and validation
  plans, budgets, and staffing schedules should not
  be in the requirements documents.
• These things increase volatility and take focus
  away from what the system is supposed to do.

10
Excluding Design Information

• Information about the system design or
  architecture should also be excluded.
• Such information might accidentally restrict the
  pursuit of alternate design approaches.
• Excluding design information is often difficult
  since some requirements are stated in a way that
  implies a particular design.

11
How Do Design Issues Become Part of Requirements?

• They are specified as requirements in the Vision
  Document by the development team (e.g., the user
  interface should be like that of Microsoft Office
  products).
• They are specified as requirements by the
  stakeholders (e.g., the system data must be
  stored in a relational database).
• A process or political decision within the
  development organization (e.g., the system must
  be developed in Java).

12
Requirements Versus Design

• Requirements (mostly) precede design.
• Users and customers, because they are closed to
  the need, make requirements decisions.
• Technologists make design decisions because they
  are best suited to pick, among the many design
  options, which option will best meet the need.

13
Iterating Requirement and Design

• Current requirements cause us to consider
  selecting certain design options.
• Selected design options may initiate new
  requirements.
• We need to continually reconsider requirements
  and design.

14
A Characterization of Requirements

• Functional software requirements they specify
  how the system behavesits inputs, its outputs,
  and the functions it provides to the user.
• Nonfunctional software requirements they
  include usability, reliability, performance, and
  supportability.
• Design constraints they specify restrictions on
  the design of a system, or the process by which a
  system is developed, that do not affect the
  external behavior of the system but that must be
  fulfilled to meet technical, business, or
  contractual obligations.