Transcript Software Engineering Process II Defining Requirements INFO 637 Glenn Booker INFO 637 Lecture #5 What are Requirements? Requirements describe key characteristics and capabilities desired for your product Requirements.

Software Engineering Process II
Defining Requirements
INFO 637
Glenn Booker
INFO 637
Lecture #5
1
What are Requirements?
Requirements describe key characteristics
and capabilities desired for your product
Requirements include functions your
product can perform (functional
requirements), and every other aspect
of your product or how it was created
(non-functional requirements)
INFO 637
Lecture #5
2
Requirements Scope
Requirements can cover not only your
product (which may include software,
hardware, and networking components)
but also:
Documentation
Training
The process for creating the product
Service or maintenance
INFO 637
Lecture #5
3
FURPS+
One way of describing requirements
is using the FURPS+ breakdown
F is for Functional
U is for Usability
R is for Reliability
P is for Performance
S is for Supportability
The “+” is for everything else
(Stolen from Larman’s Applying UML and Patterns, 2nd ed.)
INFO 637
Lecture #5
4
Functional Requirements
Functional Requirements include every
method of obtaining input, processing
inputs, and generating outputs
Often this is the most complex list
of requirements
Directly relates to system-level testing
after product is completed – can each
requirement be met?
INFO 637
Lecture #5
5
Usability Requirements
Usability requirements describe how your
product was designed to accommodate
interaction with humans
Includes human factors, types of help
available, and documentation
Some non-functional requirements may
be testable, others not
INFO 637
Lecture #5
6
Reliability Requirements
Reliability requirements may specify goals
for mean time between failures (MTBF),
recoverability, and predictability of results
Particularly used for mission-critical systems
INFO 637
Lecture #5
7
Performance Requirements
Performance relates here to how fast or
how much the product can accomplish
These typically include response time for
queries, volume of throughput, and/or
resource usage (e.g. in terms of CPU,
disk, memory, or network traffic)
INFO 637
Lecture #5
8
Supportability Requirements
How easy is it to support this system?
How easy is it to adapt to new needs,
or be reconfigured?
How easy is it to maintain?
Can it adapt to other countries
(e.g. language, power needs, etc.)?
INFO 637
Lecture #5
9
Other Requirements
The “+” includes other kinds of
requirements:
Implementation constraints (hardware,
resources, etc.)
Interfaces to external systems (which you
don’t control)
Operations; how is it used operationally?
Packaging; how is it shipped?
Legal; export and licensing issues
INFO 637
Lecture #5
10
Constraints
Requirements can include constraints on
your product or how it is created
Comply with existing PC’s, or development
environment, or database system
Comply with business rules
Comply with physical or logistical constraints
Must be developed by a woman-owned, CMM
level three small business (for example!)
Or any other kind of constraint
INFO 637
Lecture #5
11
Software Requirements Spec
Requirements can be captured in a
Software Requirements Specification
(SRS)
The SRS can also be used as a contract,
binding the developer to commit to exactly
what they will create for the customer
Helps avoid misunderstandings and unhappy
customers by making expectations clearer
INFO 637
Lecture #5
12
Communication is the Key
While a good SRS is very helpful, the
bigger need is for the developers and
customer to communicate with each other
Driving 100 mph in the wrong direction won’t
get you to your destination and faster!
Similarly, starting development without knowing
what you need to create won’t help you finish
quickly
INFO 637
Lecture #5
13
Requirements Change
Even projects with “well known
requirements” from the beginning typically
have 30% of those requirements change
before the project is completed
Must expect requirements will change, and
create a process to control those changes
INFO 637
Lecture #5
14
Requirements Change
Changes cost time and effort – need to
quantify those to know how much cost
to expect
Otherwise it’s like taking your car to a mechanic
and telling them to do whatever they want
Often a Configuration Control Board
(CCB) is used to determine whether a
particular change is acceptable
INFO 637
Lecture #5
15
Change Control
To determine if a change is needed, follow
some sort of process
See Change Control handout
First step is to screen or scrub the
proposed change
Do we understand what is suggested?
Is it really needed?
Has someone already suggested it?
INFO 637
Lecture #5
16
Change Control
Then we need to estimate how much work
the change will be
Estimate size, cost, and effort needed to
implement it
Determine who could best implement it
Determine its priority
Then start implementing the change after
approval by the CCB
INFO 637
Lecture #5
17
Change Control
The developers create the change, do
unit testing, and get peer review approval
of the change
Once ready, the CCB may determine
when the change will be implemented
(often the next available build)
Many changes may be built together,
and tested to make sure they all work
INFO 637
Lecture #5
18
Change Control
Then the CCB reviews the system test
results, and approves release of the
change
The change is now part of the new
system baseline
Process is very similar for software system
maintenance, not just development
INFO 637
Lecture #5
19
Extracting Requirements
Requirements are obtained (elicited) by
working from the most clearly understood
aspects to the most vague
Assess system feasibility
Understand organizational issues
Identify system stakeholders
Record requirements sources
INFO 637
Lecture #5
20
Extracting Requirements
Define operating environment
Assess business issues
Define domain constraints
Record requirements rationale
Prototype poorly understood requirements
Define usage scenarios
Define operational processes
INFO 637
Lecture #5
21
Another Example
The sample RFI includes examples of
functional requirements, constraints, and
meaningless jabber
See Sample SIR handout
Can you tell them apart?
INFO 637
Lecture #5
22
SRS Structure
Many different structures are available
for an SRS
The text’s is on page 113
An SRS may range from a few pages long
to hundreds
The SRS may be used to write systemlevel test procedures, to test whether
every requirement works in the
final product
INFO 637
Lecture #5
23
SRS Script
The development script for creating the
SRS includes:
Reviewing and clarifying the system needs
Allocating parts of the SRS to be done by
each team member
Developing the system test plan
Inspecting the SRS and test plan
Refining the SRS and test plan
INFO 637
Lecture #5
24
End Product
This phase results in a completed
(baselined) SRS and the system test plan
While simple in concept, these control
everything which happens from this point on
They are now baselined documents, so
changes to them need to be submitted
via the change process (form CCR)
INFO 637
Lecture #5
25