Transcript INFO 424 Team Project Practicum Week 3 – Software Requirements Specification Glenn Booker Notes mostly from Prof.

INFO 424
Team Project Practicum
Week 3 – Software Requirements Specification
Glenn Booker
Notes mostly from Prof. Hislop and INFO 627 lectures 6 to 9
INFO 424 Week 3
1
www.ischool.drexel.edu
Agenda
• Software Requirements Specification and
Test Specification
• Remember that your system may
ultimately involve non-software such as:
– Hardware
– Users
– Training
– Documentation, etc.
INFO 424 Week 3
2
www.ischool.drexel.edu
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 424 Week 3
3
www.ischool.drexel.edu
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
– Inputs to the system, in terms of content,
format, and source
INFO 424 Week 3
4
www.ischool.drexel.edu
Software Requirements
– 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
INFO 424 Week 3
5
www.ischool.drexel.edu
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 424 Week 3
6
www.ischool.drexel.edu
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 424 Week 3
7
www.ischool.drexel.edu
Requirements Gathering
• Draft system concept description and
share with user
• What are the current processes? (if any)
• What is the problem to be addressed?
– Top 5 functions
• What are the goals
– Why is this system needed?
INFO 424 Week 3
8
www.ischool.drexel.edu
Requirements Gathering
• What are the key data concepts?
• What is the scope of the product?
• What non-functional requirements are
there?
• What constraints are there (e.g. customermandated technology choices)
• Who are the key actors?
– Are there stakeholders who aren’t actors?
INFO 424 Week 3
9
www.ischool.drexel.edu
Software Requirements
Specification (SRS)
• Sources
– Document template on course site
– IEEE std. 830-1998 you download
– Prior course work and texts
• Key points
– User oriented document
• Write so users could read it and understand
– Not a design or project management document
• Do NOT make design decision or assumptions here
– Represents the agreement between developers and
client as to what the product will do
INFO 424 Week 3
10
www.ischool.drexel.edu
Sample requirements?
• The system shall have the ability to generate
ad-hoc reports.
• The system shall be client/server based.
• The system shall have a user-friendly interface.
• The system shall have the capability of remote
user access through a Web Browser with query
and reference copy functions, as a minimum.
• The system shall have the ability to cancel
active documents.
From an FAA RFI for a document management system
INFO 424 Week 3
11
www.ischool.drexel.edu
Sample requirements?
– The system shall have the ability to manage
concurrent revisions.
– The system shall have the ability to copy
drawings for reference.
– The system shall have the ability to submit
drawings for approval.
– The system shall have the ability to edit
metadata.
– The system shall have the ability to create
multiple workflows.
INFO 424 Week 3
12
www.ischool.drexel.edu
Sample requirements?
– The system shall have E-mail messaging
compliant with SMTP (UNIX) and MAPI
(Windows).
– The system shall have the ability to handle
long filenames with 32 characters or greater.
– The system shall have the ability to perform
text searches within documents.
– The system shall have the ability to generate
and store custom reports.
INFO 424 Week 3
13
www.ischool.drexel.edu
SRS
• Section 1 is the Introduction
– Notice that 1.1 pertains to the SRS document,
not your system or product
• Section 2 is a brief description of your
system
– 2.1 describes the general features of your
system; what kinds of things can a user do
with it?
– 2.2 describes the users of your system
INFO 424 Week 3
14
www.ischool.drexel.edu
SRS
• Section 3 is the main body of the
document
– 3.1 is the main breakdown of functional
requirements for your system
• Give each requirements an identifier (e.g.
paragraph number or P001) and brief name
(Generate weekly sales report)
• Input and output descriptions may be added
when helpful
INFO 424 Week 3
15
www.ischool.drexel.edu
Writing the Requirement
• Action
– List each action that the system must be able
to perform
– Write this part first (then add the input and
output)
– Use complete sentences
– “The system shall…”
• Input and Output
– Optional – don’t just repeat the Action
INFO 424 Week 3
16
www.ischool.drexel.edu
Writing the Requirement
• Input (optional)
– What causes the Action to happen?
• Must be something detectable within the software
– What data or state is needed for the action to
occur?
• Output (optional)
– What is the result of the Action?
• State changes
• Data changes
INFO 424 Week 3
17
www.ischool.drexel.edu
SRS
• Use a prefix in the identifier to indicate
how you’re breaking down requirements
– By user or actor (C = Clerk, VP = VP, etc.)
– By system component (W = Web interface,
WS= Web Server, DS = Database server...)
– By use case number (UC001)
– Or by some other convention (specify!)
• Describe the Action required for each
requirement
INFO 424 Week 3
18
www.ischool.drexel.edu
Requirement Quality
• Simply having defined the requirements
is a good start
• Beyond that, quality for each requirement
or specification has nine aspects
– Correct: meets needs of user
– Unambiguous: only has one interpretation
– Complete: meets all needs and conditions
– Consistent: with other requirements
INFO 424 Week 3
19
www.ischool.drexel.edu
Requirement Quality
– Ranked: for importance or priority
– Verifiable: often by testing
– Modifiable: to allow for requirements changes
– Traceable: to needs or later design
– Understandable
• Most of these came from IEEE 830
INFO 424 Week 3
20
www.ischool.drexel.edu
Software Requirements
Specification (SRS)
• 3.2 – Non-Functional requirements
– Write carefully and use complete sentences
• Start with the Action
– Match requirement label to content
– Define data concepts and groups; name them
and use names for Input and Outputs
INFO 424 Week 3
21
www.ischool.drexel.edu
Non-Functional Requirements
• Consider what nonfunctional requirements
are relevant for your system, such as
– Usability
•
•
•
•
•
Time needed for training
Time to perform task
Usability compared to other systems
Availability of help
Compliance with HCI standards (Windows, Mac)
INFO 424 Week 3
22
www.ischool.drexel.edu
Non-Functional Requirements
– Reliability
•
•
•
•
•
•
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)
INFO 424 Week 3
23
www.ischool.drexel.edu
Non-Functional Requirements
– Supportability
• Expected implementation time for minor, medium,
and major enhancements
• Planned or possible future enhancements mostly
affect design decisions
– Most other ‘-ilities’ are nonfunctional
requirements
• Portability (to other platforms)
• Maintainability
• Etc.
INFO 424 Week 3
24
www.ischool.drexel.edu
Performance Requirements
• Performance requirements could include
– Response time for a transaction – average,
maximum, some % below some value (e.g.
95% below 5 sec response time)
– Throughput (transactions per second)
– Capacity (number of simultaneous users)
– Degraded modes of operation (what are
performance expectations if system is
partially offline)
INFO 424 Week 3
25
www.ischool.drexel.edu
SRS
• Section 3.3 is an outline of major data
concepts
– Don’t try to do a full ERD here or include keys
– What major categories of data will your
system need to manage?
• Section 3.4 has design constraints
– Don’t make up some just to avoid a blank
section, say ‘This system has no design
constraints’ instead
INFO 424 Week 3
26
www.ischool.drexel.edu
Design Constraints
• We generally want to define requirements
so that several design approaches might
be used to implement them
• Constraints might be imposed by the
customer such as the development
language, use of corporate reuse libraries,
coding standards, or external standards
such as FDA, DOD or FCC regulations
INFO 424 Week 3
27
www.ischool.drexel.edu
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 424 Week 3
28
www.ischool.drexel.edu
Use Cases
• If you’re using use cases in section 3.1 to
capture functional requirements, include a
use case diagram
• Hints for the use case diagram:
– Actors are clearly labeled stick figures
– External systems can be labeled boxes
– System boundary is labeled with your
system’s name on it
INFO 424 Week 3
29
www.ischool.drexel.edu
Use Cases
– System boundary doesn’t enclose actors or
external systems
– Lines connect actors to the use cases they
can perform
– Generalization can be used to simplify the
diagram
– ‘Included’ use cases must be used by at least
two other use cases
INFO 424 Week 3
30
www.ischool.drexel.edu
Use Cases
• Name use cases in verb-adjective-noun
format, e.g. Modify existing customer,
Generate sales report, Delete user, etc.
• Omit trivial use cases, e.g. log in and log
out
• Number use cases, and provide
documentation of each following that
number sequence
INFO 424 Week 3
31
www.ischool.drexel.edu
Use Case documentation
• For use cases you are implementing this
cycle, documentation should include:
– Use case number and name
– Primary actor
– Main success scenario
– Alternative scenarios (Extensions)
– Typical time to execute use case
– Frequency use case will be performed
• x times per day or week or whatever
INFO 424 Week 3
32
www.ischool.drexel.edu
Use Case documentation
• For all other use cases, document them
with:
– Use case number and name
– Primary actor
– A brief narrative description of the main
success scenario (1-3 sentences)
INFO 424 Week 3
33
www.ischool.drexel.edu
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.)
• If needed, each mode’s interfaces, functional, and
performance requirements can be addressed
INFO 424 Week 3
34
www.ischool.drexel.edu
Functional Requirements
– 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
INFO 424 Week 3
35
www.ischool.drexel.edu
Functional Requirements
– 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
INFO 424 Week 3
36
www.ischool.drexel.edu
Functional Requirements
– 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
INFO 424 Week 3
37
www.ischool.drexel.edu
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 424 Week 3
38
www.ischool.drexel.edu