Requirements Engineering
and Management
INFO 627
Refining the System Definition
Glenn Booker
INFO 627
Lecture #6
1
Requirements


Now that we have a good idea of the customer
needs, have defined the main features for our
system, and selected a structure for managing
the implementation of those features…
*whew*
We can now work on refining requirements
to guide development and testing
INFO 627
Lecture #6
2
Requirements



As we define and refine requirements, it must
be clear that the written description of those
requirements is the only authority as to what
we are creating
And changes in scope or intent need to be
reflected immediately
We started by defining features vaguely – now
we add details
INFO 627
Lecture #6
3
Requirements



The system must fulfill user needs
The system requirements must be complete
and consistent, and fit in the environment
where it will live
Definition of requirements also supports
detailed feasibility study, to ensure we are
making a wise investment
INFO 627
Lecture #6
4
Requirements

How precise requirements need to be depends
on the type of application and the industry it
supports


We hope that aircraft flight control software is
designed more carefully than Microsoft Word
Goal is to produce understandable
requirements to support meeting user needs
INFO 627
Lecture #6
5
Requirements

Many methods or models can be used
to express requirements




Use Cases
Natural language
Formal methods (Z or Larch)
Storage and management of those
requirements could be in a spreadsheet
or database
INFO 627
Lecture #6
6
Requirements

Requirements need to be:



Understood by all parties concerned
Specific enough to be verified
and demonstrated
From the beginning, think of requirements in
terms of being able to prove whether they
have been fulfilled (“Trust but verify”)
INFO 627
Lecture #6
7
Software Requirements



Software requirements are generally related to
some capability the user needs to have, or
some capability the systems needs for some
other reason
Inputs and outputs are good places to start
looking for requirements
Don’t forget non-functional requirements!
INFO 627
Lecture #6
8
Software Requirements


Think of the system as a black box, and focus
on what needs to go into and leave the system
Five major classes of things can describe a
system (per Davis)

INFO 627
Inputs to the system, in terms of content, format,
and source
Lecture #6
9
Software Requirements




INFO 627
Outputs from the system, including the type of
output device, and format of the outputs
Functions of the system, to accept inputs and/or
create outputs
Attributes of the system, such as the “–ilities”,
throughput, and performance
Attributes of the system environment, such
as where it is used, and compatibility with
other systems
Lecture #6
10
Software Requirements



Using this kind of breakdown helps
ensure completeness of requirements
Also can use these categories to
help determine if something really
is a requirement
Features lead to one or more requirements

INFO 627
So requirements help to define the scope
and exact capabilities of features
Lecture #6
11
1E p. 231
Mapping Features to Requirements


We need to trace the origin of requirements
from their corresponding features
This traceability helps ensure we define
complete requirements


INFO 627
All features result in one or more requirements
[Side note: Microsoft products don’t recognize
“traceability” as a word…does that tell us
something about their products?]
Lecture #6
12
What Requirements Are Not

The challenge in writing requirements
is to avoid things which shouldn’t
impersonate requirements




Project management information
Unneeded design or implementation details
Testing information
Requirements should focus on system
behavior, not its inner workings
INFO 627
Lecture #6
13
Project Management Information

Requirements should not include




Budget, staffing, or schedule information
Configuration management plans
Testing plans (except maybe hints for very
unusual cases)
Put these in separate Program Management
Plan, CM Plan, etc.
INFO 627
Lecture #6
14
Unneeded Design Details

Do not define the system design or
architecture as requirements


INFO 627
Reduces the creativity of the developers
to use an even better approach
Includes specifying development language, tools,
design methodology (e.g. OO vs. relational
database)
Lecture #6
15
Design Constraints

If an aspect of the system design is artificially
constrained BY THE CUSTOMER, make it
a design constraint


Only if the customer mandated it
Other design decisions should only
appear in design documents, not hiding
among requirements

INFO 627
E.g. if using VB is the best language
Lecture #6
16
Testing Plans

Requirements do not include




Test plans
Verification and validation plans
Test cases
In very rare cases, a testing approach may be
hinted at or suggested if a suitable approach
may not be obvious
INFO 627
Lecture #6
17
Implied Requirement Details

Beware of stating assumptions about the form
or format of an input or output


E.g. an output might be assumed to be on paper,
but why not a web page or PDF file?
Be clear what assumptions are made about the
environment the user will have

INFO 627
Don’t necessarily have a keyboard and mouse
Lecture #6
18
Requirements vs. Design



Requirements (what the system does) should
be determined before design
Requirements are determined by the users and
customers, since they (generally) know their
needs best
Design (how) is done by technical experts,
because they know the options available
INFO 627
Lecture #6
19
Requirements vs. Design



Yet trying to implement requirements may
lead to a design which alters the req’ts
Hence in reality, design and requirements are
iterative, feeding off each other until an
acceptable balance is achieved
Changes in technology can drastically affect
requirements (client/server vs. web)
INFO 627
Lecture #6
20
Types of Requirements

A basic breakdown of requirements
may include:




1E p. 237
Functional software requirements
Non-functional software requirements
Design constraints
Functional requirements focus on actions
(user does x, system does y)
See also lecture 2, INFO 620 for the FURPS+ model
INFO 627
Lecture #6
21
Non-Functional Requirements

Non-functional requirements typically
include:

Usability





INFO 627
Time needed for training
Time to perform task
Usability compared to other systems
Availability of help
Compliance with HCI standards (Windows, Mac)
Lecture #6
22
Non-Functional Requirements

Reliability






INFO 627
Availability (%)
Mean time between failures (MTBF, hours)
Mean time to repair (MTTR, hours)
Accuracy (numeric precision, number of decimals)
Defect rate (defects/1000 lines of code)
Bugs per type (number of bugs by severity)
Lecture #6
23
Non-Functional Requirements

Performance




INFO 627
Response time for a transaction – average, maximum,
some % below some value
Throughput (transactions per second)
Capacity (number of simultaneous users)
Degraded modes of operation (what are performance
expectations if system is partially offline)
Lecture #6
24
Non-Functional Requirements

Supportability


INFO 627
Expected implementation time for minor, medium,
and major enhancements
Planned or possible future enhancements mostly
affect design decisions
Lecture #6
25
Design Constraints


We generally want to define requirements so
that several design approaches might be used
to implement them
Constraints might need to be imposed such as
the development language, use of corporate
reuse libraries, coding standards, or external
standards such as FDA, DOD or FCC
regulations
INFO 627
Lecture #6
26
Design Constraints


Should distinguish constraints from
requirements, such as using a “DC” prefix,
and isolate them from the true requirements
Identify the source of each constraint, and
why it was imposed (if known)
INFO 627
Lecture #6
27
Parent-Child Requirements



A child requirement specifies details about
its parent
Could look on as the parent is a requirement,
and the child a specification
Don’t go crazy with lots of grandchildren and
great-grandchildren – usually not worth the
effort
INFO 627
Lecture #6
28
Use Case Refinement


Use cases make sense particularly when a
system has lots of functions to perform, and
you’re using an OO methodology
If there are few users or interfaces, or
extensive non-functional requirements, might
not be the best choice
INFO 627
Lecture #6
29
Use Case Refinement



Use cases focus on who does something
(actor), how they interact with the system, and
what the system does in response (including
tasks like saving data, displaying a report,
etc.)
Use case must be of value to the actor
Name each use case clearly and concisely
INFO 627
Lecture #6
30
Use Case Refinement

Refinement of use cases may include:




INFO 627
The basic flow, or main success scenario
Variants or alternative flows – such as different
methods of payment, processing personal versus
business orders, or error conditions
Preconditions – what happens before this use case
may be used?
Postconditions – what has changed as a result of
this use case?
Lecture #6
31
Software Requirements Specification
(SRS)




A Software Requirements Specification (SRS)
defines the conceptual model of what the
system will be
Main standard is IEEE 830:1998
SRS isn’t always a single document, but
a collection of documents and models
Is a living package; evolves with the system
INFO 627
Lecture #6
32
SRS Purpose




The SRS serves to communicate among the
developers and various stakeholders
Represents an agreed contract as to what will
and won’t be in the system
Provides a basis for tracking completion of
the system
Feeds design, testing, training, etc.
INFO 627
Lecture #6
33
SRS Ownership



The SRS is owned by the developers
Often each part may have a separate owner
who is responsible for that part
All are overseen by the Vision champion,
chief architect, and the program manager
INFO 627
Lecture #6
34
SRS Format

There are many ways to arrange the contents
of an SRS



Text provides one structure (1E pp. 266-267),
which assumes you are using use cases
IEEE 830 provides another (p. 11 therein), which
is more generalized
Not all sections apply to every system; use
“Not Applicable” if that’s the case
INFO 627
Lecture #6
35
SRS Contents


Some parts of the SRS look like Vision
contents – purpose, scope, constraints,
interfaces, documentation and help – but here
the latter are described in more detail
Other issues are now addressed – licensing
and legal issues, purchased components
(implying some design concept), and all
requirements are identified (not just key)
INFO 627
Lecture #6
36
SRS Contents


The main body of the SRS is a detailed
description of the functional and nonfunctional requirements
Functional requirements can be broken down
many ways
INFO 627
Lecture #6
37
Functional Requirements

Functional requirements may be organized
(IEEE 830, App. A) by:

Mode of operation of the system; best used for
software-intensive mechanical systems, each
mode’s functional requirements are detailed
(scanning mode, editing mode, acquisition mode,
etc.)

INFO 627
If needed, each mode’s interfaces, functional, and
performance requirements can be addressed
Lecture #6
38
Functional Requirements


INFO 627
User class; where each type of user of the system
has well defined activities they must perform,
then their functional requirements are listed
Class; for object oriented systems; each class is
described in terms of its attributes, methods, and
messages
Lecture #6
39
Functional Requirements


INFO 627
Feature; similar to use case descriptions, identify
when and how each feature is to be used, and the
functional requirements for each feature
Stimulus; useful when the system’s responses
(functional requirements) are based on what kind
of specific stimulus or message it receives
Lecture #6
40
Functional Requirements


INFO 627
Functional hierarchy; break the requirements
down by information flow, process, or data
construct, and provide a data dictionary to specify
each data element’s format; good for
reengineering legacy information systems
Or any combination of the above methods
(multiple organizations), such as mixing user
class then stimulus and response
Lecture #6
41
Non-Functional Requirements

Non-functional requirements can be
documented according to the structure already
outlined




INFO 627
Usability
Reliability
Performance
Supportability
Lecture #6
42
Balancing Requirements

We need to review requirements for



Consistent level of detail throughout the system
Adequate level of detail to guide implementation,
without over constraining that implementation
Most of the SRS is text; graphics can be
helpful but beware of adding implied design
INFO 627
Lecture #6
43