SRE - Week - 2 - RE Process & Levels of Requirements

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

SRE - Week - 2 - RE Process & Levels of Requirements

Uploaded by

Copyright:

Available Formats

SRE - Week - 2 - RE Process & Levels of Requirements

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRE - Week - 2 - RE Process & Levels of Requirements

Uploaded by

Copyright:

Available Formats

Requirement Engineering Process

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

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

Examples of design processes

Requirement Engineering Process

process through which the customers, buyers, or

process of reasoning about the requirements that

process of recording the requirements in one or

process of confirming with the customer or user

process of managing all the activities carried out

RE process - inputs and outputs

A systematic approach to eliciting, organizing

Importance of Requirement Engineering

Benefits from a High-Quality Requirements

Fewer requirement defects

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

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

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

New system vs. Upgrade to existing system

Describe tasks the user must be able to

High level objectives of the organization or

The software functionality the developers

These are constraints on the services or

Represent high-level objectives of the organization

Typically come from the funding sponsor for a project, the

Describe why the organization is implementing the

Corporate policies, government regulations, industry

Business Rule: A driver must have a valid License

Possible business requirements to enforce these rules:

Police officer to inspect driver's license.

Describe user goals or tasks that the users must be

Specify the software functionality that the

The top-level requirements for a product that

Non-Functional Requirements (NFR) include

portability, efficiency, and robustness etc.

OTHER NON-FUNCTIONAL REQUIREMENTS

External interfaces between the system and the

do not affect the external behavior of the

FURPS+ Classification of Requirements

FURPS+ Classification of Requirements

Response time, throughput,

Supportability is the ability of the software to be easily

FURPS+ Classification Cont.

+ indicates additional constraints such as:

i.e. protocols for interaction with external systems

E.g. requiring a relational database

Required platform, implementation language

FURPS+ Classification Examples

"The persistence will be handled by a relational database"

"The database will be Oracle 8i" FURPS+

You might also like