Senior Design – Requirements Specification Review
REQUIREMENTS SPECIFICATION
The goal is to specify:
 what is to be accomplished
 how the system or product fits into the needs of the business
 how the system is to be used on a day-to-day basis
Sounds simple, reality is it is quite difficult.
Specification can mean different things to different people.
A specification can be written as:






a written document
a set of graphical models
a formal mathematical model
a collection of usage scenarios
a prototype
any combination of these.
We use a combination of these.
Senior Design – Requirements Specification Review
REQUIREMENTS DOCUMENT STRUCTURE






Introduction (Requirements Definition)
– Describe need for the system and how it fits with business objectives.
Functional Requirements
– Describe the services to be provided in detail. May include, use cases, state
diagrams, and other graphical representations.
Non-functional Requirements
– Define constraints on the system and the development process.
System Evolution
– Define fundamental assumptions on which the system is based and anticipated
changes.
Glossary
– Define technical terms used.
Index / Table of Contents
Senior Design – Requirements Specification Review
REQUIREMENTS DEFINITON
A statement in natural language of the services the system provides and its
operational constraints.
Written for customers.
Example: Thera Wii from 2009
There is an emerging trend toward using video games as a means of increasing
patient engagement in physical therapy. This trend is primarily driven by the newest
generation of consumer console systems which use motion-based controls. However,
clinical research into the efficacy of these systems is hindered by the inability to
automatically collect data from systems and software which were not intended for this
purpose.
We will create a new piece of software that will give researchers the ability to
experiment and quantitatively assess the value of game-based therapy. This software
will provide an extensible framework for games or interactive experiments as well as
an example suite of activities. The key aspect of this framework will allow researchers
to easily gather data from motion-based input controls such as the Wii Remote.
Various reporting methods and analysis tools will be provided for the gathered data.
Senior Design – Requirements Specification Review
REQUIREMENTS SPECIFICATION
A structured document setting out detailed descriptions of the system services.
Written as a contract between client and contractor.
Written for contractors and developers.
Senior Design – Requirements Specification Review
Requirements may be functional or non-functional
Functional requirements describe system services or features.
The key is to remember it is about the
WHAT not the HOW of your project.
One exception to this, IMHO, is the user interface. I prefer to see most of it dictated in
the requirements document, because it is a great tool to help the end-user
understand what you are developing.
Senior Design – Requirements Specification Review
Functional Requirement Examples (Future Tense)
r3.1 The software shall keep a persistent set of menus at the top of the Therapy/Profile window.
Priority 1
r3.2 The software shall list the menu options as text horizontally across the top of the window.
Priority 1
r3.3 File Menu
r3.3.1 The software shall display a drop down menu when the \File" menu is clicked on. Priority 1
r3.3.2 The software shall have an \Import Therapies..." option in the File menu. Priority 1
r3.3.3 The software shall have an \Export Therapies..." option in the File menu. Priority 1
r3.3.4 The software shall have an \Import Profiles..." option in the File menu. Priority 1
r3.3.5 The software shall have an \Export Profiles..." option in the File menu. Priority 1
r3.3.6 The software shall bring up the appropriate import or export dialog if any of the Import or
Export menu options is clicked on (see [4.3.6]). Priority 1
r3.3.7 The software shall have a \Quit" option in the File menu. Priority 1
r3.3.8 The software shall exit the program if the \Quit" option is clicked by the user. Priority 1
Senior Design – Requirements Specification Review
Functional Requirement Examples (Present Tense)
r3.1 The software keeps a persistent set of menus at the top of the Therapy/Profile window.
Priority 1
r3.2 The software lists the menu options as text horizontally across the top of the window. Priority
1
r3.3 File Menu
r3.3.1 The software displays a drop down menu when the \File" menu is clicked on. Priority 1
r3.3.2 The software has an \Import Therapies..." option in the File menu. Priority 1
r3.3.3 The software has an \Export Therapies..." option in the File menu. Priority 1
r3.3.4 The software has an \Import Profiles..." option in the File menu. Priority 1
r3.3.5 The software has an \Export Profiles..." option in the File menu. Priority 1
r3.3.6 The software brings up the appropriate import or export dialog if any of the Import or
Export menu options is clicked on (see [4.3.6]). Priority 1
r3.3.7 The software has a \Quit" option in the File menu. Priority 1
r3.3.8 The software exits the program if the \Quit" option is clicked by the user. Priority 1
It is a matter of style whether you write the requirements document in future or present tense. As
I believe the real value in the requirements document is as time moves on and the application was
completed and now is modified. However, I believe that since the period of time the document will
be used most is potentially after development, I would write it in the active voice as above.
Senior Design – Requirements Specification Review
Functional Requirement Examples (Priorities)
Priority Level
Description
Priority 1
Essential and required functionality
Priority 2
Desirable functionality
Priority 3
Extra features
Senior Design – Requirements Specification Review
REQUIREMENTS VERIFIABILITY



Requirements should be written so that they can be verified objectively.
The problem with this requirement is its use of vague terms such as “errors shall
be minimized”
– The system should be easy to use by experienced controllers and should be
organized in such a way that user errors are minimized.
The error rate should be been quantified.
– Experienced controllers should be able to use all the system functions after a
total of two hours training. After this training, the average number of errors
made by experienced users should not exceed two per day.
Software Engineering – Requirements Engineering
REQUIREMENTS VERIFIABILITY
Property
Measure
Speed
Processed Transactions/Second
User/Event Response Time
Screen Refresh Time
Size
K Bytes
Number of RAM Chips
Ease of Use
Training Time
Number of Help Frames
Reliability
Mean Time to Failure
Probability of Unavailability
Rate of Failure Occurrence
Availability
Robustness
Time to Restart After Failure
Percentage of Events Causing Failure
Probability of Data Corruption on Failure
Portability
Percentage of Target Dependent Statements
Number of Target Systems
Senior Design – Requirements Specification Review
USE CASES
It is helpful to create scenarios that identify a thread of usage for the system to be
constructed.
These scenarios are often called use cases.
Use cases tell a story about how an end user interacts with the system under a specific
set of circumstances.
This story may be:




narrative text
an outline of tasks or interactions
a template-based description
diagrammatic representation
It depicts software from an end-user point of view.
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
“A use case captures a contract.. [that] describes the system’s behavior under various
conditions as the system’s behavior under various conditions as the system responds
to a request from one of its stakeholders.”
Steps in creating a use case:
Step One:
 Define the actors that will be in involved in the story.
 Actors are different people (or devices) that use the system or product within
the context of the function/behavior that is to be described.
 Actors represent the roles that people (or devices) play as the system operates.
 An actor is anything that communicates with the system or product.
 Note, an actor and an end-user are not necessarily the same thing. End-users
may play many roles. An actor plays one role in the context of a use-case.
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Questions to ask about actors:









Who are the actor(s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What exceptions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What type of system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected change?
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Think about a home security system.
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Think about a home security system.
Three actors exist: homeowner/configuration manager, sensors, and the monitoring
subsystem.
Let’s look at the homeowner. The homeowner interacts with the home security
function in a number of different ways using either the alarm control panel or a PC:





Enters a password to allow all other interactions.
Inquires about the status of a security zone.
Inquiries about the status of a sensor.
Presses the panic button in an emergency.
Activates/deactivate the security system.
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Use case: InitiateMonitoring
Primary Actor: Homeowner
Goal in context: To set the system to monitor sensors when the homeowner leaves the
house or remains inside.
Preconditions: System was programmed for a password and to recognize various
sensors.
Trigger: The homeowner decides to “set” the system, i.e turn on the alarm function.
Scenario:
 Homeowner observes control panel.
 Homeowner enters password.
 Homeowner selects ‘stay” or “away”
Homeowner observes red alarm light to indicate that SafeHome has been armed
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Exceptions:
1.
Control panel is not ready: Homeowner checks all sensors to determine which
are open and closes them.
2.
Password is incorrect (control panel beeps once) homeowner renters correct
password.
3.
Password not recognized: monitoring and response subsytem must be
contacted to reprogram password
4.
Stay is selected: control panel beeps twice and a stay light is lit; perimeter
sensors are activated
5.
Away is selected. Control panel beeps three times and an away light is lit; all
sensors are activated
Priority: Essential, must be implemented
When available: First Increment
Frequency of use: Many times a day
Channel to actor: via control panel
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Secondary Actors: support technician, sensors.
Open issues:
1.
Should there be a way to activate the system without the use of a password or
with an abbreviated password?
2.
Should the control panel display additional text messages?
3.
Ho w much time does the homeowner have to enter a password from the time
the first key is pressed?
4.
Is there a way to deactivate the system before it activates?
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Are use cases always helpful?
I am a strong believer that use cases that do not add to the understanding of a project
are a waste of space and can detract from the formal specifications. So when are use
cases useful? When the domain is not clear. For example see the following video:
http://www.youtube.com/watch?v=pfYs5C8D4uk
How do we specify a system that accomplishes an ad-hoc network like that?
Sure we can try to specify it all in words, but here is where a use case is extremely
valuable. See how the Intelligent Tactical Mesh Networks project used use cases.
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
First, they defined the symbols used.
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Symbols continued:
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
First Use Case:
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
First Use Case:
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
First Use Case:
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Another Use Case:
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Another Use Case:
Software Engineering – Requirements Engineering
DEVELOPING USE CASES
Another Use Case:
Software Engineering – Requirements Engineering
DOCUMENTING THE USER INTERFACE
Example Global Basketball Network:
Create a new posting for the Ecommerce System
Requirements
4.5.2.1 - A textbox for the posting’s title. This is limited to 80 plaintext characters.
4.5.2..2 - A textbox for the desired price. This is limited to 20 plaintext characters.
The user may enter a range of values in any currency.
4.5.2.3 - The price is optional and may be left blank.
A4.5.2.4 – A textbox for the zip code location of the item. This is limited to 5
numerical characters.
4.5.2.5 - A combo box for the user to select the category.
4.5.2.6 - The user must select a category.
4.5.2.7 - A combo box for the user to select the subcategory. Defaults to
Miscellaneous.
4.5.2.8 A text area for the description of the item. This is limited to 1024 plaintext
characters.
.
.
.
Software Engineering – Requirements Engineering
DOCUMENTING THE USER INTERFACE
Example Global Basketball Network:
Software Engineering – Analysis Modeling
SCENARIO BASED-MODELING
Similar to a flowchart:
• Round rectangles imply
specific system functions
• Arrows represent flow
through the system
• Diamonds depict a branching
decision
Software Engineering – Analysis Modeling
SCENARIO BASED-MODELING
Swim Lane Diagram
Represents flow of
activities indicating
which actor has
responsibility for
the action.
Responsibilities are
represented as
parallel segments
that divide the
diamond vertically,
like the lanes in a
swimming pool.
Software Engineering – Requirements Engineering
SCENARIO BASED MODELING
ACTIVITY DIAGRAM
Demonstrating how the
system will work
Software Engineering – Requirements Engineering
Formal Specification
function Search ( X: array 1 .. N of INTEGER; Key: INTEGER )
return INTEGER ;
Pre:  1  i N X[i] = Key
Post: X’ [Search (X, Key)] = Key  X = X’ Key’ = Key
Senior Design – Requirements Specification Review
Non-functional requirements is a constraint on the system or on the development
process. This may include some description of the HOW.
Non-functional requirements may include:
 security standards
 system properties and constraints e.g., reliability, response time and storage
requirements. Constraints are I/O device capability, system representations,
etc.
 process requirements may also be specified mandating a particular CASE
system, programming language or development method.
Non-functional requirements may be more critical than functional requirements. If
these are not met, the system is useless.
Senior Design – Requirements Specification Review
NON FUNCTIONAL REQUIREMENTS – EXAMPLES
4.6.1 Software Constraints
• The software will rely on the Microsoft .Net Framework. It is assumed that any system running
this software has the Microsoft .Net 2.0 or greater correctly installed.
• All drivers must be installed and configured for the Bluetooth USB receiver(s).
4.6.2 Hardware Constraints
• Minimum of one available USB slot
• One Bluetooth USB per Wii input device
• Keyboard and mouse
• Monitor or other video display device
• 100MB hard disk space
• 256MB available memory
• 1GHz processor
• 64MB video card
4.6.3 Acceptance Constraints
• Before accepting the system, the developers must complete the following:
• Demo the working system and any features upon request.
• Prove that all Priority 1 functional requirements are met.
• Provide sufficient test cases to show that the system is complete and correct.
Senior Design – Requirements Specification Review
VALIDATION
How do you Validate that you’ve done a good job?
You might think that quality is hard to quantify during requirements engineering. After
all, how can you determine if what the end-user/customer is telling you is correct?
However you can check for:
 ambiguity
 conflicts
 omissions (some, obviously not all)
Senior Design – Requirements Specification Review
TRACEABILITY
Every requirement is given a unique identifier. This helps with traceability.
You can include any of the following diagrams:
 Source traceability table: identifies the source of each requirement
 Dependency traceability table: identifies how requirements are related to
another
 Subsystem traceability table: Categorizes requirements by the subsystems
they govern.
 Interface traceability table: relates requirements to both internal and external
interfaces.
Software Engineering – Requirements Engineering
BUILDING THE ANALYSIS MODEL
An analysis model provides a description of the required information, functional , and
behavioral domains for a computer based system.
An analysis model will change during the requirements gathering with some areas
stable and others being volatile.
There are many ways to represent the model.
Scenario-based elements: The system is described from the user’s point of view.
Senior Design – Requirements Specification Review
GLOSSARY
List any definitions, acronyms or abbreviations used within your document.
2.3 Definitions, Acronyms, Abbreviations
2.3.1 Physical Therapy
.
.
.
• Posture - The orientation of any body segment relative to the gravitational vector. It is an
angular measure from the vertical [1].
• Balance - The dynamics of body posture that prevents falling. It is related to the inertial
forces acting on the body and the inertial characteristics of body segments [1].
• Center of Mass (COM) - A specific point at which the system's mass behaves as if it were
concentrated [1].
• Center of Pressure (COP) - The point location of the vertical ground reaction force vector. It
represents a weighted average of all the pressures over the surface of the area that is in
contact with the ground. It is also called the Center of Balance (COB) [1].
2.3.3 Software
• Therapy - A series of tasks that is completed in one session.
• Session - A given time in which a user completes a therapy.
• Task - A subunit of a therapy that has an objective with success and fail criteria.
Senior Design – Requirements Specification Review
INDEX / TABLE OF CONTENTS
Team Inversion
Software Requirements Specification
1
By Angry Face Studios
1
1 Introduction
4
1.1Scope
4
1.2 Purpose 4
1.3 Definitions, Acronyms, and Abbreviations
1.4 Overview
5
2 Overall Description 5
2.1 Product Perspective
5
2.2 Game Play Concepts
6
2.2.1 Game Modes
6
2.2.2 Items 8
2.3 Product Functions 9
2.3.1 Agent 9
2.3.2 Operator
9
2.3.3 Server 10
2.4 System Interface 10
2.5 User Interface
10
4