Requirements Specification Template

[YourProject] Requirements Specification

Version 1.0
September 24, 2013
Use this Requirements Specification template to document the requirements for your product or
service, including priority and approval. Tailor the specification to suit your project, organizing the
applicable sections in a way that wors best, and use the checlist to record the decisions about what is
applicable and what isn!t.
The format of the requirements depends on what wors best for your project.
This document contains instructions and e"amples which are for the benefit of the person writing the
document and should be removed before the document is finalized.
To regenerate the T#$, select all %$T&'() and press *+.
,var,www,apps,conversion,tmp,scratch-.,/01230214.doc September /0, /152
6age 5 o f 50
ab!e of "ontents
1. EXECUTIVE SUMMARY.............................................................................................3
1.1 PROJECT OVERVIEW.................................................................................................................... 3
1.2 PURPOSE AND SCOPE OF THIS SPECIFICATION...................................................................................3
2. PRODUCT/SERVICE DESCRIPTION............................................................................3
2.1 PRODUCT CONTEXT.................................................................................................................... 3
2.2 USER CHARACTERISTICS............................................................................................................... 3
2.3 ASSUMPTIONS............................................................................................................................ 3
2.4 CONSTRAINTS............................................................................................................................ 3
2.5 DEPENDENCIES.......................................................................................................................... 4
3. REQUIREMENTS......................................................................................................4
3.1 FUNCTIONAL REQUIREMENTS......................................................................................................... 5
3.2 USER INTERFACE REQUIREMENTS................................................................................................... 5
3.3 USABILITY................................................................................................................................. 5
3.4 PERFORMANCE........................................................................................................................... 6
3.4.1 Capacity.......................................................................................................................... 6
3.4.2 Availability....................................................................................................................... 6
3.4.3 Latency........................................................................................................................... 6
3.5 MANAEABILITY!MAINTAINABILITY.................................................................................................. 6
3.5.1 Monitoring....................................................................................................................... 6
3.5.2 Maintenance.................................................................................................................... 6
3.5.3 Operations....................................................................................................................... 6
3.6 SYSTEM INTERFACE!INTERATION................................................................................................... "
3.6.1 Network an !arware "nter#aces...................................................................................$
3.6.2 %yste&s "nter#aces.......................................................................................................... $
3." SECURITY.................................................................................................................................. #
3.$.1 'rotection........................................................................................................................ (
3.$.2 A)t*ori+ation an A)t*entication....................................................................................(
3.# DATA MANAEMENT.................................................................................................................... #
3.$ STANDARDS COMPLIANCE............................................................................................................. #
3.1% PORTABILITY.............................................................................................................................. #
4. USER SCENARIOS/USE CASES..................................................................................9
5. DELETED OR DEFERRED REQUIREMENTS..................................................................9
6. REQUIREMENTS CONFIRMATION/STAKEHOLDER SIN!OFF.......................................1"
APPENDIX.................................................................................................................11
APPENDIX A. DEFINITIONS& ACRONYMS& AND ABBREVIATIONS.....................................................................11
APPENDIX B. REFERENCES.................................................................................................................. 11
APPENDIX C. REQUIREMENTS TRACEABILITY MATRIX.................................................................................11
APPENDIX D. ORANI'IN THE REQUIREMENTS....................................................................................... 13
6age / o f 50
5. 7"ecutive Summary
1.1 Project Overview
8escribe this project or product and its intended audience, or provide a lin or reference to the project
charter.
1.2 Purpose and Scope of this Specification
8escribe the purpose of this specification and its intended audience. 9nclude a description of what is
within the scope what is outside of the scope of these specifications. *or e"ample:
#n scope
This document addresses requirements related to phase / of 6roject (:
modification of $lassification 6rocessing to meet legislative mandate (;$.
modification of &abor Relations 6rocessing to meet legislative mandate (;$.
$ut of Scope
The following items in phase 2 of 6roject ( are out of scope:
modification of $lassification 6rocessing to meet legislative mandate <=>.
modification of &abor Relations 6rocessing to meet legislative mandate <=>.
%6hase 2 will be considered in the development of the requirements for 6hase /, but the 6hase 2
requirements will be documented separately.)
/. 6roduct,Service 8escription
9n this section, describe the general factors that affect the product and its requirements. This section
should contain bacground information, not state specific requirements %provide the reasons why
certain specific requirements are later specified).
2.1 Product Contet
?ow does this product relate to other products@ 9s it independent and self'contained@ 8oes it interface
with a variety of related systems@ 8escribe these relationships or use a diagram to show the major
components of the larger system, interconnections, and e"ternal interfaces.
2.2 !ser Characteristics
$reate general customer profiles for each type of user who will be using the product. 6rofiles should
include:
Student,faculty,staff,other
e"perience
technical e"pertise
other general characteristics that may influence the product
2." #ssumptions
&ist any assumptions that affect the requirements, for e"ample, equipment availability, user e"pertise,
etc. *or e"ample, a specific operating system is assumed to be availableA if the operating system is
not available, the Requirements Specification would then have to change accordingly.
2.$ Constraints
8escribe any items that will constrain the design options, including
parallel operation with an old system
6age 2 o f 50
audit functions %audit trail, log files, etc.)
access, management and security
criticality of the application
system resource constraints %e.g., limits on dis space or other hardware limitations)
other design constraints %e.g., design or other standards, such as programming language or
framewor)
2.% &ependencies
&ist dependencies that affect the requirements. 7"amples:
This new product will require a daily download of data from <,
Bodule < needs to be completed before this module can be built.
2. Requirements
8escribe all system requirements in enough detail for designers to design a system satisfying the
requirements and testers to verify that the system satisfies requirements.
#rganize these requirements in a way that wors best for your project. See 0 0 , #rganizing the
Requirements for different ways to organize these requirements.
8escribe every input into the system, every output from the system, and every function performed
by the system in response to an input or in support of an output. %Specify what functions are to be
performed on what data to produce what results at what location for whom.)
7ach requirement should be numbered %or uniquely identifiable) and prioritized.
See the sample requirements in *unctional Requirements, and System 9nterface,9ntegration, as well
as these e"ample priority definitions:
Priorit% &efinitions
The following definitions are intended as a guideline to prioritize requirements.
6riority 5 C The requirement is a Dmust haveE as outlined by policy,law
6riority / C The requirement is needed for improved processing, and the fulfillment of the
requirement will create immediate benefits
6riority 2 C The requirement is a Dnice to haveE which may include new functionality
9t may be helpful to phrase the requirement in terms of its priority, e.g., FThe value of the employee
status sent to 89S must be either ( or 9F or F9t 'ou!( be nice if the application warned the user that
the e"piration date was 2 business days awayF. (nother approach would be to group requirements
by priority category.
( good requirement is:
$orrect
Unambiguous %all statements have e"actly one interpretation)
$omplete %where T;8s are absolutely necessary, document why the information is unnown,
who is responsible for resolution, and the deadline)
$onsistent
Raned for importance and,or stability
Gerifiable %avoid soft descriptions lie Dwors wellE, Dis user friendlyEA use concrete terms and
specify measurable quantities)
Bodifiable %evolve the Requirements Specification only via a formal change process, preserving
a complete audit trail of changes)
8oes not specify any particular design
6age 0 o f 50
Traceable %cross'reference with source documents and spawned documents).
".1 'unctiona( Requirements
9n the e"ample below, the requirement numbering has a scheme ' ;R-&R-1HH %;R for ;usiness
Requirement, &R for &abor Relations). *or small projects simply ;R'HH would suffice. Ieep in mind
that if no prefi" is used, the traceability matri" may be difficult to create %e.g., no differentiation between
!1/! as a business requirement vs. a test case)
The following table is an e"ample format for requirements. $hoose whatever format wors best for
your project.
*or 7"ample:
Req) Requirement "omments Priorit%
&ate
R*'(
S+,
Re*ie'e( -
.ppro*e(
;R-&R-13
The system should associate
a supervisor indicator with
each job class.
;usiness 6rocess J
DBaintenance
2 4,52,10 ;ob 8ylan,
Bic Kagger
;R-&R-1L
The system should handle
any number of fees %e"isting
and new) associated with
unions.
;usiness 6rocess J
D$hanging 8ues in the
SystemE
(n e"ample of a new fee is
an initiation fee.
/ 4,52,10 ;ob 8ylan,
Bic Kagger
;R-&R-51
The system should capture
and maintain job class status
%i.e., active or inactive)
;usiness 6rocess J
DBaintenanceE
Some job classes are old
and are no longer used.
?owever, they still need to
be maintained for legal,
contract and historical
purposes.
/ 4,52,10 ;ob 8ylan,
Bic Kagger
;R-&R-5.
The system should assign the
Supervisor $ode based on
the value in the Kob $lass
table and additional criteria as
specified by the clients.
(pril /113 C Mew
requirement. 9t is one of
three new requirements
from ;R-&R-12.
/
;R-&R-5L
The system should provide
the &abor Relations office with
the ability to override the
system'derived ;argaining
Unit code and the Union
$ode for to'be'determined
employee types, including
hourly appointments.
(pril /113 C Mew
requirement. 9t is one of
three new requirements
from ;R-&R-10.
3,55,/113 C 6riority
changed from / to 2.
/
2
".2 !ser )nterface Requirements
9n addition to functions required, describe the characteristics of each interface between the product and
its users %e.g., required screen formats,organization, report layouts, menu structures, error and other
messages, or function eys).
"." !sa*i(it+
9nclude any specific usability requirements, for e"ample,
6age 3 o f 50
&earnability
The user documentation and help should be complete
The help should be conte"t sensitive and e"plain how to achieve common tass
The system should be easy to learn
%See http:,,www.usabilitynet.org,)
".$ Performance
Specify static and dynamic numerical requirements placed on the system or on human interaction with
the system:
Static numerical requirements may include the number of terminals to be supported, the number of
simultaneous users to be supported, and the amount and type of information to be handled.
8ynamic numerical requirements may include the number of transactions and tass and the amount
of data to be processed within certain time period for both normal and pea worload conditions.
(ll of these requirements should be stated in measurable form. *or e"ample, F+3N of the transactions
shall be processed in less than 5 secondF rather than Dan operator shall not have to wait for the
transaction to completeE.
3.4.1 "apacit%
9nclude measurable capacity requirements %e.g., the number of simultaneous users to be supported,
the ma"imum simultaneous user load, per'user memory requirements, e"pected application
throughput)
3.4.2 .*ai!abi!it%
9nclude specific and measurable requirements for:
?ours of operation
&evel of availability required
$overage for geographic areas
9mpact of downtime on users and business operations
9mpact of scheduled and unscheduled maintenance on uptime and maintenance communications
procedures
reliability %e.g., acceptable mean time between failures %BT;*), or the ma"imum permitted number
of failures per hour).
3.4.3 /atenc%
9nclude e"plicit latency requirements, e.g., the ma"imum acceptable time %or average time) for a service
request.
".% ,ana-ea*i(it+.,aintaina*i(it+
3.0.1 +onitorin1
9nclude any requirements for product or service health monitoring, failure conditions, error detection,
logging, and correction.
3.0.2 +aintenance
Specify attributes of the system that relate to ease of maintenance. These requirements may relate to
modularity, comple"ity, or interface design. Requirements should not be placed here simply because
they are thought to be good design practices.
6age . o f 50
3.0.3 $perations
Specify any normal and special operations required by the user, including:
periods of interactive operations and periods of unattended operations
data processing support functions
bacup and recovery operations
safety considerations and requirements
disaster recovery and business resumption
"./ S+stem )nterface.)nte-ration
Specify the use of other required products %e.g., a database or operating system), and interfaces with
other systems %e.g., UO?ires pacage interfaces with 6ub$ooie and #8S, ?766S system interfaces
with ;udget system). *or each interface, define the interface in terms of message format and content.
*or well'documented interfaces, simply provide a reference to the documentation.
#utline each interface between the product and the hardware or networ components of the system.
This includes configuration characteristics %e.g., number of ports, instruction sets), what devices are to
be supported, and protocols %e.g., signal handshae protocols).
3.2.1 3et'or4 an( 5ar('are #nterfaces
Specify the logical characteristics of each interface between the product and the hardware or networ
components of the system. This includes configuration characteristics %e.g., number of ports, instruction
sets), what devices are to be supported, and protocols %e.g., signal handshae protocols).
3.2.2 S%stems #nterfaces
7"ample systems interface requirements:
A. System1-to-System2 Interface
The Pe"ternal partyQ will create and send a fi"ed length te"t file as an email attachment to
System/mailRu.washington.edu to be imported into the System/ system for payroll calculation. This file
must be received on 789T day by 0:11 6B in order to be processed in the 789T night run. The
requirements below document the file specifications, data transfer process, and specific schedule. This
file is referred to as F*ileMameF in this document.
'i(e Structure and 'ormat
(.5. The *ileMame file is a fi"ed length te"t file.
(./. The *ileMame file is an unformatted (S$99 file %te"t'only).
(.2. The *ileMame file contains a batch totals record and several detail records.
'i(e &escription0 1atch 2ota(s Record
(.0. The batch totals record can be placed at the beginning, in the middle, or at the end of the file.
(.3. The batch totals record contains the following:
5. Record Type %value: <()
/. 6rocess Type %value: ()
2. ;atch Mumber %2 digit number assigned by 6ayroll 8ept)
0. #rigin $ode %(9S)
3. Total number of detail records
.. Total deduction amount
'i(e &escription0 &etai( Records
(... The *ileMame file contains a row for each record meeting """ criteria.
(.4. 7ach row in the *ileMame file contains the following fields, comma'delimited and encased in double'
quotes where the data includes commas or spaces:
7mployee 9d
6age 4 o f 50
Record Type
6rocess 8ate %BB88==)
<=S Mumber
7lement $ode
(mount
(mount Sign
=ear *lag
Total (mount
Total (mt Sign
".3 Securit+
3.6.1 Protection
Specify the factors that will protect the system from malicious or accidental access, modification,
disclosure, destruction, or misuse. *or e"ample:
encryption
activity logging, historical data sets
restrictions on intermodule communications
data integrity checs
3.6.2 .ut7ori8ation an( .ut7entication
Specify the (uthorization and (uthentication factors. $onsider using standard tools such as 6ub$ooie.
".4 &ata ,ana-ement
Specify the requirements for any information that is to be placed into a database, including
types of information used by various functions
frequency of use
data access rules
data entities and relationships
integrity constraints
data retention
valid range, accuracy, and,or tolerance
units of measure
data formats
default or initial values
".5 Standards Comp(iance
Specify the requirements derived from e"isting standards, policies, regulations, or laws %e.g., report
format, data naming, accounting procedures, audit tracing). *or e"ample, this could specify the
requirement for software to trace processing activity. Such traces are needed for some applications to
meet minimum regulatory or financial standards. (n audit trace requirement may, for e"ample, state
that all changes to a payroll database must be recorded in a trace file with before and after values.
".16 Porta*i(it+
9f portability is a requirement, specify attributes of the system that relate to the ease of porting the
system to other host machines and,or operating systems. *or e"ample,
6age L o f 50
6ercentage of components with host'dependent codeA
6ercentage of code that is host dependentA
Use of a proven portable languageA
Use of a particular compiler or language subsetA
Use of a particular operating systemA
The need for environment'independence ' the product must operate the same regardless of
operating systems, networs, development or production environments.
0. User Scenarios,Use $ases
6rovide a summary of the major functions that the product will perform. #rganize the functions to be
understandable to the customer or a first time reader. 9nclude use cases and business scenarios, or
provide a lin to a separate document %or documents). ( business scenario:
8escribes a significant business need
9dentifies, documents, and rans the problem that is driving the scenario
8escribes the business and technical environment that will resolve the problem
States the desired objectives
Shows the D(ctorsE and where they fit in the business model
9s specific, and measurable, and uses clear metrics for success
3. 8eleted or 8eferred Requirements
9dentify any requirements that have been deleted after approval or that may be delayed until future
versions of the system. *or e"ample:
Req)
9usiness
Requirement
Status "omments Pri
&ate
R*'(
S+,
Re*ie'e(
-.ppro*e(
;R-&R-15
The system should
validate the relationship
between ;argaining
Unit,&ocation and Kob
$lass.
(pril /113:
8eleted.
This requirement
has been replaced
by ;R-&R-12. and
;R-$$-22.
;usiness 6rocess J
D(ssigning a
;argaining Unit to an
(ppointmentE
5 4,52,10 ;ob 8ylan,
Bic Kagger
;R-&R-1/
The system should
validate that the
supervisor indicator is
correct according to job
class.
8eferred to 6hase /;:
2,/+,/113
(pril /113:
8eferred to 6hase
/;.
;usiness 6rocess J
D(ssigning a
(ppointmentE
2 4,52,10 ;ob 8ylan,
Bic Kagger
;R-&R-12
The system should
derive the bargaining
unit code, union code,
and supervisor
indicator from the job
class code and
location.
(pril /113: 8eleted
Replaced by
;R-&R-5. and
;R-&R-54.
;usiness 6rocess J
D(ssigning a
(ppointmentEA This
will eliminate the
need, typically, for the
user to enter the
bargaining unit code,
union code and
supervisor indicator.
5 4,52,10 ;ob 8ylan,
Bic Kagger
6age + o f 50
.. Requirements $onfirmation,Staeholder sign'off
9nclude documentation of the approval or confirmation of the requirements here. *or e"ample:
+eetin1 &ate .tten(ees :name an( ro!e; "omments
4,52,14 ;ob 8ylan, &abor Relations SB7
Bic Kagger, &abor Relations SB7
Ringo Starr, Technical 6roject Banager
8ebbie ?arry, Technical (nalyst
Kanis Koplin, Technical (nalyst
*red Beyer, 6roject Banager
$onfirmed ;R-&R-15 C ;R-&R-53
10,53,13 ;ob 8ylan, &abor Relations SB7
Bic Kagger, &abor Relations SB7
Ringo Starr, Technical 6roject Banager
8eferred , 8eleted: ;R-&R-15 ' ;R-&R-10,
;R-&R-14, ;R-&R-5/, ;R-&R-50,
;R-&R-53, ;R-&R-1., ;R-&R-54
6age 51 o f 50
(667M89<
The appendi"es are not always considered part of the actual Requirements Specification and are not
always necessary. They may include
Sample input,output formats, descriptions of cost analysis studies, or results of user surveysA
Supporting or bacground information that can help the readers of the Requirements SpecificationA
( description of the problems to be solved by the systemA
Special pacaging instructions for the code and the media to meet security, e"port, initial loading, or
other requirements.
Ohen appendi"es are included, the Requirements Specification should e"plicitly state whether or not
the appendi"es are to be considered part of the requirements.
1. &efinitions, .cron%ms, an( .bbre*iations
8efine all terms, acronyms, and abbreviations used in this document.
2. References
&ist all the documents and other materials referenced in this document.
3. Requirements raceabi!it% +atri<
The following trace matri" e"amples show one possible use of naming standards for deliverables
%*unctional(rea'8ocType'MM). The number has no other meaning than to eep the documents unique.
*or e"ample, the ;argaining Unit (ssignment 6rocess *low would be ;U('6*'15.
*or e"ample %5):
9usiness Requirement .rea &e!i*erab!es Status
;R-&R-15
The system should validate the relationship
between ;argaining Unit,&ocation and Kob
$lass.'''$omments: ;usiness 6rocess J
F(ssigning a ;argaining Unit to an
(ppointmentF %6riority 5)
;U( ;U('$8'15
(ssign ;U $onceptual 8esign
(ccepted
;U('6*'15
8erive ;argaining Unit'6rocess
*low 8iagram
(ccepted
;U('6*'15
8erive ;argaining Unit'6rocess
*low 8iagram
(ccepted
;R-&R-1+
The system should provide the capability for
the &abor Relations #ffice to maintain the
job class,union relationship.'''$omments:
;usiness 6rocess J FBaintenanceF %6riority
5)
;U( ;U('$8'15
(ssign ;U $onceptual 8esign
(ccepted
;U('6*'1/
;U (ssignment Rules Baint
6rocess *low 8iagram
Ready*orReview
*or e"ample %/):
9i8Req#& Pri
+ajor
.rea
&e*st#tems
&e!i*#&
&e!i* 3ame Status
;R-&R-15 5 ;U( ;U('$8'15 (ssign ;U $onceptual 8esign (ccepted
;R-&R-15 5 ;U( ;U('8S'1/ ;argaining Unit (ssignment 8; Bodification
8escription
(ccepted
;R-&R-15 5 ;U( ;U('6*'15 8erive ;argaining Unit'6rocess *low 8iagram (ccepted
6age 55 o f 50
9i8Req#& Pri
+ajor
.rea
&e*st#tems
&e!i*#&
&e!i* 3ame Status
;R-&R-15 5 ;U( ;U('U$8'15 ;U (ssign &R Use$ase 8iagram Ready*orReview
;R-&R-15 5 ;U( ;U('U$T'115 ;U (ssignment by 6$ Use$ase ' (dd
(ppointment and 8erive U;U
Reviewed
;R-&R-15 5 ;U( ;U('U$T'11/ ;U (ssignment by 6$ Use$ase ' (dd
(ppointment %U;U Mot *ound)
Reviewed
;R-&R-15 5 ;U( ;U('U$T'11. ;U (ssignment by 6$ Use$ase ' Bodify
(ppointment %Removed U;U)
Reviewed
;R-&R-1+ 5 ;U( ;U('$8'15 (ssign ;U $onceptual 8esign (ccepted
;R-&R-1+ 5 ;U( ;U('8S'1/ ;argaining Unit (ssignment 8; Bodification
8escription
(ccepted
;R-&R-1+ 5 ;U( ;U('6*'1/ ;U (ssignment Rules Baint 6rocess *low 8iagram(ccepted
;R-&R-1+ 5 ;U( ;U('U$8'12 ;U (ssign Rules Baint Use$ase 8iagram Reviewed
;R-&R-1+ 5 ;U( ;U('U$T'103 ;U (ssignment Rules Baint: Successfully (dd Mew
(ssignment Rule
Reviewed
;R-&R-1+ 5 ;U( ;U('U$T'135 ;U (ssignment Rules BaintUse$ase: Bodify Rule Reviewed
;R-&R-1+ 5 ;U( ;U('U$T'132 ;U (ssignment Rules BaintUse$ase ' Review
(ssignment Rules
Reviewed
;R-&R-1+ 5 ;U( ;U('U$T'134 ;U (ssignment Rules BaintUse$ase: 9nactivate
&ast Rule for a ;U
Reviewed
;R-&R-1+ 5 ;U( ;U('U9'1/ ;U (ssignRules Baint U9 Bocups Ready*orReview
;R-&R-1+ 5 ;U( ;U('T$'1/5 ;U (ssignment Rules Baint Test$ase: (dd Mew
Rule %(ssociated Kob $lass 8oes Mot 7"ist) '
Success
Ready*orReview
;R-&R-1+ 5 ;U( ;U('T$'1/4 ;U (ssignment Rules Baint Test$ase: Bodify Rule
' Success
Ready*orReview
;R-&R-1+ 5 ;U( ;U('T$'123 ;U (ssignment Rules Baint Test$ase: (dd Mew
Rule %(ssociated Kob $lass 8oes Mot 7"ist) ' 7rror
$ondition
Ready*orReview
;R-&R-1+ 5 ;U( ;U('T$'10+ ;U (ssignment Rules Baint Test$ase: Bodify Rule
' 7rror $ondition
Ready*orReview
*or e"ample %2):
9i8Req#& "&01 "&02 "&03 "&04 =#01 =#02 ="01 ="02 ="03 "01 "02 "03 "04
;R-&R-15
X X X X X
;R-&R-1+
X X X X X X
;R-&R-51
X X X X
6age 5/ o f 50
9i8Req#& "&01 "&02 "&03 "&04 =#01 =#02 ="01 ="02 ="03 "01 "02 "03 "04
;R-&R-55
X
6age 52 o f 50
4. $r1ani8in1 t7e Requirements
This section is for information only as an aid in preparing the requirements document.
8etailed requirements tend to be e"tensive. Sive careful consideration to your organization scheme.
Some e"amples of organization schemes are described below:
9% S%stem +o(e
Some systems behave quite differently depending on the mode of operation. *or e"ample, a control
system may have different sets of functions depending on its mode: training, normal, or emergency.
9% =ser "!ass
Some systems provide different sets of functions to different classes of users. *or e"ample, an elevator
control system presents different capabilities to passengers, maintenance worers, and fire fighters.
9% $bjects
#bjects are real'world entities that have a counterpart within the system. *or e"ample, in a patient
monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc.
(ssociated with each object is a set of attributes %of that object) and functions %performed by that
object). These functions are also called services, methods, or processes. Mote that sets of objects may
share attributes and services. These are grouped together as classes.
9% >eature
( feature is an e"ternally desired service by the system that may require a sequence of inputs to affect
the desired result. *or e"ample, in a telephone system, features include local call, call forwarding, and
conference call. 7ach feature is generally described in a sequence of stimulus'response pairs, and may
include validity checs on inputs, e"act sequencing of operations, responses to abnormal situations,
including error handling and recovery, effects of parameters, relationships of inputs to outputs, including
input,output sequences and formulas for input to output.
9% Stimu!us
Some systems can be best organized by describing their functions in terms of stimuli. *or e"ample, the
functions of an automatic aircraft landing system may be organized into sections for loss of power, wind
shear, sudden change in roll, vertical velocity e"cessive, etc.
9% Response
Some systems can be best organized by describing all the functions in support of the generation of a
response. *or e"ample, the functions of a personnel system may be organized into sections
corresponding to all functions associated with generating paychecs, all functions associated with
generating a current list of employees, etc.
9% >unctiona! 5ierarc7%
Ohen none of the above organizational schemes prove helpful, the overall functionality can be
organized into a hierarchy of functions organized by common inputs, common outputs, or common
internal data access. 8ata flow diagrams and data dictionaries can be used to show the relationships
between and among the functions and data.
.((itiona! "omments
Ohenever a new Requirements Specification is contemplated, more than one of the organizational
techniques given above may be appropriate. 9n such cases, organize the specific requirements for
multiple hierarchies tailored to the specific needs of the system under specification.
There are many notations, methods, and automated support tools available to aid in the documentation
of requirements. *or the most part, their usefulness is a function of organization. *or e"ample, when
organizing by mode, finite state machines or state charts may prove helpfulA when organizing by object,
object'oriented analysis may prove helpfulA when organizing by feature, stimulus'response sequences
may prove helpfulA and when organizing by functional hierarchy, data flow diagrams and data
dictionaries may prove helpful.
6age 50 o f 50

Requirements Specification Template

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Specification Template

Uploaded by

Copyright:

Available Formats

[YourProject] Requirements Specification

[YourProject] Requirements Specification

You might also like