SEN 207

Requirements Specification & Design

Lecture 1: Introduction to
Requirements Engineering

Dr. Ibrahim A. Salihu

Nile University of Nigeria
Course instruction
 Use of mobile phone is not allowed in
the class
 Attendance is compulsory (70%)
 Late coming will not be tolerated.
 No entry to after 30 minutes of
lecture
Course assessment
 Project 15%
 Midterm 20%
 Quiz 5%
 Final exam 60%
 Teams code lu38xq5
About the course
 In this course, you will become familiar with
software requirements and some issues
surrounding them.
 You will learn what a software requirement is,
including the different types of requirements.
 Then, you will learn how to deal with changing
requirements and control project scope, as well
as how requirements affect design.
 These course will give you the knowledge you
need to move on to eliciting and creating good
quality requirements for software product.
Learning Objectives

 To understand requirements engineering.

 Understand the importance of
requirements engineering
 Understand software requirements.
 Understand the importance of software
requirements
 Key Success Factors in Requirements
Engineering
 Requirements Engineering Artefact
Learning outcome
 By the end of the course;
 You will know how to carry out the
different activities to make a good
requirement for a software product
 You will also know and recognise when
requirements is deficient and needs to
be improved.
Introduction
Introduction cont…
Why are requirements Important?
 Studies indicates that about half of
the factors associated with project or
product success are requirements
related.
 Recently, researchers have reported
on studies showing that project
success is directly tied to
requirements quality
Why are requirements Important?
 Requirements help us to clearly
define client’s needs.
 To detect errors early before they
become expensive to fix.
 To ensure that, the product we are
building meet the needs of your
client.
Introduction cont…
 These days, end users are becoming
more demanding
 As a result, products are becoming more
sophisticated
 In order to ensure that you get the right
product and have it done right
 You need to make sure you start with
good requirements.
What is software Requirements?
 There are several definitions of
requirements.

 Software Requirements: they are the

specific description of your client’s need.

 Software requirements are defined

through the requirements engineering
process.
Requirements Engineering?
 Requirements engineering is the most
crucial and most important activity in
the software development life cycle
because the errors introduced at this
stage are the most expensive errors
requiring lot of rework if detected late in
the software life cycle.
Requirements Engineering
cont…
 The Software Requirements
Specification (SRS) document produced
as an output of this activity is used by
successive stages of life cycle i.e.
 for generating design document
 for coding,
 for generating test cases in software testing
and
 also plays a lead role in acceptance testing.
Why Has Requirements Engineering
Become So Important?
 For years, many products were
successfully created without the
participation of professionals who
specialized in requirements creation
or management.
 So, why is requirements engineering
(RE) so important today?
Why Has Requirements Engineering
Become So Important? Cont…
 The answer lies in the changing nature
of industry and society in general.
 First, the pace of product development
has picked up drastically.
 Whereas just a few decades ago,
product improvements would be a slow
process, today customers often demand
new versions of a product in less than
one year.
Why Has Requirements Engineering
Become So Important? Cont…
 Second, turnover and technology
change have impacted the experience
levels of professionals engaged in the
development of products.
 Just a few short years ago, engineers
might expect to spend their entire
careers with a single company,
 Whereas today job change is more
common.
Why Has Requirements Engineering
Become So Important? Cont…
 Finally, outsourcing and offshoring
have dramatically changed the
product life cycle.
 Specifications must now be created
for implementation or manufacturing
by organizations with potentially
limited or no domain expertise.
Why Has Requirements Engineering
Become So Important? Cont…
 Software development is highly coupled to the
domain; e.g., cell phone software and avionics
software tend to be designed, built, and
managed with processes that are heavily
domain specific.
 This results in domain-specific, complex
software for which high-quality requirements
specifications are essential.
Why Has Requirements Engineering
Become So Important? Cont…
 Requirements engineering is extremely
important when a product, service, or industry
is regulated.
 For example, the U.S. government’s Food and
Drug Administration (FDA) and Federal Aviation
Administration (FAA) both mandate specific
activities and work products (e.g., hazard
analysis) where there is the potential for injury
or death.
Why Has Requirements Engineering
Become So Important? Cont…
 Sarbanes-Oxley regulations mandate
traceability for certain types of financial
software used by companies doing business in
the United States. The European Union and
Japan have regulations for their respective
businesses.
 Good requirements engineering practices are
essential for companies that must comply with
government regulations.
Aim of Requirements Engineering
 The basic goal of requirements phase in the
SDLC is to produce the Requirements
Specification Document(RSD) or Software
Requirement Specification (SRS) which
describes the complete external behavior of
the proposed software system.
 The process of developing this document is
referred to Requirements Engineering.
Requirements Engineering (RE)
 “Requirements Engineering involves
all lifecycle activities devoted to
identification of user requirements,
analysis of the requirements to
derive additional requirements,
documentation of the requirements as
a specification, and validation of the
documented requirements against user
needs, as well as processes that support
these activities.”
Requirements Engineering
“The systematic process of documenting requirements
through an interactive co-operative process of analyzing
the problem, documenting the resulting observations in
a variety of representation format and checking the
accuracy of the understanding gained.”

“ The systematic use of proven principles, techniques, tools

and languages for the cost effective analysis,
documentation and ongoing evolution of user needs and
the specification of the external behavior of the system
in order to satisfy these needs.”
 Requirements Engineering

Input to this activity of requirements

engineering are requirements which are
informal and fuzzy and output is clear, well
defined and consistent requirements written in
formal notation RSD or SRS as shown -

Informal and Fuzzy Requirements Well Defined Complete and

Requirement Consistent Requirements
Engineering
Requirements Engineering

 It is essential that the software engineering

team understand the requirements of a
problem before the team tries to solve the
problem.
 RE is software engineering actions that start
with communication activity and continues into
the modeling activity.
 RE establishes a solid base for design and
construction. Without it, resulting software has
a high probability of not meeting customer
needs.
Misconceptions about
Requirements Engineering
 Some of the more common
misconceptions are listed under the
headings that follow.
 Misconception 1: Any Subject Matter Expert
Can Become a Requirements Engineer after a
Week or Two of Training.
 Requirements engineers need strong communication
and knowledge of engineering skills, the ability to
organize and manage a data set of requirements,
high-quality written and visual presentation skills,
and the ability to extract and model business
processes using both text and graphical (e.g.,
Integration DEFinition [IDEF], Unified Modeling
Language [UML]) techniques.
 Misconception 2: Non-functional and
Functional Requirements Can Be Elicited
Using Separate Teams and Processes.
 The subject domains for non-functional and
functional requirements are related, may
impact each other, and may result in
iterative changes as work progresses. Team
isolation may do more harm than good.
 Misconception 3: Processes That Work
for a Small Number of Requirements Will
Scale.
 Requirements engineering processes do not
scale well unless crafted carefully. For
example, a trace matrix is an N × N matrix,
where N is the number of requirements of
interest. In each cell, a mark or arrow
indicates that there is a trace from
requirement Ri (row i) to requirement Rj
(column j).
Key Success Factors in
Requirements Engineering
 The key factors for success in
requirements engineering.
 Most of the factors can be evaluated
prior to project initiation.
 Although project success cannot be
guaranteed, it is likely that if several of
the success factors are not in place
there may be significant project
difficulties.
 The Project Has a Full-Time, Qualified
Chief Architect.
 He provides technical continuity and vision,
and is responsible for the management of
the non-functional requirements (e.g.,
scalability, quality, performance,
environmental, etc.) and for the
implementation of the functional
requirements.
 An Effective Requirements
Management Process Is in Place
 The critical success factors in a
requirements management process are
well defined by the Capability Maturity
Model Integration (CMMI), specifically
those addressing change management
and traceability.
 Requirements Elicitation Starts with
Marketing and Sales
 The marketing and sales organizations
and the project’s requirements
engineering staff must establish
strong bonds to enable accurate
definition of product and/or product
line features.
 Requirements Reviews Are Conducted for
All New or Changed Requirements or
Features.
 Requirements must be reviewed, and the
review must occur at the right level.
 Requirements Engineers Are Trained and
Experienced.
 Requirements engineering is like any other
scientific or engineering endeavor in that the
basic skills can be learned through training.
 Subject Matter Experts Are Available as
Needed.
 Arrangements must be made early on to
access the experts needed to assist in
defining requirements.
 All Stakeholders Are Identified.
 Customer management includes rapid
feedback during prototyping, minimizing the
number of points of contact between project
staff and stakeholders, and maintaining strict
control of feature change requests.
Requirements
Engineering Artifact Modeling
 The purpose of requirements
engineering artifact modeling is to
 Define a reference model for RE that
provides the core set of RE artifacts
(work products) and their
interdependencies.
 Guide the establishment and
maintenance of product- and project-
specific RE processes [Geisberger 2006].
 Thus, early requirements engineering activities
include
 Analyzing marketing information, stakeholder, and
user needs to derive the functional and non-
functional requirements to be met by the system’s
design
 Understanding the effect of these requirements on
the business that creates the product
 Consolidating these requirements into consistent and
complete requirements and systems specifications as
defined in the Requirements Engineering Artifact
Model (REAM).
 Thus, the key components of requirements
engineering artifact modeling are
 An RE artifact model as a measurable reference
model that can be used to support interdisciplinary
communication and specifications development
 A process tailoring approach that specializes the RE
artifact model to specific organizational or project
needs
 RE artifact-centered process guidelines that define
completion levels of the RE artifact model. The
specified completion levels form a baseline for
measuring project progress and artifact quality.
Summary
 We have discussed requirements
engineering
 We have learnt software requirements
 We discussed the difference between
functional and non functional requirements
 We have studied the classification of
requirement