Software

Requirements Engineering
Lecture 16 and 17
Introduction to Requirements Analysis and Specification

SESD-2213
FALL 2020

Dr. Anam Mustaqeem

anam.mustaqeem@ucp.edu.pk
Office: Cabin #2, F303 Building A
OFFICE HOURS: Monday : 10:00 AM- 02:00 PM
Thursday: 10:00 AM- 02:00 PM
 RE process model
3
(suggested by Bray)
Again, this diagram shows
• RE activities (elicitation, analysis,
specification, HMI design)
• subsequent design activity (internal design)
• RE documents (requirements, specification,
HMI specification)

Important point:
Distinction between
• Problem domain (described by requ. doc.)
• System (to be built) (described by spec. doc.)
Note: one has to distinguish between current
(problematic) version of the problem domain,
and the projected future version which includes
the system to be built.
4 Table of Contents

 Introduction to Requirements Analysis

 Structuring Requirements

 External design

 Modeling
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

5 What is Requirements Analysis

The process of studying and analyzing the customer and the user needs to arrive at a definition of the
problem domain and system requirements
 Objectives
 Discover the boundaries of the new system (or software) and how it must interact with its environment within
the new problem domain
 Detect and resolve conflicts between (user) requirements
 Negotiate priorities of stakeholders
 Prioritize and triage requirements
 Elaborate system requirements, defined in the requirement specification document, such that managers can
give realistic project estimates and developers can design, implement, and test
 Classify requirements information into various categories and allocate requirements to sub-systems
 Evaluate requirements for desirable qualities
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

6 Questions
 We have seen how to specify requirements in terms of structure, standards, and writing rules, but:
 How to identify the real problems to solve in the elicitation results?
 How to detect conflicting aspects?
 How to negotiate to resolve conflicts?
 How to decide what is important and a priority?
 How to ensure that nothing is forgotten?
 How to validate that the findings of the analysis are good?
 How to use models in this context?
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

7 How to Find the Real Problems?

 Ask: Why?
 Root cause analysis
 Determine (recursively) the factors that contribute to the problem(s) found by stakeholders

 The causes do not all have the same impact nor the same weight
 Some may perhaps not deserve to be corrected, at least for the moment
 Goal-oriented modeling can help understand these causes and their relationships

 This analysis identifies problems that need to be solved

 Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures

8 What is Requirements Specification?

 The invention and definition of the behavior of a new system (solution domain) such that it will produce
the required effects in the problem domain
 Start from a knowledge of the problem domain and the required effects determined by elicitation and
analysis
 Generally involves modeling
 Results in the specification document
 Precise expression of requirements, may include models


Specification

description of Solution
System needed to
satisfy Problem Domain


Hardware

Domain 
Software
properties

Requirements
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

9 Requirements Analysis
 Problem analysis
 Development of product vision and project scope
 Analysis and elicitation feed each other

Elicitation
Elicitation Questions and points
Notes to consider

Analysis
Requirements Specification

 Analysis goes hand-in-hand with modeling

 Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures

10 Requirements Modeling
 Elicitation/analysis and modeling are intermixed

Source: http://www.telelogic.com/download/paper/SystemsEngineeringSandwich.pdf
 Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures

11 Requirements Modeling
This is an essential task in specifying requirements
 Map elements obtained by elicitation to a more precise form
 Help better understand the problem
 Help find what is missing or needs further discussion

 Different modeling languages

 Informal:
natural language
 Goal-oriented modeling (GRL)
 Functional modeling:
UML (Unified Modeling Notation)
SDL (Specification and Description Language)
Logic, e.g. Z, VDM (Vienna Development Method)
UCM (Use Case Maps)
...
 Introduction Simple Checks Prototyping Functional Test Design User Manual Formal V&V Reviews and Inspections

12 Requirements Verification and Validation

 Need to be performed at every stage during the (requirements) process
 Elicitation
 Checking back with the elicitation sources
 “So, are you saying that . . . . . ?”

 Analysis
 Checking that the domain description and requirements are correct

 Specification
 Checking that the defined system requirement will meet the user requirements under the assumptions of the
domain/environment
 Checking conformity to well-formedness rules, standards…
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

13 Requirements Classification
In order to better understand and manage the large number of requirements, it is important to organize them in
logical clusters
 It is possible to classify the requirements by the following categories (or any other clustering that appears to
be convenient)
 Features
 Use cases
 Mode of operation
 User class
 Responsible subsystem
 This makes it easier to understand the intended capabilities of the product
 And more effective to manage and prioritize large groups rather than single requirements
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

14 Requirements Classification – Features

 A Feature is
 a set of logically related (functional) requirements that provides a capability to the user and enables the satisfaction of
a business objective

 The description of a feature should include1

 Name of feature (e.g. Spell check)
 Description and Priority
 Stimulus/response sequences
 List of associated functional requirements

[1] Source: K.E. Wiegers

 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

15 Requirements Classification – Feature Example (1)

 3.1 Order Meals
 3.1.1 Description and Priority
 A cafeteria Patron whose identity has been verified may order meals either to be delivered to a specified company location or to be picked up
in the cafeteria. A Patron may cancel or change a meal order if it has not yet been prepared.
 Priority = High.
 3.1.2 Stimulus/Response Sequences
 Stimulus: Patron requests to place an order for one or more meals.
 Response: System queries Patron for details of meal(s), payment, and delivery instructions.
 Stimulus: Patron requests to change a meal order.
 Response: If status is “Accepted,” system allows user to edit a previous meal order.
 Stimulus: Patron requests to cancel a meal order.
 Response: If status is “Accepted, ”system cancels a meal order.

 3.1.3 Functional Requirements

 3.1.3.1. The system shall let a Patron who is logged into the Cafeteria Ordering System place an order for one or more meals.
 3.1.3.2. The system shall confirm that the Patron is registered for payroll deduction to place an order.
 ......
Source: K.E. Wiegers
16 Requirements Specification = External Design
 Requirements Specification is «The invention and definition of the behavior of a new system (solution
domain) such that it will produce the required effects in the problem domain »
 During Requirements Analysis, one finds the existing properties of the problem domain, as well as the
requirements that should be satisfied in the domain-to-be. We assume that the domain-to-be will include a new
system-to-be-built and other aspects of the domain may also be changed.
 The determination of this domain-to-be, including the system-to-be) is a typical design process. It is called
external design because the system-to-be is considered during this process as a black-box and the external
environment of it is designed (in a white-box manner) – the domain-to-be.
 Introduction Simple Checks Prototyping Functional Test Design User Manual Formal V&V Reviews and Inspections

The World and the Machine1

17 (or the problem domain and the system)
Specification (S)

Domain
properties (D)
these are assumptions
about the environment
of the system-to-be
Hardware (C)

Requirements (R)
Software (P)

 Validation question (do we build the right  Verification question (do we build the
system?) : if the domain-to-be (excluding the system right?) : if the hardware has the
system-to-be) has the properties D, and the properties H, and the software has the
system-to-be has the properties S, then the properties P, then the system
requirements R will be satisfied. requirements S will be satisfied.
D and S  R C and P  S
 Conclusion:
D and C and P  R

[1] M. Jackson, 1995

 Introduction Simple Checks Prototyping Functional Test Design User Manual Formal V&V Reviews and Inspections

18 Example
Th
 Requirement ea
b ssu
 (R) Reverse thrust shall only be enabled
h eca mpt
when the aircraft is moving on runway. ydr use ion
opl the D3
 Domain Properties ane p la is f
on ne al s
we ma y e
 (D1) Deploying reverse thrust in mid-flight
t ru
has catastrophic effects. nw
 (D2) Wheel pulses are on if and only if wheels are turning.
ay.
 (D3) Wheels are turning if and only if the plane is moving on the runway.
 System specification
 (S) The system shall allow reverse thrust to be enabled if and only if wheel pulses are on.

 Does D1 and D2 and D3 and S  R?

 Are the domain assumptions (D) right? Are the requirement (R) or specification (S) what is really needed?

based on P. Heymans, 2005

19 Requirement specifications including assumptions
 Often the requirements for a system-to-be include assumptions about the environment of the system.
 The system specification S, then, has the form:

S=A G
where A are the assumptions about the environment and G are the guarantees that the system will provide as long as A
hold.

 If these assumptions (A) are implied by the known properties of the domain (D), that is D  A, and we
can check that the domain properties (D) and the system guarantees (G) imply the requirements (R), that
is D and G  R, then the “validation condition” D and S  R is satisfied.
20 Specification with assumptions and guarantees (exemple)

Example: A power utility provides electricity to a client. The problem is that the monthly invoice is not
related to the electricity consumption, because there is no information about this consumption.
 Idea of a solution: introduce an electricity counter.
 Specification of the electricity counter
 Inputs and outputs
 input power from utility (voltage, current) – voltage supplied by utility
 output power to client (voltage, current) – current used by client
 Reset button (input)
 consumption (output - watt-hours of electricity consumption)
21 Example (suite)
 Assumptions
 Input voltage < 500 Volts (determined by utility)
 Output current < 20 Amps (determined by client)

 Guarantees
 Output voltage = input voltage
 Input current = output current
 Consumption output shall indicate the consumption since the last reset operation, that is, the integral of (output voltage x
output current) over the time period from the occurrence of the last reset operation to the current time instant.

 Software example
 Specification of a method providing the interface “List search(Criteria c. Assumption: c is a data structure
satisfying the Criteria class properties. Guarantee: the returned result is a list satisfying the List class
properties and includes all items from the database that satisfy c.
 Introduction Simple Checks Prototyping Functional Test Design User Manual Formal V&V Reviews and Inspections

22 Formal Verification and Validation

 Evaluating the satisfaction of “D and S  R” is difficult with natural language
 Descriptions are verbose, informal, ambiguous, incomplete...
 This represents a risk for the development and organization

 Verification of this “validation question” is more effective with formal methods (see below)
 Based on mathematically formal syntax and semantics
 Proving can be tool-supported

 We can also reduce this risk by using semi-formal modeling

 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

23 Models
 According to B. Selic, a model is a reduced representation (simplified, abstract) of (one aspect of) a system
used to:
 Help understand complex problems and / or solutions
 Communicate information about the problem / solution
 Direct implementation

 Qualities of a good model

 Abstract
 Understandable
 Accurate
 Predictive
 Inexpensive
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

24 Modeling Notations
 Semi-formal notation (URN, UML...)
 Natural language (English)
+ Syntax (graphics) well defined
+ No special training required
+ Partial common understanding, reasonably easy to
- Ambiguous, verbose, vague, learn
obscure ...
+ Partial automation
- No automation
- Meaning only defined informally
 Ad hoc notation (bubbles and arrows) - Still a risk of ambiguities
+ No special training required
 Formal notation (Logic, SDL, Petri nets, FSM ...)
- No syntax formally defined
+ Syntax & semantics defined
- meaning not clear, ambiguous
+ Great automation (analysis and transformations)
- No automation
- More difficult to learn & understand
 Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures

25 Modeling notations (2)

 Informal language is better
understood by all stakeholders
 Good for user requirements, contract
 But, language lacks precision
 Possibility for ambiguities
 Lack of tool support
 Formal languages are more precise
 Fewer possibilities for ambiguities
 Offer tool support (e.g. automated verification and transformation)
 Intended for developers

Source (for decision table): Easterbrook and Callahan, 1997

 Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures

26 Modeling Structure
Concepts of Entities and their Relationships. Use one of the following notations:
 ERD (Entity Relationship Diagram – the traditional version)
 UML class diagrams
 Relational tables
 Can be used for the following
 Model of the problem domain (called “domain model”)
 The two versions: existing and to-be

 Model of input and output data structures of system-to-be

 Model of the stored data (database)
 not necessarily an image of the domain data
 Additional data is introduced (e.g. user preferences)

 Architectural design of the system-to-be

 Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures

27 Modeling inputs and outputs

 Nature of inputs and outputs:
 IO related to problem (problem data)
 Additional data related to solution (solution data)
 E.g., prompts, user options, error messages…

 Collected in Data Dictionary using

 Plain text (natural language)
 EBNF
 Code-like notations
 Logic (e.g., VDM)
 Structure charts
 …
 Graphical output (screens, forms)
 Iconic (representational) drawings, prototype screens or forms, printouts produced by operational prototype
 Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures

28 Modeling Dynamic Behavior

 Behavior modeling techniques
 Text (plain, function statements, use cases)
 Decision tables
 Activity Diagrams / Use Case Maps
 Finite state machines
 Simple state machines (FSM) : use state diagrams or transition table notation
 Extended state machines (e.g. UML State Machines – including SDL)
 Harel’s State Charts (concepts included in UML notation)
 Petri nets (allows for flexible concurrency, e.g. for data flow, similar to Activitity Diagrams)

 Logic (e.g. Z, VDM) for describing input-output assertions and possibly relationship to internal object state that is
updated by operations)
 It is important to chose what best suits the problem
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

29 Model Analysis
 By construction
 We learn by questioning and describing the system
 By inspection
 Execute/analyze the model in our minds
 Reliable?
 By formal analysis
 Requires formal semantics (mathematical) and tools
 Reliable (in theory), but expensive (for certain modeling approaches)
 By testing
 Execution, simulation, animation, test...
 Requires well-defined semantics and execution/simulation tools
 More reliable than inspection for certain aspects
 Possible to interact directly with the model (prototype)
 Introduction Structured Analysis OO Analysis Problem Frames State Machine-Based Analysis Triage/Prioritization

30 Typical Modeling Approaches

 Many approaches involve modeling to get a global picture of the requirements
 Structured Analysis (1970)
 Object-Oriented Analysis (1990)
 Problem Frames (1995)
 State Machine-Based Analysis
 Conflict Analysis
 E.g. with mis-use cases or with GRL/UCM models and strategies/scenarios

 It is important to distinguish between

 Notation used for defining the model
 Process defining a sequence of activities leading to a desired model
 Note: Analysis can be on individual requirements as well
 Remember tips and tricks on how to write better requirements
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

31 Requirements Specification Document (1)

 Clearly and accurately describes each of the essential requirements (functions, performance, design
constraints, and quality attributes) of the system / software and its external interfaces
 Defines the scope and boundaries of the system / software

 Each requirement must be described in such a way that it is feasible and objectively verifiable by a
prescribed method (e.g., by inspection, demonstration, analysis, or test)

 Basis for contractual agreements between contractors or suppliers and customers

 Elaborated from elicitation notes

 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

32 Requirements Specification Document (2)

 Specifications are intended to a diverse audience
 Customers and users for validation, contract, ...
 Systems (requirements) analysts
 Developers, programmers to implement the system
 Testers to check that the requirements have been met
 Project Managers to measure and control the project

 Different levels of detail and formality is needed for each audience

 Different templates for requirements specifications

 e.g. IEEE 830
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

33 Example Specification (1)

lamp
Appearance
12 cm
switch
lever

Causal Input Timing Output

relationship relationship

 When the switch lever is moved down, then, within 0.1 seconds, the lamp illuminates.

 When the switch lever is moved up, then, within 0.2 seconds, the lamp goes out.

Source: Bray 2004

 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

34 Example Specification (2)

 Extract from the requirements specification
 R1: The system shall provide illumination of at least 500 candela.
 R2: The system shall fit within a cube with maximum width of 15cm.
 R3: The illumination can be switched on and off by a human operator.
 R4: The system shall respond to operator input within 0.5 seconds.
 R5: The system shall have a built-in power supply which should be capable of maintaining continuous
illumination for at least 4 hours.
 etc . . . . . . .

 Several alternative designs could satisfy these requirements

Source: Bray 2004

 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

35 IEEE 830-1998 Standard

 Title of Standard
 « IEEE Recommended Practice for Software Requirements Specifications »

 Describes the content and qualities of a good software requirements specification (SRS)

 Presents several sample SRS outlines

 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

36 IEEE 830-1998 Standard – Objectives

 Help software customers to accurately describe what they wish to obtain

 Help software suppliers to understand exactly what the customer wants

 Help participants to:

 Develop a template (format and content) for the software requirements specification (SRS) in their own
organizations
 Develop additional documents such as SRS quality checklists or an SRS writer’s handbook
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

37 IEEE 830-1998 Standard – Benefits

 Establish the basis for agreement between the customers and the suppliers on what the software product is
to do

 Reduce the development effort

 Forced to consider requirements early  reduces later redesign, recoding, retesting
 Provide a basis for realistic estimates of costs and schedules

 Provide a basis for validation and verification

 Facilitate transfer of the software product to new users or new machines
 Serve as a basis for enhancement requests
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

38 IEEE 830-1998 Standard – Considerations

 Section 4 of IEEE 830 (how to produce a good SRS)
 Nature (goals) of SRS
 Functionality, interfaces, performance, qualities, design constraints

 Environment of the SRS

 Where does it fit in the overall project hierarchy

 Characteristics of a good SRS

 Generalization of the characteristics of good requirements to the document

 Evolution of the SRS

 Implies a change management process

 Prototyping
 Helps elicit software requirements and reach closure on the SRS

 Including design and project requirements in the SRS

 Focus on external behavior and the product, not the design and the production process (describe in a separate document)
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

39 IEEE 830-1998 Standard – Structure of the SRS

 Section 5 of IEEE 830

 Contents of SRS
 Introduction
 General description of the software product
 Specific requirements (detailed)
 Additional information such as appendixes and index, if necessary
Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

IEEE 830-1998 Standard – Section 1 of SRS

•Describe purpose of this SRS
•Describe intended audience
 Title
 Table of Contents •Identify the software product
•Enumerate what the system will and will not do
 1. Introduction •Describe user classes and benefits for each
 1.1 Purpose
 1.2 Scope
 1.3 Definitions. Acronyms, and Abbreviations
 1.4 References •Define the vocabulary of the SRS
(may reference appendix)
 1.5 Overview
 2. Overall Description •List all referenced documents including sources
 3. Specific Requirements (e.g., Use Case Model and Problem Statement;
Experts in the field)
 Appendices
 Index
•Describe the content of the rest of the SRS
•Describe how the SRS is organized
Requirements Specification Document
IEEE 830-1998 Standard – Section 2 of SRS
 Title
 Table of Contents
 1. Introduction
 2. Overall Description
 2.1 Product Perspective
 2.2 Product Functions
 2.3 User Characteristics
 2.4 Constraints
 2.5 Assumptions and Dependencies
 3. Specific Requirements
 4. Appendices
 5. Index
IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207
•Present the business case and operational concept of the system
•Describe how the proposed system fits into the business context
•Describe external interfaces: system, user, hardware, software, communication
•Describe constraints: memory, operational, site adaptation
•Summarize the major functional capabilities
•Include the Use Case Diagram and supporting narrative
(identify actors and use cases)
•Include Data Flow Diagram if appropriate
•Describe and justify technical skills
and capabilities of each user class
•Describe other constraints that will limit developer’s
options; e.g., regulatory policies; target platform,
database, network software and protocols, development
standards requirements
Requirements Specification Document
IEEE 830-1998 Standard – Section 3 of SRS (1)
 …
 1. Introduction
 2. Overall Description
 3. Specific Requirements
 3.1 External Interfaces
 3.2 Functions
 3.3 Performance Requirements
 3.4 Logical Database Requirements
 3.5 Design Constraints
 3.6 Software System Quality Attributes
 3.7 Object Oriented Models
 4. Appendices
 5. Index
IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207
Specify software requirements in sufficient
detail to enable designers to design a system to satisfy
those requirements and testers to verify
requirements
State requirements that are externally perceivable by
users, operators, or externally connected systems
Requirements should include, at a minimum, a
description of every input (stimulus) into the system,
every output (response) from the system, and all
functions performed by the system in response to an
input or in support of an output
(a) Requirements should have characteristics of
high quality requirements
(b) Requirements should be cross-referenced to
their source.
(c) Requirements should be uniquely identifiable
(d) Requirements should be organized to
maximize readability
Requirements Specification Document
IEEE 830-1998 Standard – Section 3 of SRS (2)
 …
 1. Introduction
 2. Overall Description
 3. Specific Requirements
 3.1 External Interfaces
 3.2 Functions
 3.3 Performance Requirements
 3.4 Logical Database Requirements
 3.5 Design Constraints
 3.6 Software System Quality Attributes
 3.7 Object Oriented Models
 4. Appendices
 5. Index
IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207
•Detail all inputs and outputs
(complement, not duplicate, information presented in section 2)
•Examples: GUI screens, file formats
•Include detailed specifications of each
use case, including collaboration and
other diagrams useful for this purpose
•Include:
a) Types of information used
b) Data entities and their relationships
•Should include:
a) Standards compliance
b) Accounting & Auditing procedures
•The main body of requirements organized in a variety of
possible ways:
a) Architecture Specification
b) Class Diagram
c) State and Collaboration Diagrams
d) Activity Diagram (concurrent/distributed)
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

44 IEEE 830-1998 Standard – Templates

 Annex A of IEEE 830

 Section 3 (Specific Requirements) may be organized in many different ways based on

 Modes
 User classes
 Concepts (object/class)
 Features
 Stimuli
 Organizations
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

45 Relationship of IEEE 830 and ISO/IEC 12207 (1)

 12207
 Common framework for « Software life cycle processes »
 ISO/IEC 12207 = IEEE/EIA 12207

 IEEE 830-1998 and IEEE/EIA 12207.1-1997 both place requirements on documents describing software
requirements
 Annex B of IEEE 830 explains the relationship between the two sets of requirements for those who want to
produce documents that comply with both standards simultaneously
 Such compliance may be required by customers when requesting proposals or issuing call for tenders
 Requirements Specification Document IEEE 830 Standard Relationship of IEEE 830 and ISO/IEC 12207

46 Relationship of IEEE 830 and ISO/IEC 12207 (1)

 Note: Table B.3 is more detailed and shows the correspondence between the two standards at the level of
requirements types