Requirements

Engineering-An
Introduction
What is Requirements Engineering?
• To make sure that a software solution correctly solves a particular problem, we must first perfectly
understand and define what problem needs to be solved.
• Figuring out what the right problem can be surprisingly difficult.
• We need to discover, understand, formulate, analyse and agree on what problem could be solved, why such a
problem needs to be solved and who should be involved in the responsibility of solving that problem

• Broadly, this is what requirements engineering is all about

The Problem World and the machine
Solution
• Let us consider e-commerce world
• The world has the phenomena of items being delivered to buyers only once they
have been paid;
• The machine owns the phenomena of payment records being created in the
machine's database
• The phenomena of payment notifications being sent to sellers are shared, as the
machine can control them whereas the world can monitor them.
• Requirements engineering is concerned with the machine's effect on the
surrounding world and the assumptions we make about that world.
• As a consequence, it is solely concerned with world phenomena, including shared
ones.
• Requirements and assumptions have their meaning in the problem world.
• In contrast, software design is concerned with machine phenomena.
• In a machine-building project, the business of requirements engineers is to investigate
the problem world.
• A system denote a set of components interacting with each other to satisfy some global
objectives.

• We will consider two versions of the same system:

• • The system-as-is, the system as it exists before the machine is
built into it.
• • The system-to-be, the system as it should be when the machine
will be built and operated in it.
Example 1 : E-Auction system
. Consider an e-auction system on the Internet. This system is made up
of components such as sellers, buyers, shipping companies, an
independent e-payment subsystem, e-mail systems, and the software to
be developed or extended for inserting and advertising items, handling
bids, billing highest bidders, recording evaluations of sellers and buyers,
securing transactions and so forth. Global properties emerging from
component interactions include the satisfaction of buyers getting wider
access to interesting items, the satisfaction of sellers getting wider
access to potential buyers, auction rules regulating the system,
trustworthiness relationships and so on.
Example 2 : A Flight management
System

• A flight management system includes components such as pilots, air traffic

controllers, on-board and on-ground instruments, the autopilot software to be
developed, an independent collision-avoidance subsystem and so forth. Global
properties emerging from component interactions include the objectives of rapid
and safe transportation of passengers, regulating laws about wind directions,
aircraft speed, minimal distance between aircrafts and so forth
• ln the first example of an auction world, the system-as-is is a standard
auction system with no support for electronic bidding. The system-to-be
is intended to provide such support in order to make items biddable
from anywhere at any time.
• In a flight management world, the System-as-is might include some
autopilot software with limited capabilities; the system-to-be would then
include autopilot software with extended capabilities.

• In the former example the system-to-be is the outcome of a new

software project, whereas in the latter example it results from a software
evolution project
• So there is always a system-as-is.
 The software-to-be and its environment
• .
• software-to-be. The machine's software to be developed or modified is one component of the
system-to-be.
• Other components pertain to the machine's surrounding world. They will form the environment of
the software-to-be. Such components may include:
• • People or business units playing specific roles according to organizational policies.
• • Physical devices operating under specific rules in conformance with physical laws – for
example sensors, actuators, measurement instruments or communication media.
• • Legacy, off-the-shelf or foreign software components with which the software-to-be needs to
interact.

• As we are concerned with the problem world, we need to consider both the system-as-is, to understand its
objectives, regulating laws, deficiencies and limitations, and the
• system-to-be, to elaborate the requirements on the software-to-be accordingly together with assumptions on the
environment
• In this setting, we may define requirements engineering as a coordinated set of
activities for exploring, evaluating, documenting, consolidating, revising and
adapting the objectives, capabilities, qualities, constraints and assumptions that
the system-to-be should meet based on problems raised by the system-as-is and
opportunities provided by new technologies.
 The WHY, WHAT and WHO dimensions of requirements engineering

• The problem world may be structured along three dimensions.

• why a system-to-be is needed,

• what needs must be addressed by it,
• and who in this system will take part in fulfilling such needs
 The WHY dimension

• ,The contextual reasons for a new version of a system must be made

explicit in terms of objectives to be satisfied by it. the limitations of
the system-as-is and the opportunities to be exploited.
• Acquiring domain knowledge We need to get a thorough
understanding of the domain in which the problem world is rooted.
• in terms of concepts, regulating laws, procedures and terminology
• Evaluating alternative options in the problem world need to
assess the pros and cons of alternatives in order to select the most
preferable one.like digital libraries, driverless trains, e-agendas
• Evaluating technology opportunities We also need to acquire a
thorough understanding of the oppportunities provided by technologies
emerging in the domain under consideration, together with their
implications and risks. For example, what are the strengths,
implications and risks associated with digital libraries, driverless trains
or e-agendas?
• Handling conflicts The objectives that the system-to-be should satisfy are
generally identified from multiple sources which have conflicting viewpoints and
interests.
• As a result, there may be different perceptions of what the problems and
opportunities are; and there may be different views on how the perceived problems
should be addressed.
• In the end, a coherent set of objectives needs to emerge from agreed trade-offs.
• Example: Library management. access to state-of-the-art books and journals should
be made more effective.
• university authorities are likely to emphasize the objective of cost reduction through
integration of department libraries.
• Departments might be reluctant to accede to the implications of this, such as losing
their autonomy.
• Library staff might be concerned by strict enforcement of rules limiting library
opening periods, the length of loan periods or the number of loans to the same patron.
In contrast, library patrons might want much more flexible usage rules
The WHAT dimension
• This RE dimension is concerned with the functional seroices that the system-to-be should provide
to satisfy the objectives identified along the WHY-dimension.
• Such services often rely on specific system assumptions to work properly. They need to meet
constraints related to performance, security, usability, interoperability and cost - among others.
• Some of the services will be implemented by the software-to-be whereas others will be realized
through manual procedures or device operations.
• The system services, constraints and assumptions may be identified from the agreed system
objectives, from usage scenarios envisioned in the system-to-be, or from other elicitation
techniques
• They should be traceable back to system objectives so that we can argue that the latter will be
satisfied.
• The formulation of software services must also be mapped to precise specifications for use
by :software developers .
Example: Library management
Bibliographical query facility is a desirable software service in the UWON library
system-to-be objectives of increased coverage, information accuracy and wider
accessibility will be achieved through that service.
• One assumption to meet the objective of anywhere/anytime accessibility is that
library users should have Web access outside library opening hours.
• Constraints on the bibliographical query service might refer to the
• average response time to a query,
• the interaction mode
• query/answer format for useability by non-experts,
• user privacy (e.g. non-staff users should not be able to figure out what other
users have borrowed).
 The WHO dimension
• This RE dimension addresses the assignment of responsibilities for
achieving the objectives, services and constraints among the
components of the system-to-be - humans, devices or software.
• An important objective, service or constraint might not be achieved if
the system component responsible for it fails to behave accordingly
• Example: Library management.
• The objective of accurate book classification will not be
achieved if department faculty members, who might be made
responsible for it, do not provide accurate keywords when
books are acquired in their area.
• The objective of limited loan periods for increased availability
of book copies will not be achieved if borrowers do not
respond to warnings or threatening reminders, or if the
software that might be responsible for issuing such reminders
in time fails to do so.