SOFTWARE REQUIREMENTS

1
SOFTWARE REQUIREMENTS
Requirements
Design
Construction
2
Definition

• Software requirements express the needs and
  constraints placed on a software product that
  contribute to the solution of some real-world
  problem.

3
Topics for Software Requirements

• Software Requirements Fundamentals
• Requirements Process
• Requirements Elicitation
• Requirements Analysis
• Requirements Specification
• Requirements Validation
• Practical Considerations

4
Software Requirements Fundamentals

• Definition of a Software Requirement
• Product and Process Requirements
• Functional and Non-functional Requirements
• Emergent Properties
• Quantifiable Requirements
• System Requirements and Software Requirements

5
Requirements Definition

• A software requirement is a property which must
  be exhibited in order to solve some problem in
  the real world.
• All software requirements must be verifiable.

6
Product and Process Requirements

• Product parameter
• A requirement on software to be developed
• For example
• The software shall verify that a student meets
  all prerequisites before he or she registers for
  a course.
• Process parameter
• a constraint on the development of the software
• For example
• The software shall be developed in C

7
Functional and Nonfunctional Requirements

• Functional requirements
• Describe the functions to be executed by the
  software.
• Nonfunctional requirements
• Describe constraints to the solution.
• Also known as constraints or quality
  requirements.
• Common types of nonfunctional requirements
• performance requirements
• maintainability requirements
• safety requirements
• reliability requirements

8
Emergent Properties

• Requirements which cannot be addressed by a
  single component, but which depend for their
  satisfaction on how all the software components
  interoperate.
• Emergent properties are crucially dependent on
  the system architecture.

9
Quantifiable Requirements

• Software requirements should be stated as clearly
  and as unambiguously as possible, and, where
  appropriate, quantitatively.
• It is important to avoid vague and unverifiable
  requirements which depend for their
  interpretation on subjective judgment.

10
System Requirements and Software Requirements

• System requirements are the requirements for the
  system as a whole.
• Systems include hardware, software, firmware,
  people, information, techniques, facilities,
  services, and other support elements.
• In a system containing software components,
  software requirements are derived from system
  requirements.

11
Requirements Process

• Process Models
• Process Actors
• Process Support and Management
• Process Quality and Improvement

12
Process Models

• Not a front-end activity of the software life
  cycle, but rather a process initiated at the
  beginning of a project and continuing to be
  refined throughout the life cycle
• Identifies software requirements as configuration
  items, and manages them using the same software
  configuration management practices as other
  products of the software life cycle processes
• Needs to be adapted to the organization and
  project context

13
Process Actors

• Defines the roles of the people who participate
  in the requirements process
• Requirements specialist
• mediate between the domain of the stakeholder
  and that of software engineering.
• Software stakeholders
• Users
• Customers
• Market analysts
• Regulators
• Software engineers

14
Requirements Elicitation

• Where software requirements come from and how
  the software engineer can collect them.
• Also known as requirements capture, requirements
  discovery, and requirements acquisition.
• Key areas
• Requirements Sources
• Elicitation Techniques

15
Requirements Sources

• Goals
• Domain knowledge
• Stakeholders
• The operational environment
• The organizational environment

16
Elicitation Techniques

• Interviews
• Scenarios, e,g., use cases
• Prototypes
• Facilitated meetings
• Observation

17
Requirements Analysis

• The process of analyzing requirements to
• Detect and resolve conflicts between requirements
  
• Discover the bounds of the software and how it
  must interact with its environment
• Elaborate system requirements to derive software
  requirements
• Key areas
• Requirements Classification
• Conceptual Modeling
• Architectural Design and Requirements Allocation
  
• Requirements Negotiation

18
Requirements Classification

• Whether the requirement is functional or
  nonfunctional
• The source of the requirements, derived from
  high-level requirements, emergent properties, or
  imposed by stakeholders.
• Whether the requirement is on the product or the
  process.
• The requirement priority.
• The scope of the requirement.
• Volatility/stability.

19
Conceptual Modeling

• The purpose is to aid in understanding the
  problem, rather than to initiate design of the
  solution.
• Conceptual models are concerned with entities
  from the problem domain configured to reflect
  their real-world relationships and dependencies.
  
• Types of models
• data and control flows
• state models
• event traces

• user interactions
• object models
• data models

20
Requirements Specification

• A document of software requirements which can be
  systematically reviewed, evaluated, and
  approved.
• Types of specification documents
• System Definition Document
• System Requirements Specification
• Software Requirements Specification

21
System Definition Document

• Intent
• Defines the high-level system requirements from
  the domain perspective.
• Readership
• representatives of the system users and
  customers.
• Contents
• overall objectives
• target environment
• constraints and assumptions
• functional and non-functional requirements
• conceptual models

22
System Requirements Specification

• Intent
• Specify system requirements
• Readership
• System and software engineers
• Contents
• system requirements
• software requirements derived from the system
  requirements
• requirements for the software components

23
Software Requirements Specification

• Intent
• Establishes the basis for an agreement between
  the customer and the developer
• Permits a rigorous assessment of requirements
• Provide a realistic basis for estimating product
  costs, risks, and schedules
• Readership
• Software engineers
• Notation
• Formal and semi-formal notations which allow the
  requirements to be described as precisely as
  possible.

24
Requirements Validation

• The process of examining the requirements
  document to ensure that it defines the right
  software
• Techniques
• Requirements Reviews
• Prototyping
• Model Validation
• Acceptance Tests

25
Practical Considerations

• Iterative Nature of the Requirements Process
• Change Management
• Requirement Attributes
• Requirements Tracing
• Measuring Requirements