Requirements Engineering

&
Analysis, Specification,
Modeling
Fall 2009
SEN-261 : Software Engineering
Tazeen Muzammil
 Introduction to
Requirements
Definition
“A feature of the system or a description of
something the system is capable of doing in order to
fulfill the system’s purpose”

Strengths
1) Must/Shall 2) Should 3) Will

Goal:
To understand the problem in terms of the following:
- Organization - Existing Systems
- Processes - Improvements
Requirement Engineering, Analysis,
Specification & Modeling 2
Requirements Engineering
REQUIREMENTS
REQUIREMENTS ELICITATION DEFINITION
AND ANALYSIS AND SPECIFICATION

Problem Problem Prototyping Documentation

analysis description and testing and
validation

Have we captured Are we using Is this function Have we captured

all the user need? the right feasible? what the user
techniques or expects?
views?

Requirement Engineering, Analysis,

Specification & Modeling 3
 User Requirements
Definition

1.LIBSYS shall keep track of data

required by copyright licensing
agencies in the UK and elsewhere.

Requirement Engineering, Analysis,

Specification & Modeling 4
 System Requirements
Specification
1.1. On making a request for a document from LIBSYS, the
requestor shall be presented with a form that records
details of the user and the request made’
1.2. LIBSYS request form shall be stored on the system for five
years from the date of the request.
1.3. All LIBSYS request forms must be indexed by user, by the
name of the material and by the supplier of the request.
1.4. LIBSYS shall maintain a log of all requests that have been
made to the system.
1.5. For material where authors lending rights apply loan
details shall be sent monthly to copyright licensing
agencies that have registered with LIBSYS.

Requirement Engineering, Analysis,

Specification & Modeling 5
 Functional and non-
functional requirements
Functional requirements
Statements of services the system should provide, how
the system should react to particular inputs and how the
system should behave in particular situations.

Non-functional requirements
Constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.

Domain requirements
Requirements that come from the application domain of
the system and that reflect characteristics of that domain

Requirement Engineering, Analysis,

Specification & Modeling 6
 Non-functional
requirements
Define system properties and constraints e.g.
reliability, response time and storage
requirements. Constraints are I/O device capability,
system representations, etc.
Process requirements may also be specified
mandating a particular CASE system, programming
language or development method
Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system is useless

Requirement Engineering, Analysis,

Specification & Modeling 7
 Classification of Non-
functional
Product requirements
Requirements which specify that the delivered
product must behave in a particular way e.g.
execution speed, reliability, etc.
Organisational requirements
Requirements which are a consequence of
organisational policies and procedures e.g. process
standards used, implementation requirements, etc.
External requirements
Requirements which arise from factors which are
external to the system and its development process
e.g. interoperability requirements, legislative
requirements, etc.

Requirement Engineering, Analysis,

Specification & Modeling 8
 Classification of Non-
functional
Non-functional
requirements

Product Organizational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements Requirement Engineering, Analysis, requirements requirements
Specification & Modeling 9
 Non-functional
requirements
Examples:
• Product Requirements
8.1. The user interface for LIBSYS shall be implemented as
simple HTML without frames or JAVA applets.
• Organizational Requirements
9.3.2. The system development process and deliverable
document shall conform to the process and deliverables
defined in XYZ-CO-SP-STAN-95.
• External Requirements
10.6. The system shall not disclose any personal information
about system users apart from their name and library
reference number to the library staff who use the system.

Requirement Engineering, Analysis,

Specification & Modeling 10
Functional requirements
Describe functionality or system services

Depend on the type of software, expected users

and the type of system where the software is used

Functional user requirements may be high-level

statements of what the system should do but
functional system requirements should describe the
system services in detail

Requirement Engineering, Analysis,

Specification & Modeling 11
 Functional requirements

Examples:
1. The user shall be able to search either all the initial set
of databases or select a subset from it.
2. The system shall provide appropriate viewers for the
user to red document in the document store.
3. Every order shall be allocated a unique identifier(ORDER-
ID) which the user shall be able to copy to the accounts
permanent storage area.

Requirement Engineering, Analysis,

Specification & Modeling 12
Classification of Functional
Requirements
User requirements
Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers
Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge

Software specification
A detailed software description which can serve as a
basis for a design or implementation. Written for
developers

Requirement Engineering, Analysis,

Specification & Modeling 13
Classification of Functional
Requirements
System requirements
A structured document setting out detailed
descriptions of the system services. Written as a
contract between client and contractor
More detailed specifications of user requirements
Serve as a basis for designing the system
May be used as part of the system contract
System requirements may be expressed using
system models.

Requirement Engineering, Analysis,

Specification & Modeling 14
Classification of Functional
Requirements

Requirement Engineering, Analysis,

Specification & Modeling 15
Requirement Engineering
Steps
1. Requirement Elicitation
2. Requirement Analysis
3. Requirement Specification
4. System Modeling
5. Requirement Validation
6. Requirement Management

Requirement Engineering, Analysis,

Specification & Modeling 16
Requirements Elicitation
Requirements elicitation is the
practice of obtaining the
requirements of a system from
users, customers and other
stakeholders.
The practice is also sometimes
referred to as requirements
gathering.
Requirement Engineering, Analysis,
Specification & Modeling 17
Requirements Elicitation
Types Requirements Elicitation
Techniques:
1. Application Specification Techniques
Interview, Group Meeting
1. Quality Function Deployment
Survey, S/W review, Interview
1. Use Case
Interview, Observation

Requirement Engineering, Analysis,

Specification & Modeling 18
Requirements Elicitation
Techniques
Interview / Meeting
Survey / Questionnaire
Braining Storming and idea reduction
Review Internal / External Documents
Review Software
Observation
Business Plan
Requirement Engineering, Analysis,
Specification & Modeling 19
 Requirements Analysis
Goal
To bridge the gap between the problem domain
and the technical domain
Requirements analysis, also called requirements engineering, is
the process of determining user expectations for a new or
modified product.
Requirements analysis involves frequent communication with
system users to determine specific feature expectations,
resolution of conflict or ambiguity in requirements as demanded
by the various users or groups of users, avoidance of feature
creep and documentation of all aspects of the project
development process from start to finish.
Requirements analysis is a team effort that demands a
combination of hardware, software and human factors
engineering expertise as well as skills in dealing with people.

Requirement Engineering, Analysis,

Specification & Modeling 20
 Requirements Analysis
Tasks
Problem Recognition
Evaluation and Synthesis
Modeling
Specification
Review

Requirement Engineering, Analysis,

Specification & Modeling 21
 Requirements
Specification
Goal
To provide a representation of the software for
the customer’s review and approval

Software requirements document (or SRS) is the official

statement of what the system developers should implement.
It should include both the user requirements for a system and
a detail specification of the system requirements.
It is NOT a design document. As far as possible, it should set of
WHAT the system should do rather than HOW it should do it

Requirement Engineering, Analysis,

Specification & Modeling 22
Users of a Requirements
Document
Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Use the requirements to

System engineers understand what system is to
be developed

System test Use the requirements to

engineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts
Requirement Engineering, Analysis,
Specification & Modeling 23
 S/W Requirement
Specification
Introduction
(SRS)
Functional Requirements Definition
Non-functional Requirements Definition
System Model
Information Description
Functional Description
Behavioral Description
Validation Criteria
Bibliography
Appendix & Glossary
Requirement Engineering, Analysis,
Specification & Modeling 24
Requirements Validation

Goal
Requirements validation examines the
specification to ensure that the system
requirements have been stated
unambiguously; that inconsistencies,
omissions and errors have been detected
and corrected.

Requirement Engineering, Analysis,

Specification & Modeling 25
 Requirements Review
The primary requirements validation
technique is review:
Conducted by both software developer
and customer
Once review is completed, SRS is signed
off by both the parties.
After approval the specification becomes a
‘Contract’ for software development

Requirement Engineering, Analysis,

Specification & Modeling 26
Requirements Review?
Are the requirements complete?
Are the requirements concise?
Are the requirements correct?
Are the requirements consistent?
Are the requirements modular? Can they
accommodate change?
Are the requirements realistic?
Is the requirement needed by the customer?
Are the requirements traceable?

Requirement Engineering, Analysis,

Specification & Modeling 27
 Requirements
Management

Goal
Requirements management is a set of
activities that help the project team to
identify, control, and track requirements
and changes to requirements at any time
as the project proceeds.

Requirement Engineering, Analysis,

Specification & Modeling 28
 Analysis Methods &
Models

Analysis Method:
Structured Analysis
Object-Oriented Analysis
Modeling Techniques:
Data Modeling (Entity Relation Diagram)
Processing/Function Modeling (Data Flow Diagram)
Control/Behavior Modeling (State Transition Diagram)

Requirement Engineering, Analysis,

Specification & Modeling 29
Structured Analysis

Requirement Engineering, Analysis,

Specification & Modeling 30
Object-Oriented Analysis

Requirement Engineering, Analysis,

Specification & Modeling 31
Requirements Analysis:
Structured Techniques

Requirement Engineering, Analysis,

Specification & Modeling 32
 Data Modeling - ERD
Data objects, attributes and relationships
Cardinality and Modality (Crow Foot Notation)
Entity Relationship diagram (ERD)

Entity Relationship Entity

Doctor Treats Patient

Requirement Engineering, Analysis,

Specification & Modeling 33
 Data Flow Diagrams
Graphical representation that
depicts information flow and the
transforms that are applied as data
moves from input to output
Concepts:
Context Diagram / Level 0 Diagram
Leveling
Balancing
Process Specification

Requirement Engineering, Analysis,

Specification & Modeling 34
 DFD symbols
External Producer/Consumer of
Entity information outside
the bounds of the
system
Process Transformer of
information
Data item or
Data collection of data
Item items
Repository of data
Data Store stored for one or
more processes

Requirement Engineering, Analysis,

Specification & Modeling 35
State Transition Diagrams
Represent states
State
of the system

Transitions
between states;
activities that
trigger state
change

Requirement Engineering, Analysis,

Specification & Modeling 36
Requirements Analysis: 
Object-Oriented
Techniques

Requirement Engineering, Analysis,

Specification & Modeling 37
 Object Model
ClassName
Attribute 1
Basic class model
Attribute 2 includes name,
Attribute N
attributes, &
Operation 1
Operation N
operations

Superclass
Inheritance
discriminator

Subclass1 Subclass2

Requirement Engineering, Analysis,

Specification & Modeling 38
 Object Model
AssemblyClass Aggregation

Part1-Class Part2-Class

Class Exactly one

Multiplicity of
Associations
Class Many/Optional

1..* One or more

Class

Requirement Engineering, Analysis,

Specification & Modeling 39
 Object Modeling Steps
Identify objects and classes
Prepare a data dictionary
Identify associations between objects
Identify attributes of objects and links
Organize and simplify object classes using
inheritance
Verify that access paths exist for likely queries
Iterate and refine the model
Group classes into modules

Requirement Engineering, Analysis,

Specification & Modeling 40