Chapter 4: Requirement Engineering

1
Objectives
• Introduce software requirements and to discuss the processes involved
in discovering and documenting these requirements.
• Understand the concepts of user and system requirements
• Understand the differences between functional and nonfunctional
software requirements.
• Understand the principal requirements engineering activities of
elicitation, analysis and validation, and the relationships between these
activities.
• Understand why requirements management is necessary and how it
supports other requirements engineering activities.
2
Topics Covered
User and System Requirements
Functional and non-functional requirements
Requirements Engineering Process
Requirements Elicitation and analysis
Requirements Specification
Requirements Validation
Requirements Change

3
 Requirement Engineering
• Requirements engineering is a process of gathering and defining of what the
services should be provided by the system.
• ‘user requirements’ to mean the high-level abstract requirements and ‘system
requirements’ to mean the detailed description of what the system should do.
• User Requirements: It describes the services that the system should provide
and the constrains under which it must operate. It’s usually written in a natural
language and supplied by diagrams
• The Mentcare system shall generate monthly management reports showing the
cost of drugs prescribed by each clinic during that month.
• System Requirements : are more detailed descriptions of the software
system’s functions, services, and operational constraints.

4
• The system requirements document (sometimes called a functional specification)
should define exactly what is to be implemented.
System requirements specification
• On the last working day of each month, a summary of the drugs prescribed, their
cost and the prescribing clinics shall be generated.
• The system shall generate the report for printing after 17.30 on the last working day
of the month.
• A report shall be created for each clinic and shall list the individual drug names, the
total number of prescriptions, the number of doses prescribed and the total cost of
the prescribed drugs.
• If drugs are available in different dose units (e.g. 10mg, 20mg, etc.) separate reports
shall be created for each dose unit.
• Access to drug cost reports shall be restricted to authorized users as listed on a
management access control list.

5
Functional & Non-Functional Requirements
•Functional requirements: It covers the main functions that should be provided
by the system, more specific functional system requirement describe the system
functions, it’s inputs, processing, how it’s going to react to a particular input, and
what’s the expected output.
•This is the list of the actual services which a system will provide. eg.client
demand feature software, business rules for particular organization for which
developing software.
•Non-Functional Requirements: These are constraints on the services or
functions offered by the system. They include timing constraints, constraints on
the development process, and constraints imposed by standards
•Non-functional requirements may affect the overall architecture of a system
rather than the individual components.
6
• Nonfunctional requirements arise through user needs because of budget
constraints, organizational policies, the need for interoperability with other
software or hardware systems, or external factors such as safety
regulations or privacy legislation.
• For example, functional requirements for the Mentcare 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
employee number.
7
 Non-Functional Requirements

Product requirements Organizational

External requirements
requirements
• Efficiency • Interoperability
• Delivery • Ethics
• Reliability
• Implementation • Legislative
• Portability
• Standards • Privacy
• Usability
• Performance • Safety

• Space

8
Product requirement
•The Mentcare system shall be available to all clinics during normal working
hours (Mon–Fri, 08:30–17:30).
•Downtime within normal working hours shall not exceed 5 seconds in any
one day.
Organizational requirement
•Users of the Mentcare system shall identify themselves using their health
authority identity card.
External requirement
•The system shall implement patient privacy provisions as set out in HStan-
03-2006-priv.
Figure .Examples of possible non-functional requirements for the Mentcare system

9
Domain requirements
•From the application domain of the system
•May be functional or non-functional
•Examples: Medicine, library, physics, chemistry

10
Requirements engineering processes
• Requirements engineering processes may include four high-level
activities.
• These focus on assessing if the system is useful to the business
(feasibility study), discovering requirements (elicitation and
analysis), converting these requirements into some standard form
(specification), and checking that the requirements actually define
the system that the customer wants (validation).
• Requirements engineering processes ensures your software will
meet the user expectations, and ending up with a high quality
software.
• At the end of this stage, a requirements document that specifies
11
the requirements will be produced and validated with the
 Requir ements
Feasibility elicitation and
stud y
analysis
Requir ements
specification
Feasibility Requir ements
repor t validation

System
models

User and system

requirements

Requir ements
document

Figure 4.1. The requirements engineering process.

12
Figure 4.2. A spiral view of the requirements engineering process
13
1. Feasibility Report
• Before getting started with the software, you need to make a study to
identify of whether the system is worth implementing and if it can be
implemented under the current budget, technical skills, schedule, and if
it does contribute to the whole organization objectives or not, etc.
• The business requirements are the need of the customer or the
developing organization; why the software is being developed, that must
be fulfilled to achieve a high-level objective.
• The results of the feasibility study should be a report that recommends
whether to go forward to the next process or you won’t be able to
implement the software at all.
•Technical , Operational  , Economic Feasibility
14
2. Requirements elicitation and analysis
•Requirements elicitation is the practice of researching and discovering the
requirements of a system from users, customers, and other stakeholders. The practice
is also sometimes referred to as "requirement gathering"
• In this activity, software engineers work with customers and system end-users to
find out about the domain requirements, what services the system should provide, and
the other constrains.
• It may also involve a different kinds of stockholders; end-users, managers, system
engineers, test engineers, maintenance engineers, etc.

Figure 4.3. The requirements elicitation and analysis process 15

• A stakeholder is anyone who has direct or indirect influence on the
requirements.
Requirements Discovery:
• It’s the process of interacting with, and gathering the requirements
from, the stakeholders about the required system and the existing
system (if exist).
• It can be done using some techniques, like interviews, scenarios,
prototypes, etc, which help the stockholders to understand what the
system will be like.
• Eliciting and understanding requirements from system stakeholders is
a difficult process for several reasons:
• Stakeholders may not know what exactly they want the software to
16
do, or they may give un-realistic requirements.
• Different stakeholders have different requirements and they may
express these in different ways, which will result in conflict between
the requirements, so we have to discover and resolve these conflicts.
• There might be some factors that influence on the stakeholder’s
decision, like for example, managers at a company or professors at
the university want to take a full control over the management
system.
Interviews
• In these interviews, the requirements engineering team puts
questions to stakeholders about the system that they currently use and
the system to be developed. Requirements are derived from the
answers to these questions.
17
The questions fall under two categories:
Closed-Ended questions:
where the stakeholder answers a pre-defined set of question.
Open-Ended questions:
There is no a pre-defined expected answer, engineering team explores a range of
issues with system stakeholders and hence develop a better understanding of
their needs.
• In practice, interviews usually use mixture of both. Usually, start with the
open-ended questions, and then use the closed-ended questions to be more
specific about some requirements that aren’t clear yet.
• Interviews are good to get an overall understanding of what stakeholders need,
how they might interact with the new system, and the difficulties they face with
the current system.
18
Ethnography
•A social scientist spends a considerable time observing and analyzing how people
actually work.
•People do not have to explain or articulate their work.
•Social and organizational factors of importance may be observed.
•Ethnographic studies have shown that work is usually richer and more complex
than suggested by simple system models.
Scope of ethnography
•Requirements that are derived from the way that people actually work rather than
the way I which process definitions suggest that they ought to work.
•Requirements that are derived from cooperation and awareness of other people’s
activities.
–Awareness of what other people are doing leads to changes in the ways
in which we do things. 19
• Ethnography is effective for understanding existing processes but cannot
identify new features that should be added to a system.
• Ethnography is an observational technique that can be used to understand
operational processes and help derive requirements for software to support
these processes.
• Ethnography can provide an in-depth understanding of the socio-
technological realities surrounding everyday software development
practice, i.e., it can help to uncover not only what practitioners do, but also
why they do it

20
Focused ethnography
•Developed in a project studying the air traffic control process
•Combines ethnography with prototyping
•Prototype development results in unanswered questions which focus the
ethnographic analysis.
•Ethnography is helpful to understand existing systems which may have
some historical basis which is no longer relevant, but this understanding
does not always help with innovation

21
Figure 4.4. Ethnography and prototyping for requirements analysis

22
Scenarios
• Stories and scenarios are essentially the same thing. They are a description of how
the system can be used for some particular task.
• Scenarios are real-life examples of how a system can be used.

• They should include

• A description of the initial situation.
• A description of the flow of the events or interactions with the system
• A description of the exceptions, or in other words, what can go wrong, and
how it can be handled.
• Information about other activities that might be going on at the same time
• A description of the system state when the scenario finishes.

• Scenario-based elicitation involves working with stakeholders to identify scenarios

and to capture details to be included in these scenarios. Scenarios may be written as
23
text, supplemented by diagrams, screen shots, etc.
Figure 4.5. Scenario for uploading photos in KidsTakePics

24
Use cases
•Use cases identify interactions between the system and it’s users or even
other external systems (using graphical notations), involves some
symbols to describe the system:

Actors: Are those who interact with the system; human or other systems
Interaction (Use Case): It denotes the name of the interaction (verb). It’s
represented as a named ellipse.
Connection: Lines that links between the actors and the interactions.
Include Relationship: It denotes a connection between two interactions when
an interaction is invoked by another.
Exclude Relationship: It denotes a connection between two interactions when
you want to extend an interaction by adding or optional functionality.
25
Figure 4.6. Use cases consultation for the Mentcare system

26
• Use cases identify the individual interactions between the system and its
users or other systems. Each use case should be documented with a textual
description. These can then be linked to other models in the UML that
will develop the scenario in more detail.
• The UML is a standard for object-oriented modeling, so use cases and use
case based elicitation are used in the requirements engineering process

27
 ATM machine

Actors
Customers
Bank staff
ATM service engineer

Use cases
Withdraw cash
Check balance
Add cash to machine
Check security video recording

• Use case NOT describe internal behaviour,

But external Actor can be
• External system (e.g. Paypal)
• External hardware (e.g. smoke detector fire alarm)
• External agency (e.g. Police, fire brigade)
• So Use cases are always systems EXTERNAL behaviour
28
• Use case and scenarios are effective techniques for eliciting the
requirements. But, because they focus on the interactions with the
system, they aren’t effective for eliciting high-level business, non-
functional, or domain requirements.
29
Requirements Classification & Organization
•It’s very important to organize the overall structure of the system. Putting
related requirements together, and decomposing the system into sub
components of related requirements. Then, we define the relationship
between these components.
•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.

30
Requirements prioritization and negotiation
• One of the reasons is the conflicts that may arise as a result of having
different stakeholders involved. Why? because it’s hard to satisfy all
parties, if it’s not impossible.
•This activity is concerned with prioritizing requirements and finding
and resolving requirements conflicts through negotiations until you reach
a situation where some of the stakeholders can compromise.
Requirements specification
•The requirements are documented and input into the next round of the
spiral. Formal or informal requirements documents may be produced.

31
3. Requirement Specification
• Requirement specification is the process of generating requirement
document that is useful for user and system. The requirements should be
clear, easy to understand, complete and consistent.
• The user requirements for a system should describe the functional and
non-functional requirements so that they are understandable by users
who don’t have technical knowledge
• You should write user requirements in natural language supplied by
simple tables, forms, and intuitive diagrams.

32
• The system requirements on the other hand are expanded version of
the user requirements that are used by software engineers as the
starting point for the system design.
• They add detail and explain how the user requirements should be
provided by the system. They shouldn’t be concerned with how the
system should be implemented or designed.
• The system requirements may also be written in natural language
but other ways based on structured forms, or graphical notations are
usually used.
• The most two common ways are the natural and structured
languages.

33
Natural language (informal requirements):
•The requirements are written using numbered sentences in natural language. Each
sentence should express one requirement.
Structured natural language:
•Forms/templates are used to bring some rigor to natural language presentations.
•Structured natural languages are neither formal nor graphical, and can be too much
oriented to algorithms and specific programming languages.
Graphical notations:
•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.
Formal specification:
•Based on logic, state machines…
•Hard to understand for many people

34
4. Requirements Validation
•Requirements validation is a process of ensuring the specified
requirements meet the customer needs. It’s concerned with finding
problems with the requirements.
•These problems can lead to extensive rework costs when these they are
discovered in the later stages, 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 code errors. Because a
change to the requirements usually means the design and implementation
must also be changed, and re-tested.
•During the requirements validation process, different types of checks
should be carried out on the requirements. These checks include:
35
Validity checks: The functions proposed by stakeholders should be
aligned with what the system needs to perform, However further thought
and analysis may identify additional or different functions that are
required.
Consistency checks: Requirements in the document shouldn’t conflict or
different description of the same function.
Completeness checks: The document should include all the
requirements and constrains.
Realism checks: Ensure the requirements can actually be implemented
using the knowledge of existing technology, the budget, schedule, etc.

36
Verifiability: Can the requirements be checked?
•Requirements should be written so that they can be tested. This means you
should be able to write a set of tests that demonstrate that the system meets
the specified requirements.
Requirements validation techniques
• Requirements reviews: Systematic manual analysis of the requirements
• Prototyping: Using an executable model of the system to check
requirements.
• Test-case generation: Developing tests for requirements to check
testability
• Automated consistency Analysis: Checking the consistency of a
structured requirements description

37
 Requirements change
• The requirements for large software systems are always changing. One
reason for the frequent changes is that these systems are often developed to
address “wicked” problems—problems that cannot be completely defined
(Rittel and Webber 1973).
• Requirements change is caused by:
• Business process changes
• Technology changes
• Better understanding of the problem
Figure 4.7. Requirements evolution

39
 Requirements management planning

• Requirements management is the process of managing changing

requirements during the requirements engineering process and system
development.
• Requirements management includes planning and change management.

• During the requirements engineering process, Requirements management

decisions:
Requirements identification: Each requirements are individually
identified so, that it can be cross-referenced with other requirements and
used in traceability assessments.
A change management process: This is the set of activities that assess the
impact and cost of changes
40
• Traceability policies: The amount of information about requirements
relationships that is maintained
• CASE tool support: The tool support required to help manage requirements
change
• Traceability is concerned with the relationships between requirements, their
sources and the system design
Source traceability: Links from requirements to stakeholders who proposed
these requirements
Requirements traceability: Links between dependent requirements in the SRS.
Design traceability: Links from the requirements to the design
Features traceability: Indicates how requirements relate to important features
specified by the use
Interface traceability: Indicates how requirements are related to internal
interface and external interface of a system. 41
Requirements change management
Problem analysis and change specification
•The process starts with an identified requirements problem or, sometimes,
with a specific change proposal.
•During this stage, the problem or the change proposal is analyzed to check
that it is valid.
Change analysis and costing
•The cost of making the change is estimated in terms of modifications to the
requirements document and, if appropriate, to the system design and
implementation.
•Once this analysis is completed, a decision is made as to whether or not to
proceed with the requirements change.

42
 Change implementation
•The requirements document and, where necessary, the system design and
implementation, are modified.
•So, easily individual sections can be changed and replaced without
affecting other parts of the document.

Identified Revised
problem Problem analysis and Change analysis Change requirements
change specification and costing implementation

Figure 4.8. Requirements change management

43
Thank you

44