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.
Download
Report
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