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
