Requirement Engineering
Akram Salah
Overview
Requirements
Define what the system is required to do and
the circumstances under which it is required to
operate.
Define the services that the system should provide
Set the constraints on the system’s operation.
Example: a library system
1. The system shall maintain records of all library
materials including books, serials, newspapers and
magazines, videos and audio tapes, reports, collections
of transparencies, computer disks and CD-ROMs.
2. The system shall allow users to search for an item by
title, author, or ISBN.
3. The system’s user interface shall be implemented using
World-Wide-Web browser.
4. The system shall support at least 20 transactions per
second.
5. The system facilities which are available to public
users shall be demonstrable in 10 minutes or less.
Overview
1. Very general requirements set what the
system should do in broad terms.
2. Functional requirements, define part of the
system functionality.
3. Implementation requirements, state how the
system must be implemented.
4. Performance requirements, specify a minimum
acceptable performance of the system.
5. Usability requirements, specify maximum
acceptable time to demonstrate the use of the
system.
Overview
If requirements are wrong, inaccurate, or
incomplete:
System may be delivered late and cost more than
originally expected.
The customer and end-users are not satisfied with
the system.
The system may be unreliable
Errors or crashes
If the system continues in use, the cost of
maintaining and evolving the system are usually
very high.
System
Architectural Requirements
requirements
Design partitioning
engineering
Software
requirements
engineering
System System Subsystem
validation Integration development
Requirements document
. Introduction
1.1 Purpose of the document
1.2 Scope of the product
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview of the remainder document
2. General Description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements
External interfaces, functionality, performance requirements, logical database
requirements, design constraints, system attributes, and quality characteristics.
4. Appendices
5. Index
Requirements document
System customers
Specify the requirements and read them to check that
they meet their needs. They specify changes.
Managers
Plan a bid for the system and plan the system
development process
System Engineer
Understand what system is to be developed
System test Engineer
Develop validation tests for the system
System maintenance engineer
Understand the system and relationships between parts.
Requirements document
Guidelines for the document
Define standard templates for describing
requirements
Use language simply, consistently, and
concisely
Use diagrams appropriately
Supplement natural language with other
description of requirements
Specify requirements quantitatively.
SR Fundamentals
Software Requirements (SR) express the
needs and constraints placed on a software
product that contribute to some real-world
problem.
Software engineering refers to systematic
handling of requirements.
A requirements engineer (requirements
specialist) is the person, team, or
organization, responsible for handling
requirements.
SR Fundamentals
Requirements engineering: the process
involved in developing system requirements.
Requirements engineering process:
structures set of activities involved in
developing system requirements.
Requirements document: the formal
statement of the system requirements.
Stakeholders: anyone who is affected in
someway by the system
Requirements management: the process
involved in managing changes to
SR Fundamentals
Definition:
A software requirement is a property which
must be exhibited by software developed to
solve a particular problem.
To automate part of a task for someone who uses
the software
To support the business process of an organization
that has commissioned the software
To correct shortcomings of existing software
To control a device
SR Fundamentals
Essential property of SR should be
Validated
Verifiable
Complexity adds to those
SR Fundamentals
Product vs. process requirements
Product parameters are requirements on the
software to be developed
“the software shall verify that a student meets all
prerequisites before he/she registers for a course”
Process parameter essentially constraints on
the development of the software
“the software shall be written in Ada”
Implicit process requirements
SR Fundamentals
Functional vs. nonfunctional requirements
Functional requirements describe functions
that the software is to execute
Formatting text
Modulating a signal
SR Fundamentals
Nonfunctional requirements act to constraint
the solution
Quality constraints
Performance,
Maintainability
Safety
Reliability
Nonfunctional requirements are difficult to be
checked and developed than functional
requirements
SR Fundamentals
Emergent properties
Can not be addressed by a single component
It depends on how all the components
interoperate
The throughput of a call center
They are crucially dependent on system
architecture
SR Fundamentals
Quantifiable requirements
Clear
Unambiguous
Preferably quantifiable
Avoid vague, unverifiable, or depend or
personal interpretations
A software shall be reliable
The software shall be user friendly
SR Fundamentals
System requirements & software
requirements
A system is an interacting combination of
elements to accomplish a defined objective
Elements include: hardware, software,
firmware, people, information, techniques,
facilities, services, and other support elements.
System requirements
Software requirements are derived from
system requirements
Requirements Process
Developing software requirements is a
process.
A process is a set of activities each has a purpose
but together result in one goal.
Requirements
Engineering
Requireme Requirement Requirements
nts s Management
Inception Development
Elicitatio Analys Specificati Validation
n is on
Source: Larry Boldt, Trends in Requirements Engineering People-Process-Technology, Technology Builders, Inc., 2001
Requirements Process
Requirements development tasks
Requirements elicitation
Acquisition
Not gathering or collecting
Requirements Analysis
Requirements Specification
Requirements Validation
Practical Considerations
Organization’s culture
Product vision
Limited resources
Many see documentation as an unnecessary
overhead
As product evolves
Customer base grows
Discover that they need to recover the
requirements
Practical Considerations
SR depend on
Users
Business process
Devices
Environment
Typically complex combination of different people on
different levels in organization with different views and
interests.
There is no one way of handling requirements
Interactive nature of the requirements process
Practical Considerations
Change management
Likely requirements would change
Technical details
Customer views
Business environment …
How to manage change
Relationships among requirements
Scope of requirements
Practical Considerations
Requirements Attributes
Functional or non functional
derived from high level requirements or
directly imposed by a stakeholder
Product or process
Priority
Mandatory
Highly desirable
Optional
Scope of requirement
Volatility/ stability
Practical Considerations
Requirements tracing
Recovering the source of requirements and
predicting the effect of requirements.
Backward
To the requirement or stakeholder(s) which
motivated it
Forward
Requirement and design entities that satisfy them
(complex directed acyclic graph)
Practical Considerations
Measuring requirements
Volume of the requirements for a product
Size of change
Estimating cost of development and
maintenance
Functional Size Measurement (FSM)
Practical Considerations
Requirements quality factors
Accuracy
Completeness
Consistency
Quantifiable
Verifiable