Requirement Engineering Process

Lecture 2

Processes

A process is an organized set of activities which transforms inputs to

outputs
Process descriptions encapsulate knowledge and allow it to be reused
Examples of process descriptions
Instruction manual for a dishwasher
Cookery book
Procedures manual for a bank
Quality manual for software development

Design Processes

Processes which involve creativity, interactions between a wide range of different

people, engineering judgment and background knowledge and experience

Examples of design processes

Writing a book
Designing a processor chip
Requirements engineering

Requirement Engineering Process

Software Requirement
Engineering
Lecture 2
Instructor: Saima Imtiaz

RE Process Activities

Requirements Elicitation
The

process through which the customers, buyers, or

users of a software system discover, reveal,
articulate, and understand their requirements

Requirement Analysis
The

process of reasoning about the requirements that

have been elicited
Involves examining requirements for conflicts or
inconsistencies, combining related requirements, and
identifying missing requirements

RE Process Activities

Requirements Specification
The

process of recording the requirements in one or

more forms, including natural language and formal,
symbolic, or graphical representations

Requirement Validation
The

process of confirming with the customer or user

of the software that the specified requirements are
valid, correct, and complete.

Requirement Management
The

process of managing all the activities carried out

during RE

RE process - inputs and outputs

Existing
systems
information
Agreed
requirements

Stakeholder
needs
Organisational
standards
Regulations

Requirements
engineeringprocess

System
specification
System
models

Domain
information
Kotonya and Sommerville (1998)

Requirement Management

A systematic approach to eliciting, organizing

and documenting requirements of the system
and
A process that establishes and maintains
agreement between customer and project team
and on changing requirements of system.

Why we need RM

It is difficult

Organize requirements
Prioritize requirements
Control access to requirements
Provide resources for requirements

Importance of Requirement Engineering

Benefits from a High-Quality Requirements

Process

Fewer requirement defects

Reduced development rework
Fewer unnecessary features
Faster development
Fewer miscommunications
Reduced scope creep
Reduced project chaos
More accurate system testing estimates
Higher customer and team member satisfaction

Software Types

Types of project

Source of Requirements:

Customer-driven

Market-driven

developed for a specific customer, but want to market the software eventually

Internal or In-house

involve a developer who needs to develop a system to be sold in the market

Single system vs. Product Family (product line)

Hybrid

involve a specific customer who needs a system to solve a specific problem

One-off (bespoke)

Some employees of a company needs a system to solve a specific problem.

The system is developed by the employees of the same company.
May or may not involve consultant(s)

New system vs. Upgrade to existing system

LEVELS OF REQUIREMENTS

Levels of Requirements

Business Requirements

User Requirements

Describe tasks the user must be able to

accomplish with the product or system

Functional Requirements

High level objectives of the organization or

customer requesting system or product

The software functionality the developers

must build into the product to enable
users to accomplish their tasks, thereby
satisfying the business requirements

Non-functional Requirements

These are constraints on the services or

functions offered by the system. They
include timing constraints, constraints on
the development process,
implementation constraints, security,
standards etc

BUSINESS REQUIREMENTS

Represent high-level objectives of the organization

or customer who requests the system.

Typically come from the funding sponsor for a project, the

acquiring customer, the manager of the actual users, the
marketing department, or a product visionary.

Describe why the organization is implementing the

systemthe objectives the organization hopes to
achieve.
Recorded in a vision and scope document,
sometimes called a project charter or a market
requirements document.
Defining the project scope is the first step in
controlling the common problem of scope creep.

BUSINESS RULES

Corporate policies, government regulations, industry

standards, etc.
Business
rules
are
not
themselves
software
requirements because they exist outside the boundaries
of any specific software system.
However, they often restrict who can perform certain use
cases or they dictate that the system must contain
functionality to comply with the pertinent rules.
Example 1: License Inspection Project

Business Rule: A driver must have a valid License

Possible business requirements to enforce these rules:

Police officer to inspect driver's license.

Quiz # 01

Quiz # 01
Lecture week 1 and 2 ( till slide 16)

USER REQUIREMENTS

Describe user goals or tasks that the users must be

able to perform with the product.
Valuable ways to represent user requirements include
use cases
scenario descriptions
event-response tables
An example of a use case is "Make a Reservation" using
an airline, or a hotel web site.

FUNCTIONAL REQUIREMENTS

Specify the software functionality that the

developers must build into the product to enable
users to accomplish their tasks, thereby satisfying
the business requirements.
Almost any action, e.g. calculate, inspect, publish,
or most other active verbs can be a functional
requirement.
Example:
The product shall predict which road sections will freeze
within the selected time parameters.
The user shall be able to search either the entire database
of patients or select a subset from it (admitted patients, or
patients with asthma, etc.)

SYSTEM REQUIREMENTS

The top-level requirements for a product that

contains multiple subsystemsthat is, a
system (IEEE 1998c).
A system can be all software or it can include
both software and hardware subsystems.
People are a part of a system, too, so certain
system functions might be allocated to human
beings.

NFRs/QUALITY ATTRIBUTES

Non-Functional Requirements (NFR) include

performance goals and descriptions of quality
attributes.
Quality attributes augment the description of
the product's functionality by describing the
product's characteristics in various dimensions
that are important either to users or to
developers.
Characteristics that relate to the system as a
whole
usability,

portability, efficiency, and robustness etc.

Examples: NFRs

OTHER NON-FUNCTIONAL REQUIREMENTS

External interfaces between the system and the

outside world.
Constraints that impose restrictions on the
choices available to the developer for design
and construction of the product.
Constraints

do not affect the external behavior of the

system, but must be fulfilled to meet technical,
business, or contractual obligations.
Example: The system development process and
deliverable documents shall conform to the MIL-STD2167A

Example: Constraints

FURPS+ Classification of Requirements

Functional
Non-Functional (NFRs)
Usability
The ease with which the system can be learned
and operated by the intended users.
Help, documentation, required training time, task
times for typical tasks, conformance to usability
standards, etc.
Reliability
Allowed MTBF (Mean Time Between Failures)
Maximum defect rate allowed per KLOC
Recoverability, etc.

FURPS+ Classification of Requirements

Performance

Response time, throughput,

Average, maximum response time for a transaction
Number of customers/transactions the system can
accommodate
Example:
Buyers want to complete sales processing very
quickly. One bottleneck is external payment
authorization. Our goal: authorization in less than 1
minute, 90% of the time.

Supportability:

Supportability is the ability of the software to be easily

modified to accommodate enhancements and repairs
Maintainability, adaptability, configurability, etc.

FURPS+ Classification Cont.

+ indicates additional constraints such as:

Design Constraints

Interface constraints

i.e. protocols for interaction with external systems

Implementation Constraints

E.g. requiring a relational database

Required platform, implementation language

Physical constraints

Hardware devices

FURPS+ Classification Examples

"The persistence will be handled by a relational database"

FURPS+ Type?

+ design constraint.

"The database will be Oracle 8i" FURPS+

+ implementation constraint.

Type?

"The system will run seven days a week, twenty-four hours per
day" FURPS+ Type?
R reliability requirement.

THE END
ANY QUESTIONS?

THANK YOU