T i

Topics
Wisdom of the Land

Overview of requirements engineering activities

Elicitation and requirements technique
A quick walkthrough examples of different forms of
requirements definitions
Requirements validation criteria

Requirements Engineering
Processing Elicitation and Gathering
Processing,
Lecture 3

P
Preparation
i
for
f Requirements
R
i
Engineering
E i
i
Plan
for
Requirements
Activities

Agreeing on
Resources,
Process and
Schedule for
Requirements
Activities

Obtain and
Organize
g
the
Agreed upon
Resources and
Process

R
Requirements
i
t E
Engineering
i
i
Activities
A ti iti

Requirements
Definition

Requirements
Elicitation

Requirements
A l i
Analysis

1. Prior to actually performing the requirements engineering activities, it is

important to plan for the resources and time needed to perform this crucial
step in software engineering

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

Requirements
P t t i
Prototyping

Requirements
Review

2. Some organizations even perform requirements engineering as a separate

2
separate,
stand-alone activity and price it separately, with the option of folding the cost
into the whole project if they get the call to complete the software project
3

Lecture 3

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Requirements
Specification

Requirements
Agreement &
Acceptance

Lecture 3

Why is this set of activities important and

why
h should
h ld requirements
i
b
be d
documented?
d

M j Requirements
Major
R
i
E
Engineering
i
i
Activities
A i ii
Elicitation
Documentation and definitions
Specifications
Prototyping
yp g
Analysis
Review and validation
Agreement and acceptance

Clear requirements are needed for design and implementation

activities
Requirements documentation is needed to create test cases and test
scenarios -- especially for large systems where the test team is a
separate group of people from the developers
Requirements document is needed to control potential scope-creep.
R i
Requirements
document
d
is
i needed
d d to create user training
i i material,
i l
marketing material, and documents for support and maintenance
R i
Requirements
t document
d
t provides
id a way to
t segmentt a large
l
project,
j t
prioritize releases, and easier project management
Think about agile processes where this crucial step may sometimes be
compromised by the novice software engineers.

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

R
Requirements
i
t Elicitation
Eli it ti

Second or third follow-on

follow on release of a planned
planned sequences of
software product where requirements are already established
Requirements provided as a part of a request for price quotation for a
software development project

Have to be established byy software engineers

g

Users have an understanding of only the requirements related to their

specific job tasks
The business rationale and goals are not clear
There may be contradicting and incomplete requirements stated by
the
h users and
d customers

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

Need to seek out the business and management

perceptions and goals for the software project

Be given to the software engineers

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Hi h L
High
Levell R
Requirements
i
t Elicitation
Eli it ti

Requirements may:

Lecture 3

Business opportunity and business needs

Justification for the project
S
Scope
Major constraints
Major functionality
Success factor
User characteristics

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

Functional Requirements versus

N
Non-Functional
F
ti
l Requirements
R
i
t

E
Example
l off Requirements
R
i
t
Functional requirements:
q
Describe the interactions between the system
y
and its environment independent from implementation

The watch system must display the time based on its location

Nonfunctional requirements: User visible aspects of the system not directly

related to functional behavior

The response time

Th
i
must be
b less
l
than
h 1 second
d
The accuracy must be within a second
The watch must be available 24 hours a day except from 2:00am-2:01am and
3:00am-3:01am

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

10

Meetings
g are conducted and attended byy both software engineers
g
and
customers

M k lists
Make
li t off
functions, classes

A "facilitator" (can be a customer, a developer, or an outsider) controls the

meeting

A "definition mechanism" (can be work sheets, flip charts, or wall stickers

or an electronic
l
i bbulletin
ll i bboard,
d chat
h room or virtual
i
l fforum)) iis used
d

Make lists of
constraints, etc.

11

no

yes
Use QFD to
prioritize
requirements

to identify
identif the problem
roblem
propose elements of the solution
negotiate different approaches, and
specify a preliminary set of solution requirements

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

formal prioritization?

Elicit requirement s

The goal is

Fact-Finding
Techniques

Conduct FAST
meetings

Rules for preparation and participation are established

An agenda is suggested

Lecture 3

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Eli iti
Eliciting
R
Requirements
i
t

on the level of detail to be included in the requirements

document
the degree of trust which exists between a system customer
and a system developer

Source: G. Kotonya and I. Sommerville 1998, lecture notes on Non-Functional Requirements

Eli iti
Eliciting
R
Requirements
i
t Process
P

The implementation language must be COBOL

Must interface to the dispatcher system written in 1956

There is no a clear distinction between functional and

non-functional requirements
Wh th or nott a requirement
Whether
i
t is
i expressed
d as a
functional or a non-functional requirement may depend:

Constraints (Pseudo requirements): Imposed by the client or the

environment in which the system will operate

define actors

informally
prioritize
requirements
draw use-case
diagram

write scenario

Create Use-cases
complete template

Lecture 3

12

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

S
Seven
F
Fact-Finding
t Fi di
Techniques
T h i

A Fact-Finding
F t Fi di
St
Strategy
t

Sampling of existing documentation

documentation, forms,
forms and databases
Research and site visits
Observation of the work environment
Questionnaires
Interviews
Prototyping
Joint requirements planning (JRP)

1
1.

Learn from existing documents, forms, reports, and files

2.

If appropriate, observe the system in action

3.

Given all the facts that already collected, design and distribute
questionnaires to clear up things that arent fully understood

4.

Conduct interviews (or group work sessions)

5.

(Optional).
(O
i l) Build
B ild discovery
di
prototypes ffor any ffunctional
i l
requirements that are not understood or for requirements
th t need
that
d to
t be
b validated
lid t d

Each with different strengths and suitability for different scenarios

6.

Follow up to verify facts

13

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

6-Dimensions of Detailed Requirements

Eli i i
Elicitation

Eli it ti
Elicitation
Work
W k Products
P d t

14

A statement of need and feasibility

A bounded statement of scope for the system or product
A lilistt off customers,
t
users, and
d other
th stakeholders
t k h ld
who
h
participated in requirements elicitation
Ad
description off the
h systems
technical
h
l environment
A list of requirements (preferably organized by function) and
the domain constraints that apply to each
A set of usage scenarios that provide insight into the use of
the system or product under different operating conditions
Anyy prototypes
p
yp developed
p to better define requirements
q

Business Workflow
Individual Functionalityy

Data and Data formats

Requirements

Existing & Systems Interfaces

Other Constraints: Performance,

Reliability, etc.

User Interfaces
15

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

16

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

R
Requirements
i
t Analysis
A l i

R
Requirements
i
t Categorization
C t
i ti

Requirements analysis is composed of:

Categorizing the requirements

P i iti i th
Prioritizing
the requirements
i
t

By detailed requirements area:

Individual functionality
B i
Business
flflow
Data and information needs
User interfaces
f
Other interfaces to external systems
Various constraints

17

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

R
Requirements
i
t Categorization
C t
i ti
(cont.)
(
t)

Basic functionality
Pre-conditions of functionalityy
Flow of events or scenarios
Post-conditions for the functionality
Error conditions and alternative flows

19

Actors (or all external interfaces with the system, including the
users)
Related use cases
Boundary conditions

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

View Oriented Requirements Definition (VORD) is based

on the concept that requirements are viewed differently
by different people:

Using OO use case methodology which identifies:

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

R
Requirements
i
t Categorization
C t
i ti
(cont.)
(
t)

Usingg OOs
Us
OO s use case, w
which
c identifies:
e t es:

18

Performance
Security
Reliability
Etc.

Lecture 3

20

Identify stakeholders and their viewpoints of the requirements

C
Categorize
i the
h viewpoints
i
i off requirements
i
and
d eliminating
li i i any
duplication
R fi the
Refine
h id
identified
ifi d viewpoints
i
i off requirements
i
Map the viewpoints of requirements to the system and the
services
i
that
h the
h system must provide
id

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

R
Requirements
i
t Prioritization
P i iti ti

R
Requirements
i
t Priorities
P i iti

Most of the time we have limitations of:

Time
R
Resources
Technical capabilities

Criteria for prioritization:

We need to prioritize the requirements to satisfy these

limitations

21

Lecture 3

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

#1

#2

Brief
B
i f Req.
R
Description
page
g
One p
query must
respond in
less than
1 second

22

Req. Source
A Major
account
Marketing
Rep
Rep.

Req. Priority
Priority 1
1*

Help text
Large account Priority 2
must be
users
field sensitive

These are often subjective and requirements should be

prioritized with the help of many of the stakeholders

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

Requirements Definition/Prototyping/
R i
Review

A Simple
Si
l Requirements
R
i
Prioritization
P i ii i
List
Li
Req. #

Current user/customer demands or needs

C
Competition
titi and
d currentt market
k t condition
diti
Anticipated future and new customer needs
S
Sales
advantages
Critical problems in existing product

Req. Status
Accepted for
this release

Once the requirements are solicited,

solicited analyzed and
prioritized, more details must be spelled out. Three major
activities which may be intertwined must be performed:

Postponed
for next
release

Requirements definition
R i
Requirements
prototyping
i
Requirements reviewing

* Priorityy mayy be 1,, 2,, 3,, or 4,, with 1 being

g the highest
g
23

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

24

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

Requirement Definition using English and

I
Input-Process-Output
tP
O t t Diagram
Di
Form
F

R
Requirements
i
t Definitions
D fi iti

Requirements definitions may be written in different

forms:

Req. #

Simple input/process/output descriptions in English

Dataflow Diagrams (DFD)
E i Relation
Entity
R l i Di
Diagram (ERD)
Use Case Diagram from Unified Modeling Language (UML)

# 12:
customer
order

Input
Items by type
quantityy
and q
Submit request

Process

Accept the items

p
and respective
quantities

Lecture 3

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Orders

Customer

Display
p
acceptance
message

26

Lecture 3

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Requirements Definition using

Entity-Relation-Diagram (ERD)

R
Requirements
i
t Definition
D fi iti
using
i
DFD
Inventory Info.

Package Data

Product avail.
Info.

Packaging
details

Shipping
Order ProcessingInstruct.

and
Ask for
confirmation
message

Once the requirements are defined in detail using any of

the above forms, theyy still need to be reviewed byy the
users/customers and other stakeholders

25

Output

Author

writes

m
Book

Cardinality:
y specifies
p
the number of occurrences of entities

Packaging

Invoice
Book

Author

Customer credit,,
address, etc.

Modality: specifies the necessities of relationship to exist

Customer Info DB
27

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

28

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

Requirements Definition using Use Case

Diagram
Di

Requirements Definition specifying

Entity and Attributes

Add Course

(b) Tabular form

(a) Graphical form

Employee

Register for Section

Employee
- Name
- Age
- Address

Address

Street

Name

City

Age

State

Add Section
Student

- Street
- City
- State
- Zip
Zip

Add Student
Choose Section
Registrar

29

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

R
Requirements
i
t Prototyping
P t t i

Visual looks (size,

(size shape,
shape position,
position color)
Flow (control and logical flow)

The prototyping may be performed in one of the two

modes:

31

Low fidelity : using paper/cardboard to represent screens and

human to move the boards
High fidelity : using automated tools such as Visual Basic to
code the screens and direct the logical flow of these screens

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

R
Requirements
i
t Specification
S
ifi ti

Requirements prototyping mostly address the User

Interface (UI) part of the requirement in terms of:

30

Lecture 3

Once the requirements are defined

defined, prototypes and
reviewed, it must be placed into a requirements
specification document
IEEE / EIA Standard 12207.1-1997 may be purchased from
IEEE It
IEEE.
I outlines
li
the
h guideline
id li ffor 3 major
j sections
i
off a
requirements specification document.

32

Introduction
High level description

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

R
Requirements
i
t Specification
S
ifi ti
(cont.)
(
t)

R
Requirements
i
t Validation
V lid ti

IEEE / EIA Standard 12207.1-1997

12207 1-1997 (continued)

Correctness:

Completeness:

Detailed descriptions

Details of each functionality (input-output-process)

(input output process)
Interfaces, including user interfaces and network interfaces
Performance requirements (response time,
time throughput,
throughput etc.)
etc )
Design constraints, standards, etc.
Additional attributes such as security,
security reliability
reliability, etc
etc.
Any additional unique requirements

Consistency:

Clarity:

V ifi bili
Verifiability:

Clients View
Clients
Think of the problems that your business may have
Create backlog - wish list for the system to build
Practitioners View
Classify the wish list in terms of functional and nonfunctional requirements
For each group, try to use any fact-finding technique to
find information on the priority of wish list items

35

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3

Requirements can be implemented and delivered

Once the system is built, a repeatable test can be designed to demonstrate that the system
fulfills the requirements

Traceability:

P j t Exercise
Project
E
i Scrum
S
P
Practice
ti

There are no ambiguities

g
in the requirements
q

Realism:

Lecture 3

Th
There
are no functional
f
l or nonfunctional
f
l requirements that
h contradict
d eachh other
h

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

All possible scenarios through the system are described

described, including exceptional behavior by
the user or the system

33

The requirements represent the clients view

34

Each system function can be traced to a corresponding set of functional requirements

ITCS371 Introduction to Software Engineering ICT@MU

Academic Year 2016 Semester 1

Lecture 3