 |
The Software Requirements Specification |
| << Requirements Elicitation for Software |
| Attributes of Software Design, Key Features of Design >> |
Software
Project Management
(CS615)
LECTURE
# 15
2.
Software Development
Fundamentals
Technical
Fundamentals
2.11
Requirements
Management
⇒ The
Software Requirements Specification
The
Software
Requirements Specification is
produced at the culmination of
the
analysis
task, The function and
performance allocated to software as
part of
system
engineering are refined by
establishing a complete
information
description,
a detailed functional description, a
representation of system
behavior,
an
indication of performance requirements
and design constraints,
appropriate
validation
criteria, and other: information
pertinent to requirements. The
National
Bureau of
Standards; IEEE (Standard No.
830-1984), and the U.S.
Department of
Defense
have all proposed candidate
formats for software
requirements
specifications
(as well as other software
engineering documentation).
Mode of
specification has a great impact on
quality of solution. Forcing
SWE to
work
with incomplete, inconsistence, or
misleading specifications result
in
frustration
and confusion affecting:
Quality
Timeliness
and
Completeness
of SW product
·
Principles
i.
Separate
functionality from
implementation.
ii.
Develop a
model of desired behavior of a
system that encompasses data
and
the
functional response of a system to
various stimuli from the
environment.
iii.
Establish
the context in which SW
operates by specifying the
manner in which
other
system components interact
with software.
iv.
Define
the environment in which
system operates and indicate
how a highly
inter-wined
collection of agents react to stimuli in
the environment (changes
to
objects) produced by those agents.
v.
Create a
cognitive model rather than
a design or implementation model.
Cognitive
model describes a system as
perceived by its user
community.
103
Software
Project Management
(CS615)
vi.
Recognize
that; "the specifications
must be tolerant of incompleteness
and
augmentable."
vii.
A
specification is always a model
an abstraction-of some
real (or envisioned)
situation
that is normally quite
complex. Hence it will be incomplete and
will exit
at many
levels of detail.
i.
Establish
the content and structure of a
specification in a way that will enable
it to
be amenable to
change.
·
Representation
i.
Representation
format and content should be
relevant to the problem.
(A
general
outline of SRS can be
developed).
ii.
Information
contained within the
specification should be nested.
iii.
It should
reveal layers of information so
that reader can move to the
level
of detail
required. Paragraph & diagram
number scheme to indicate
level.
iv.
Diagrams
and other notational forms
should be restricted in number
and
consistent
in use. (Confusing or inconsistent
notations, whether
graphical
or
symbolic degrades understating and
foster errors.)
v.
Representation
should be revisable.
vi.
The
content of specification will change.
Ideally, CASE tools should
be
available
to update all representations that are
affected by each change.
The
function and performance allocated to
software as part of system
engineering
are
refined by establishing:
1.
A
complete information
description,
2.
A
detailed functional
description,
3.
A
representation of system
behavior,
4.
An
indication of performance requirements
and design constraints,
5.
Appropriate
validation criteria, and other:
information pertinent to
requirements.
The
Introduction
of
the software requirements
specification states the goals
and
objectives
of the software, describing it in
the context of the
computer-based
system;
actually, the Introduction
may be nothing more than
the software scope of
the
planning document.
104
Software
Project Management
(CS615)
The
Software
Requirements Specification is
produced at the culmination of
the
analysis
task. The function and
performance allocated to software as
part of
system
engineering are refined by
establishing:
A
complete information
description
A
detailed functional
description
A
representation of system
behavior
An
indication of performance requirements
and design constraints
Appropriate validation criteria and
other information pertinent
to
requirements.
The
Information
Description provides
a detailed description of the
problem that
the
software must solve.
Information content, flow, and
structure are
documented.
Hardware,
software, and human interfaces
are described (or external
system
elements:
and internal software
functions.
A
description of each function
required to solve the
problem is presented in
the
Functional
Description.
A processing
narrative is provided for
each function:
Design
constraints are stated and
justified
Performance
characteristics are stated,
and
One or more
diagrams are included to
graphically represent the
overall
structure
of the software and interplay among
software functions and
other
system
elements
The
Behavioral
Description section
of the specification examines
the operation of
the
software as a consequence of external
events and internally generated
control
characteristics.
Validation
Criteria is
probably the most important
and, ironically, the most
often,
neglected
section of the Software
Requirements specification.
How do we
recognize a successful
implementation?
What
classes
of
tests must be conducted to
validate function,
performance,
and
constraints?
We
neglect this section because
completing it demands a thorough
understanding
of
software requirements-something that we
often do not have at this
stage.
Yet,
specification of validation criteria
acts as an implicit review of
all other
requirements.
It is essential that time and attention
be given to this
section.
Finally,
the specification includes a
Bibliography
and Appendix.
105
Software
Project Management
(CS615)
The
bibliography contains
references to all documents that
relate to the
software.
These include other software
engineering documentation,
technical
references, vendor literature, and;
standards.
The
appendix contains
information that supplements
the specifications.
Tabular
data, detailed description of
algorithms, charts, graphs and
other
material,
are presented as appendixes.
In many
cases the Software
Requirements Specification may be
accompanied by
an
executable prototype (which in
some cases may replace the
specification), a
paper
prototype or a Preliminary
User's Manual. The
Preliminary
Users Manual
presents
the software as a black box:
That is, heavy emphasis is
placed on user
input and
the resultant output. The
manual can serve as a valuable tool
for
uncovering
problems at the human/machine
interface.
⇒ Review
A review
of the Software
Requirements Specification (and/or
prototype) is
conducted
by both the software
developer and the
customer.
Extreme
care should be taken in
conducting the review
because the
specification
forms
the foundation of the
development phase.
The
review is first conducted at a
macroscopic level; that is,
reviewers attempt to
ensure
that the specification is
complete, consistent, and accurate when
the overall
information,
functional, and behavioral domains;
are considered. However, to
fully
explore each of these
domains, the review becomes
more detailed,
examining
not only broad descriptions
but the way in which
requirements are
worded.
For example, when
specifications contain "vague
terms" (e.g., some,
sometimes,
often, usual ordinarily, most,
or
mostly),
the
reviewer should flag
the
statements
for further
clarification.
Once
the review is complete, the
Software Requirements Specification is
"signed-
off by
both the customer and the
developer. The specification
becomes a
"contract"
for software development.
Requests for changes in
requirements after
the
specification is finalized will not be
eliminated. But the customer
should note
that
each after- the-fact change is an
extension of software scope and
therefore
can
increase cost, and/or
protract the
schedule.
Even
with the best review
procedures in place, a number of common
specification
problems
persist. The specification is difficult
to "test" in any meaningful
way,
and
therefore inconsistency or omissions
may pass unnoticed. During
the review,
changes
to the specification may be
recommended. It can be extremely
difficult to
assess
the global impact of a
change; that is, how a
change in one function affects
requirements
for other functions. Modem
software engineering
environments
incorporate
CASE tools that have
been developed to help solve
these problems.
106
Table of Contents:
- Introduction & Fundamentals
- Goals of Project management
- Project Dimensions, Software Development Lifecycle
- Cost Management, Project vs. Program Management, Project Success
- Project Management’s nine Knowledge Areas
- Team leader, Project Organization, Organizational structure
- Project Execution Fundamentals Tracking
- Organizational Issues and Project Management
- Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
- Project Execution: Product Implementation, Project Closedown
- Problems in Software Projects, Process- related Problems
- Product-related Problems, Technology-related problems
- Requirements Management, Requirements analysis
- Requirements Elicitation for Software
- The Software Requirements Specification
- Attributes of Software Design, Key Features of Design
- Software Configuration Management Vs Software Maintenance
- Quality Assurance Management, Quality Factors
- Software Quality Assurance Activities
- Software Process, PM Process Groups, Links, PM Phase interactions
- Initiating Process: Inputs, Outputs, Tools and Techniques
- Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
- Project Planning Objectives, Primary Planning Steps
- Tools and Techniques for SDP, Outputs from SDP, SDP Execution
- PLANNING: Elements of SDP
- Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
- Organizational Systems
- ORGANIZATIONAL PLANNING, Organizational Management Tools
- Estimation - Concepts
- Decomposition Techniques, Estimation – Tools
- Estimation – Tools
- Work Breakdown Structure
- WBS- A Mandatory Management Tool
- Characteristics of a High-Quality WBS
- Work Breakdown Structure (WBS)
- WBS- Major Steps, WBS Implementation, high level WBS tasks
- Schedule: Scheduling Fundamentals
- Scheduling Tools: GANTT CHARTS, PERT, CPM
- Risk and Change Management: Risk Management Concepts
- Risk & Change Management Concepts
- Risk Management Process
- Quality Concept, Producing quality software, Quality Control
- Managing Tasks in Microsoft Project 2000
- Commissioning & Migration