Essentials of Software Requirements

1-Stakeholders:
Customer, User Requirement Analyst, Developer, Tester, Document Writer, Project
Manager. Legal Staff, Manufacturing People, Sales, Marketing, Field Support. Help Desk
and other people

2- Requirements Definitions:
Requirements are the foundation for both the software development and the project

management activities, all stakeholders must be committed to following an effective

requirements process.
IEEE defines requirement as
or achieve an objective.
a user to solve a problem
"A condition or capability needed by or system component to
be met or possessed by a System
A condition or capability that must document.
other formally imposed
contract, standard, specification.
or
satisfy a or capability as in
I or 2"
A documented representation
of a condition
and Sawyer
Sommervile are descriptions of
According to should be implemented. They
"Requirements specification
are...a of what be a constra1nt
or attribute. They may
should behave, or of a system property
how the system
on the development process ofthe system.

3-Types of Requirements:
& Scope Document)
A. Business Requirements (Vision Business Rules
Requirements (Use Case Document)
B. User Business
Functional Requirements (SRS)
System Requirement,
C. Constraints
External Interface,
Rule, Quality attribute,
D. Non Functional Requirements
or customer
represent high-level
objectives of the organization
A- Business requirements come from the funding
sponsor for
Business requirements typically department.
who requests the system. of the actual users. the marketing
the acquiring customer, the manager is implementing
a project, describe why the organization
Business requirements the business
or a product visionary.
record
hopes to achieve. I like to
the organization or a market
the system-the objectives somet1mes called a project
charter
and scope document,
requirements in a vISIon
requirements document.

must be able to perform with

or tasks that the userS

requirements
describe user goals cases, scenario
requirements include
B-User use
to represent user the user
the product. Valuable ways therefore describe what
tables. User requirements
descriptions, and
event-response
use case is
"Make a Reservation" using
of a
with the system. An example
will be able to do Web site.
an airline, a
rental car, or a hotel
(SRS).
in a sofiware
requirements specification
are
documented
software system.
Ill refer
C- Functional requirements behavior of the
as necessary
the expected that contains the
which describes as fully be database or spreadsheet 1s
document, although it can a
tool. The SRS
to the SRS as a requirements management
stored in a commercial
information
requirements,
 used in development, testing. quality assurance, project
functions.
management, and related
project
D- Nonfunctional requirements include
attributes. Quality attributes augment thepertormance of goals and descriptions of
quality
describing the description the product's
product's characteristics in various dimensions that are functionality by
users or to developers. These
characteristics include usability. important either to
efficiency, and robustness. These are also included in the SRS. portability. integrity,
Business Rules, Constraints and Feature
Business rules include corporate policies,
government regulations. industry standards,
accounting practices, and computational algorithms. "Playing by the Rules." business rules
are not themselves software
requirements because they exist outside the boundaries of any
specific software system. However, they often restrict who can perform certain use
they dictate that the system must contain functionality to comply with the pertinent cases
rules. or
Sometimes business rules are the origin of specific quality attributes that are
implemented in
functionality. Therefore, you can trace the genesis of certain functional requirements back to
a particular business rule.

Constraints impose restrictions on the choices available to the developer for design and
construction of the product.

A feature is a set of logically related functional requirements that provides a capability to the
user and enables the satisfaction of a business objective. In the commercial software arena, a
feature is a group of requirements recognizable to a stakeholder that aids in making a
purchase decision-a bullet item in the product description. A customer's list of desired
product features is not equivalent to a description of the user's task-related needs Web
browser favorites or bookmarks, spell check, macro recording, automobile power windows.
online update of tax code changes, telephone speed-dialing, and automatic virus signature
updating are examples of product features. A feature can encompass multiple use cases, and
each use case requires that multiple functional requirements be implemented to allow the user
to perform the task.

Requirements specifications do not include design or implementation details (other than

known constraints). project planning information, or testing information (Leffingwell and
Widrig 2000). Separate such items from the requirements so that the requirements activities
can focus on understanding what the team intends to build.

E- Requirement Development and Management

RE is divided into two divisions. which are: RD and RM

Requirements Development:
Requirement Development is further divided into Elicitation, Analysis. Specificalion and
Validation. Sub disciplines encompass all the activities involved with gathering, evaluating.
and documenting the requirements for a software or software-containing product, including
the following:

I. Identifying the products' expected user classes

2. Eliciting needs from individuals who represent each user class
 goals and the business objectives with which those tasks
Linderstanding user tasks and
a

align to distinguish their task goals from

the informalion received irom users
rules, suggested solutions, and
4 Analyzing nontunctional requiremernis,
business

functional requirements,
extraneous information
soltware components defined in the
requiremenis l0
of the top-level
s Allocating portions
atltributes
system architecture
of quality
relative importance
the
Understanding models
6. implementation
priorities specifications and
wrillen r e q u i r e m e n t s
7. Negotiating user needs into understanding of the
users'
the collected to e n s u r e a
common

8. Translating requirements accepts them

group
documented development
the belore the
9. Reviewing correct any
and to
problems
stated requirements
with the
Requirement Management: an agreement
nmaintaining
entails "establishing
and That a g r e e m e n t is
(Paulk et al. 1995). is
software project"
management
Requirements C u s t o m e r acceptance
requirements
for the and the models.
the
c u s t o m e r on
the specifications also must accept
the written requirements approval. The developers activities
embodied in requirements management
needed for Requirements
half the equation into a product.
only build them
specifications
and agree to
include the following:
the currently
agreed-
in time representing
baseline (a snapshot
requirements
1. Defining
the release) of each change
for a specific the likely impact
of requirements
body and evaluating
changes
upon requirements
proposed
2. Reviewing controlled waay
the project in
a
before approving it
requirements changes into
approved
3. Incorporating
with the requirements of requirements
changes
plans current estimated impact
4. Keeping project c o m m i t m e n t s based on the
source code. and test
cases

5. Negotiating
new corresponding designs,
requirements to their the project
activity throughout
individual
6. Tracing status and change
requirements
7. Tracking

Bad Requirements:
F-Costing in that you
over something
problems is rework-doing
of requirements
30 to 50 percent
of your total development
The major consequence Rework can c o n s u m e 85 percent of the
done. account for 70 to
was already errors
thought and requirements
cost
and Papaccio 1988),
(Boehm
1997).
rework cost (Leffingwell

Insufficient User Involvement:

on gathering
essential to work hard
don't understand why it is so user
involvement,
often not emphasize
Customers
their quality. Developers might think
requirements and assuring fun as writing
code or because they
much
with users isn't as
difficult to gain access
to people
either because working some cases, it's
the need. In
already know what
users
they
who will actually use the product.

Creeping User Requirements: exceed their planned

projects often
evolve and grow during development, understandings
of the size
requirements on realistic
As Such plans aren't always
based
modifications make
the problem
schedules and budgets.
requirements: constant requirements
and complexity of the
 lhes p a r t h
the users' frequent requests for changes in the 1eur
problem respond to these requests
The that developers
wse
n
n the way
the
rarth
statement
of the project's bus1ness objectives
and th a clear
beg1n wth
a
creep. and expected product usage Evaluae l
ge
scope
l1mitations. successcrnteria. reference framework An
aganst this
mana
To scope.
ISIOn.
raquirements
changes
c
stakeholders make
features or will help the
impact analy
s t r a e g i e

proposaf new fea s1s

includes in time.
that and the associated costs
which changes to accept
process
change about wh always has a
e decisIons success. but change
critical to
business
Change is often
informad trade-ofs
feature
rsources.
or

pnce

Ambiguous Requirements:

Gold Platting: specification. perhaps

create a limited
Minimal Specification:
tempted to out the spec
are to flesh
staff or managers the developers
marketing They expect
Sometimes sketched on
a napkin
concept
just a
product
progresses
while the project
have
subsets of features.
Overlooked User Classes: diflerent
identify the
use
who might don't
have several
groups ofusers expenence
levels. If you
products vary1ng needs won't
be met
Most or have
of use. on. some
user
frequencies early
for vour product
different
classes
user
impornant
Inaccurate Planning Process:
Requirement

G-Benefits
from High Quality
defects
requirements
Fewer
I Reduced
development
rework

2 features
unnecessary

3 Fewer
enhancement
costs
Lower
4.
5 Faster development
6 . F e w e r m i s c o m m u n i c a t i o n s

creep
7 Reduced scope chaos
project
8. Reduced estimates

accurate system-testing satisfaction

9. More customer
team
and
member

10.Higher
Requirements
H - C h a r a c t e r i s t i c s
of Correct Statement
Verifiable.
Characteristics
of Requirement Prioritized.
Unambiguous.

Feasible. Necessary,
Correct. Specification
Complete,
Characteristics of Requirement
Traceable
Modifiable.
Consistent,
Complete.
 What is Risk?
"Tomorrow problems are today's risk. Hence, a clear definition of a "risk" is a
problem that could cause some loss or threaten the progress of the project, but
which has not happened yet.

These potential issues might harm cost, schedule or technical success of the project
and the quality of our software device, or project team morale.

Risk Management is the system of identifying addressing and eliminating these

problems before they can damage the project.

We need to differentiate risks, as potential issues, from the current problems of the
project.

Different methods are required to address these two kinds of issues.

For example, staff storage, because we have not been able to select people with the
right technical skills is a current problem, but the threat of our technical persons
being hired away by the competition is a risk.

Risk Management
A software project can be concerned with a large variety of risks. In order to be adept
to systematically identify the significant risks which might affect a software project,it
is essential to classify risks into different classes. The project manager can then check
which risks from each class are relevant to the project.

There are three main classifications of risks which can affect a software project:

1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel,
resource, and customer related problems. A vital project risk is schedule slippage.
Since the software is intangible, it is very tough to monitor and control a software
project. It is very tough to control something which cannot be identified. For any
manufacturing program, such as the manufacturing of cars, the plan executive can
recognize the product taking shape.

2. Technical risks: Technical risks concern potential method, implementation,

interfacing, testing, and maintenance issue. It also consists of an ambiguous
 technical uncertainty.
specification,
changing specification, development
incomplete due to the
Specification, Most technical risks appear
obsolescence.

and technical knowledge

about the project.
insufficient
team's
an
excellent product that
contain risks of building
of risks
risks: This type commitments, etc.
3. Business budgetary
o r personnel
need, losing
no one

Other risk categories

assessment of
uncovered after careful
risks that can be
Known risks: Those environment in which the
1. 1. and technical
business
the unrealistic
the project
program,
reliable data sources (e.g.,
and more
developed,
plan is being
delivery date) from previous project
that are hypothesized
Predictable risks: Those risks
2. 2.
turnover)
experience (e.g, past but are extremely
risks that can and do occur,
risks: Those
3 3. Unpredictable
advance.
tough to identify in

Management
Principle of Risk
description, design,
In this, we review thebigger system
1. Global Perspective: and the impact the
risk is going
look at the chance
implementation. We
and
to have. the
Consider the threat
which may appear in
forward-looking
view:
2. Take a
events.
the next
future and create future plans for directing
communications
is to allow the free flow of
Communication: This
3 Open
members so that they
have certainty about
between the client and
the team

the risks.
is made an
In this method risk management
4. Integrated management:

part of project management.

integral
tracked continuously
5. Continuous process: In
this phase, the risks are

throughout the risk management paradigm.