INTRODUCTION TO

REQUIREMENTS
ENGINEERING
Software System Requirements engineering Module, 1503271
1

Edited By:
Dr Ahmad Nabot
Dr Ahmad Nabot
SOFTWARE ENGINEERING
 Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of system specification
through to maintaining the system after it has gone into use.

 Engineering discipline
 Using appropriate theories, methods and tools to solve problems bearing in mind
organizational and financial constraints.
 All aspects of software production:
 Software Engineering is Not just technical process of software development.
Also, software project management and the development of tools, methods etc. to
support software production.

2
SOFTWARE PROCESS
 The systematic approach that is used in software engineering is
sometimes called a software process.

 A software process is a sequence of activities that leads to the

production of a software product.

 There are four fundamental activities that are common to all software
processes. These activities are:

3
SOFTWARE PROCESS
ACTIVITIES:
1. Software Specification (Requirements), where customers and engineers define
the software that is to be produced and the constraints on its operation.
2. Software Development, where the software is designed and programmed
(Design and implementation (Code)).
(Creating Models (class diagram, flow charts, use cases, interactions,
algorithms, internal structure, data to be used, etc.), then Programming
(new or reuse).
3. Software Validation (Testing), where the software is checked to ensure that it
is what the customer requires.
4. Software Evolution, where the software is modified to reflect changing
customer and market requirements.
(Management and Documentation are ongoing activities that are aligned with
the previous activities).
4
REQUIREMENT ENGINEERING (RE)

Requirements engineering: is the process of finding out, by understanding

and defining, analyzing, documenting and checking what services the
system should provide and the constraints on its operation.

5
Definitions

 Requirement Engineering:
The subset of system engineering concerned with discovering, developing,
tracing, analyzing, qualifying, communicating and managing requirements
that define the system at successive levels of abstraction.

6
-Notes about the definition of requirements engineering:
A. Discovering: requirements elicitation.
B. Tracing: tracing requirements to other artifact, provides a mean of
validating requirements and capturing rationale of design.
C. Qualifying: refers to all kinds of testing.
D. Communication: requirements are the means of comm. Between
customers, developers, users…
E. Level of abstraction: organize requirements into layers. the requirements
at the top layer define the system in terms of problems to be solved,
requirements at subsequent layers define the system in terms of
implementable solution.

7
WHAT ARE REQUIREMENTS?
 Requirements:
Are specifications of what should be implemented. They are descriptions of how
the system should behave, or of a system property or attribute. They may be
constraints on the development process of the system.

 Requirement, functional
A statement of some function or feature that should be implemented in a system.
 Requirement, non-functional
A statement of a constraint or expected behavior that applies to a system. This
constraint may refer to the emergent properties of the software that is being
developed or to the development process.

8
WHAT ARE REQUIREMENTS?
 Requirement:

 A statement that identifies a product or process operational,

functional, or design characteristic or constraint, which is
unambiguous, testable or measurable, and necessary for product
or process acceptability (by consumers or internal quality
assurance guidelines)
….. IEEE-STD-1220-1998

9
Definition Explained:

 Statement. That a requirement should be a statement is perhaps biased

towards textual expression, whereas they can also be captured in
tabular form, in diagrammatic form in notations such as UML, in
formal notations,, or in domain-specific notations.

 The important concept, though, is to have a set of traceable,

manageable elements identified as requirements.

10
 Product or process. Complete solutions contain varying mixtures of product
(things that are built in response to requirements) and process (procedures for
using the things that are built). Requirements may therefore define process as
well as product. In addition to this, there may be requirements that stipulate
how the product should be developed, usually for quality control purposes.

 Operational, functional, or design characteristic or constraint. There are

many different kinds of requirement, giving rise to different kinds of language,
analysis, modelling, process and solution.

 Unambiguous. A requirement should lend itself to a clear, single understanding,

common to all parties involved.

11
 Testable or measurable. Requirements are used to test that the design or
solution is acceptable. For this to be possible, the requirement should be
quantified, thus providing a means of “measuring” the solution against it.

 Necessary for product or process acceptability. This highlights the

multidimensional role that requirements play: they serve to define what should
be designed and developed, and also define how the solution should be tested
and accepted. They have an influence in the earliest stages of the development
process as well as in the latest stages during acceptance.

 By consumers or internal quality assurance guidelines. Requirements come from

many sources, including but not limited to customers, regulatory bodies, users and
internal quality procedures.

12
DEFINITION OF
STAKEHOLDER
A stakeholder is a person, group, or organization that is actively
involved in a project, is affected by its process or outcome, or can
influence its process or outcome. Stakeholders can be internal or
external to the project team and to the developing organization. The
next Figure identifies many of the potential stakeholders in these
categories. Not all of these will apply to every project or situation, of
course.

Stakeholders are considered key sources of requirements.

13
What do customers want?
-The requirements engineer seeks to satisfy customer wants and need.

-One way to understand the needs levels of customers is to visit

Maslows classic hierarchy of self-actualization.

Maslow’s classic hierarchy of self actualization.
• The most basics are at the bottom.
• We will not move up if lower level are not satisfied.
• Self actualization: “to become every thing that one capable of
becoming” or Desire for fulfillment.

14
What do customers want?
- The figure shows Maslow’s hierarchy of self-actualization.

15
What do customers want?
- The figure shows the hierarchy of customer needs/wants

16
What do customers want?
the lowest level is basic functionality. Being a point of sale system implies certain functions must be
present—such as create a sale, return an item, update inventory, and so on.

At the enabling level, the customer desires features that provide enabling capabilities with respect to other
systems (software, hardware, or process) within the organization. So the POS system ties into some
management software that allows for sales data to be tracked by managers for forecasting or inventory
control purposes. The functionality at the enabling level may not meet or exceed competitors’ capabilities.

Those functional needs are met at the competitive advantage level. Here the customer wishes for this new
system to provide capabilities that exceed those of the competition or otherwise create a business
advantage.

Finally, ground-breaking desires would imply development of technology that exceeds current theory or
practice and has implications and applications beyond the system in question. For example, some kind of
new data-mining technology might be desired that exceeds current technologies. As with the Maslow
hierarchy, the idea is that the lower-level functionality must not be sacrificed to meet the higher
levels of functionality.
17
WHAT IS REQUIREMENT
SPECIFICATION
Requirements specification is the process of writing down the user and
system requirements in a requirements document.

As a product, Software Requirements Specification (SRS) document, is

the document that states the requirements of a software system.

18
IS REQUIREMENT ENGINEERING
IMPORTANT TO SOFTWARE
ENGINEERING?
WHY??

19
IMPORTANCE OF REQUIREMENT
ENGINEERING
 Requirements engineering (RE) is the most important area of software
engineering and possibly of the entire software life cycle.

 Errors produced at this stage, if undetected until a later stage of software

development, can be very costly.

 If the requirement specification is done correctly, errors of later stages will be

less. Hence, software development and maintenance cost will be less, and
customers will get their desired system.

Also, RE produces important deliverable … (SRS)

20
 - Effective requirements engineer lies at the heart of an organization’s ability to guide the ship.
 - Requirements are the basis for every project.
 - Once a greed requirement drive the project activity.
 -Without a relatively stable requirement base a development project can only founder.

 - Requirements form the base for :-

1. Project Planning.
2. Risk management.
3. Acceptance testing.
4. Trade off.
5. Change control.

21
The most common reasons for project failure are not technical the
following table identifies main reasons for project fail:

% 13.1 .incomplete req 1*

% 12.4 .Lack of user involvement 2* - The table show percentage of
% 10.6 3 reasons of project failure.
.Lack of resources
% 9.9 .Unrealistic expectation 4* -Those marked with an stars
% 9.3 .Lack of executive support 5 are related to req.
% 8.7 .Changing req 6*
-From surveys conducted by standish
% 8.1 .Lack of planning 7
group. 1995&1996
% 7.5 .Didn’t need any longer 8*

22
  Project success factors:
15.9 % User involvement. *1
13.9 % Management support. 2
13.0 % Clear statement of req. *3 Smaller milestone
(Is the same of check
9.6 % Proper planning. 4 point).
8.2 % Realistic expectation. *5
7.7 % Smaller milestone. 6
7.2 % Competent staff. 7
5.3 % Owner ship. *8

23
IS REQUIREMENT SPECIFICATION
IMPORTANT TO SOFTWARE
ENGINEERING?
WHY??

24
IMPORTANCE OF REQUIREMENT
SPECIFICATION
 An agreement with your customer on exactly how the system will operate
 A point of synchronization for the project team
 A basis for building a master plan and schedule
 Instructions to engineers on what to build
 A baseline for change control

25
LEVELS OF REQUIREMENTS:
 If a company wishes to let a contract for a large software development
project, it must define its needs in a sufficiently abstract way that a
solution is not predefined. The requirements must be written so that
several contractors can bid for the contract, offering, perhaps,
different ways of meeting the client organization’s needs.

 Once a contract has been awarded, the contractor must write a

system definition for the client in more detail so that the client
understands and can validate what the software will do.
 Both of these documents may be called the requirements document for
the system
26
LEVELS OF REQUIREMENTS ABSTRACTION:
 User requirements (High level)
 Statements in natural language plus diagrams of the services that the
system is expected to provide and its operational constraints.
Written for customers.
 Collected user requirements often appear as a “concept of
operations” (Conops) document. In many situations user stories can
play the role of user requirements.
 System requirements (Low level)
 A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract between
client and contractor.
 Collected in system requirements specification (SRS) document. 27
EXAMPLE

28
READERS OF DIFFERENT TYPES OF REQUIREMENTS
SPECIFICATION
You need to write requirements at different levels of detail because different readers
use them in different ways

29
 REQUIREMENTS CLASSIFICATION FROM
FUNCTIONAL POINT OF VIEW:
 Functional requirements
 Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in
particular situations.
 May state what the system should not do.
 Non-functional requirements
 Constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc.
 Often apply to the system as a whole rather than individual features or
services.
30
FUNCTIONAL REQUIREMENTS
 Describe functionality or system services.
 Depend on the type of software, expected users and the
type of system where the software is used.
 Functional user requirements may be high-level
statements of what the system should do.
 Functional system requirements should describe the
system services in detail.

31
EXAMPLE:
FUNCTIONAL REQUIREMENTS FOR THE MENTAL HEALTH
CARE PATIENT MANAGEMENT SYSTEM (MHC-PMS)

 1) A user shall be able to search the appointments lists for all clinics.
 2) The system shall generate each day, for each clinic, a list of patients who are
expected to attend appointments that day.
 3) Each staff member using the system shall be uniquely identified by his or her 8-
digit employee number.

These user requirements define specific functionality that should be

included in the system. The requirements show that functional
requirements may be written at different levels of detail (contrast
requirements 1 and 3). 32
FUNCTIONAL REQUIREMENTS EXAMPLES
SMART HOMES – AIR
CONDITIONER/HEATING SUB SYSTEM
 Smart home shall be divided into zones for heating and cooling.
 System shall accept desired temperature setting for each zone, for no
less than (4) periods in the day.
 System shall accept input for desired room temperature when room is
unoccupied.
 System shall detect motion to determine if a room is occupied, and
make proper adjustments to the temperature.
 System shall differentiate between pets and occupants for motion
detection and temperature adjustment.
 System shall monitor outdoor temperature and humidity

33
REQUIREMENTS IMPRECISION (LACK OF
ACCURACY)
 Problems arise when requirements are not precisely stated.
 Ambiguous requirements may be interpreted in different ways by
developers and users.

 Consider the term ‘search’ in requirement 1(A user shall be able to search
the appointments lists for all clinics).
 User intention – search for a patient name across all appointments in all
clinics;
 Developer interpretation – search for a patient name in an individual
clinic. User chooses clinic then search.

34
NON-FUNCTIONAL
REQUIREMENTS
 These define system properties and constraints e.g.
reliability, response time and storage requirements.
 Alternatively, they may define constraints on the system
implementation, such as Constraints on I/O device capability,
system representations (Interfaces), etc.
 Process requirements may also be specified mandating a
particular IDE, programming language or development
method.
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system may
be useless.
35
NON-FUNCTIONAL REQUIREMENTS IMPLEMENTATION
 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 system services that are required.
 It may also generate requirements that restrict existing
requirements.

 (Notes) 36
NON-FUNCTIONAL REQUIREMENTS CLASSIFICATIONS:

37
NON-FUNCTIONAL
CLASSIFICATIONS
 Product requirements
 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.

 Examples include performance requirements on how fast the system

must execute and how much memory it requires, reliability
requirements that set out the acceptable failure rate, security
requirements, and usability requirements.

38
NON-FUNCTIONAL
CLASSIFICATIONS
 Organisational requirements
 Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.

 Examples include operational process requirements that define

how the system will be used, development process requirements
that specify the programming language, the development
environment or process standards to be used, and environmental
requirements that specify the operating environment of the
system.

39
NON-FUNCTIONAL CLASSIFICATIONS
 External requirements
 Requirements which arise from factors which are external to the system
and its development process e.g. interoperability requirements,
legislative requirements, etc.

 These may include regulatory requirements that set out what must be
done for the system to be approved for use by a regulator, such as a
central bank; legislative requirements that must be followed to ensure
that the system operates within the law; and ethical requirements that
ensure that the system will be acceptable to its users and the general
public.

40
 EXAMPLES OF NONFUNCTIONAL
REQUIREMENTS IN THE MHC-PMS
Product requirement
The MHC-PMS shall be available to all clinics during normal working
hours (Mon–Fri, 0830–17.30). Downtime within normal working hours
shall not exceed five seconds in any one day.

Organizational requirement
Users of the MHC-PMS system shall authenticate themselves using their
health authority identity card.

External requirement
The system shall implement patient privacy provisions as set out in HStan-
03-2006-priv.

41
DOMAIN REQUIREMENTS
 Are derived from the application domain.
 Domain requirements may consist of new functional requirements
and constraints on existing requirements, or they may specify how
particular computations are performed.
 If domain requirements are not satisfied, the system may be
unworkable
 Example: banking domain. Requirements related to finance
and account shall be provided to the requirements engineer
such as taxes calculations
 Example: in baggage handling system, the new system should
follow regulations applied in the domain.
 Example: a train control system has to take into account the 42
braking characteristics in different weather conditions
DOMAIN REQUIREMENTS PROBLEMS
 Understandability
 Requirements are expressed in the language of the application domain;
 This is often not understood by software engineers developing the system.
e.g. The system safety shall be assured according to standard IEC 60601-
1:Medical Electrical Equipment – Part 1:General Requirements for Basic Safety
and Essential Performance.

43
DOMAIN REQUIREMENTS PROBLEMS
 Implicitness
 Domain specialists understand the area so well that they do not
think of making the domain requirements explicit.
 e.g. The deceleration of the train shall be computed as:  D
(train) = D (control) + D (gradient)
 where
 D (gradient) is 9.81ms2 * compensated gradient/alpha and
the values of 9.81ms2 /alpha are known for different types of
train.

44
ADDRESSING THE REQUIREMENTS 4CS:
In principle, requirements should be
Complete:
 They should include descriptions of all facilities required.
 All services required by the users should be defined.
 Consistent:
 There should be no conflicts or contradictions in the descriptions of the
system facilities.
 The requirements should not have contradictory definitions.
 Correct: requirements are not wrong.
 Clear: Requirements should be written in unambiguous and clear
way.
45
RELATIONSHIP BETWEEN REQUIREMENTS SPECIFICATION LEVELS
AND TESTING

46
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. For Example:
 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.

47
WHAT ARE THE FUNDAMENTAL
ACTIVITIES OF REQUIREMENT
ENGINEERING???

48
REQUIREMENTS DEVELOPMENT AND MANAGEMENT

 As the Figure shows, requirements development is subdivided into elicitation,

analysis, specification, and validation. These subdisciplines encompass all the
activities involved with exploring, evaluating, documenting, and confirming the
requirements for a product. 49
ELICITATION
 Elicitation encompasses all of the activities involved with discovering
requirements, such as interviews, workshops, document analysis,
prototyping, and others. The key actions are:

 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.
50
ANALYSIS
 Analyzing requirements involves reaching a richer and more precise
understanding of each requirement and representing sets of requirements in
multiple ways. Following are the principal activities:

 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
51
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.

52
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.

53
NOTE:
 Iteration is a key to requirements development success.
Plan for multiple cycles of exploring requirements,
progressively refining high-level requirements into more
precision and detail, and confirming correctness with users.
This takes time and it can be frustrating. Nonetheless, it’s an
intrinsic aspect of dealing with the fuzzy uncertainty of
defining a new software system.

54
REQUIREMENTS MANAGEMENT
Requirements management activities include the following:

 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
55
REQUIREMENTS MANAGEMENT
Requirements management activities include the following:

 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

56
The boundary between requirements development and requirements management. 57
 WHEN BAD REQUIREMENTS HAPPEN TO
GOOD PEOPLE
 The major consequence of requirements problems is rework—doing
again something that you thought was already done—late in development
or after release.
 Rework often consumes 30 to 50 percent of your total development cost,
and requirements errors can account for 70 to 85 percent of the rework
cost.
 It can cost far more to correct a defect that’s found late in the project than
to fix it shortly after its creation.
 Suppose it costs $100 (on a relative scale) to find and fix a requirement
defect while you’re still working on the requirements. If you discover that
error during design instead, you have to pay the $1 to fix the requirement
error, plus another $200 or $300 to redo the design that was based on the
incorrect requirement. 58
SOME OF THE MOST COMMON REQUIREMENTS RISKS
ARE
 Insufficient user involvement:
 Insufficient user involvement leads to late-breaking requirements that
generate rework and delay completion.
 particularly when reviewing and validating the requirements, is that the
business analyst might not understand and properly record the true
business or customer needs.
 Inaccurate planning:
 Vague, poorly understood requirements lead to overly optimistic estimates,
which come back to haunt you when the inevitable overruns occur.
 The top contributors to poor software cost estimation are frequent
requirements changes, missing requirements, insufficient communication
with users, poor specification of requirements, and insufficient
requirements analysis 59
SOME OF THE MOST COMMON REQUIREMENTS RISKS
ARE
 Creeping user requirements:
 As requirements evolve and change during development, projects often
exceed their planned schedules and budgets (which are nearly always too
optimistic anyway).
 Project managers should build contingency buffers into schedules so the
first new requirement that comes along doesn’t derail the schedule.
 Ambiguous requirements:
 One symptom of ambiguity in requirements is that a reader can interpret a
requirement statement in several ways. Another sign is that multiple readers of a
requirement arrive at different understandings of what it means.
 Ambiguity leads to different expectations on the part of various stakeholders. Some of
them are then surprised at whatever is delivered. Ambiguous requirements cause
wasted time when developers implement a solution for the wrong problem. Testers
who expect the product to behave differently from what the developers built waste
time resolving the differences. 60
SOME OF THE MOST COMMON REQUIREMENTS RISKS
ARE
 Gold plating:
 takes place when a developer adds functionality that wasn’t in the requirements
specification (or was deemed out of scope) but which the developer believes “the
users are just going to love.” If users don’t care about this functionality, the time
spent implementing it is wasted. Rather than simply inserting new features,
developers and BAs should present stakeholders with creative ideas for their
consideration. Developers should strive for leanness and simplicity, not going
beyond what stakeholders request without their approval.

 Overlooked stakeholders:
 If you don’t identify the important user classes for your product early on,
some user needs won’t be met. After identifying all user classes, make sure
that each has a voice, as discussed in Chapter 6, “Finding the voice of the
user.”
61
REFERENCES
 This presentation material has been prepared from the references below:
 Karl Wiegers and Joy Betty, Software Requirements, 3rd Edition, Microsoft. Chapter 1
 Ian Somerville, Software Engineering, 10th edition, Pearson. Chapter 2

62