Chapter 8

Requirement Engineering Techniques

By Seffi G.
 Agenda
 Introduction
 Properties of RE methods
 RE methods
 Data-flow modeling methods
 Semantic data modeling methods
 Object-oriented methods
 Formal methods
 Viewpoint-oriented requirements
methods
 Structured Analysis and Design technique (SADT)
 Controlled Requirement Expression (CORE)
 Viewpoint oriented system Engineering (VOSE)
Introduction
 Process of requirements engineering is
usually guided by a requirements method
 Requirement methods are systematic ways of
producing system models
 System models are important bridges
between the analysis Associated with the
method usually there is a notation that
provides a means for expressing the
requirements
 Requirement engineering methods should
posses certain properties
 To effectively address the difficult problem of
establishing an adequate set of requirements
 Properties of RE methods
Necessary properties for a RE method
 Suitability for agreement with the end-user
 The notation should be understandable for someone
without training
 Include both formal & informal description for the
requirements
 The precision of definition of its notation
 The extent to which requirements may be checked for
consistency & correctness using the notation
 Assistance with formulating requirements
 Must be guided by a problem analysis techniques
 Scope for integrating other approaches
 No requirement approach adequately articulate all
requirements of a system
 A RE method should be able to support the incorporation
of other modeling techniques
Properties of RE methods…
 Definition of the world outside
 Therequirement model is incomplete unless the
environment with which the component interacts is
modelled.
 Scope for malleability(flexibility)
 Mustbe tolerant of temporary incompleteness and
adaptable to changes in the nature of the needs
being satisfied by the component
 Scope for communication
 Needs
to be able to support the need for people to
communicate their ideas and obtain feedback
 Tool support
 Notations
& methods supported by tools to manage
complexity and to deal large volume of information
 RE method

 There are various requirement engineering

methods
 Data-flow modeling method
 Semantic data modeling method
 Object-oriented methods
 Formal methods
 Viewpoint-oriented methods
 However, there is no ideal requirement method
 A number of methods use a variety of modelling
techniques to formulate system requirements
 DFDs
 focuses on how data moves through a system.
 It models the processes that transform data and the storage
locations that hold data.
 particularly useful for systems where data transformation is
a core aspect of its functionality.
 The main representation is through Data Flow Diagrams
(DFDs) which show inputs, processes, outputs, and data
stores.
• Strengths:
 • Intuitive for understanding data movement.
 • Good for visualizing process interactions.
 • Effective for systems with straightforward data flow.
 • Weaknesses:
 • Not ideal for representing complex control logic.
 • Can become complex and difficult to manage for large
sysms.
 • May not represent data structures with equal ease.
 Data-flow modeling method
User database

user details
update details
Library
card update
Check
user
user
details

UserID
Library User status
user
requested
ItemID
item Check
Item
item
status
issued return date
Issue Library
item
item assistant

item details
Update details

Item database

Library example - Level 1 data flow

 Semantic Data Modeling
 focuses on capturing the meaning and relationships between
data elements. It's not just about the how data flows, but the
what data represents.
 Key tools are Entity-Relationship Diagrams (ERDs). It

emphasizes identifying entities, their attributes, and

relationships between those entities.
• Strengths:
 • Excellent for understanding complex data relationships.
 • Provides a solid foundation for database design.
 • Helps in creating consistent and accurate data models.
• Weaknesses:
 • Less focused on process flow or functionality.
 • Can be more time-consuming during initial data analysis
and modeling.
 • Might need to be combined with other methods for
comprehensive modeling.
 Semantic model
Identifier Source Description Type Priority

Requirement Specification
1

has
(0,N)
1,N
N
Identifier Changes result in Version

description author

rationale

ERM for Software requirement

 Object Oriented methods
 This method views the system as a collection of interacting
objects. Objects encapsulate data (attributes) and behaviors
(methods).
 Key concepts are classes, objects, inheritance, polymorphism,

and encapsulation. UML diagrams are often used to represent

the structure and behavior of the system.
• Strengths:
 • Good for code reusability and maintainability.
 • Flexible for modeling complex systems.
 • Real-world problem representation tends to be more
natural.
• Weaknesses:
 • Can be complex for very simple systems.
 • Requires a deep understanding of OOP concepts.
 • Can sometimes lead to over-engineering if not applied
carefully.
 Object-oriented method
 There are various requirements methods based
on object orientation
 Shlaer and Mellor (1988), Colbert (1989), Coad and
Yourdon (1989), Wirf-Brock (1990), Rumbaugh
(1991), Jacobson (1992), Martin-Odell (1992)
 Most methods based on the object-oriented
model share certain common analysis steps:
 Identify core objects
 Construct the object structures defining the
associations between object classes
 Define the attributes associated with each object
 Determine the relevant operations for each object
 Define the messages that may be passed between
objects
 Object modeling - Library

example
A library system is intended to provide its users with the ability to
automate the process of:
 Acquiring library items
 Cataloguing library items
 Browsing library items
 Loaning library items
 Library items comprise published and recorded material
 The system will be administered by a member of the library staff
 Users must register with the system administrator before they
can borrow library items
 Library users are drawn from three primary groups:
Students, Members of staff and External users
 All library users have as part of their registration:
Name, Library number, Address, Account, Students - Degree
programme and admission number, Staff - Staff number ,
External users - Employer details
 Initial classes identified
Library user Library item Library staff Account

Relationships between classes are identified

We can identify the following relationships from
the partial requirements:
(i) A library user borrows a library item
(ii) A library item is recorded or published
(iii) The system administrator registers the library user
(iv) Library users are students, staff and external users
(v) The system administrator catalogues the library
items
(vi) The library assistant issues the library items
Basic object model showing attributes and
relationships
Inheritance for Library user & item
Identifying the attributes
 Attributes can be revealed by the analysis of the
system requirements
 For example, it is a requirement that all library
users must be registered before they can use the
library
 This means that we need to keep registration

data about library users

 Library users may also be provided with an

account to keep track of the items loaned to

them
 Library item has the attributes; title, description
and classmark
 The library user class has the attributes; name,
address and library id
 Determine Object operations
 to describe operations to be performed on the
objects
 Certain operations are implicit from the object
structure
 These include operations for accessing and

modifying the attribute values. These

operations are assumed and we need not show
them explicitly in the model
 One way of identifying operations is by
modelling the messages thatMessages
may be passed
between
between the objects objects
Operations for library user and
library staff
Define the messages that may be passed
between objects
 Object operations may also be identified

by modelling event scenarios for the

different functions provided by the system
 Events are then traced to objects that react
to them
 Typically scenarios model the interactions
between the users and the system
 Formal methods

 Requirements specification techniques can be

categorised on a “formality” spectrum
 Semi-formal and informal methods
 Use natural language, diagrams, tables and simple
notation
 Include structured analysis and object-oriented
analysis
 Formal methods include:
 Based on mathematically formal syntax and
semantics
 Include Z, VDM (Viena development method),
LOTOS(Language Of Temporal Ordering Specification)
 Z: Good for systems where precise specification
of state transitions and data relationships is
critical (e.g., safety-critical systems). It also
focuses on state-based modelling.
 VDM: Good for systems that deal with data
transformations, state changes and algorithmic
details
 Use LOTOS when you need to formally specify
and analyze the dynamic interactions and
communication patterns of a concurrent system,
especially where timing and sequencing of
actions are important.
 Key Differences Summarized:

| Feature | LOTOS | Z Notation | VDM

 ---------------------------- | --------------------------------------- --------------------|
 | Primary Focus | Concurrency, Communication, Time Ordering
| Data structures and relationships, State changes | Data
transformations, Abstract data types, operations
|
 | Modeling Approach | Behavior of interacting processes |
State-based modeling with schemas | Function based
modeling with pre/post conditions |
 | Core Concepts | Process algebra, actions, events | Set
theory, logic, relations, schemas | Abstract data types, pre/post
conditions |
 | Strength | Concurrent and distributed systems | Data
intensive and High-Integrity Systems | Data Transformations
and Algorithmic behavior |
 Formal methods…
 Components of formal specification language
 Syntax that defines the specific notation with which
the specification is represented
 Semantics that help to define a “universe of objects”
that will be used to describe the system
 Relations which define the rules that indicate which
objects properly satisfy the specification
 Formal methods are not widely used amongst
software developers
 Factors contributing to slow acceptance of formal
methods:
· Difficulty in understanding the notations
· Difficulty in formalising certain aspects of requirements
· Payoff is not obvious.
“payoff is not obvious”
 developers and project managers might
resist adopting formal methods, viewing
them as a high-risk/low-reward
approach.
 They might perceive the added upfront
effort as unnecessary, especially if the
perceived benefits are long-term and
difficult to quantify.
 The lack of immediate and readily visible
benefits often makes it difficult to justify
the time and cost involved.
 Formal methods…
 The number of formal specification languages in use today
can be broadly divided into two categories.
 Model-based notations - Z and VDM
 Process algebras -based notations – CSP(communicating
sequential process), CCS(Calculus of Communicating Systems)
and LOTOS
 Advantages of formal methods
 Removes ambiguity
 Encourages greater rigor in the early stages of software engineering
 Possible to verify the correctness, incompleteness and
inconsistency checking of the specification
 Disadvantages of formal methods
 Difficult to represent behavioural aspects of problem
 Some requirements can only be determined through empirical
evaluation and prototyping
 Do not address the problem of how the requirements are
constructed
 Lack of adequate tool support
Viewpoint-oriented requirements
methods
 RE involves the capture, analysis and
resolution of many ideas, perspectives and
relationships at varying levels of detail
 RE needs looking at the requirements from
multiple viewpoints
 Methods based on rigid global schemes do
not adequately address the diversity of issues
presented by RE problems
 It is built on the premise that requirements
should be collected and indeed organized
from a number of different viewpoints.
 Viewpoint-oriented requirements
methods…
 Consider the requirements for a system to be
installed on a train which will automatically bring the
train to a stop when it wrongly goes through a
danger signal
 Some examples of viewpoints for this system :
 Driver : Requirements from the train driver on the
system
 Trackside equipment: Requirements from trackside
equipment which must interface with the system to
be installed
 Safety engineer: Safety requirements for the system
 Existing on-board systems: Compatibility
requirements
 Braking characteristics: Requirements which are
derived from the braking characteristics of a train.
 Viewpoint-oriented requirements

methods…
Advantages of viewpoint-oriented approaches
 They explicitly recognise the diversity of sources of
requirements
 They provide a mechanism for organising and structuring this
diverse information
 They imparts a sense of thoroughness (completeness)
 They provide a means for requirements sources or stakeholders
to identify and check their contribution to the requirements
 There are requirement methods that have adopted view-
oriented schemes for formulating and managing
requirements.
 Structured Analysis and Design technique (SADT)
 Controlled Requirement Expression (CORE)
 Viewpoint oriented system Engineering (VOSE)
 Viewpoint oriented Requirements Definition(VORD)
 There is no best method for RE & any of the methods may
be appropriate in different circumstances.
SADT viewpoints
 SADT was developed in the late 1970s
 The notation consists of a rectangle
representing some system activity and a set
of four arrows
 SADT does not have an explicit notion of
viewpoints User database Item database
 Instead viewpoints
User details are an intuitive extension of
Item availability

its modelling
[Library user]
technique
library card
I1
return date issued item [Library user]
Issue library item
[Issue clerk] 01
I2
requested item
[Library user] I3

In example “viewpoints” are shown in square

 Controlled requirements expression
(CORE)
 CORE was developed for the British Aerospace in the
late 1970s by System Designers
 The CORE method is based on functional
decomposition approach
 CORE is explicitly based on viewpoints
 CORE defines its viewpoints at two levels
 Defining viewpoints
 Sub-processes of the system, viewed in a top-down manner
 Bounding viewpoints
 Entities that interact indirectly with the intended system
 The CORE method is made up of 7 iterative steps:
 Viewpoint identification Viewpoint structuring  Tabular
collection  Data structuring  Single viewpoint modelling
 Combined viewpoint modelling Constraint analysis
Step 1-Identifying viewpoints
 The first step involves identifying possible
viewpoints
 From this initial list, defining and bounding
viewpoints are identified
 There are no hard and fast rules for
Initial viewpoints
identifying relevant viewpoints
Library user Issue clerk Book User database

Validate user Issue item Video

Procure item Catalogue item
Return item Register user

Update item database Book supplier

Library card Item database
 Step 1-Pruning viewpoints…
 The last stage in viewpoint identification involves
pruning the identified viewpoints into a set of
bounding and defining viewpoints as shown in

Bounding Viewpoints Defining Viewpoints

Library user Register user Validate

user
User
database Issue item Return item
Issue clerk
Item
Catalogue item Order item
database
Book supplier
Update item
database

 Each bubble represents the most abstract form of

the viewpoint
Step 2 - Viewpoint structuring
 Involves iteratively decomposing the ‘target
system’ into a hierarchy of functional sub-
systems
 Structurally bounding viewpoints are placed
at the same level as the target system
 Each functional Library
subsystem
World constitutes a
viewpoint
Library user Book supplier Library system Item database User database

Register function Issue function Update Order

functions functions
Step 3 - Tabular collection
 A mechanism for gathering information
about a viewpoint
 Each viewpoint is considered in turn with
respect to the action it performs
 Data used for these actions, the output data
derived, the source of the data and the
destination of the data
 Tabular collections serve the purpose of
exposing omissions and conflicts in the
Source Input Action Output Destination
information flow across viewpoints
Library user requested check item issued item Library user
item
error message Issue clerk
Library user library card validate user loan default message Issue clerk
 Steps 4-7
 The data structuring step involves decomposing data
items into constituent parts and creating a data
dictionary
 Step 5 and 6 involve modelling viewpoint actions using
action diagrams
 An action diagram is similar in notation to an SADT
diagram
 The final step in CORE involves performing constraint
analysis on the system as a whole
 Problems with CORE
 Poorly defined notion of a viewpoint
 Difficult to say what is and what is not a valid viewpoint
 Analysis focuses on internal perspectives - defining
viewpoints
 Bounding viewpoints not analysed beyond been seen as
sinks and sources of data
 Difficult to integrate other requirements methods
 Viewpoint-oriented system

engineering (VOSE)
Developed at Imperial College, London in the early
1990s
 Viewpoint-oriented system engineering is a framework
for integrating development methods
 VOSE uses the notion of viewpoints to partition and
distribute the activities and knowledge of the
participants in software development
 Viewpoints capture the role and responsibility of a
participant at a particular time
 A Viewpoint can be thought of as a template describing:
 Style or representative scheme what it sees
 Domain
 Specification
 Work plan
 Work record
 Viewpoint-oriented system
engineering…
 Standard viewpoint template slots

 Viewpoint configurations
 Viewpoints can be organised into configurations
 A configuration may consist of
 Templates with different styles, ‘viewing’ the same
partition of the problem domain, or
 Templates with the same style ‘viewing’ different
partitions of the problem domain
 Viewpoint-oriented system
engineering…
Library example
 Consider a library item presented the user at
the issue desk for borrowing, returning or
reserving
 ‘Library world’ can be partitioned into the
domains of the issue desk and the library user
 Data-flow and state transition schemes are
used to model the library item from point of
view each domain

Data-flow model -Issue desk domain

Viewpoint-oriented system
engineering…

State transition model -Issue

Desk Domain

State transition - Library user domain

 Conflict resolution
 Important to ensure that consistency between
different representations of the domains
 For similar styles conflicts are resolved by
checking for the loss of continuity between the
models
 For different styles the correspondences between
representation schemes need to be identified to
facilitate consistency checking
Conflict resolution…

Mapping on
Correspondence between different
transition and function styles same
domain

Mapping on different
Correspondence domains same style
between state and
Viewpoint-oriented requirements definition

 a method specifically focused on defining

requirements from different viewpoints.
 It emphasizes the systematic identification,
specification, and structuring of requirements from
each viewpoint.
 VORD encourages the use of multiple representation
techniques, such as use cases, scenarios, and data
models, to capture all aspects of a system.
 The system requirements are created based on these
different views.
 Developed at the University of Lancaster intended
for specifying interactive systems
Viewpoint-oriented requirements
definition

 VORD defines two main types of viewpoints;

direct and indirect
 Direct viewpoints
 Interact directly with the intended system
 Correspond directly to clients in that they receive
services the system and provide control
information
 Include operators/users or other sub-systems
interfaced to the system being analysed
 Example: A library user viewpoint which is
concerned with accessing the system services
through the internet (direct)
 Viewpoint-oriented requirements
definition…
Indirect viewpoints
 Do not interact directly with the intended system
 Indirect viewpoints have an ‘interest’ in some or
all the services which are delivered by the system
 Generate requirements which constrain the
services delivered to direct viewpoints
 Includes organisation, environment, engineering
and regulatory viewpoints
 Examples:
A systems planning viewpoint which is concerned
with future delivery of library services (indirect)
 A trade-union viewpoint which is concerned with the
effects of system introduction on staffing levels and
library staff duties (indirect)
 Viewpoint-oriented requirements
validation
 Uses viewpoints to support early requirements
validation
 Objective of the approach is identify and classify
problems related to completeness and correctness
 Viewpoints, perspectives and views
 Viewpoint is defined as a standing position used by
an individual when examining a universe of discourse
 A perspective is defined as a set of facts observed
and modelled according to a particular aspect of
reality
 A view is defined as an integration of these
perspectives
 A viewpoint language is used to represent the
viewpoints
 Method steps
 Involves at least two analysts (viewpoints) using
VWPL
 A view is constructed by describing the problem
using three perspectives; data, process and actor
perspectives
 Analysts use the is-a and part-of hierarchies to
improve their own view
 Perspectives and hierarchies are analysed and a ‘list
of discrepancies’ and ‘types of discrepancies’
produced
 Perspectives are integrated into a view

 Expressed in the process perspective together with

the hierarchies
 After two views are available compare the different

viewpoints for correctness and completeness

Comparisons
These viewpoint-oriented techniques offer structured
and systematic
approaches for capturing and managing diverse
requirements in
complex systems like ERP.
Each technique has its own strengths and can be
used effectively to
manage specific needs related to viewpoints
View Vs Perspective
View point Validation
 the process of checking that the
requirements captured from a particular
viewpoint are correct, complete, and
consistent with ….
 ensures that there are no contradictions
or conflicts within the viewpoint's set of
requirements, and between the
viewpoints when integrated
 helps you confirm that what you think
you heard is indeed what the
stakeholder mean