1. Requirements
Engineering
Indri Sudanawati Rozas
April 2012

2. Activities?
Feasibility Requirements
study elicitation and
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
U and system
ser
requirements
Requirements
document

3. Requirements analysis
• Sometimes called requirements elicitation
or requirements discovery
• Involves technical staff working with
customers to find out about the application
domain, the services that the system should
provide and the system’s operational
constraints
• May involve stakeholders: end-users,
managers, engineers involved in
maintenance, domain experts, trade unions,
etc.

4. Requirements Analysis
• Acquire understanding about the problem domain
characteristics and problem to find the solution
• It is an information-acquiring, -collating, and –structuring
process through which one attempts to understand all the
various parts of a problem and their relationships.
• Basic Issues:
– How to effectively elicit a complete set of requirements
from the customer or other sources?
– How to decompose the problem into intellectually
manageable pieces?
– How to organize the information so it can be understood?
– How to communicate about the problem with all the parties
involved?
– How to resolve conflicting needs?
– Ho to know when to stop?

5. Analysis Principles
Each analysis method has a unique point of view.
All analysis methods are related by a set of operational principles:
• represent and understand the information domain
• define the functions that the software
• represent the behavior of the software
• use models to depict information, function, and behavior
--> uncover the details in a layered fashion.
• move from essential information toward to details
A set of guidelines for requirement engineering:
•understand the problem before beginning to create the analysis model
•develop prototypes to help user to understand how human-machine
interactions
•record the origin of and the reasons for every requirement
•use multiple views of requirements
•prioritize requirements
• work to eliminate ambiguity

6. The Information Domain
• Software is built to process data, to transform data from one
form to another.
• Software also process events.
• The first operational analysis principle requires to exam the
information domain.
• Information domain contains three different views of the data
and control:
– information content and relationship:
information content --> represent the individual data and control objects
– information flow:
represents the manner in which data and control change as each moves
through a system. Data and control moves between two transformations
(functions)
– information structure:
represent the internal organization of various data and control items
• data tree structure
• data table (n-dimension)

7. The requirements analysis process
Requirements
definition and
Requirem ents specification
validati
on
Domain
Prioritization
understanding
Process
entry
Requirements Conflict
collection resolution
Classification

8. System models
• Different models may be produced during the
requirements analysis activity
• Requirements analysis may involve three structuring
activities which result in these different models
– Partitioning. Identifies the structural (part-of)
relationships between entities
– Abstraction. Identifies generalities among
entities
– Projection. Identifies different ways of looking at
a problem
• Using modeling techniques, e.g. UML

9. System Requirements Analysis Consideration
http://www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf

10. Requirements Analysis
Fundamental Techniques (Views)
• functional view
– hierarchy - function tree
– process  use cases
– information ow  data flow diagram (DFD)
• data oriented view
– data structures  data dictionary (DD), syntax diagram, Jackson
diagram
– relations between entities  entity relationship diagram (ER)
• object-oriented view
– class structure  class diagram
• algorithmic view
– control structures
– pseudo code, structogram, flow diagram, Jackson diagram
– conditions  rules, decision table
• state-oriented view
– state machines
– Petri nets
– sequence charts

11. Methods for Requirements Analysis
1. Structured Analysis
2. Object Oriented Analysis
3. Problem Domain Oriented Analysis
4. Viewpoint Oriented Analysis

12. 1. Structured Analysis
• Centered upon modeling the pre-existing system
– Process
– Data flow
– Structure of data stored
• Weakness:
– Downplay the study of the problem domain
– Requirements are specified in term of design
– Lack of sharp boundary between analysis and
design encourage premature design
– Functional specification is absent
– Ill-suited for certain (not rarely) types of
application

13. 2. Object Oriented Analysis
• It’s not really an analysis:
– It requires pre-existing requirements document
and behaviour specification.
• High-level, architectural, design of the solution
system.
• OOA Outline:
– Identify object classes within the problem
domain
– Define the attribute and methods of those
classes
– Define the behaviour of those classses
– Model the relationships between those classes

14. 2. Object Oriented Analysis
• Three perspective of class model
– Specification (i.e. interface classes)
– Conceptual (i.e. problem domain classes
– related to analysis)
– Implementation (i.e. related to internal
design)

15. 3. Problem Domain Oriented Analysis
• Centered on modeling the problem context
– Problem frames: capture significantly more
information about the problem domain
• Less modeling, more description, procedure:
– Collect basic information and develop problem
frame(s) to establish the type of the problem
domain
– Collect further detail and develop description of
the relevant characteristics of the problem
domain
– Collect and document the requirements for the
new system

16. 3. Problem Domain Oriented Analysis
• Type of problem domain:
– Workpiece system – perform directed operations upon
objects that exist only within the system
– Control system – control the behavior (required-
commanded) of part of the problem domain
– Information system – provide information (automatically-
responsively) about the problem domain
– Transformation system – transform input data in a
particular format into output data in a corresponding,
particular format
– Connection system – maintain correspondence between
sub-domains that are not directly connected

17. 4. Viewpoint-oriented analysis
• Stakeholders represent different ways of looking
at a problem or problem viewpoints
– different types of stakeholders
– different views among stakeholders of same type
• This multi-perspective analysis is important as there
is no single correct way to analyse system
requirements

18. Multiple problem viewpoints
Problem
to be
analysed

19. Requirements vs. Design
Requirements Design
Describe what will be delivered Describe how it will be done
Primary goal of analysis: Primary goal of design:
UNDERSTANDING OPTIMIZATION
There is more than one solution There is only one (final) solution
Customer interested Customer not interested (Most of
the time) except for external