Software Requirements Engineering

Lecture # 1

Introduction
ALI JAVED

Lecturer

SOFTWARE ENGINEERING DEPARTMENT

U.E.T TAXILA

Email:: ali.javed@uettaxila.edu.pk

Office Room #:: 7

 Text Book

y Managing Software Requirements: A

Use Case Approach, Second Edition By
D
Dean L ffi
Leffingwell,
ll Don
D Wid i Addison-
Widrig, Addi
Wesley

y Software Requirements, Second

Edition by Karl E.
Wiegers ISBN:0735618798, Microsoft
Press
 Presentation Outline

ƒ What is Requirement?
ƒ The Goal of Software Development
ƒ Stakeholder’s Environment
ƒ Customer’s Types
ƒ Root Causes of Project Success and Failures
ƒ The Frequency of Requirement Errors
ƒ The High Cost of Requirement Errors
ƒ Requirements Management
ƒ Types of Software Applications
ƒ The Problem Domain
‰ Stake Holder Needs
ƒ The Solution Domain
‰ Features
‰ Software Requirements
q
ƒ An Introduction To Use cases
ƒ Use Case Diagram
ƒ Use Case Elements
ƒ Relationship between Use case Elements
ƒ ATM Example Use Case Diagram
 What is Requirement?

IEEE Definition of Requirement

ƒ A condition or capability
p y that must be met or possessed
p by
y a
system or system component to solve a problem or to achieve an
objective
 The Goal of Software Development
ƒ The goal of software development is to develop quality software—on time
and on budget—that meets customers' real needs.

ƒ A software is good if it MEETS STAKEHOLDERS EXPECTATIONS:

‰ it is (at least) correct,

correct reliable,
reliable maintainable,
maintainable user
user-friendly
friendly …
‰ the total cost it incurs over all phases of its life cycle is minimal and within the
budget

ƒ A Stakeholder
k h ld is anyone whoh could
ld affects
ff or be
b affected
ff d by
b the
h
implementation of a new system or application.

ƒ However stakeholders are different!

However,
Context: Stakeholder's Environment
 Customers Types
ƒ We can have various types of customers for which various organizations
develops applications/ products/ software's while considering them and
their requirements in mind
 Customers Types
‰ For some of us, the customer is an external entity, purchase order in hand, whom
we must convince to disregard our competitor's claims and to buy our shrink-
wrapped software product because it's easier to use, has more functionality, and,
in the final analysis, is just better.

‰ For others of us, the customer is a company that has hired us to develop its
software, based on expectations that the software developed will be of the highest
quality and will transform the company into a more competitive, more profitable
organization in the marketplace.
marketplace

‰ For others of us, the customer is sitting down the hall or downstairs or across the
country, waiting anxiously for that new application to enter sales orders more
efficiently
e ce ty o or to use e
e-commerce
co e ce for
o se
selling
g tthe
e co
company's
pa y s goods a
and
d se
services
ces so
that the company we both work for will ultimately be more profitable and our jobs
more rewarding and just more fun.
 The Root Causes of Project Success and Failure
ƒ The first step in resolving any problem is to understand the root causes.

ƒ The 1994 Standish Group survey study noted the three most commonly
cited factors that caused projects to be "challenged":

‰ Lack of user input: 13 percent of all projects

‰ Incomplete requirements and specifications: 12 percent of all projects
‰ Changing requirements and specifications: 12 percent of all projects
 The Root Causes of Project Success and Failure

ƒ Thereafter, the data diverges rapidly. Of course, your project could

fail because of an unrealistic schedule or time frame (4 percent of
the projects cited this), inadequate staffing and resources (6
percent), inadequate technology skills (7 percent), or various other
reasons.

ƒ Nevertheless, to the extent that the Standish figures are

representative of the overall industry, it appears that at least a
thi d off development
third d l t projects
j t run into
i t trouble
t bl for
f reasons that
th t are
directly related to requirements gathering, requirements
documentation, and requirements management.
 The Root Causes of Project Success and Failure
ƒ Although the majority of projects do seem to experience schedule/budget
overruns, if not outright cancellation, the Standish Group found that 9
percent of the projects in large companies were delivered on time and on
budget; 16 percent of the projects in small companies enjoyed a similar
success. That leads to an obvious question: What were the primary
"success factors" for those projects?
ƒ According to the Standish study, the three most important factors were

‰ User involvement: 16 percent of all successful projects

 The Root Causes of Project Success and Failure

‰ Executive management support: 14 percent of all successful projects

‰ Clear statement of requirements: 12 percent of all successful projects
 The Root Causes of Project Success and Failure
ƒ Other surveys have even more striking results. For example, the European
Software Process Improvement Training Initiative (ESPITI) [1995]
conducted a survey to identify the relative importance of various types of
software problems in industry. The results of this large
large-scale
scale survey, based
on 3,800 responses, are indicated in Figure

Largest software development problems by category. (Data derived from ESPITI [1995].)
 The Root Causes of Project Success and Failure
ƒ The two largest problems, appearing in about half the responses, were

‰ Requirements specifications
‰ Managing
i customer requirements
i

ƒ It seems clear that requirements deserve their place as a leading root

cause of software problems, and our continuing personal experiences
support that conclusion. Let's take a look at the economic factors
associated with this particular root cause.
 The Frequency of Requirements Errors
ƒ Both the Standish and the ESPITI studies provide qualitative data indicating that
respondents feel that requirements problems appear to transcend other issues in
terms of the risks and problems they pose to application development. But do
requirements problems affect the delivered code?

ƒ Table 1. summarizes a 1994 study by Capers Jones that provides data regarding the
likely number of "potential" defects in a development project and the typical
"efficiency" with which a development organization removes those defects through
various combinations
b off testing, inspections, and
d other
h strategies.

Table 1. Defect Summary

Defect Origins Defect Potentials Removal Efficiency Delivered Defects

Requirements 1.00 77% 0.23

Design 1.25 85% 0.19
Coding 1 75
1.75 95% 0 09
0.09
Documentation 0.60 80% 0.12
Bad fixes 0.40 70% 0.12

Total 5.00 85% 0.75

ƒ Requirements errors top the delivered defects and contribute approximately one third
of the total delivered defects to the defect pile
 The High Cost of Requirements Errors
ƒ If requirements errors can be fixed quickly, easily, and economically, we still may not
have a huge problem. This last statistic delivers the final blow. Just the opposite tends
to be true. Studies performed at companies including GTE, TRW, IBM, and HP have
measured and assigned costs to errors occurring at various phases of the project
lif
lifecycle.
l Davis
D i [1993] summarized
i d a numberb off these
th studies,
t di as Figure
Fi 2 illustrates.
2. ill t t
ƒ Although these studies were run independently, they all reached roughly the same
conclusion: If a unit cost of one is assigned to the effort required to detect and repair
an error during the coding stage, then the cost to detect and repair an error during
the requirements stage is between five to ten times less. less Furthermore,
Furthermore the cost to
detect and repair an error during the maintenance stage is twenty times more.

Figure 2. Relative cost to repair a defect at different lifecycle phases.

 The High Cost of Requirements Errors
ƒ Altogether, the figure illustrates that as much as a 200:1 cost savings
results from finding errors in the requirements stage versus finding errors
in the maintenance stage of the software lifecycle.

ƒ Two issues have been discussed together in Figure 2.

‰ the relative costs of various categories of errors and

‰ the
h cost off fixing
fi i them
h at different
diff stages in
i the
h software
f lif
lifecycle.
l
 The High Cost of Requirements Errors
ƒ The errors discovered during the design of a development project could fall
into one of two categories:
‰ errors that occurred when the development staff created a technical design from a
correct set of requirements or

‰ errors that should have been detected as requirements errors somewhat earlier in
the process but that somehow "leaked" into the design phase of the project.

ƒ It's the latter category of errors that turn out to be particularly expensive,
for two reasons.

‰ By the time the requirements-oriented error is discovered, the development group

will have invested time and effort in building a design from those erroneous
requirements. As a result, the design will probably have to be thrown away or
reworked.

‰ The true nature of the error may be disguised; everyone assumes that they're
looking for design errors during the testing or inspection activities that take place
during this phase, and considerable time and effort may be wasted until someone
says,
y , "Wait a minute! This isn't a design
g mistake after all;; we've g got the wrongg
requirements.“
 The High Cost of Requirements Errors– Defect Leakage
ƒ The problems associated with "leakage" of defects from one lifecycle phase
to the next are fairly obvious when you think about them, but most
organizations haven't investigated them very carefully

ƒ One organization that has done so is Hughes Aircraft. A study by Snyder

and Shumate [1992] follows the leakage phenomenon for a large collection
of projects Hughes has conducted over the past 15 years.

ƒ The study indicates that 74 percent of the requirements-oriented defects

were discovered during the requirements analysis phase of the project—
that is,
is the formal phase during which customers and systems analysts
discuss, brainstorm, negotiate, and document the project requirements.
That's the ideal time and place to discover such errors, and it's likely to be
the most inexpensive time and place.

ƒ However, the study also shows that 4 percent of the requirements defects
"leak" into the preliminary, or high-level, design of the project and that 7
percent leak further into detailed design.
p g The leakageg continues throughout
g
the lifecycle, and a total of 4 percent of the requirements errors aren't
found until maintenance, when the system has been released to the
customers and is presumably in full-scale operation.
 The High Cost of Requirements Errors– Defect Leakage
ƒ Thus, depending on when and where a defect is discovered in a software application
development project, we're likely to experience the effect of 50–100 times cost. The
reason is that in order to repair the defect, we are likely to experience costs in some
or all of the following areas:
‰ Re-specification.
‰ Redesign.
‰ Recoding.
‰ Retesting.
‰ Change orders (telling users and operators to replace a defective version of the system with the
corrected version).
‰ Corrective action (undoing whatever damage may have been done by erroneous operation of the
improperly specified system, which could involve sending refund checks to angry customers,
rerunning computer jobs,
jobs and so on).
on)
‰ Scrap (including code, design, and test cases that were carried out with the best of intentions but
then had to be thrown away when it became clear they were based on incorrect requirements).
‰ Recall of defective versions of software and associated manuals from users. (Since software is now
embedded in products ranging from digital wristwatches to microwave ovens to automobiles, the
recall could include both tangible products and the software embedded within them.)
‰ Warranty costs.
‰ Product liability (if the customer sues for damages caused by the defective software).
‰ Service costs for a company representative to visit a customer's field location to reinstall the new
software.
f
‰ Documentation
 Requirements Engineering Process
y Elicitation: work with the customer on gathering requirements

y Analysis: process this information to understand it, classify in various

categories
categories, and relate the customer needs to possible software
requirements

y Specification: Structure the customer input and derived requirements as

written
itt d
documents
t andd diagrams
di

y Validation: you’ll ask your customer to confirm that what you’ve written is
accurate and complete and to correct errors.
 Requirements Management
ƒ Requirements define capabilities that the systems must deliver, and conformance (or
lack of conformance) to a set of requirements often determines the success (or
failure) of projects. It makes sense, therefore, to find out what the requirements are,
write them down, organize them, and track them in the event that they change.

ƒ Stated another way, we'll define requirements management as, “ a systematic

approach to eliciting, organizing, and documenting the requirements of the
system, and a process that establishes and maintains agreement between
the
h customer and d the
h project
j team on the
h changing
h i requirements
i off the
h
system.”

ƒ Let's take a closer look at some key concepts contained in this definition.

‰ Anyone who has ever been involved with complex software systems—whether from the
perspective of a customer or a developer—knows that a crucial skill is the ability to elicit the
requirements from users and stakeholders.

‰ Since hundreds, if not thousands, of requirements are likely to be associated with a system, it's
important to organize them.

‰ Since most of us can

can'tt keep more than a few dozen pieces of information in our heads,
documenting the requirements is necessary to support effective communication among the
various stakeholders. The requirements have to be recorded in an accessible medium: a
document, a model, a database, or a list on the whiteboard.
 Requirements Management
y What do these elements have to do with managing requirements? Project
size and complexity are major factors here: nobody would bother talking
about "managing" requirements in a two-person project that had only 10
requirements to fulfill. But to verify 1,000 requirements
requirements—a
a small purchased
software product—or 300,000 requirements—a Boeing 777—it's obvious
that we will face problems of organizing, prioritizing, controlling access to,
and providing resources for the various requirements. On even a modest-
size project, questions will naturally arise.

‰ Which project team members are responsible for the wind speed requirement
(#278), and which ones are allowed to modify it or delete it?
‰ If requirement #278 is modified,
modified what other requirements will be affected?
‰ How can we be sure that someone has written the code in a software system to
fulfill requirement #278, and which test cases in the overall test suite are intended
to verify that the requirements have indeed been fulfilled?
 Types of Software Applications
ƒ Information Systems

‰ Information systems and other applications developed for use within a company
(such as the payroll system being used to calculate the take-home
take home pay for our next
paycheck). This category is the basis for the information system/information
technology industry, or IS/IT.
 Types of Software Applications
ƒ Commercial Software Applications

‰ Software developed and sold as commercial products (such as the MS Office).

Companies developing this type of software are often referred to as independent
software vendors, or ISVs.
 Types of Software Applications
ƒ Embedded Software's

‰ Software that runs on computers embedded in other devices, machines, or

complex systems (such as those contained in the airplane,
airplane in cell phones,
phones in
washing machines, in ovens, the automobile and many more…….) This type of
software's are known as software embedded-systems applications, or embedded
applications.
 The Problem Domain
ƒ Most successful requirements journeys begin with a trip to the land of the
problem. This problem domain is the home of real users and other
stakeholders, people whose needs must be addressed in order for us to
build the perfect system.

ƒ This is the home of the people who need the rock or a new sales order
entry system or a configuration management system good enough to blow
the competition away.

Problem Domain
 The Problem Domain
ƒ These users have business or technical problems that they need our help to
solve. Therefore, it becomes our problem to understand their problems, in
their culture and their language, and to build systems that meet their
needs. Since this territory can seem a little foggy, therefore represented
as a cloud.

ƒ Within the problem domain, we use a set of team skills as our map and
compass to understand the problem to be solved. While we are here, we
need to gain an understanding of the problem and the needs that must be
filled to address this problem.
 Stakeholder Needs

ƒ Stakeholders are people who have a stake or interest in the project

ƒ It is also our responsibility to understand the needs of users and other

stakeholders whose lives will be affected by our solution. As we elicit those
needs, we'll stack them in a little pile called stakeholder needs, which we
represent
p as a py
pyramid.

Needs
 Moving Toward the Solution Domain
ƒ We move to Solution domain from the problem domain in order to provide
a solution to the problem at hand.

ƒ In the solution space, we focus on defining a solution to the user's

problem; this is the realm of computers, programming, operating systems,
networks, and processing nodes. Here, we can apply the skills we have
learned much more directly.
 Moving Toward the Solution Domain
Features of the System

ƒ First, however, it will be helpful to state what we learned in the problem

domain and how we intend to resolve those issues via the solution. This is
not a very long list and consists of such items as the following.

‰ "The
The car will have power windows.
windows."
‰ "Defect-trending charts will provide a visual means of assessing progress."
‰ "The program will allow Web-enabled entry of sales orders."
‰ “ The Attendance of students will be enrolled through face detection ."
‰ These are simple descriptions,
descriptions in the user's language,
language that we will use as labels to
communicate with the user how our system addresses the problem. These labels
will become part of our everyday language, and much energy will be spent in
defining them, debating them, and prioritizing them. We'll call these descriptions
features of the system
y to be built and will define a feature as

ƒ a service provided by the system that fulfills one or more stakeholder

needs.
 Moving Toward the Solution Domain
Features of the System

ƒ Graphically, we'll represent features as a base for the previous needs

pyramid
 Moving Toward the Solution Domain
Software Requirements

ƒ Once we have established the feature set and have gained agreement with the
customer,
t we can move on to
t defining
d fi i th more specific
the ifi requirements
i t we will
ill need
d to
t
impose on the solution.

ƒ If we build a system that conforms to those requirements, we can be certain that the
system we develop
d l will
ll deliver
d l the
h features
f we promised.
d In turn, since the
h features
f
address one or more stakeholder needs, we will have addressed those needs directly in
the solution.

ƒ These more specific requirements are the software requirements. We'll represent them
as a block within our pyramid in a manner similar to the features. We also note that
these appear pretty far down on the pyramid, and this implies, correctly, that we have
much work to do before we get to that level of specificity
 Moving Toward the Solution Domain
Software Requirements
 Overview of the Problem Domain and Solution Domain
ƒ We have moved from the problem domain, represented by the cloud and the user needs we
discovered, to a definition of a system that will constitute the solution domain, represented by the
features of the system and the software requirements that will drive its design and implementation.
Moreover, we have done so in a logical, stepwise fashion, making sure to understand the problem
and the user's needs before we envision or define the solution.
 An Introduction to Use Cases

ƒ A use case describes a sequence of actions, performed by a system, that

yields a result of value to a user

ƒ In other words, a use case describes a series of user system interactions

that help the user to accomplish something

ƒ A use case diagram involves two elements

‰ Use cases

‰ Actors

ƒ Actors are the people or systems that interact with the use cases

ƒ Mostly you will find that they are the users of the system that you are
g
modeling
 Reasons for Use Cases

ƒ No information system exists in isolation

ƒ Most systems interact with humans or other automated systems (actors)

that use the system for some purpose

ƒ Use Cases spec

specify
y tthe
e be
behavior
a o o of tthe
e syste
system

ƒ Helps visualize the system

 Use Case Notation
ƒ Use case Notation:: A use case is represented by an oval shaped icon or ellipse.

ƒ The name of the use case can be written either inside the ellipse but can also be placed
beneath it like:

Cash Withdrawal

Cash Withdrawal
 Actor Notation
ƒ Actor Notation:: In a use case diagram an Actor is represented by a stick person like
symbol shown below

ƒ The name of an Actor is written beneath it like:

Customer
 Relationships in Use Case Diagram

ƒ There are several types of relationships that may appear on a use case
diagram:

‰ An association between an actor and a use case

‰ An association between two use cases

‰ A generalization between two actors

‰ A generalization between two use cases

 Relationships in Use Case Diagram

ƒ An association between an actor and a use case

‰ Actors are connected

d to the
h use cases with
h which
h h they
h interact by
b a line
l that
h
represents a relationship between the use cases and actors

ATM Example
 Relationships in Use Case Diagram

ƒ An association between two use cases

‰ A use case can be

b associated
d with
h another
h use case, they
h can have
h the
h following
f ll
relationships,

9 Generalization between use cases

9 Include relationship between use cases
9 Extend relationship between use cases
 Relationships in Use Case Diagram

ƒ An association between two Actors

‰ An Actor can be
b associated
d with
h another
h actor through
h h Generalization
l relationship
l h

ATM Example
 Relationships in Use Case Diagram

ƒ A Generalization between two Use cases

‰ Sometimes it becomes
b apparent that
h there
h is more than
h one version off a use case
and each has some actions in common and some that are unique to each one

‰ In this case we can have a generalized use case and its specialized version
Use Case Diagram for ATM System
Any question