INSTRUCTOR: SHAZMINA GULL

COURSE: SOFTWARE REQUIREMENT

ENGINEERING (SENG-01302)

Department of Software Engineering

The Islamia University of Bahawalpur,
Rahim Yar Khan Campus
 SOFTWARE

• Software is currently the dominant force of change of new products. The

trend is driven by three key factors:
• Arbitrary complexity
• Instant distribution
• “Off-the-shelf” components
• The result is pressure to reduce the development cycle and the time to deploy
technology. However, “time to market” is not sufficient. The real goal is “time to market
with the right product”. Establishing the requirements enables us to agree on and
visualize the “right product”.

2
 REQUIREMENTS

• Consultant Brian Lawrence suggests that a requirement is “anything that

drives design choices” (Lawrence 1997).
• Ian Sommerville and Pete Sawyer (1997):
• Requirements are a specification of what should be implemented. They are descriptions
of how the system should behave, or of a system property or attribute. They may be a
constraint on the development process of the system.

3
 REQUIREMENTS

• Software requirements include a time dimension. They could be present tense, describing
the current system’s capabilities. Or they could be for the near-term (high priority), mid-
term (medium priority), or hypothetical (low priority) future. They could even be past
tense, referring to needs that were once specified and then discarded.
• Requirements provide both the “navigation chart” and the means of steering towards the
selected destination.
• Requirements therefore form the basis for:
• project planning;
• risk management;
• acceptance testing;
• tradeoff;
• change control.

4
NECESSITY OF REQUIREMENTS

5
NECESSITY OF REQUIREMENTS

6
 REQUIREMENTS AND QUALITY

• Quality, then, is “fitness for purpose” or conformance to requirements –

it is providing something that satisfies the customer and in doing so
ensures that the needs of all the stakeholders are taken into account.

7
 SOFTWARE REQUIREMENT
ENGINEERING
• A vital part of the systems engineering process, requirements engineering
first defines the problem scope and then links all subsequent development
information to it. Only in this way can we expect to control and direct
project activity; managing the development of a solution that is both
appropriate and cost-effective.

8
SOFTWARE REQUIREMENT
ENGINEERING

9
 ELICITATION

• Identifying the product’s expected user classes and other stakeholders.

• Understanding user tasks and goals and the business objectives with which
those tasks align.
• Learning about the environment in which the new product will be used.
• Working with individuals who represent each user class to understand
their functionality needs and their quality expectations.

10
 ANALYSIS

• Analyzing the information received from users to distinguish their task goals from
functional requirements, quality expectations, business rules, suggested solutions,
and other information
• Decomposing high-level requirements into an appropriate level of detail
• Deriving functional requirements from other requirements information
• Understanding the relative importance of quality attributes
• Allocating requirements to software components defined in the system
architecture
• Negotiating implementation priorities
• Identifying gaps in requirements or unnecessary requirements as they relate to
the defined scope

11
 SPECIFICATION

• Requirements specification involves representing and storing the collected

requirements knowledge in a persistent and well-organized fashion. The
principal activity is:
• Translating the collected user needs into written requirements and diagrams suitable
for comprehension, review, and use by their intended audiences

12
 VALIDATION

• Requirements validation confirms that you have the correct set of

requirements information that will enable developers to build a solution
that satisfies the business objectives. The central activities are:
• Reviewing the documented requirements to correct any problems before the
development group accepts them.
• Developing acceptance tests and criteria to confirm that a product based on the
requirements would meet customer needs and achieve the business objectives.

13
 REQUIREMENTS MANAGEMENT

• Defining the requirements baseline, a snapshot in time that represents an agreed-

upon, reviewed, and approved set of functional and nonfunctional requirements,
often for a specific product release or development iteration
• Evaluating the impact of proposed requirements changes and incorporating
approved changes into the project in a controlled way
• Keeping project plans current with the requirements as they evolve
• Negotiating new commitments based on the estimated impact of requirements
changes
• Defining the relationships and dependencies that exist between requirements
• Tracing individual requirements to their corresponding designs, source code, and
tests
• Tracking requirements status and change activity throughout the project

14
 TYPES OF REQUIREMENTS

• Business requirement:
• A high-level business objective of the organization that builds a product or of a
customer who procures it.
• Business rule:
• A policy, guideline, standard, or regulation that defnes or constrains some aspect of the
business. Not a software requirement in itself, but the origin of several types of
software requirements.
• Constraint:
• A restriction that is imposed on the choices available to the developer for the design
and construction of a product.

15
 TYPES OF REQUIREMENTS

• External interface requirement:

• A description of a connection between a software system and a user, another software
system, or a hardware device.
• Feature:
• One or more logically related system capabilities that provide value to a user and are
described by a set of functional requirements.
• Functional requirement:
• A description of a behavior that a system will exhibit under specific conditions.
• Nonfunctional requirement:
• A description of a property or characteristic that a system must exhibit or a constraint
that it must respect.

16
 TYPES OF REQUIREMENTS

• Quality attribute:
• A kind of nonfunctional requirement that describes a service or performance
characteristic of a product.
• System requirement:
• A top-level requirement for a product that contains multiple subsystems, which could
be all software or software and hardware.
• User requirement:
• A goal or task that specific classes of users must be able to perform with a system, or a
desired product attribute.

17
RELATIONSHIPS
OF DIFFERENT
REQUIREMENTS

18
 PRODUCT VS. PROJECT
REQUIREMENTS
• So far, we have been discussing requirements that describe properties of a
software system to be built. Let’s call those product requirements. Projects
certainly do have other expectations and deliverables that are not a part of
the software the team implements, but that are necessary to the successful
completion of the project as a whole. These are project requirements but
not product requirements.

19
 PRODUCT VS. PROJECT
REQUIREMENTS
• Physical resources the development team needs, such as workstations, special hardware
devices, testing labs, testing tools and equipment, team rooms, and videoconferencing
equipment.
• Staff training needs.
• User documentation, including training materials, tutorials, reference manuals, and release
notes.
• Support documentation, such as help desk resources and field maintenance and service
information for hardware devices.
• Infrastructure changes needed in the operating environment. Requirements and procedures for
releasing the product, installing it in the operating environment, configuring it, and testing the
installation.
• Requirements and procedures for transitioning from an old system to a new one, such as data
migration and conversion requirements, security setup, production cutover, and training to
close skills gaps; these are sometimes called transition requirements (IIBA 2009).

20
 PRODUCT VS. PROJECT
REQUIREMENTS
• Product certification and compliance requirements.
• Revised policies, processes, organizational structures, and similar documents.
• Sourcing, acquisition, and licensing of third-party software and hardware
components.
• Beta testing, manufacturing, packaging, marketing, and distribution requirements.
• Customer service-level agreements.
• Requirements for obtaining legal protection (patents, trademarks, or copyrights)
for intellectual property related to the software.

21
REQUIREMEN
T LIFE-CYCLE
AND LAYERS
(V MODEL)

22
 REQUIREMENTS IN THE PROBLEM
AND SOLUTION DOMAINS
• Software engineering is concerned with developing and managing effective
solutions to problems. As has been discussed, it is a staged process vital for
businesses in enabling them to produce the right product within acceptable
time-scales and costs.
• Those stages of development associated with the highest levels of system
description – statement of need, usage modelling and stakeholder
requirements – should be firmly rooted in the problem domain, whereas
subsequent layers, starting with system requirements, operate in the
solution domain.

23
 REQUIREMENTS IN THE PROBLEM
AND SOLUTION DOMAINS
• Without a clear distinction between problem and solution, the following
may result:
• lack of understanding of the real problem;
• inability to scope the system and understand which functions to include;
• domination of debate about the system by the developers and suppliers, because the
only descriptions of the system are expressed in terms of solutions;
• inability to find optimal solutions due to lack of design freedom.

24
REQUIREMENTS IN THE PROBLEM
AND SOLUTION DOMAINS

25
 SOFTWARE
DEVELOPMENT
PROCESS

26
 A GENERIC
PROCESS FOR
REQUIREMENTS
ENGINEERING

27
 ENGINEER
REQUIREMENT
S GENERIC
PROCESS

***Qualification strategy is essential. 28

 ENGINEER
REQUIREMENTS
PROCESS IN
CONTEXT OF
CHANGES

29
 DERIVING REQUIREMENTS

• Derivation of component requirements based on a design architecture

• These requirements may be identical with one or more input
requirements; others may have been derived from input requirements to
partition them amongst the components.
• A further set of requirements consists of constraints(interface constraints
and possible physical constraints such as mass, volume, power usage and
heat dissipation) imposed either by the component architecture or input
requirements.

30
 DERIVING REQUIREMENTS

• In addition to establishing the component requirements, it is also necessary

to establish the satisfaction relationship between the input requirements
and the derived requirements.
• This relationship indicates which input requirements are satisfied by which
derived requirements and can be used to establish that:
• all input requirements are satisfied;
• all derived requirements are necessary (i.e., they directly or indirectly satisfy
• one or more input requirements).

31
 DERIVING THE QUALIFICATION
STRATEGY
• The satisfaction relationship is about generating derived requirements from input
requirements – how the system is designed.
• The qualification strategy plans how each requirement will be tested at each level.
• Each qualification action should consider the following aspects:
• the kind of action that would be appropriate for the requirement;
• the stage at which each action could take place – the earlier the better;
• any special equipment that would be needed for the action;
• what would constitute a successful outcome.
• Stakeholder requirements give rise to acceptance trials, whereas system
requirements give rise to system tests, that is, prior to delivery to the customer.

32
 BENEFITS OF ENGINEER
REQUIREMENTS GENERIC PROCESS
• It identifies common actions that are relevant at every level that led to the
establishment of information according to the information model presented.
• agreeing input requirements with the customer;
• analysis of input requirements to determine the risks and potential pitfalls in satisfying the
requirements;
• creating one or more models to investigate possible strategies for deriving requirements;
• generating requirements derived from the input requirements via the analyze and model
information;
• agreeing the derived requirements with the team(s) that will be responsible for
implementing them;
• establishing the satisfaction relationship between input requirements and derived
requirements;
• establishing the qualification relationship between derived requirements and the relevant
qualification strategy.

33
 BENEFITS OF ENGINEER
REQUIREMENTS GENERIC PROCESS
• The current state of the information can be used to measure progress, to assess
the impact of proposed changes and to define metrics on how a project is
performing.
• For example, the state of a requirement can be captured by its three attributes:
• agreement;
• satisfaction;
• qualification.
• The ideal state for any requirement in any system development is that it should
be:
• agreed between customer and supplier;
• have a qualification strategy agreed for it;
• be satisfied by lower-level requirements (or design).

34