Requirement Engineering

 The requirements for a system are the

descriptions of what the system should do?
 These requirements reflect the needs of
customers for a system that serves a certain
purpose such as controlling a device, placing an
order, or finding information.
 The process of finding out, analyzing,
documenting and checking these services and
constraints is called requirements engineering
(RE).
User and System Requirement
 User requirements are statements, in a natural
language plus diagrams, of what services the
system is expected to provide to system users
and the constraints under which it must operate.
 System requirements are more detailed
descriptions of the software system’s functions,
services, and operational constraints.
 The system requirements document should
define exactly what is to be implemented. It may
be part of the contract between the system
buyer and the software developers.
Functional and Non Functional Req.
 Functional requirements are statements of
services the system should provide, how the
system should react to particular inputs, and
how the system should behave in particular
situations.
 In some cases, the functional requirements may
also explicitly state what the system not do.
 Non-functional requirements are constraints
on the services or functions offered by the
system.
 They include constraints on timing, development
process, and constraints imposed by standards.
 Non-functional requirements often apply to the
system as a whole.
Functional Requirements
 The functional requirements for a system
describe what the system should do.
 These requirements depend on the type of
software being developed, the expected users
of the software, and the general approach taken
by the organization when writing requirements.
 Functional requirements are usually described
in an abstract way that can be understood by
system users.
 Functional system requirements describe the
system functions, its inputs and outputs,
exceptions, etc., in detail.
Functional requirements for MHC-PMS system,
used to maintain information about patients
receiving treatment for mental health problems:
 A user shall be able to search the appointments
lists for all clinics.
 The system shall generate each day, for each
clinic, a list of patients who are expected to
attend appointments that day.
 Each staff member using the system shall be
uniquely identified by his or her eight-digit
employee number.
Functional Requirement for Library Mgmt. System
 Allow the user to search for books based on
title, publication date, author.
 Users can request, reserve, or renew a book.
 Librarian can add and manage the books.
 The system should notify the user and librarian
about the overdue books.
Non Functional Requirement
 Non-functional requirements, as the name
suggests, are requirements that are not directly
concerned with the specific services delivered
by the system to its users.
 They may define constraints on the system
implementation such as the capabilities of I/O
devices or the data representations used in
interfaces with other systems.
 Non-functional requirements, such as
performance, security, or availability, usually
specify or constrain characteristics of the system
as a whole.
 Failing to meet a non-functional requirement
can mean that the whole system is unusable
Non Functional Requirement Continue
 Non-functional requirements may affect the
overall architecture of a system rather than the
individual components.
 For example, to ensure that performance
requirements are met, you may have to
organize the system to minimize
communications between components.
 A single non-functional requirement, such as a
security requirement, may generate a number of
related functional requirements that define new
system services that are required.
 It may also generate requirements that restrict
existing requirements.
Non Functional Requirement Continue
 Non-functional requirements may affect the
overall architecture of a system rather than the
individual components.
 For example, to ensure that performance
requirements are met, you may have to
organize the system to minimize
communications between components.
 A single non-functional requirement, such as a
security requirement, may generate a number of
related functional requirements that define new
system services that are required.
 It may also generate requirements that restrict
existing requirements.
The Software Requirement Document
 The software requirements document is an official
statement of what the system developers should
implement.
 The user and system requirements are integrated
into a single description.
 The user requirements are defined in an
introduction to the system requirements
specification.
 Requirements documents are essential when an
outside contractor is developing the software
system.
 Agile development methods argue that
requirements change so rapidly that a requirements
document is out of date as soon as it is written, so
the effort is largely wasted.
The Software Requirement Document
 The requirements document has a diverse set
of users, ranging from the senior management
of the organization that is paying for the system
to the engineers responsible for developing the
software.
 The diversity of possible users means that the
requirements document has to be a
compromise between communicating the
requirements to customers, defining the
requirements in precise detail for developers
and testers, and including information about
possible system evolution.
The Users of Requirement Document
The Structure of Requirement Document
 Preface
 Introduction
 Glossary
 User Requirement definition
 System Architecture
 System Requirement Specification
 System Models
 System Evolution
 Appendices
 Index
Requirement Specification
 Requirements specification is the process of
writing down the user and system requirements
in a requirements document.
 The user and system requirements should be
clear, unambiguous, easy to understand,
complete, and consistent.
 In practice, this is difficult to achieve as
stakeholder interpret the requirements in
different ways and there are often inherent
conflicts and inconsistencies in the
requirements.
 The requirements document should not include
details of the system architecture or design.
Requirement Specification
 We should write user requirements in natural
language, with simple tables, forms, and
intuitive diagrams.
 System requirements are expanded versions of
the user requirements that are used by software
engineers as the starting point for the system
design.
 the system requirements should simply describe
the external behavior of the system and its
operational constraints.
 They should not be concerned with how the
system should be designed or implemented.
Why it is practically impossible to execute all
design information
 You may have to design an initial architecture of
the system to help structure the requirements
specification.
 In most cases, systems must interoperate with
existing systems, which constrain the design
and impose requirements on the new system.
 The use of a specific architecture to satisfy non-
functional requirements may be necessary. An
external regulator who needs to certify that the
system is safe may specify that an already
certified architectural design be used.
Ways of writing a simple requirement
specification
 Natural Language Sentence
 The requirements are written using numbered
sentences in natural language. Each sentence
should express one requirement.
 Structure Natural Language
◦ The requirements are written in natural language
on a standard form or template. Each field
provides information about an aspect of the
requirement.
 Graphical Notation
 Graphical models, supplemented by text
annotations, are used to define the functional
requirements for the system; UML use case and
sequence diagrams are commonly used.
Ways of writing a simple requirement
specification
 Design Description Language
◦ This approach uses a language like a
programming language, but with more abstract
features to specify the requirements by defining
an operational model of the system.
◦ This approach is now rarely used although it can
be useful for interface specification.
 Mathematical Specification
◦ These notations are based on mathematical
concepts such as finite-state machines or sets.
Although these unambiguous specifications can
reduce the ambiguity in a requirements
document, most customers don’t understand a
formal specification.
Spiral view of req. Engineering Process
Requirement Engineering Process

 In practice, requirements engineering is

an iterative process in which the activities
are interleaved.
◦ Feasibility Study – Tracking useful factors to
the business.
◦ Elicitation and Analysis – Requirement
Discovery.
◦ Specification – Converting requirements into
some standard form.
◦ Validation – Checking that the requirements
actually define the system that the customer
wants.
 Requirement Elicitation
 In this activity, software engineers work with
customers and system end-users to find out about
the application domain, what services the system
should provide, the required performance of the
system, hardware constraints, and so on.
Requirement Elicitation Cont.
• Requirements elicitation and analysis may
involve a variety of system stakeholder who
should have some direct or indirect influence
on the system requirements.
• Stakeholders include end users who will
interact with the system and anyone else in
an organization who will be affected by it.
• Each organization will have its own version
or instantiation of this general model
depending on local factors such as the
expertise of the staff, the type of system
being developed, the standards used, etc.
Process of Req. Elicitation
• Requirement Discovery
 This is the process of interacting with
stakeholders of the system to discover their
requirements. Some of the methods are
questionnaires, JAD, Interview, Prototyping.
• Requirement classification and Organization
 This activity takes the unstructured collection of
requirements, groups related requirements, and
organizes them into coherent clusters.
 The most common way of grouping
requirements is to use a model of the system
architecture to identify sub-systems and to
associate requirements with each sub-system.
Process of Req. Elicitation
• Requirement Prioritization and negotiation
 Inevitably, when multiple stakeholders are involved,
requirements will conflict. This activity is concerned
with prioritizing requirements and finding and
resolving requirements conflicts through negotiation.
• Requirement Specification
• The requirements are documented and input into the
next round of the spiral. Formal or informal
requirements documents may be Produced.
Process of Req. Elicitation
• Stakeholders often don’t know what they want
from a computer system except in the most
general terms.
• Stakeholders in a system naturally express
requirements in their own terms and with implicit
knowledge of their own work.
• Different stakeholders have different
requirements and they may express these in
different ways.
• Political factors may influence the requirements
of a system.
• The economic and business environment in
which the analysis takes place is dynamic.
Process of Req. Elicitation
• Stakeholders often don’t know what they want
from a computer system except in the most
general terms.
• Stakeholders in a system naturally express
requirements in their own terms and with implicit
knowledge of their own work.
• Different stakeholders have different
requirements and they may express these in
different ways.
• Political factors may influence the requirements
of a system.
• The economic and business environment in
which the analysis takes place is dynamic.
Requirement Discovery Methods
• Interviewing
 Interviews are good for getting an overall
understanding of what stakeholders do, how
they might interact with the new system, and the
difficulties that they face with current systems.
 Interviews are also not an effective technique
for eliciting knowledge about organizational
requirements and constraints because there are
subtle power relationships between the different
people in the organization.
 In general, most people are generally reluctant
to discuss political and organizational issues
that may affect the requirements.
Requirement Discovery Methods
• It can be difficult to elicit domain
knowledge through interviews for two
reasons:
• In these interviews, the requirements
engineering team puts questions to
stakeholders about the system that they
currently use and the system to be developed.
◦ Closed interviews, where the stakeholder
answers a pre-defined set of questions.
◦ Open interviews, in which there is no pre-
defined agenda. The requirements
engineering team explores a range of issues
with system stakeholders and hence develop
Requirement Discovery Methods
• Interviewing
 Interviews are good for getting an overall
understanding of what stakeholders do, how
they might interact with the new system, and the
difficulties that they face with current systems.
 Interviews are also not an effective technique
for eliciting knowledge about organizational
requirements and constraints because there are
subtle power relationships between the different
people in the organization.
 In general, most people are generally reluctant
to discuss political and organizational issues
that may affect the requirements.
Scenarios
 Scenarios can be particularly useful for adding
detail to an outline requirements description.
Each scenario usually covers one or a small
number of possible interactions. It includes
 A description of what the system and users expects
when the scenario starts.
 A description of the normal flow of events in the
scenario.
 A description of what can go wrong and how this is
handled.
 Information about other activities that might be
going on at the same time.
 A description of the system state when the scenario
finishes.
Use cases
 A behaviorally related sequence of steps ( a
scenario), both automate and manual, for the
purpose of completing single business task.
 It is a collection of success and failure scenarios
that describe actor using a system to support a
goal.
 It is made up of set of possible sequence of
interaction between the system and actor in a
particular environment.
Actor
 Actor is something with behavior such as
person computer system or organization that
use the service of the system or provide the
service to the system.
 It specifies a role played by a user or any other
system that interact with the subject.
 Actors are play not only by people but also by
organization, software and machine.
◦ Types of Actor
 Primary Actor
 Supporting Actor
 Offstage Actor
Ethnography
 Ethnography is an observational technique that
can be used to understand operational
processes and help derive support
requirements for these processes.
 The day-to-day work is observed and notes
made of the actual tasks in which participants
are involved.
 The value of ethnography is that it helps
discover implicit system requirements that
reflect the actual ways that people work, rather
than the formal processes defined by the
organization.
Ethnography and Prototyping
 Ethnography can be combined with prototyping
The ethnography informs the development of
the prototype so that fewer prototype refinement
cycles are required.
 Furthermore, the prototyping focuses the
ethnography by identifying problems and
questions that can then be discussed with the
ethnographer.
Requirement Validation
 Requirements validation is the process of
checking that requirements actually define the
system that the customer really wants.
 This is important because errors in requirements
document can lead to extensive rework costs
when these problems are discovered during
development or after the system is in service.
 The cost of fixing a requirements problem by
making a system change is usually much
greater than repairing design or coding errors.
 The reason for this is that a change to the
requirements usually means that the system
design and implementation must also be
changed.
Checking in Requirement Validation
 Validity Checks
 Consistency Checks
 Completeness Checks
 Realism Checks
 Verifiability
Requirement Validation Technique
◦ Requirement Review
◦ Prototyping
◦ Test Case Generation
Requirement Management
 The requirements for large software systems
are always changing.
 One reason for change is that these systems
are usually developed to address ‘wicked’
problems—problems that cannot be completely
defined.
Why Change is Inventible
 The business and technical environment of the
system always changes after installation.
 The people who pay for a system and the users
of that system are rarely the same people.
 System customers impose requirements
because of organizational and budgetary
constraints.
 Large systems usually have a diverse user
community, with many users having different
requirements and priorities that may be
conflicting or contradictory.
Requirement Management Process
 Requirement Management Planning
◦ Requirement identification
◦ A Change Management Process
◦ Traceability Process
◦ Tool Support
 Requirement Storage
 Change management
 Traceability Process
Requirement Management Process
 Principle stage of Change Management
◦ Problem analysis and change specification
◦ Change analysis and costing
◦ Change implementation