Software Requirement

Engineering
SEC-2071

Lecture 22

Dr. Muhammad Adeel

[email protected]

1
Review of Lectures 1-21

Lecture # 22

2
 Introduction
• Requirements form the basis for all
software products

• Requirements engineering is the

process, which enables us to
systematically determine the
requirements for a software
product
3
 Software Requirements - 1
• Complete specification of the desired
external behavior of the software
system to be built
• What is external behavior?
• Software requirements may be:
– Abstract statements of services and/or
constraints
– Detailed mathematical functions

4
 Software Requirements - 2
• Software requirements may be:
– Part of the bid of contract
– The contract itself
– Part of the technical document, which
describes a product

5
 Sources of Requirements
• Stakeholders
– People affected in some way by the
system
• Documents
• Existing system
• Domain/business area

6
 Kinds of Software
Requirements
• Functional requirements
• Non-functional requirements
• Domain requirements
• Inverse requirements
• Design and implementation
constraints
7
 Functional Requirements - 1
• Statements describing what the system
does, i.e., functionality of the system
• Statements of services the system
should provide
– Reaction to particular inputs
– Behavior in particular situations
• Sequencing and parallelism are also
captured by functional requirements
8
 Examples
• The system shall solve a quadratic
equation using the following
formula
2
x = (-b+sqrt(b – 4*a*c))/2*a
• The user shall be able to search
either the entire database of
patients or select a subset from it
(admitted patients, or patients with
asthma, etc.)
9
Non-Functional Requirements
-1
• Most non-functional requirements
relate to the system as a whole. They
include constraints on timing,
performance, reliability, security,
maintainability, accuracy, the
development process, standards, etc.,
emergent behavior
• Often more critical than individual
functional requirements 10
Non-Functional Requirements
-2
• Must be built into the framework of
the software product
• Failure to meet a non-functional
system requirement may make the
whole system unusable

11
 Types of Non-Functional
Requirements
Non-Functional
requirements

Product Organizational External

requirements requirements requirements

12
 Product Requirements - 1
Product
requirements

Usability Efficiency Reliability Portability

requirements requirements requirements requirements

Performance Space
requirements requirements

13
 Product Requirements - 2
• The system shall allow one
hundred thousand hits per minute
on the website
• The system shall not have down
time of more than one second for
continuous execution of one
thousand hours
14
Organizational Requirements -
1
Organizational
requirements

Standards Implementation Delivery

requirements requirements requirements

15
Organizational Requirements -
2
• The system development process
and deliverable documents shall
conform to the MIL-STD-2167A
• Any development work sub-
contracted by the development
organization shall be carried out in
accordance with Capability
Maturity Model 16
 External Requirements - 1
External
requirements

Interoperability Ethical Legislative

requirements requirements requirements

Privacy Safety
requirements requirements

17
 External Requirements - 2
• The system shall not disclose any
personal information about
members of the library system to
other members except system
administrators
• The system shall comply with the
local and national laws regarding
the use of software tools 18
 Metrics for Non-Functional
Requirements
• Speed
• Size
• Ease of use
• Reliability
• Robustness
• Portability
19
 Domain Requirements - 1
• Requirements that come from the
application domain and reflect
fundamental characteristics of that
application domain. Can be functional
or non-functional
• These requirements, sometimes, are
not explicitly mentioned, as domain
experts find it difficult to convey domain
requirements 20
 Domain Requirements - 2
• Their absence can cause
significant dissatisfaction
• Domain requirements can impose
strict constraints on solutions.
This is particularly true for
scientific and engineering domains

21
 Inverse Requirements
• They explain what the system shall
not do. Many people find it
convenient to describe their needs
in this manner
• These requirements indicate the
indecisive nature of customers
about certain aspects of a new
software product 22
 Design and Implementation
Constraints
• They are development guidelines
within which the designer must
work
• These requirements can seriously
limit design and implementation
options
• Can also have impact on human
resources 23
 Requirements Problems
• The requirements don’t reflect the real
needs of the customer for the system
• Requirements are inconsistent and/or
incomplete
• There are misunderstandings between
customers, those developing the
system requirements, and software
engineers developing or maintaining
the system
24
 Problems with Natural
Languages - 1
• Lack of clarity
• Requirements confusion
• Requirements amalgamation

25
 Problems with Natural
Languages - 2
• Natural language understanding
relies on the specification readers
and writers using the same words
for same concept
• A natural language requirements
specification is over-flexible. You
can say the same thing in
completely different ways 26
 Problems with Natural
Languages - 3
• It is not possible to modularize
natural language requirements. It
may be difficult to find all related
requirements
– To discover the impact of a change,
every requirement have to be
examined

27
 Process - 1
• A process is an organized set of
activities, which transforms inputs
to outputs
• Synonyms: procedure, method,
course of action, etc.
• Processes are essential for dealing
with complexity in real world

28
 Process - 2
• Processes document the steps in
solving a certain problem

• They allow knowledge to be reused

• Allows people to apply the process

in their peculiar but similar
problems
29
 Requirements Engineering
Process

The process(es) involved in

developing system requirements

30
 RE Process - Inputs and
Outputs
Existing
systems
information

Stakeholder Agreed
needs requirements

Organizational Requirement System

standards engineering process specification

System
Regulations models

Domain
information

31
 RE Process Variability
• RE processes vary radically from one
organization to another, and even
within an organization
• Unstructured process rely heavily on
the experience of the people, while
systematic processes are based on
application of some analysis
methodology , but still require human
judgment 32
 Variability Factors - 1
• Technical maturity
• Disciplinary involvement
• Organizational culture
• Application domain

33
 Requirements Engineering
Activities

Requirements Requirements
Requirements Requirements
Elicitation Analysis and
Specification Validation
Negotiation

User Needs,
Domain Information, Agreed
Existing System Requirements Requirements
Information, Regulations, Document
Standards, Etc.

34
 RE Process Maturity Model
Defined
Defined process based on best practice
Process improvement in place

Repeatable

Standardized requirements engineering

Fewer requirements errors

Initial

Ad-hoc requirements engineering

Requirements errors are common
35
 Social and Cultural Issues in
RE
• Some aspects of the requirements
engineering process deal with
social and cultural issues
• What is the best way to deal with
these issues?

36
 Six Areas of Social Issues - 1
• Within the client organization

• Within the requirements team

• Between the client and the

requirements team
37
Six Areas of Social Issues - 2
• Between the development and
requirements teams

• Within the development team

• Between the development team

and the client
38
 Cultural Issues in RE
• Time zones differences
• Language and terminology
differences
• Religious and racial differences
• Ethical issues
• Political differences
• Differences in business
39
environment
 Basics of Knowledge
Acquisition
• Reading
• Listening
• Asking
• Observing

40
 Requirements Elicitation
Techniques
• Individual
• Group
• Modeling
• Cognitive

41
 Problems in Requirements
Elicitation
• Problems of scope
• Problems of understanding
• Problems of volatility

42
Components of Requirements
Elicitation

Application Problem to be
Domain Solved

Stakeholder Business
Needs and Context
Constraints

43
 A General Requirements
Elicitation Process
Establish Understand Organize Collect
Objectives Background Knowledge Requirements

Business Organizational Stakeholder Stakeholder

goals structure identification requirements

Problem to Application Goal Domain

be solved domain prioritization requirements

Domain
System Existing knowledge Organizational
constraints systems filtering requirements

44
 Knowledge Structuring
Techniques
• Partitioning
• Abstraction
• Projection

45
Specific Elicitation Techniques

• Interviews

• Scenarios

• Observations and social analysis

• Requirements reuse

46
 Interview Steps
• Prepare
• Conduct
– Opening
– Body
– Closing
• Follow through

47
 Listening Steps
• Hear
• Interpret
• Respond
• Evaluate

48
Iterative Aspects of Elicitation,
Analysis, and Negotiation
Draft
Statement of
Requirements
Requirements
Elicitation

Requirements
Analysis

Requirements Requirements
Documents Problems

Requirements
Negotiation 49
 Requirements Analysis
Requirements Analysis
Process

Necessity Consistency and Feasibility

checking completeness checking
checking

Conflicting and
Unnecessary Infeasible
incomplete
requirements requirements
requirements

50
 Analysis Techniques
• Analysis checklists
– A checklist is a list of questions
which analysts may use to assess
each requirement
• Interaction matrices
– Interaction matrices are used to
discover interactions between
requirements and to highlight
conflicts and overlaps
51
 Requirements Negotiation
Process

Conflicting and
Unnecessary Infeasible
incomplete
requirements requirements
requirements

Requirements Requirements Requirements

discussion prioritization agreement

Requirements Negotiation
52
 Stages of Negotiation
Meetings
• Information stage

• Discussion stage

• Resolution stage

53
Types of Requirements Errors
• Errors of omission

• Errors of commission

• Errors of clarity and ambiguity

• Errors of speed and capacity

54
 Prevention vs. Removal
• For requirements errors, prevention is
usually more effective than removal
• Joint application development (JAD),
quality function deployment (QFD), and
prototyping are more effective in defect
prevention
• Requirements inspections and
prototyping play an important role in
defect removal. Discussed in detail
perspective-based reading technique 55
 Validation Inputs and Outputs

Requirements
document List of problems

Organizational Requirements
knowledge Validation
Agreed actions
Organizational
standards

56
Requirements Review Process

Plan review Distribute

documents

Prepare for Hold review

review meeting

Follow-up Revise
actions documents

57
 Pre-review Checking Stages

Check Check Check document Run

document document against automatic
structure completeness standards checkers

Requirements Problems
document report

58
 Hard-to-Test Requirements
• System requirements
• Exclusive requirements
• Some non-functional requirements

59
 Requirements Management
• The process of managing change
to the requirements for a system
• In this lecture, we’ll talk about the
reasons for changes in
requirements and how to manage
them

60
 Sources of Change - 1
• New business or market conditions
dictate changes in product
requirements or business rules
• New customer needs demand
modification of data produced by
information systems, functionality
delivered by products, or services
delivered by computer-based system
61
 Sources of Change - 2
• Reorganization or business
growth/downsizing causes
changes in project priorities or
software engineering team
structure
• Budgetary or scheduling
constraints cause a redefinition of
the system or product 62
 Main Concerns in
Requirements Management
• Managing changes to agreed
requirements
• Managing the relationships between
requirements
• Managing the dependencies between
the requirements document and other
documents produced in the systems
engineering process
63
 Change Management Stages
Identified
problem

Problem analysis and Change analysis and Change

change specification costing implementation

Revised
requirements

64
 Change Analysis and Costing
Process
Rejected request

Change
request Find directly Req. list Find
Check request
affected dependent
validity Valid requirements
request
Requirements change list Rejected
request

Requirements
Cost Cost
changes
Propose info info
Assess costs Assess costs
requirements
of change acceptability
changes
Accepted
Rejected request change
Customer Customer
information information 65
 Requirements Traceability
• Refers to ability to describe and follow
the life of a requirement, in both a
forwards and backwards direction
• That is from its origins, through its
development and specification, to its
subsequent deployment and use, and
through all periods of on-going
refinement and iteration in any of these
phases 66
 Classifications of
Requirements Traceability
• Backward-from traceability
• Forward-from traceability
• Backward-to traceability
• Forward-to traceability

67
 Backwards and Forwards
Traceability

Business plan Requirements document Design specification

Forward-to traceability Forward-from traceability

Backward-from traceability Backward-to traceability

68
 Categories of Traceability
• Requirements-sources traceability
• Requirements-rationale traceability
• Requirements-requirements
traceability
• Requirements-architecture
traceability
• Requirements-design traceability
• Requirements-interface traceability
69
 Types of Prototyping
• Throw-away prototyping

• Evolutionary prototyping

70
 Approaches to Prototyping
• Paper prototyping

• ‘Wizard of Oz’ prototyping

• Executable prototyping

71
Good Luck on Mid Term Paper

72