Requirements Engineering

1
Requirements Engineering
2
Overview

• To frame our discussion, consider
• What is the nature of software requirements?
• How are requirements determined?

3
Outline

• What are Requirements?
• Importance of Requirements
• Requirements Engineering Process

4
What are requirements?

• A statement of a system service or constraint.
• A condition or capability needed by a user to
  solve a problem or achieve an objective.
  (IEEE-610)

5
Requirements Example (1)

• 1. The system shall maintain records of all
  library materials including books, serials
  newspapers and magazines, video and audio tapes,
  reports, collections of transparencies, computer
  disk and CD-ROMs.
• Sets out in broad terms what the system should do.

6
Requirement Example (2)

• 2. The system shall allow users to search for an
  item by title, author, or ISBN.
• Define system functionality.

7
Requirements Example (3)

• 3. The user interface shall be implemented using
  a World-wide Web browser.
• State how the system must be implemented.

8
Requirements Example (4)

• 4. The system shall support at least 20
  transactions per second.
• Specify a minimum acceptable performance criteria.

9
Requirements Example (5)

• 5. The system facilities, available to public
  users, shall be demonstrable in 10 minutes or
  less.
• Specify usability requirements in quantitative
  terms.

10
Requirements (1)

• Requirements describe
• User-level behaviors or functionality (features)
• General system properties
• Definitions of other systems which must be
  integrated
• Specific operational constraints
• Domain rules (e.g., computation)
• Development constraints

11
Requirements (2)

• A requirement is a specification of what a system
  must do -- the things about the system users can
  observe.
• Behavioral Requirements (Functional) define what
  the system does. These describe the inputs and
  outputs of the system. Information concerning how
  the inputs and outputs relate.
• Nonbehavioral Requirements define the attributes
  of the system as it performs its job. They
  include a complete description of the system as
  it performs its job.

12
Requirements are Important!
13
Importance (1)

• 1. The later in the life cycle that an error is
  detected the more expensive it is to repair.
• 2. Errors remain latent and are not detected
  until well after the stage at which they are
  made.
• 54 of errors detected after coding and unit
  testing.
• 45 of these errors were requirements and design
  errors.

14
Importance (2)

• 3. There are numerous requirements errors.
• Estimates indicate that 56 of all errors are
  errors during the requirements stage.
• 4. Requirements errors are typically nonclerical.
  
• incorrect facts 49
• omissions 31
• inconsistencies 13
• ambiguities 5

15
Importance (3)

• 5. Requirements errors can be detected.
• Review by Authors 23
• Review by Others 10
• As Design Reference 45

16
Requirements Engineering Costs

• For large hardware/software systems about 15 of
  development budget.
• For smaller systems which are mostly software
  around 10 of development budget.

17
Requirements Engineering Process (1)

• A structured set of activities which are
  followed to derive, validate and maintain a
  systems requirements document.

18
Requirements Engineering Process (2)
Regulations
Standards
Existing System Information
Requirements
Requirements Engineering Process
System Specification
Domain Information
Stakeholder Needs
System Models
Stakeholder
Analyst
19
Requirements Engineering Process (3)

• Inputs
• Existing System Information
• Information about systems that either will be
  replaced by the proposed system, or which the
  system must interact with.
• Stakeholder Needs
• Descriptions of needs stakeholders perceived to
  have of the suggested system.
• Domain Information
• General information about the nature of the
  domain and the types of activities that are
  covered by the situation being considered.

20
Requirements Engineering Process (4)
Controls Organizational Standards Standards used
in the organization to coordinate system
development or maintain quality, etc.
Regulations External regulations that need to
be considered as the problem is considered and
the solution evolves.
21
Requirements Engineering Process (6)
Mechanisms Stakeholders Are people or
organizations affected by the system and who have
a direct influence on the requirements?
Analyst The member of the project team
responsible for managing the requirements process
(requirements manager).
22
Stakeholders

• End-users, managers, engineers who develop or
  maintain related systems, domain experts, union
  representatives, etc.
• May not know what they really want, or may find
  it difficult to articulate
• May make unrealistic demands
• Express requirements in their own terms with
  implicit knowledge of their own work
• May be politically motivated

23
Requirements Engineering Process (7)
Outputs Requirements The agreed upon
functional and non-functional requirements for
the system. System Specification A more
detailed version of the system which may be
required in some instances. System Models
Models, usually in diagrammatic form, which
describe the system from the necessary
perspectives.
24
RE Process Decomposition
Feasibility Study
Requirements Analysis
Requirements Definition
Feasibility Report
Requirements Specification
System Models
Definition of Requirements
Requirements Document
Requirements Specification
25
Requirements Elicitation

• Requirements elicitation is about understanding
  the "real" problem. This understanding comes from
  interacting with people that are intimately
  involved in a particular domain. Here is where
  the different stakeholders with their particular
  perspectives need to be identified. The problem
  solver needs to have the perspectives of all
  those involved in the current environment to make
  sense of their world.

26
Requirements Analysis

• Observation of existing systems, processes
• Discussion with potential users, procurers
• Development of problem domain models
• Process, State, Data flow, E/R, etc.
• Prototype development

27
Social and Organizational Issues

• Potential influence on all viewpoints
• Example System Boundaries
• Can analysis be carried out on one site?
• Is it necessary to consult a particular manager?
• Will a larger system result in an expanded
  development group?

28
Example

• Requirement Elicitation
• Consider a system which will allow senior
  managers to access information directly. An
  organizational factor may be the intention to
  reduce the numbers of middle managers. The middle
  managers have a vested interest in seeing the
  system fail, but are an important source of
  information about requirements.

29
Ethnographic Analysis

• Ethnography
• Technique whereby a sociologist spends
  considerable time observing in the working
  environment. Does not involve people explaining
  what they do.
• Problem
• Studying existing work supported by imperfect
  systems may lead to erroneous conclusions
  concerning requirements.

30
Example

• Air traffic controllers may keep the audible
  conflict alert turned off, because they
  deliberately place aircraft on conflicting paths
  (temporarily). One might conclude that conflict
  alert is not a requirement, instead of requiring
  an improved conflict alert system.

31
Requirements Specification

• The understanding of the problem is then cast in
  terms of a solution. This solution is referred to
  as the requirements specification. The problem
  solver takes the information collected during
  requirements elicitation and structures it in
  terms of a set of functional and non-functional
  requirements for the system.

32
Requirements VV

• The requirements that are written must be
  affirmed. There are two concerns
• 1. are these the stated requirements correct?
  (validation)
• 2. are the requirements stated correctly?
  (verification)
• It is important that the requirements
  engineering process not conclude until the
  requirements are agreed upon by the stakeholders.

33
Requirements document contents

• Introduction
• Glossary
• System models
• Functional requirements
• Non-functional requirements
• System evolution
• Requirements specification
• Index and table of contents

34
Requirements document

• Should specify only external behavior
• Should specify constraints on the implementation
• Should be easy to change
• Should serve as a reference tool for system
  maintainers
• Should record forethought about life cycle
• Should characterize acceptable responses to
  undesired events.

35
Requirements Validation

• Correctness
• Any set of requirements is a compromise across a
  diverse group of users
• Completeness
• Consistency
• Realism
• There is no point in specifying unrealistic
  requirements

36
Requirements Review (formal)

• Developer walks customer through each
  requirement, explaining implications.
• Review team checks each requirement for
• Clarity
• Consistency
• Verifiability How can the requirement be tested?
• Traceability What is the source of the
  requirement?
• Adaptability Can the requirement be changed
  without major effects on other requirements?