Software Requirements Engineering

Software Requirements
Engineering
IEEE: »Software Engineering«
...is the application of a systematic, disciplined, quantifiable

approach to the development, operation, maintenance, and
retirement of software, that is, the application of
engineering to software
Software Requirements
• A complete description of what the software system will do

without describing how it will do it is represented by the
software requirements
• Software requirements are complete specification of the desired

external behavior of the software system to be built
IEEE: »Requirement«
(1) A condition or capability that must be met or possessed by a

system or system component to satisfy a contract, standard,
specification, or other formally imposed documents.
(2) A condition or capability needed by a user to solve a problem or

achieve an objective.
(3) A documented representation of a condition or capability as in

(1) or (2).
Separate the problem from the solution
Definition of Requirements Engineering (RE)
Definition of Requirements Engineering (RE)
• Requirements Engineering refers to the “systematic handling of requirements”
• “A systematic approach to eliciting, organizing, and documenting the requirements

of the system, and a process that establishes and maintains agreement between the
customer and the project team on the changing requirements of the system”
• “the branch of systems engineering concerned with the desired properties and
constraints of software-intensive systems, the goals to be achieved in the
software’s environment, and assumptions about the environment”
Requirements engineering activities
Requirements Elicitation and Analysis
• Requirements elicitation (also called requirements acquisition, requirements
capture, requirements discovery, requirements gathering) is a process of
“identifying needs and bridging the disparities among the involved
communities for the purpose of defining and distilling requirements to meet
the constraints of these communities”
• While requirements analysis is a process of understanding and reviewing

requirements. The most difficult part of this phase is to ensure effective
communication between various stakeholders and the elicitation of tacit
knowledge
Requirements Modelling
• During requirements modelling, requirements are

modelled to resolve possible conflicts by negotiation
between stakeholders
Requirements Documentation
• Requirements documentation is the process of documenting the

agreed requirements at an appropriate level of detail in the most
suitable notation based on a well-defined document structure.
Requirements Verification and Validation
• Requirements verification and validation (V&V) is the process of examining
the requirements document to ensure that it is unambiguous, consistent and
complete, and that the stakeholders are satisfied with the final requirements
specification.
• The task of verification is to check whether the requirements comply with

given constraints, and are consistent, complete and unambiguous. This is
usually done by formal verifications or inspections.
• The task of validation is to certify that the specified requirements comply with
the given user and customer intentions. This means that the requirements need
to be expressed in a notation that is understandable by the customer.
Requirements Management
• Requirements management is the process of identifying, organizing,

documenting and tracking changing requirements in a project as well as the
impact of these changes.
• It is an on-going task throughout the whole RE process and might span the
whole software lifecycle
Why should we engineer requirements?
the task is important:

• the requirements are the basis for the downstream development
the requirements must be correct and complete in order to build the right software
product
errors in the requirements are costly
• to a large extent, development team communicates with the customer via

requirements
Why should we engineer requirements? (cont.)
the task is difficult:

• the requirements are often unclear in the beginning projects must handle
large numbers of requirements
the task is recurring:

• every project must handle requirements, all the time
• we can no longer do requirements "adhoc" but need
• a systematic approach – that is, engineering
Sources of Requirements
• Stakeholders
• People affected in some way by the system
• Documents
• Existing system
• Domain/business area
16
Types of Software Requirements
• Functional requirements
• Non-functional requirements
• Domain requirements
• Inverse requirements
• Design and implementation constraints
17
Functional Requirements - 1
• Statements describing what the system does
• Functionality of the system
18
• Statements of services the system should provide

• Reaction to particular inputs
• Behavior in particular situations
19
• Sequencing and parallelism are also captured by functional requirements
• Abnormal behavior is also documented as functional requirements in the

form of exception handling
20
• Functional requirements should be complete and consistent
• Customers and developers usually focus all their attention on functional

requirements
21
Functional Requirements Example # 1
• The system shall solve a quadratic equation using the following formula
x = (-b+sqrt(b2 – 4*a*c))/2*a
22
• 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.)
23
• The system shall provide appropriate viewers for the user to read documents
in the document store
24
• Every order shall be allocated a unique identifier (ORDER_ID) which the

user shall use to access that order
25
• The system shall allow customers to return items within fifteen days of the
purchase. A customer must present the original sale receipt to return an item
26
27
Non-Functional Requirements
• Non-functional requirements define the overall qualities or attributes of the

resulting system
• Non-functional requirements place restrictions on the product being developed,

the development process, and specify external constraints that the product must
meet.
• Most non-functional requirements relate to the system as a whole. They include

constraints on timing and performance, reliability, security, maintainability, accuracy, the
development process, standards, etc. 28
Functional and Non-functional requirements
• No clear distinction between functional and non-functional requirements.

• Whether or not a requirement is expressed as a functional or a non-functional
requirement may depend:
• on the level of detail to be included in the requirements document
• the degree of trust which exists between a system customer and a system
developer.
• They are often more critical than individual functional requirements
• They relate to system as a whole
• Failure to meet a non-functional system requirement may make the whole

system unusable
30
Non-Functional
requirements
Product Organizational External

requirements requirements requirements
31
Product Requirements
Product
requirements
Usability Efficiency Reliability Portability

requirements requirements requirements requirements
Performance Space
requirements requirements
32
Organizational Requirements
Organizational
requirements
Standards Implementation Delivery

33
Organizational Requirements Examples
• The system development process and deliverable documents shall conform to

the MIL-STD-2167A
• Any development work sub-contracted by the development organization shall

be carried out in accordance with Capability Maturity Model
34
External Requirements
External
requirements
Interoperability Ethical Legislative

Privacy Safety
requirements requirements
35
External Requirements Examples
• The system shall not disclose any personal information about members of the
library system to other members except system administrators
• The system shall comply with the local and national laws regarding the use of
software tools.
36
Observations on Non-Functional Requirements
• Non-functional requirements can be written to reflect general goals for the

system. Examples include:
• Ease of use
• Recovery from failure
• Rapid user response
37
NFRs as Goals
• Non-functional requirements are sometimes written as general goals, which

are difficult to verify
• They should be expressed quantitatively using metrics (measures) that can be

objectively tested
38
Example: Goal converted into an NFR
• Goal (unverifiable)
• The system should be easy to use by experienced users and should be organized
in such a way that user errors are minimized
• Non-functional requirement (verifiable)

• Experienced users shall be able to use all the system functions after a total of
two hours’ training. After this training, the average number of errors made by
experienced users shall not exceed two per day
39
Metrics for
(NFRs)
Metrics for NFRs - 1
Property Measure
Speed 1. Processed
transactions/second
2. Response time
3. Screen refresh time
Requirements related to “Speed” can use different measures to quantify the

goal.
•Refresh rate is the number of times in a second that a display hardware
41
draws the data.
Property Measure
Size 1. K bytes
2. Number of function points
Requirements related to “Size” can use different measures

to quantify the goal
Property Measure
Ease of use 1. Training time
2. Number of help frames
Requirements related to “Ease of use” can use different

measures to quantify the goal
Property Measure
Reliability 1. Mean time to failure
2. Probability of
unavailability
3. Rate of failure occurrence
4. Availability
Requirements related to “Reliability” can use different

Property Measure
Robustness 1. Time to restart after failure
2. Percentage of events
causing failure
3. Probability of data
corruption on failure
Requirements related to “Robustness” can use different measures to

quantify the goal.
•The degree to which system continues to function properly when confronted with invalid
inputs, defects in hardware or software components, unexpected operating conditions.
Property Measure
Portability 1. Percentage of target-
dependent systems
2. Number of target systems
Requirements related to “Portability” can use different

46
47
Domain Requirements
• Requirements that come from the application domain reflect fundamental
characteristics of that application domain
• These can be both the functional or non-functional requirements
• These requirements, sometimes, are not explicitly mentioned.
• Domain experts find it difficult to convey domain requirements due to

domain specific terminology.
48
Domain Requirements
• Domain requirements can impose strict constraints on solutions. This is

particularly true for scientific and engineering domains.
• Their absence can cause significant dissatisfaction
• It is expressed using language which is specific to the application domain and

it is often difficult for the software engineers to understand it.
49
Domain Requirements –
Library system
• Example:
1. There shall be a standard user interface to all databases which shall be
based on the Z39.50.
2. Because of copyright restriction , some documents must be deleted
immediately on arrival.
50
Domain Requirements
• Banking domain has its own specific constraints, for example, most banks do
not allow over-draw on most accounts, however, most banks allow some
accounts to be over-drawn
51
52
Inverse Requirements
• They explain what the system shall not do.

Many people find it convenient to describe their needs in this manner
• These requirements indicate the indecisive nature of customers about certain

aspects of a new software product
• Example:
The system shall not use red color in the user interface, whenever it is asking
for inputs from the end-user
53
54
Design and Implementation Constraints
• They are development guidelines within which the designer must work
• These requirements can seriously limit design and implementation options
• Can also have impact on human resources
55
Design and Implementation Constraints
Examples
• The system shall be developed using the Microsoft .Net platform
• The system shall be developed using open source tools and shall run on Linux
operating system
56
Another View of Requirements
• In general requirements can be viewed as:
• User/customer requirements
OR
• System contract requirements
User/Customer Requirements
User/Customer Requirements
• Functional and non-functional requirements should be stated in natural language
with the help of forms or simple diagrams describing the expected services of a
system by the User under certain constraints
• These are understandable by users, who have no, or little, technical knowledge
• System design characteristics should be avoided as much as possible
• It is a good practice to separate user requirements from more detailed system

requirements in a requirements document.
• Including 59
too much information in user requirements, constraints the system
designers from coming up with creative solutions
System Contract Requirements
• Sets out the system services and constraints in detail

• May serve as the basis of contract for implementation of the system
• Should be complete and consistent
• They are used by the designers and developers as the starting point for system
design
• They should be understood by technical staff of the customer organization
and the development team
61
• An initial architecture of the system may be defined to help structure the
requirements specification.
• Natural language is often used to describe system requirements

• e.g. the help files should be available in multiple languages.
• Some specification languages may be used with natural language, which add
structure to specifications and reduce ambiguity
• Unified Modeling Language (UML) is a specification language, which has 62

become the standard for modeling requirements
Impact of Wrong Requirements
• When requirements are wrong, systems are late, unreliable and don’t meet
customers needs
• This results in enormous loss of time, revenue, market share, and trust of
customers
63
Requirements Engineering Process
The process(es) involved in

developing system requirements is
collectively known as
Requirements Engineering Process
64
RE Process - Inputs and Outputs
Existing
systems
information
Stakeholder Agreed
needs requirements
Requirements
Organizational Engineering Process System
standards specification
System
Regulations models
Domain
information
65
RE Process – Inputs
It includes:
• Existing system information
• Information about the functionality of systems to be replaced
• Information about other systems, which interact with the system being specified
• Stakeholder needs
• Description of what system stakeholders need from the system to support their work
• Organizational standards
• Standards used in an organization regarding system development practice, quality
management, etc.
66
RE Process – Inputs
• Regulations
• External regulations such as health and safety regulations, which apply to the system
• Domain information
• General information about the application domain of the system
67
RE Process – Outputs
It includes
• Agreed requirements
• A description of the system requirements, which is understandable by stakeholders and
which has been agreed by them
• System specification
• This is a more detailed specification of the system, which may be produced in some cases
• System models
• A set of models such as a data-flow model, an object model, a process model, etc., which
describes the system from different perspectives
68
ATM stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators
RE Process
Requirement Engineering Process has a formal starting and ending point in the
overall software development life cycle.
Begins
There is recognition that a problem exists and requires a solution
A new software idea arises
Ends
With a complete description of the external behavior of the software to be built
70
RE Process
• It is a continuous process in which the related activities are repeated until

requirements are of acceptable quality
• It is one of the most critical processes of system development
71

Software Requirements Engineering

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

Software Requirements Engineering

Uploaded by

Copyright:

Available Formats

Software Requirements

...is the application of a systematic, disciplined, quantifiable

• A complete description of what the software system will do

• Software requirements are complete specification of the desired

(1) A condition or capability that must be met or possessed by a

(2) A condition or capability needed by a user to solve a problem or

(3) A documented representation of a condition or capability as in

• Requirements Engineering refers to the “systematic handling of requirements”

• “A systematic approach to eliciting, organizing, and documenting the requirements

• While requirements analysis is a process of understanding and reviewing

• During requirements modelling, requirements are

• Requirements documentation is the process of documenting the

• The task of verification is to check whether the requirements comply with

• Requirements management is the process of identifying, organizing,

the task is important:

• to a large extent, development team communicates with the customer via

the task is difficult:

the task is recurring:

• Statements describing what the system does

• Functionality of the system

• Statements of services the system should provide

• Sequencing and parallelism are also captured by functional requirements

• Abnormal behavior is also documented as functional requirements in the

• Functional requirements should be complete and consistent

• Customers and developers usually focus all their attention on functional

• Every order shall be allocated a unique identifier (ORDER_ID) which the

• Non-functional requirements define the overall qualities or attributes of the

• Non-functional requirements place restrictions on the product being developed,

• Most non-functional requirements relate to the system as a whole. They include

• No clear distinction between functional and non-functional requirements.

• They relate to system as a whole

• Failure to meet a non-functional system requirement may make the whole

Product Organizational External

Usability Efficiency Reliability Portability

Standards Implementation Delivery

• The system development process and deliverable documents shall conform to

• Any development work sub-contracted by the development organization shall

Interoperability Ethical Legislative

• Non-functional requirements can be written to reflect general goals for the

• Non-functional requirements are sometimes written as general goals, which

• They should be expressed quantitatively using metrics (measures) that can be

• Non-functional requirement (verifiable)

Requirements related to “Speed” can use different measures to quantify the

Requirements related to “Size” can use different measures

Requirements related to “Ease of use” can use different

Requirements related to “Reliability” can use different

Requirements related to “Robustness” can use different measures to

Requirements related to “Portability” can use different

• These can be both the functional or non-functional requirements

• These requirements, sometimes, are not explicitly mentioned.

• Domain experts find it difficult to convey domain requirements due to

• Domain requirements can impose strict constraints on solutions. This is

• Their absence can cause significant dissatisfaction

• It is expressed using language which is specific to the application domain and

• They explain what the system shall not do.

• These requirements indicate the indecisive nature of customers about certain

• These requirements can seriously limit design and implementation options

• Can also have impact on human resources

• The system shall be developed using the Microsoft .Net platform

• In general requirements can be viewed as:

• System design characteristics should be avoided as much as possible

• It is a good practice to separate user requirements from more detailed system

• Sets out the system services and constraints in detail