Requirements readers

Clientmanagers
Systemendusers
Userrequirements Clientengineers
Contractormanagers
Systemarchitects

Systemendusers
Clientengineers
Systemrequirements
Systemarchitects
Softwaredevelopers

Clientengineers(perhaps)
Softwaredesign
Systemarchitects
specification
Softwaredevelopers
 Functional and non-functional
requirements
Functional requirements
How the system should react to particular
inputs and how the system should behave in
particular situations.
Non-functional requirements
Non-functional requirements are "constraints",
"quality attributes", "quality goals", "quality of
service requirements" etc.
Domain requirements
Requirements that come from the application
domain of the system and that reflect
characteristics of that domain
 Functional Requirements
It describe system functionality
Depends on the type of software, expected users
and the type of system where the software is used.

Requirements completeness and consistency

In principle requirements should be both
complete and consistent
Complete
They should include descriptions of all facilities
required
Consistent
There should be no conflict in the descriptions of the
system facilities
 Non-functional requirements
Define system properties and constraints e.g.
reliability, response time and storage requirements.
Process requirements may also be specified programming
language or development method
Non-functional requirements may be more critical than
functional requirements. If these are not met, the system is
useless
Product requirements
delivered product must behave in a particular way
e.g. execution speed, reliability, etc.
Organisational requirements
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
 Requirements engineering processes

Requirements engineering helps software

engineer to better understand the problem they
will work to solve.

The processes used for RE vary widely depending on the

application domain, the people involved and the organisation
developing the requirements.
 Requirements Engineering
Tasks
Seven distinct tasks
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements Management
Some of these tasks may occur in parallel and all are adapted
to the needs of the project
All strive to define what the customer wants
All serve to establish a solid foundation for the design and
construction of the software
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation
Requirements
Management

7
 Inception Task
During inception, the requirements engineer asks a set of
questions to establish
A basic understanding of the problem
The people who want a solution
The nature of the solution that is desired
The effectiveness of preliminary communication and collaboration
between the customer and the developer
Through these questions, the requirements engineer needs to
Identify the stakeholders
Recognize multiple viewpoints
Work toward collaboration
initiate the communication
 Elicitation Task
Eliciting requirements is difficult because of

Problems of scope in identifying the boundaries of the

system or specifying too much technical detail rather than
overall system objectives
Problems of understanding what is wanted, what the
problem domain is, and what the computing environment
can handle

Problems of volatility because the requirements change

over time

Elicitation may be accomplished through two

activities
Collaborative requirements gathering
Quality function deployment
 Elaboration Task
During elaboration, the software engineer takes
the information obtained during inception and
elicitation and begins to expand and refine it
Elaboration focuses on developing a refined
technical model of software functions, features,
and constraints
It is an analysis modeling task
Use cases are developed
Domain classes are identified along with their attributes
and relationships
State machine diagrams are used to capture the life on an
object
The end result is an analysis model that defines
the functional, informational, and behavioral
domains of the problem
 Negotiation Task
During negotiation, the software engineer
reconciles the conflicts between what the customer
wants and what can be achieved given limited
business resources
Requirements are ranked (i.e., prioritized) by the
customers, users, and other stakeholders
Risks associated with each requirement are
identified and analyzed
Rough guesses of development effort are made
and used to assess the impact of each requirement
on project cost and delivery time
Using an iterative approach, requirements are
eliminated, combined and/or modified so that each
party achieves some measure of satisfaction
The Art of Negotiation

Recognize that it is not competition

Map out a strategy
Listen actively
Focus on the other partys interests
Dont let it get personal
Be creative
Be ready to commit
 Specification Task
A specification is the final work product produced by
the requirements engineer
It is normally in the form of a software requirements
specification
It serves as the foundation for subsequent software
engineering activities
It describes the function and performance of a
computer-based system and the constraints that will
govern its development
It formalizes the informational, functional, and
behavioral requirements of the proposed software in
both a graphical and textual format
 Validation Task
During validation, the work products produced as a
result of requirements engineering are assessed for
quality
The specification is examined to ensure that
all software requirements have been stated
unambiguously
inconsistencies, omissions, and errors have been
detected and corrected
the work products conform to the standards
established for the process, the project, and the
product
The formal technical review serves as the primary
requirements validation mechanism
Members include software engineers,
customers, users, and other stakeholders
 Requirements Management
Task
During requirements management, the project
team performs a set of activities to identify,
control, and track requirements and changes to the
requirements at any time as the project proceeds
Each requirement is assigned a unique identifier
The requirements are then placed into one or more
traceability tables
These tables may be stored in a database

A requirements traceability table is also placed at

the end of the software requirements specification
Requirements engineering processes

Requirements engineering processes may include four high-level

activities.
If the system is useful to the business (feasibility study),

discovering requirements (elicitation and analysis),

converting these requirements into some standard form

(specification), and
checking that the requirements actually define the system that
the customer wants (validation).
 Feasibility studies
A feasibility study is a short, focused study that should take
place early in the RE process. It should answer three key
questions:

a)does the system contribute to the overall objectives of the

organization?

b) can the system be implemented within schedule and budget using

current technology? and

c) can the system be integrated with other systems that are used?
 Requirements elicitation and analysis

software engineers work with customers and system end-

users to find out about the application domain,what services
the system should provide, the required performance of the
system, hardware constraints, and so on.
 Requirements elicitation and analysis
The process activities are:

1. Requirements discovery
2. Requirements classification and
organization
3. Requirements prioritization and negotiation
4. Requirements specification
 Requirements elicitation and analysis
The process activities are:
1. Requirements discovery is the process of interacting with
stakeholders of the system to discover their requirements. Domain
requirements from stakeholders and documentation are also
discovered during this activity.

Requirements discovery (sometime called requirements

elicitation) is the process of gathering information about the
required system and existing systems

2. Requirements classification and organization takes the

unstructured collection of requirements, groups related
requirements, and organizes them into coherent clusters.
 Requirements elicitation and analysis
3. Requirements prioritization and negotiation when multiple
stakeholders are involved, requirements will conflict. This activity is
concerned with prioritizing requirements and finding and resolving
requirements conflicts through negotiation.

4. Requirements specification The requirements are documented and

input into the next round of the spiral.

Requirements elicitation and analysis is an iterative process with

continual feedback from each activity to other activities.
 viewpoint

A viewpoint is way of collecting and organizing a set of

requirements from a group of stakeholders who have something in
common.

Each viewpoint includes a set of system requirements.

Viewpoints might come from end-users, managers, etc. They help

identify the people who can provide information about their
requirements and structure the requirements for analysis.
 Interviewing

Formal or informal interviews with system stakeholders are part

of most requirements engineering processes.

In these interviews, the requirements engineering team puts

questions to stakeholders about the system that they currently use
and the system to be developed.
 Interviewing
Requirements are derived from the answers to these questions.
Interviews may be of two types:
1. Closed interviews, where the stakeholder answers a pre-defined set
of questions.
2. Open interviews, in which there is no pre-defined agenda. The
requirements engineering team explores a range of issues with
system stakeholders and hence develop a better understanding of
their needs.

Interviews are good for getting an overall understanding of what

stakeholders do,how they might interact with the new system, and
the difficulties that they face with current systems.
 Scenarios

Scenarios can be particularly useful for adding detail to an outline

requirements description.

They are descriptions of example interaction sessions. Each

scenario usually covers one or a small number of possible
interactions.

A scenario starts with an outline of the interaction. During the

elicitation process, details are added to this to create a complete
description of that interaction.
 Scenarios

a scenario may include:

1. A description of what the system and users expects when the

scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the
same time.
 Use cases

A use case is a methodology used in system analysis to identify,

clarify, and organize system requirements.

The use case is made up of a set of possible sequences of

interactions between systems and users in a particular
environment and related to a particular goal.

Use cases are documented using a high-level use case diagram.

The set of use cases represents all of the possible interactions that
will be described in the system requirements.
Use cases
 Ethnography

Ethnography is an observational technique that can be used to

understand operational processes and help derive support
requirements for these processes.

The day-to-day work is observed and notes made of the actual

tasks in which participants are involved.

The value of ethnography is that it helps discover implicit system

requirements that reflect the actual ways that people work, rather
than the formal processes defined by the organization.
 Requirements validation

Requirements validation is the process of checking that

requirements actually define the system that the customer really
wants.

finding problems with the requirements.

Requirements validation is important because errors in a

requirements document can lead to extensive rework costs when
these problems are discovered during development or after the
system is in service.
 Requirements validation

During the requirements validation process, different types of

checks should be carried out on the requirements in the
requirements document.

These checks include:

1. Validity checks : A user may think that a system is needed to

perform certain functions.

Systems have diverse stakeholders with different needs and any set
of requirements is inevitably a compromise across the stakeholder
community.
 Requirements validation

2. Consistency checks Requirements in the document should not

conflict. No contradictory constraints or different descriptions of the
same system function.

3. Completeness checks The requirements document should include

requirements that define all functions and the constraints intended
by the system user.
 Requirements validation

4. Realism checks Using knowledge of existing technology, the

requirements should be checked to ensure that they can actually be
implemented. These checks should also take account of the budget
and schedule for the system development.

5. Verifiability To reduce the potential for dispute between customer

and contractor, system requirements should always be written so that
they are verifiable. Should be able to write a set of tests that can
demonstrate that the delivered system meets each specified
requirement.
Requirements Evolution
 Requirements Evolution
There are a number of requirements validation techniques that can
be used individually or in conjunction with one another:

1.Requirements reviews The requirements are analyzed systematically by a

team of reviewers who check for errors and inconsistencies.

2. Prototyping is an executable model of the system in question is

demonstrated to end-users and customers. They can experiment with this
model to see if it meets their real needs.

3. Test-case generation Requirements should be testable. If the tests for the

requirements are devised as part of the validation process, this often reveals
requirements problems. If a test is difficult or impossible to design, this
usually means that the requirements will be difficult to implement and
should be reconsidered. Developing tests from the user requirements before
any code is written is an integral part of extreme programming.
 Requirements Evolution
Requirements management

Once a system has been installed and is regularly used, new requirements
inevitably emerge.

It is hard for users and system customers to anticipate what effects the new system
will have on their business processes and the way that work is done.

Once end-users have experience of a system, they will discover new needs and
priorities.
Requirements management planning

Planning is an essential first stage in the requirements management process. The

planning stage establishes the level of requirements management detail that is
required.
Requirements management planning

Planning is an essential first stage in the requirements management process. The

planning stage establishes the level of requirements management detail that is
required.
 Requirements storage

Change management

Traceability management
Requirements change management :

There are three principal stages to a change management process:

1.Problem analysis and change specification

1.Change analysis and costing

3. Change implementation
Petri nets

A Petri net (also known as a place/transition net or P/T net) is one

of several mathematical modelling for the description of
distributed systems.

A Petri net is a directed bipartite graph, in which the nodes

represent transitions (i.e. events that may occur, signified by bars)
and places (i.e. conditions, signified by circles).

The directed arcs describe which places are pre- and/or post
conditions for which transitions (signified by arrows).
 Example: EFTPOS System
EFTPOS= Electronic Fund Transfer
Point of Sale)
EFTPOS System

Scenario 1: Normal
Enters all 4 digits and press OK.
Scenario 2: Exceptional
Enters only 3 digits and press OK.

A Petri Net Specification

consists of three types of components: places (circles), transitions
(rectangles) and arcs (arrows):
Places represent possible states of the system;
Transitions are events or actions which cause the change of state;
And
Every arc simply connects a place with a transition or a transition
with a place.
A Change of State
is denoted by a movement of token(s) (black dots) from
place(s) to place(s); and is caused by the firing of a
transition.
The firing represents an occurrence of the event or an
action taken.
The firing is subject to the input conditions, denoted by
token availability.

Example: Vending Machine

The machine dispenses two kinds of snack bars 20c

and 15c.
Only two types of coins can be used
10c coins and 5c coins.
The machine does not return any change
Example: Vending Machine (STD of an
FSM)
Example: Vending Machine (A Petri
net)
Example: Vending Machine (3 Scenarios)
Scenario 1:
Deposit 5c, deposit 5c, deposit 5c, deposit 5c, take
20c snack bar.
Scenario 2:
Deposit 10c, deposit 5c, take 15c snack bar.
Scenario 3:
Deposit 5c, deposit 10c, deposit 5c, take 20c snack
bar.

Multiple Local States

A system may have many local states to form a global
state.
There is a need to model concurrency and
Other Types of Petri Nets
High-level Petri nets
Tokens have colours, holding complex information.

Timed Petri nets

Time delays associated with transitions and/or places.
Fixed delays or interval delays.
Stochastic Petri nets: exponentially distributed random variables
as delays.

Object-Oriented Petri nets

Tokens are instances of classes, moving from one place to
another, calling methods and changing attributes.
Net structure models the inner behaviour of objects.
The purpose is to use object-oriented constructs to structure
and build the system.
 DATA DICTIONARY
The data dictionary is an organized
listing of all data elements that are
pertinent to the system, with precise,
rigorous definitions so that both user
and system analyst will have a common
understanding of inputs, outputs,
components of stores and intermediate
calculations.

The data dictionary is always

implemented as part of a CASE
 The data dictionary stores the following
type of information:

Namethe primary name of the data or

control item, the data store or an external
entity.

Aliasother names used for the first entry.

Where-used/how-useda listing of the

processes that use the data or control item
and how it is used (e.g., input to the
process, output from the process, as a store,
as an external entity.
 Content descriptiona notation for
representing content.

Supplementary informationother
information about data types, preset values
(ifknown), restrictions or limitations, and so
forth.
Notations in Data
Dictionary
Example-Data Dictionary
The data dictionary entry begins as follows:
Name: telephone number
Aliases: none
Where used/how used: assess against set-up (output)
dial phone (input)
Description:
Telephone number = [local number|long distance
number]
Local number = prefix + access number
Long distance number = 1 + area code + local
number
Area code = [800 | 888 | 561]
Prefix = *a three digit number that never starts with 0