Lecture 6: Requirements

Engineering
based on Chapter 6

Lecturer Head of Department

 1. Requirement processing
• Requirements form a set of statements
that describe user’s needs and desires
• Requirements engineering: a set of
activities related to the development and
agreement of the final set of requirement
specifications.
 Preparation for Requirements Engineering

Agreeing on Obtain and

Plan Resources, Organize the
For Process and Agreed upon
Requirements Schedule for Resources and
Activities Requirements Process
Activities

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.

2. Some organizations even perform requirements engineering as a 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.
 Major Requirements Engineering Activities

• Elicitation
• Documentation and definitions
• Specifications
• Prototyping
• Analysis
• Review and Validations
• Agreement and acceptance
 Requirements
Requirements Definition
Elicitation

Requirements
Requirements Requirements Specification
Analysis Prototyping

Requirements Requirements
Review Agreement &
Acceptance

Requirements Engineering Activities

 Why is this set of activities important and why
should requirements be documented?

• 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.
• Requirements document is needed to create user training material,
marketing material, and documents for support and maintenance.
• Requirements document provides a way to segment a large project,
prioritize releases , and easier project management

Think about agile processes where this crucial step may sometimes be
compromised by the novice software engineers.
 2. Requirements Elicitation

• Requirements may:
– Be given to the software engineers
• Second or third follow-on release of a “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 by software engineers
• 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 users and customers
 High Level Requirements Elicitation

• Need to seek out the business and management

perceptions and goals for the software project
– Business opportunity and business needs
– Justification for the project
– Scope
– Major constraints
– Major functionality
– Success Factor
– User characteristics
6-Dimensions of Detailed Requirements Elicitation
Business Workflow

Individual Functionality Data and Data formats

Requirements

Existing & Systems Interfaces Other Constraints: Performance,

Reliability, etc.

User Interfaces
 3. Requirements Analysis

• Requirements analysis is composed of:

– Categorizing the requirements

– Prioritizing the requirements
 Requirements Categorization

• By detailed requirements area:

– Individual functionality
– Business flow
– Data and information needs
– User interfaces
– Other interfaces to external systems
– Various constraints
• Performance
• Security
• Reliability
• Etc.
 Requirements Categorization (cont.)

• OO’s Use Case is basically a

depiction of the following
information:
– Basic functionality
– Pre-conditions of functionality
– Flow of events or scenarios
– Post-conditions for the functionality
– Error conditions and alternative flows
 Requirements Categorization (cont.)

• Using OO Use Case methodology

which identifies:
– Actors (or all external interfaces with the
system, including the users)
– Related use cases
– Boundary conditions
 Actor
• An unusual term that refers to all external
interfaces with the system.
• Each actor takes on a certain role with regard
to interfacing with the system
• Identifying actors, analysts should ask
questions
– Who uses the system
– Who operates and maintains the system
– What other systems use this system?
– What other systems are used by this system
 Requirements Categorization (cont.)

• View Oriented Requirements Definition (VORD) is

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

– Identify stakeholders and their viewpoints of the

requirements
– Categorize the viewpoints of requirements and
eliminating any duplication
– Refine the identified viewpoints of requirements
– Map the viewpoints of requirements to the system and
the services that the system must provide
 Requirements Prioritization

• Most of the time we have limitations of :

– Time
– Resources
– Technical capabilities

• We need to prioritize the requirements to satisfy

these limitations
 Requirements Priorities
• Criteria for prioritization:

– Current user/customer demands or needs

– Competition and current market condition
– Anticipated future and new customer needs
– Sales advantages
– Critical problems in existing product

• These are often subjective and requirements

should be prioritized with the help of many of the
stakeholders.
 Brief Req. Req. source Req. priority Req. Status
Req. # description

One page A Major Priority 1*

#1 query must account Accepted for
respond in Marketing this release
less than Rep.
1 second
Help text Large account Priority 2 Postponed
#2 must be users For next
field sensitive release

* Priority may be 1, 2, 3, or 4, with 1 being the highest

A Simple Requirements Prioritization List

 Requirements Comparison and Prioritization

• Requirements prioritization is an activity of comparing the

requirements and placing them in some order relative to
each other.

– Done with just experience and gut feel

– Done with a little more rigor:

• Sort by priority groups (e.g. previous 2 charts) where the priority

groups are based on some prioritization criteria list

• Pair-wise comparison, normalize and compute relative value using

the Analytical Hierarchical Process (AHP) – see pages 159-161 of
text book
 Pairwise Comparison Matrix
Req1 Req2 Req3
Req1 1 3 5
Req2 1/3 1 1/2
Req3 1/5 2 1

Given a pair (x,y), the intensity value is considered 1 if x is deemed to

be of equal value to y. It is 2 if x is little more valuable than y and so
on until 9.
Sum each column and divide each value in the column by the sum

Req1 Req2 Req3

Req1 .65 .5 .77
Req2 .22 .17 .08
Req3 .13 .33 .15
20
 Pairwise Comparison Matrix
• Sum each row:
• Row 1 (Req1) = 1.92
• Row 2 (Req2) = .47
• Row 3 (Req)3 = .61
• Divide each sum by the number of
requirements:
• 1.92/3 = .64 Only good for
• 0.47/3 = .15 small number
• 0.61/3 = .20 of requirements
• Results
• Req1 highest (64% of total req value)
• Req3 second highet (20%)
• Req2 lowest (15%) 21
4. Requirements Definition/Prototyping/Review

• Once the requirements are solicited, analyzed

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

– Requirements definition
– Requirements prototyping
– Requirements reviewing
 Requirements Definitions

• Requirements definitions may be written in different

forms:

– Simple Input/process/output descriptions in English

– Dataflow diagrams (DFD)
– Entity Relations diagram (ERD)
– Use Case Diagram from Unified Modeling Language (UML)

• Once the requirements are defined in detail using any of

the above forms, they still need to be reviewed by the
users/customers and other stakeholders.
 Req. # Input Process Output

# 12: - Items by type - Accept the - Display

customer and quantity items and acceptance
order - Submit request respective message and
quantities - Ask for
confirmation
message

Requirement Definition using English and

Input-Process-Output Diagram Form
 DFD
Source or
Dest of data

data store

Processing

Flow of data
 data store

Inventory Info.
Package Data
Product avail.
Packaging
Info.
details
Shipping
Orders
Order Processing Instruct. Packaging
Customer
Invoice
Customer credit,
address, etc.

Customer Info DB

Requirements Definition using DFD

 Requirements Definition using
Entity- Relation-Diagram (ERD)
1 m
writes
Author Book

Cardinality: specifies the number of occurrences of entities

Author Book

Modality: specifies the necessities of relationship to exist

 Requirements Definition specifying
Entity and Attributes
(a) Graphical form
(a) Tabular form

Employee Employee

- Name
- Age
- Address
Address Name Age
- Street
- City
- State
- Zip

Street City State Zip

Requirements Definition using Use Case Diagram

Add Course
Register For Section

Add Section
Student

Add Student
Choose Section

Registrar
 Requirements Prototyping (1/2)

• Requirements prototyping mostly

address the User Interface (UI) part of
the requirement in terms of:
– Visual looks (size, shape, position,
color)
– Flow (control and logical flow)
 Requirements Prototyping (2/2)

• The prototyping may be performed in

one of the two modes:
– 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
 5. Requirements Specification
• Once the requirements are defined, prototyped and
reviewed, it must be placed into a Requirements
Specification document
• IEEE /EIA Standard 12207.1-1997 may be purchased from
IEEE. It outlines the guideline for 3 major sections of a
requirements specification document.
– Introduction
– High Level description
– Detailed descriptions
• Details of each functionality (input-out-process)
• Interfaces, including user interfaces and network interfaces
• Performance requirements (response time, throughput, etc.)
• Design constraints, standards, etc.
• Additional attributes such as security, reliability, etc.
• Any additional unique requirements
Software Requirements Specification
The Software Requirements Specification (SRS) specifies the requirements for a
Computer Software Configuration Item (CSCI) and the methods to be used to ensure
that each requirement has been met. Requirements pertinent to the CSCIs external
interfaces may be presented in the SRS or in one or more interface requirements
specifications (IRSs).

1.0 Introduction to the Document

1.1 Purpose of the Project
State the purpose of the system or subsystem to which this document applies.
1.2 Scope of the Project
1.3 Acronyms, Abbreviations, Definitions
1.4 References
1.5 Outline of Rest of SRS
2.0 General Description of Product
2.1 Context of Product
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies

33
Software Requirements Specification
3.0 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4Communications Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.1.1 Short, imperative sentence stating highest ranked functional
requirement.
3.2.1.2 Description
A full description of the requirement.
3.2.1.3 Criticality
Describes how essential this requirement is to the overall system.
3.2.1.4 Technical issues
Describes any design or implementation issues involved in satisfying
this requirement.
3.1.2.5 Cost and schedule
Describes the relative or absolute costs associated with this issue.

34
Software Requirements Specification
3.2.1.6 Risks
Describes the circumstances under which this requirement
might not able to be satisfied, and what actions can be
taken to reduce the probability of this occurrence.
3.1.2.7 Dependencies with other requirements
Describes interactions with other requirements.
3.1.2.8 ... others as appropriate
3.2.2 Class 2
3.2.3 Class 3
...
3.3 Performance Requirements
3.4 Design Constraints
3.5 Quality Requirements
3.6 Safety requirements
3.7 Security and Safety Requirements
3.8 Computer Resource Requirements
3,9 Personnel Requirements
3,10 Training Related Requirements
3.11 Logistics Related Requirements
3.12 Other Requirements 35
 Software Requirements
Specification
4.0 Notes
4.1 Intended Use
4.2 Definitions Used in this Document
4,3 Abbreviations Used in this Document
4.4 Changes from Previous Issue
5.0 Appendices

36
 Requirements “Sign Off”

• Having a requirements specification agreed to and

signed off is important:

– Serves as a milestone marker and formally exits a phase of

software engineering
– Serves as baseline from which any future changes can be
monitored and controlled
 Requirements Traceability

• Capability to trace a requirements is needed to

ensure that the product has fully implemented the
requirements.

• We need to trace requirements:

– Requirements from source (people and documents)
– Requirements to later steps (design, implementation)

• We also need to link requirements to other “pre-

requisite” requirements.
 Partially filled Traceability Table

Requirement Design Code Test Other

Reqs.
1 Test Case 32 2,3
comp. X Module 3
Module 5 Test Case 16
2 comp. w 1
Test Case 27
3 comp. X Module 2 1