Introduction to Requirements

Engineering
 Motivation
• The beginning is the most important part of the
work.1
• Requirements engineering can greatly reduce the
amount of rework needed later in the life of the
software and can cost-effectively improve various
qualities of the system.
• Too often systems engineers forego sufficient
requirements engineering activity either because they
do not understand how to do requirements engineering
properly, or because there is a rush to start coding.

[1] Plato, 4 B.C.

 Mars Climate Orbiter
• In 1999, the Mars Climate Orbiter disappears around
Mars

• Cost: about $125M US

• Problem caused by a misunderstanding between a team

in Colorado and one in California

• One team used the metric system while the other used
the English system for a key function…
3
 GIRES
• GIRES1 (Gestion intégrée des ressources)
– Integrated management of resources
– To replace >1000 existing systems
– In 140 organisations / departments
– Affecting 68000 employees!
• 8-year project of the Quebec government, started 1998
• $80 million budget
• Could not cope with changes to the requirements…
– Cost of $400 millions after 5 years, and very late
– Project cancelled in 2003
[1] http://radio-canada.ca/nouvelles/Index/nouvelles/200303/04/012-GIRES.shtml
4
Definition and Importance of
Requirements
What is Requirements Engineering
• Is the branch of engineering concerned with
the real-world goals for, functions of, and
constraints on systems.
• It is also concerned with the relationship of
these factors to precise specifications of
system behavior and to their evolution over
time.
 What is Requirements
• A fundamental challenge for the requirements
engineer is recognizing that customers often
confuse requirements and goals (and
engineers sometimes do too).
• Goals are high-level objectives of a business,
organization, or system,
• A requirement specifies how a goal should be
accomplished by a proposed system.
• A requirement is:
• Capturing the purpose of a system

• An expression of the ideas to be embodied in the system or

application under development

• A statement about the proposed system that all stakeholders agree

must be made true in order for the customer’s problem to be
adequately solved
• Short and concise piece of information
• Says something about the system
• All the stakeholders have agreed that it is valid
• It helps solve the customer’s problem
According to IEEE 830-1993
• A requirement is defined as:
• A condition or capability needed by a user to solve a problem or
achieve an objective

• satisfy a contract, standard, specification, or other formally document

“Requirements Engineering”?
• Requirements Engineering (RE) is:
• The activity of development, elicitation, specification, analysis, and
management of the stakeholder requirements, which are to be met by
a new or evolving system
• RE is concerned with identifying the purpose of a software system…
and the contexts in which it will be used
• How/where the system will be used
• Big picture is important
• Captures real world needs of stakeholders affected by a software
system and expresses them as artifacts that can be implemented by a
computing system
Requirements Engineering Activities

Requirements Engineering

Requirements Requirements Requirements

Inception Development Management

Elicitation Analysis Specification Verification

Source: Larry Boldt, Trends in Requirements Engineering People-Process-Technology, Technology Builders, Inc., 2001
About these RE Activities…
• Inception
• Start the process (business need, market opportunity, great idea, ...), business
case, feasibility study, system scope, risks, etc.
• Requirements elicitation
• Requirements discovered through consultation with stakeholders
• Requirements analysis and negotiation
• Requirements are analyzed and conflicts resolved through negotiation
• Requirements specification
• A precise requirements document is produced
• Requirements validation
• The requirements document is checked for consistency and completeness
• Requirements management
• Needs and contexts evolve, and so do requirements!
General Problems with the Requirements Process
• Lack of the right expertise (software engineers, domain
experts, etc.)

• Initial ideas are often incomplete, and wildly optimistic

• Difficulty of using complex tools and diverse methods
associated with requirements gathering
Statistics from NIST Report
• NIST (National Institute of Standards and Technology) has
published a comprehensive (309 pages) :
• 70% of the defects are introduced in the specification phase
• 30% are introduced later in the technical solution process
• Only 5% of the specification inadequacies are corrected in the
specification phase
• 95% are detected later in the project or after delivery where the cost
for correction on average is 22 times higher compared to a correction
directly during the specification effort
• The NIST report concludes that extensive testing is essential, however
testing detects the dominating specification errors late in the process

[1] http://www.nist.gov/public_affairs/releases/n02-10.htm (May 2002)

 Failures Requirements Definition/Importance Requirements Types Development Process Requirements Activities

Why Focus on Requirements ?

• Distribution of Defects • Distribution of Effort to Fix Defects

Code
Code Other Design
Requirements 1%
7% Other Requirements 4% 13%
56% 10% 82%

Design
27%

Source: Martin & Leffinwell

View of the Software Engineering Institute (SEI)

• SEI’s vision is:

• The right software, delivered defect free, on time & on cost, every time
• “Right software” implies software that satisfies requirements for
functionality and qualities (e.g., performance, cost…) throughout its
lifetime
• “Defect free” software is achieved either through exhaustive testing
after coding or by developing the code right the first time
 Requirements Level Classification
• User requirements
• System requirements
• Design specifications
 User Requirements
• User requirements are abstract statements written in
natural language with accompanying informal diagrams.
• Describes the business needs for what users require
from the system
• They specify what services (user functionality)the
system is expected to provide and any constraints.
• 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
• System requirements are detailed descriptions of the
services and constraints.
• System requirements are sometimes referred to as
functional specification
• These requirements are derived from analysis of the user
requirements and they should be structured and precise.
• The requirements are collected in a systems requirements
specification (SRS) document.
• Use cases can play the role of system requirement in
many situations.
 Design Specifications
• Used as the basis for implementation by
developers.
• Derived from analysis of the system
requirements specification
User and System Requirements Example
• The readers of the user
requirements are not
usually concerned with how
the system will be
implemented and may be
managers who are not
interested in the detailed
facilities of the system.
• The readers of the system
requirements need to know
more precisely what the
system will do because they
are concerned with how it
will support the business
processes or because they
are involved in the system
implementation.
Relationship between requirements
specification levels and testing
Requirements Specifications Types
• Another taxonomy for requirements specifications focuses on the type
of requirement from the following list of possibilities:

 Functional requirements (FRs)

 Nonfunctional requirements (NFRs)
 Domain requirements
 Functional requirements (FRs)
• Describe the services the system should provide and how
the system will react to its inputs.
• Functional requirements can be
– high level and general
• (In which case they are user requirements in the sense that was
explained previously).
– or they can be detailed, expressing inputs, outputs,
exceptions, and so on
• (in which case they are the system requirements described before).
• There are many forms of representation for functional
requirements, from natural language (in our case, the
English language), visual models, and the more rigorous
formal methods.
Functional requirements examples
• Functional requirements need to be clear,
simple, and unambiguous.
• Here are some examples of well-written
functional requirements:
o The system must send a confirmation email
whenever an order is placed.
o The system must allow blog visitors to sign up for the
newsletter by leaving their email.
o The system must allow users to verify their accounts
using their phone number.
Functional requirements examples
• User story: As an existing user, I want to be able
to log into my account.
• Functional requirements:
– The system must allow users to log into their
account by entering their email and password.
– The system must allow users to log in with their
Google accounts.
– The system must allow users to reset their password
by clicking on "I forgot my password" and receiving a
link to their verified email address.
Requirements Specifications Types

 Functional requirements (FRs)

 Nonfunctional requirements (NFRs)
 Domain requirements
Nonfunctional Requirements NFRs
• Software systems are characterized both by
– their functional behavior (what the system does)
– and by their nonfunctional behavior (how the
system behaves with respect to some observable
attributes such as performance, reliability,
reusability, maintainability, etc.
• Despite the importance of NFRs, they are
almost always left to be verified after the
implementation is finished.
 Functional and Non-functional
requirements
• Every functional requirement typically has a
set of related non-functional requirements, for
example:
o Functional requirement: "The system must allow the user
to submit feedback through a contact form in the app."
o Non-functional requirement: "When the submit button is
pressed, the confirmation screen must load within 2
seconds."
 NFRs categories
1) Quality
• Most important
• Include safety, privacy, reliability, usability, and maintainability requirements.
• Generally, any software quality or attribute that ends in an “ility” is a
nonfunctional requirement.
• These so-called ilities derive from many sources including laws and regulations,
standards, environmental constraints, and elsewhere.
2) Design/ Implementation Constraints
Ex: restrictions on using certain architectural patterns or specific programming
languages
3) Economic Constraints: These are constraints which include the immediate
and/or long-term development cost
4) Operating Constraints: These are constraints which include physical constraints,
personnel availability, skill-level considerations, system accessibility for maintenance,
etc
5)Political/Cultural Constraints: These are constraints which include policy and legal
issues (e.g., what laws and standards apply to the product).
 NFRs
• It is important to recognize that NFRs are not stand-alone requirements
For example,
• NFRs can be associated with functional requirements: “Only
authorized users should be able to access X functionality of the
system,”
• or it can be associated with the resources required for the project:
“The software maintainers should have at least two years of
experience in Oracle database.
• It is also important to distinguish between what an NFR is and what it
may require to be satisfied. For example:
• the requirement for secure interaction while reading email messages
is classified as an NFR.
• But satisfying this requirement may require the introduction of some
technical design/architectural decisions, such as authentication,
authorization, or messages encryption.
Requirements Specifications Types

 Functional requirements (FRs)

 Nonfunctional requirements (NFRs)
 Domain requirements
 Domain Requirements
• Domain requirements reflect the environment in which the system operates
such as train operation, medical records, e-commerce etc.
• These types of requirements may consist of new functional/ on functional
requirements or constraints on existing functional requirements
• For example, the requirements for the insulin pump system that delivers
insulin on demand include the following domain requirement:
o 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.
– This requirement means that the developers must be familiar with that standard to ensure
that they do not violate it.
 Domain requirements
• Describes system characteristics and features that reflect the
domain
• If domain requirements are not satisfied, the system may be
unworkable

34
 Domain requirements Problems
1. Understandability: domain requirement are expressed in
the language of the application domain, this is often not
understood by software engineers.
2. Implicitness: Domain specialists understand the area so
well that they do not think of making the domain
requirements explicit.

35
 Requirement Engineer
• Requirement Engineer: responsible for creating
requirement document, and make sure
documented requirement are met through stages
od project.
• Requirement Engineer must have knowledge in:
– Using CASE tools.
– Using general Modeling techniques.
– Using modeling languages and ability to choose the best
one for a given problem.
– Using management and traceability tools.
36
 Requirement Engineering Process
• The goal of Requirements Engineering Process
is to create and maintain a system
requirement document.
• The overall process include four high-level
requirement engineering sub-process:
– Feasibility study.
– Elicitation and analysis.
– Specification.
– Validation.
37
Requirement Engineering Process

38
 Requirement Engineering Process
• The Requirements Engineering Process involve
the following activities:
– Feasibility Study.
– Requirement Elicitation.
– Requirement Analysis.
– Requirement Documentation.
– Requirement Validation.
– Requirement Management.

39
 Feasibility Studies
• A feasibility study decides whether or not the
proposed system is worthwhile.
• Is defined as an evaluation or analysis of the
potential impact of proposed project or
program.

40
 Feasibility Studies
A feasibility Study aims to answer the following
questions:
1. does the system contributes to the overall
organizational objectives?
2. Can the system can be engineered using
current technology and within budget?
3. Can the system can be integrated with other
systems that are used?

41
 Feasibility Studies
Feasibility Study involve:

1. information assessment.

2. information collection.

3. report writing.

42
 Feasibility Studies
Questions for people in the organization:
1. How would the organization cope if this system was not implemented?
2. What are the problems with current processes and how would a new
system help alleviate them?
3. What direct contribution will the system make to the business
objectives and requirements?
4. Can information be transferred to and from other organizational
systems?
5. Does the system require technology that has not previously been used
in the organization?
6. What must be supported by the system and what need not be
supported?

43
Different Aspects of Conducting Feasibility
Study
A Feasibility Study can be divided as following:
1. Economic Feasibility.
2. Technical Feasibility.
3. Legal Feasibility.
4. Organizational Feasibility.

44
Different Aspects of Conducting Feasibility
Study
1. Economic Feasibility: give the economical
justification for new system.
2. Technical Feasibility:
a. Understand the different technologies involved.
b. Find out if the organization current process
requires technology
c. Fid out if the necessary experise exist to use
technology

45
Different Aspects of Conducting Feasibility
Study
3. Legal Feasibility: be ascertained wither the
new system may result in any infringement,
violation, contracts or liabilities.
4. Organizational Feasibility: what are the issues
in hand and what are the management
expectations.

46
Documentation of Feasibility Study
Feasibility report contains: 3.2 Criteria used in selecting the final
approach.
1. Introduction.
1.1 Statement of Problem 4. System description:
1.2 Implementation Environment. 4.1 abbreviated statement of scope
1.3 Constraints. 4.2 feasibility of allocated elements.
2. Management summery and 5. Cost benefit analysis
Recommendations 6. Evaluation of technical risk
2.1 Important findings. 7. Legal ramifications.
2.2 comments. 8. Other project specific topics
2.3 Recommendations.
2.4 Impacts
3. Alternatives:
3.1 alternative system configurations.

47
Requirements Elicitation/Discovery
• Requirements elicitation/discovery involves
uncovering what the customer needs and wants.
• While some requirements will be obvious many
requirements will need to be extricated from the
customer through well-defined approaches.
• Also involves discovering who the stakeholders
are; for example, are there any hidden
stakeholders?
• Elicitation also involves determining the NFRs,
which are often overlooked
 Requirements Analysis and Agreement
• Requirements analysis and requirements agreement
involves techniques to deal with a number of problems
with requirements in their “raw” form, that is, after they
have been collected from the customers.
• Problems with raw requirements include the following:
They don’t always make sense.
 They often contradict one another
 They may be inconsistent.
They may be incomplete.
They may be vague or just wrong.
They may interact and be dependent on each other
Many of the elicitation techniques that we will discuss subsequently are intended
to avoid or alleviate these problems
Requirement Analysis Process

50
 Requirement Analysis Process
Requirement process Activities are
1. Domain understanding
2. Requirements collection
3. Classification
4. Conflict resolution
5. Prioritization
6. Requirements checking

51
 Requirement Documentation
• Requirement documentation is written after
elicitation and analysis, document called
software requirement specification (SRS).
• SRS is specifications of a system that describes
the system functionalities, performance and
constraints of the system.

52
 Requirements Representation
• Requirements representation (or modeling) involves
converting the requirements processed raw
requirements into some model (usually natural
language, mathematics, and visualizations).
• Proper representations conversion into a system
architecture and design.
• Various techniques are used for requirements
representation:
• informal (e.g., natural language, sketches, and diagrams),
• formal (mathematically sound representations),
• and semiformal
• Usually some combination of these is employed in requirements
representation
 Requirements Validation
• Validation is the process of determining if
the specification is a correct representation
of the customers’ needs.
• Validation answers the question “Am I
building the right product?”
• Requirements validation involves various
semiformal and formal methods, text-based
tools, visualizations, inspections, and so on.
 Requirements Management
• One of the most overlooked aspects of requirements engineering,
requirements management involves managing the realities of
changing requirements over time.
• It also involves fostering traceability (ability to track and
understand how different requirements are interconnected and
how they relate to each other)
• Managers also need to learn the skills to intelligently push back
when scope creep occurs.
• Using tools to track changes and maintain traceability can
significantly ease the burden of requirements management.
• Tools such as:
– IBM Engineering Requirements Management DOORS
– Jira
– ….
 Rule of Customer
• Helping the requirements engineer understand what they
need and want
• (elicitation and validation)
• Helping the requirements engineer understand what they
don’t want
• Providing domain knowledge when necessary and possible
• Alerting the requirements engineer quickly and clearly
when they discover that they or others have made
mistakes
• Alerting the requirements engineer quickly when they
determine that changes are necessary (really necessary)