Software Requirements Engg

9
Requirements Requireme Requireme Requireme Requireme Requireme
Engineering nts nts nts nts nts
Process Elicitation Analysis Specificatio Validation Manageme
n nt
Requireme

Χ Process
Models Χ Requireme
nt Sources
nt
Classificati
on
Requireme
nt
Definition
Document
Conduct of
Requireme
nts
Reviews
Change
Management

Requireme
Process nts
Conceptual

Χ
Actors Attributes
Elicitation Modeling Software
Techniques Requirements Prototyping
Process Architectura Specification Requireme
Support l Design and (SRS) Model nts Tracing
and Requiremen Validation
Manageme ts Allocation Structure
nt and Acceptance
Standards Tests
Process Quality Requireme
and nt Document
Improvemen Negotiation Quality
t

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 13

 Requirements Analysis

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 14

(1) Requirements Classification
‰ Functional or nonfunctional.
‰ Derived from one or more high-level requirements.
‰ Requirement is on the product or the process.
‰ Requirement priority: Often classified on a fixed point
scale such as mandatory, highly desirable, desirable,
optional.
‰ Scope of the requirement: Some requirements (
particularly non-functional ones) have a global scope in
that their satisfaction cannot be allocated to a discrete
component.

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 15

 Components of SW Requirements
Business
Requirement

Vision and Scope Document

User Quality
Requirement Attributes
Other
Use Case Document Non Functional
Requirement
System Functional
Requirement Requirement Constraints*

restrictions
SW Requirement Spec (SRS)

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 16

(2) Conceptual Modeling
‰ Conceptual models comprise models of entities
from the problem domain configured to reflect
their real-world relationships and dependencies.
These include:
™ data and control flows,
™ state models,
™ event traces,
™ user interactions,
™ object models and many others.
‰ The issue of modeling is tightly coupled with that
of methods. Methods and notations come and go in
fashion.
Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 17
(3) Architectural Design and Requirements Allocation
‰In many cases, the requirements engineer
acts as system architect because the process of
analyzing and elaborating the requirements
demands that the subsystems and components
that will be responsible for satisfying the
requirements be identified.
‰This is requirements allocation – the assignment of
responsibility (for satisfying requirements) to
subsystems.

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 18

 Structured Design Example:
Level 0 <Context> DFD
processing
user request requested
digital video
video signal
monitor
processor
video
source NTSC
video signal

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 19

 The Data Flow Hierarchy

a b
x P y level 0

a c p2
p1
f

d p4 p5 b
p3 e g
level 1

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 20

 Hierarchy of DFDs
Shipment
Orders Advice
Sales
Customers Manag Warehouse
System Orders
Invoices
1.1
Context Diagram Check Credit
(Level 0) Limit
1 Verified Overlimit
Orders Verify Rejected Orders Orders
Order Orders 1.2
Revise/Auth
Verified Orders oris Order
2 Rejected
Accept Orders
Invoices Shipment Advice
Order Verify Order DFD
Sales Management DFD (Level 1) (Level 2 )
Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 21
 DFDs: A Look Ahead

analysis model

Maps onto
design model

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 22

 Process/SW Specification (PSPEC)
bubble

PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 23

 A Design Note

PSPEC one or more ”components"

in the software design

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 24

 Creating Mini-Specs (SRS)

Software
Specification

Dr. Arshad A Shahid FAST-NU Islamabad Spring 2009 25