TE2104

Software Requirements
Engineering

Topic 7:
Requirements Analysis I
 Contents
• Requirements Analysis
– Models
• System Modelling
– UML Diagram Types
• Goal Diagram
• System and Context Boundaries
• Context Diagram
• Data Flow Diagram
 RECAP
Requirements Engineering Process
R equirements
Feasibility
elicitation and
study
analysis
R equirements
specification

Feasibility R equirements
r eport validation

System
models

User and system

requirements

R equirements
document
Requirements vs Design

CPRE-FL © Mathias Lampe

Requirements vs Design

CPRE-FL © Mathias Lampe

 What is Requirement
Analysis?
• Requirements analysis:
– specifies software’s operational characteristics (functional)
– indicates software's interface with other system elements
(functional & quality)
– establishes constraints that software must meet (quality &
constraints)

• It allows Requirements Analysts to:

– elaborate on basic requirements established during earlier
requirement engineering tasks.
– build analysis models that depict user scenarios and functional
activities.
 Models

Reality
(Universe of discourse)

Model
(Abstract Representation)
 Models
• Models are abstraction for a specific purpose.

Properties of models:
•Mapping of reality
•Reduction of reality
•Pragmatic property
 Why using models?
• Easier to understand selected information
– Pictures are easier to understand and memorise

• Record them more quickly Combination of

natural language
– Allow to focus on certain perspectives and models provide
advantages of both
• Document information unambiguously

FTSM has 8 blocks: A…H. Block A is

VS situated in between block B and E.
Block B is parallel with Block D bla bla
bla bla…
What is a Goal?
 What is a Goal?
• A goal
– High level objective of one or more stakeholders about a
property of the system to be developed or the
development project.

• A goal model
– A conceptual model that documents goals, their
decomposition into sub-goals and goals dependencies.
A Goal Model
A Goal Model
 System Modelling
• The process of developing abstract models of a system, with
each model presenting a different view or perspective of
that system.

• System modelling normally use some kind of graphical

notation. Currently, the Unified Modeling Language (UML)
has become the de facto standard.

• System modelling helps the requirements engineers to

understand the functionality of the system and models are
used to communicate with customers.
 System Modelling
• Models of the existing system clarifies what the existing system
does.
– Acts as a basis for discussing current strengths and weaknesses. Lead to
requirements for the new system.

• Models of the new system explains the proposed requirements to

other system stakeholders.
– Use these models to discuss design proposals and to document the system
for implementation.

• In a model-driven engineering process, it is possible to generate a

complete or partial system implementation from the system model.
 System Modelling
• To construct models, specific modelling languages are
used.
• A modelling language is defined by its syntax and
semantics.
– Syntax: elements to be used and how to combine them
correctly
– Semantic: meaning of the elements by which the
interpretation is made
APPLE
ALI
EAT
ORANGE PLAY

CAT ELEPHANT
Syntax
Semantic
ALI EATS AN APPLE
 System Modelling
Perspectives:
• An external perspective, where we model the context or
environment of the system.
• An internal perspective, where we model the insights of the
system :
– A process perspective

– An interaction perspective, where we model the interactions between a

system and its environment, or between the components of a system.
– A structural perspective, where we model the organisation of a system
or the structure of the data that is processed by the system.
– A behavioral perspective, where we model the dynamic behavior of the
system and how it responds to events.
 System Modelling
(UML Diagram Types)
External Perspective:
• Context diagram, which shows the environment of a system.
Internal Perspectives:
• Use case diagrams, which show the interactions between a system and its
environment. (Interaction – Functional)
• Activity diagrams, which show the activities involved in a process or in data
processing. (Process – Functional)
• Sequence diagrams, which show interactions between actors and the system
and between system components. (Interaction – Functional)
• Class diagrams, which show the object classes in the system and the
associations between these classes. (Structural – Data)
• State diagrams, which show how the system reacts to internal and external
events. (Behavioral)
 System Modelling

ERD
Use Case
Goal
DFD
diagram
Sequence

State diagram
 System Context
• The part of reality that is relevant for the requirements of a system.

• The possible aspects of reality influence the context of a system:

– People (stakeholders or groups of stakeholders)
– Systems in operation (other technical systems or hardware)
– Processes (technical or physical processes, business processes)
– Events (technical or physical)
– Documents (laws, standards, system documentation)

• If system context is incorrectly or incompletely considered, it may

result in incomplete and erroneous requirements and thus, leads to
system failure.
 System Context
Stakeholders Documents
(e.g. Law, regulation)

Business Process
& Events
Human interface

Hardware interface Software interface

SYSTEM

Hardware System Software System

System and Context Boundaries
• It is necessary to separate the system context from the system to
be developed as well as from the parts of reality that are irrelevant
for the system.

• Defining the system boundary:

– Which aspects pertain to the system to be developed and which aspects

belong in the system context?

• Defining the context boundary:

– Which aspects pertain to the system context (i.e. have relation to the
system to be developed) and which aspects are part of the irrelevant
environment?
System and Context Boundaries

System Boundary
SYSTEM
CONTEXT

SYSTEM

IRRELEVANT ENVIRONMENT

Context Boundary
System and Context Boundaries

System
Boundary SYSTEM
CONTEXT

SYSTEM

The system boundary separates the system to be developed from its

environment.
•It separates the part of reality that can be modified or altered by the development process
from aspects of the environment that cannot be changed or modified by the development
process.
System and Context Boundaries
System Boundary:
• Established to define what is inside and what is outside the system.
– They show other systems that are used or depend on the system being
developed.

• The position of the system boundary has a profound effect on the

system requirements.

• Defining a system boundary is a political judgment.

– There may be pressures to determine system boundaries that
increase/decrease the influence or workload of different parts of an
organisation.
System and Context Boundaries

SYSTEM
CONTEXT

SYSTEM

IRRELEVANT ENVIRONMENT
Context Boundary

The context boundary separates the relevant part of the environment of a

system to be developed from the irrelevant part.
•The irrelevant part does not influence the system to be developed and thus does not
have to be considered.
System and Context Boundaries
Extended/Reduced
Context Boundary

SYSTEM
CONTEXT

SYSTEM

IRRELEVANT ENVIRONMENT
Original Context
Boundary
The gray zone is the vague separation of the system and the context as well as
the irrelevant environment. It may shift over time during the requirements
engineering process.
 How to Illustrate System Context?
• Option 1: Context Diagram

IRRELEVANT SYSTEM
ENVIRONMENT CONTEXT

SYSTEM
How to Illustrate System Context?
• Option 2: Use Case Diagram
Point of Sales

Process Sale

Customer
Payment
Authorization
Service
Handle Returns
SYSTEM
Cashier CONTEXT
«actor»
Cash In Money Accounting
System
Manager
«actor»
HR System

SYSTEM

IRRELEVANT
THESE ARE CALLED SYSTEM MODELS
ENVIRONMENT
 System Modelling
(UML Diagram Types)
Example: UML activity diagram
 System Modelling
(UML Diagram Types)
Example: UML sequence diagram
 System Modelling
(UML Diagram Types)
Example: UML class diagram
 System Modelling
(UML Diagram Types)
Example: UML statecharts
 Context Diagram
• A Context Diagram is used to illustrate the operational context
of a system.
– It shows what lies outside the system boundary.

• Social and organisational concerns may affect the decision on

where to position the system boundary.

• The diagram is a top-level view that shows the system and its
relationship with other systems (i.e. scope of the system).
 Context Diagram
Symbols to draw a Context Diagram:

Receives input data and produces output that has

a different content, form or both.

Represents one or more data items – a line with a

single or double arrowhead.

A rectangle, which may be shaded to make it look

three-dimensional. Name of the entity appears
inside the symbol.
 Context Diagram
Steps to draw a Context Diagram:
1.Start by placing a single process symbol in the center of the
page. The symbol represents the entire system, and identify it as
Process 0.

2.Place the system entities around the perimeter of the page.

3.Use data flows to connect the entities to the central process.

Context Diagram
 Context Diagram
Example:
1. Upon receiving the order from the customer, the order clerk checks for
the availability of the ordered items.
2. If any of the item is a discontinued item, then order reject notice is issued.
3. The picking list is generated and sent to warehouse. Upon receiving the
completed order from warehouse, the clerk issues the invoice to
customer.
4. Upon receiving the payment from the customer, the clerk calculates the
commission for the corresponding sales representative, deposit the
payment to the bank.
5. A cash receipts record is sent to accounting department.
Context Diagram
 Beyond Context Diagram –
Data Flow Diagram
• A Data Flow Diagram (DFD) shows how the system transforms
input data into useful information through a set of processes.
– What are the input data?
– What are the processes involved to transform the input data?
– Where the data is stored and retrieved?
– What are the output data?

• Illustrates how data moves through a system but does not show
program logic or processing steps.
– Provides a logical model that shows what the system does, not how it does
it.
 Beyond Context Diagram –
Data Flow Diagram
Symbols to draw a Data Flow Diagram:

Receives input data and produces output that

has a different content, form or both.

Represents one or more data items – a line

with a single or double arrowhead.

Represent data that the system stores

 Beyond Context Diagram –
Data Flow Diagram
Correct Use of Symbols to draw a Data Flow Diagram:
 Beyond Context Diagram –
Data Flow Diagram
Correct and Incorrect Use of Symbols of DFD:
 Beyond Context Diagram –
Data Flow Diagram
Steps to draw a Data Flow Diagram:
•Three-step process:
1. Draw a Context Diagram
2. Draw a DFD Level 0
3. Draw the lower-level diagrams
 Beyond Context Diagram –
Data Flow Diagram
Steps to draw a Data Flow Diagram:
2.Draw a DFD Level 0
– Level 0 is an exploded view of process 0 (context diagram).
– Level 0 zooms in the system and shows major internal process,
data flows, and data stores.
– Level 0 also repeats the entities and data flows that appear in the
context diagram.
– Must retain all the connections that flow into and out of process 0.
– If same data flows in both directions, use a double-headed arrow.
 Beyond Context Diagram –
Data Flow Diagram
Example: DFD Level 0 for an Order System
 Beyond Context Diagram –
Data Flow Diagram
Steps to draw a Data Flow Diagram:
3.Draw the lower-level diagrams
– Must use leveling and balancing techniques.
– Leveling
• Uses a series of increasingly detailed DFDs to describe a system.
– Balancing
• Ensures that the input and output data flows of the parent DFD
are maintained on the child DFD.
 Beyond Context Diagram –
Data Flow Diagram
Example: DFD Level 1 for an Order System
 Beyond Context Diagram –
Data Flow Diagram
Leveling DFD

Context Diagram

DFD Level 0

DFD Level 1
 Beyond Context Diagram –
Data Flow Diagram
Balancing DFD
DFD Level 0

Context Diagram
 Beyond Context Diagram –
Data Flow Diagram
Balancing DFD
DFD Level 1

DFD Level 0
 THANK YOU
• Question?
• Tutorial:
– Discuss and execute Elicitation (group project Phase
1)
– Case study – context D, DFD
– Project Goal model
• Next Lecture:
– Requirements Analysis II