Software Requirements Specification
for
<Project>
Version <X.X>
Prepared by
Group Name: <place your group name here>
<name> <name> <name> <name> <name> <student <student <student <student <student > > > > > <e!mai"> <e!mai"> <e!mai"> <e!mai"> <e!mai">
#nstructor: $ourse: &ab Section: 'eac%in( )ssistant: *ate:
<place your instructors name here> <p"ace your course name %ere> <place your lab section here> <place your TAs name here> <p"ace t%e date of submission %ere>
Software Requirements Specification for <Project>
Page ii
$ontents
<IN THIS TEMPLATE YOU WILL FIND TEXT BOUNDED BY THE <> SYMBOLS. THIS TEXT APPEARS IN ITALICS AND IS INTENDED TO GUIDE YOU THROUGH THE TEMPLATE AND PROVIDE EXPLANATIONS REGARDING THE DIFFERENT SECTIONS IN THIS DOCUMENT. THERE ARE TWO TYPES OF COMMENTS IN THIS DOCUMENT. THESE COMMENTS THAT ARE IN BLACK ARE INTENDED SPECIFICALLY FOR THAT COURSE. THESE COMMENTS THAT ARE IN BLUE ARE MORE GENERAL AND APPLY TO ANY SRS. PLEASE, MAKE SURE TO DELETE ALL OF THE COMMENTS BEFORE SUBMITTING THE DOCUMENT. ...................................................III THE EXPLANATIONS PROVIDED BELOW, DO NOT COVER ALL OF THE MATERIAL, BUT MERELY, THE GENERAL NATURE OF THE INFORMATION YOU WOULD USUALLY FIND IN SRS DOCUMENTS. IT IS BASED ON THE IEEE REQUIREMENTS AND WAS ADAPTED SPECIFICALLY FOR THE NEEDS OF SOFTWARE ENGINEERING K!"# M!" COURSES. MOST OF THE SECTIONS IN THIS TEMPLATE ARE REQUIRED SECTIONS, I.E. YOU MUST INCLUDE THEM IN YOUR VERSION OF THE DOCUMENT. FAILURE TO DO SO WILL RESULT IN MARKS DEDUCTIONS. OPTIONAL SECTIONS WILL BE EXPLICITLY MARKED AS OPTIONAL...............................................III $ INTRODUCTION......................................................................................................................................................$ % OVERALL DESCRIPTION..................................................................................................................................... SPECIFIC REQUIREMENTS.................................................................................................................................& " OTHER NON'FUNCTIONAL REQUIREMENTS...............................................................................................( & OTHER REQUIREMENTS.....................................................................................................................................)
Re+isions
Version Draft Type and Number Primary )ut%or,sFull Name *escription of Version Information about the revision. This table does not need to be filled in whenever a document is touched, only when the version is being upgraded. *ate $omp"eted 00/00/00
Software Requirements Specification for <Project>
Page iii
<In this template you will find text bounded by the <> symbols. This text appears in italics and is intended to guide you through the template and provide explanations regarding the different sections in this document. There are two types of comments in this document. These comments that are in black are intended specifically for that course. These comments that are in blue are more general and apply to any ! . "lease# make sure to delete all of the comments before submitting the document. The explanations provided below# do not cover all of the material# but merely# the general nature of the information you would usually find in ! documents. It is based on the I$$$ re%uirements and was adapted specifically for the needs of oftware $ngineering &'()*&+() courses. +ost of the sections in this template are re%uired sections# i.e. you must include them in your version of the document. ,ailure to do so will result in marks deductions. -ptional sections will be explicitly marked as optional.
Software Requirements Specification for <Project>
Page 1
. #ntroduction
<T- .-/ "lease provide a brief introduction to your pro0ect and a brief overview of what the reader will find in this section.>
... *ocument Purpose
<Identify the product whose software re%uirements are specified in this document# including the revision or release number. .escribe the scope of the product that is covered by this ! # particularly if this ! describes only part of the system or a single subsystem. T- .-/ 1rite 234 paragraphs describing the purpose of this document as explained above.>
../ Product Scope
<"rovide a short description of the software being specified and its purpose# including relevant benefits# ob0ectives# and goals. T- .-/ 234 paragraphs describing the scope of the product. +ake sure to describe the benefits associated with the product.>
..0 #ntended )udience and *ocument 1+er+iew
<.escribe the different types of reader that the document is intended for# such as developers# pro0ect managers# marketing staff# users# testers# and documentation writers 5In your case it would probably be the client and the professor6. .escribe what the rest of this ! contains and how it is organi7ed. uggest a se%uence for reading the document# beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.>
..2 *efinitions3 )cronyms and )bbre+iations
<.efine all the terms necessary to properly interpret the ! # including acronyms and abbreviations. 8ou may wish to build a separate glossary that spans multiple pro0ects or the entire organi7ation# and 0ust include terms specific to a single pro0ect in each ! . T- .-/ "lease provide a list of all abbreviations and acronyms used in this document sorted in alphabetical order.>
..4 *ocument $on+entions
<In general this document follows the I$$$ formatting re%uirements. 9se :rial font si7e 22# or 24 throughout the document for text. 9se italics for comments. .ocument text should be single spaced and maintain the 2 margins found in this template. ,or ection and ubsection titles please follow the template. T- .-/ .escribe any standards or typographical conventions that were followed when writing this ! # such as fonts or highlighting that have special significance. ometimes# it is useful to divide this section to several sections# e.g.# ,ormatting ;onventions# <aming ;onventions# etc.>
Software Requirements Specification for <Project>
Page 2
..5 References and )c6now"ed(ments
<=ist any other documents or 1eb addresses to which this ! refers. These may include user interface style guides# contracts# standards# system re%uirements specifications# use case documents# or a vision and scope document. T- .-/ 9se the standard I$$$ citation guide for this section. :n example citation guide is posted for you on the website.>
Software Requirements Specification for <Project>
Page 3
/ 1+era"" *escription
/.. Product Perspecti+e
<.escribe the context and origin of the product being specified in this ! . ,or example# state whether this product is a follow3on member of a product family# a replacement for certain existing systems# or a new# self3contained product. If the ! defines a component of a larger system# relate the re%uirements of the larger system to the functionality of this software and identify interfaces between the two. In this part# make sure to include a simple diagram that shows the ma0or components of the overall system# subsystem interconnections# and external interface . In this section it is crucial that you will be creative and provide as much information as possible. T- .-/ "rovide at least one paragraph describing product perspective. "rovide a general diagram that will illustrate how your product interacts with the environment and in what context it is being used.>
/./ Product 7unctiona"ity
< ummari7e the ma0or functions the product must perform or must let the user perform. .etails will be provided in ection &# so only a high level summary is needed here. -rgani7e the functions to make them understandable to any reader of the ! . : picture of the ma0or groups of related re%uirements and how they relate# such as a top level data flow diagram or ob0ect class diagram# will be effective. T- .-/ 2. "rovide a bulleted list of all the ma0or functions of the system 4. (Optional) "rovide a .ata ,low .iagram of the system to show how these functions relate to each other.>
/.0 8sers and $%aracteristics
<Identify the various users that you anticipate will use this product. 9sers may be differentiated based on fre%uency of use# subset of product functions used# technical expertise# security or privilege levels# educational level# or experience. T- .-/ 2. .escribe the pertinent characteristics of each user. ;ertain re%uirements may pertain only to certain users. &. .istinguish the most important users for this product from those who are less important to satisfy.>
/.2 1peratin( 9n+ironment
<.escribe the environment in which the software will operate# including the hardware platform# operating system and versions# and any other software components or applications with which it must peacefully coexist. In this part# make sure to include a simple diagram that shows the ma0or components of the overall system# subsystem interconnections# and external interface T- .-/ :s stated above# in at least one paragraph# describe the environment your system will have to operate in. +ake sure to include the minimum platform re%uirements for your system. >
Software Requirements Specification for <Project>
Page 4
/.4 *esi(n and #mp"ementation $onstraints
<.escribe any items or issues that will limit the options available to the developers. These might include/ hardware limitations 5timing re%uirements# memory re%uirements6> interfaces to other applications> specific technologies# tools# and databases to be used> parallel operations> language re%uirements> communications protocols> security considerations> design conventions or programming standards 5for example# if the customer?s organi7ation will be responsible for maintaining the delivered software6. T- .-/ In this section you need to consider all of the information you gathered so far# analy7e it and correctly identify at least @ constraints.>
/.5 8ser *ocumentation
<=ist the user documentation components 5such as user manuals# on3line help# and tutorials6 that will be delivered along with the software. Identify any known user documentation delivery formats or standards. T- .-/ 8ou will not actually develop any user3manuals# but you need to describe what kind of manuals and what kind of help is needed for the software you will be developing. -ne paragraph should be sufficient for this section.>
/.: )ssumptions and *ependencies
<=ist any assumed factors 5as opposed to known facts6 that could affect the re%uirements stated in the ! . These could include third3party or commercial components that you plan to use# issues around the development or operating environment# or constraints. The pro0ect could be affected if these assumptions are incorrect# are not shared# or change. :lso identify any dependencies the pro0ect has on external factors# such as software components that you intend to reuse from another pro0ect. T- .-/ "rovide a short list of some ma0or assumptions that might significantly affect your design. ,or example# you can assume that your client will have 2# 4 or at most @( :utomated Aanking +achines. $very number has a significant effect on the design of your system. >
Software Requirements Specification for <Project>
Page 5
0 Specific Requirements
0.. 9;terna" #nterface Requirements
0.... 8ser #nterfaces
<.escribe the logical characteristics of each interface between the software product and the users. This may include sample screen images# any B9I standards or product family style guides that are to be followed# screen layout constraints# standard buttons and functions 5e.g.# ;ancel6 that will appear on every screen# error message display standards# and so on. .efine the software components for which a user interface is needed. T- .-/ The least you can do for this section is to describe in words the different 9ser Interfaces and the different screens that will be available to the user. Those who will be able to provide optional Braphical 9ser Interface screenshots# will be rewarded by extra marks.>
0.../ <ardware #nterfaces
<.escribe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types# the nature of the data and control interactions between the software and the hardware. 8ou are not re%uired to specify what protocols you will be using to communicate with the hardware# but it will be usually included in this part as well. T- .-/ "lease provide a short description of the different hardware interfaces. If you will be using some special libraries to communicate with your software mention them here. In case you have more than one hardware interface divide this section into subsections.>
0...0 Software #nterfaces
<.escribe the connections between this product and other specific software components 5name and version6# including databases# operating systems 51indowsC =inuxC $tcD6# tools# libraries# and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. .escribe the services needed and the nature of communications. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way 5for example# use of a global data area in a multitasking operating system6# specify this as an implementation constraint. T- .-/ The previous part illustrates some of the information you would usually include in this part of the ! document. To make things simpler# you are only re%uired to describe the specific interface with the operating system.>
0...2 $ommunications #nterfaces
<.escribe the re%uirements associated with any communications functions re%uired by this product# including e3mail# web browser# network server communications protocols# electronic forms# and so on. .efine any pertinent message formatting. Identify any communication standards that will be used# such as ,T" or ETT". pecify any communication security or encryption issues# data transfer rates# and synchroni7ation mechanisms. T- .-/ .o not go into too much detail# but provide 234 paragraphs were you will outline the ma0or communication standards. ,or example# if you decide to use encryption there is no need to
Software Requirements Specification for <Project>
Page 6
specify the exact encryption standards# but rather# specify the fact that the data will be encrypted and name what standards you consider using. >
0./ 7unctiona" Requirements
< ,unctional re%uirements capture the intended behavior of the system. This behavior may be
expressed as services# tasks or functions the system is re%uired to perform. This section is the direct continuation of section 4.4 where you have specified the general functional re%uirements. Eere# you should list in detail the different product functions with specific explanations regarding every function. T- .-/ Arake the functional re%uirements to several functional areas and divide this section into subsections accordingly. "rovide a detailed list of all product operations related to these functional areas.
0.0 =e%a+iour Requirements
0.0.. 8se $ase View
<: use case defines a goal3oriented set of interactions between external actors and the system under consideration. ince sometimes we will not be able to specify completely the behaviour of the system by 0ust tate .iagrams# we use use3cases to complete what we have already started in section &.&.2. T- .-/ "rovide a use case diagram which will encapsulate the entire system and all possible actors. .o not include detailed use case descriptions 5these will be needed when you will be working on the Test "lan6# but make sure to include a short description of what every use3case is# who are the actors in your diagram. ,or more information please refer to your 9+= guide and the +iniThermostat ! example file.>
Software Requirements Specification for <Project>
Page 7
2 1t%er Non!functiona" Requirements
2.. Performance Requirements
<If there are performance re%uirements for the product under various circumstances# state them here and explain their rationale# to help the developers understand the intent and make suitable design choices. pecify the timing relationships for real time systems. +ake such re%uirements as specific as possible. 8ou may need to state performance re%uirements for individual functional re%uirements or features. T-.-/ "rovide at least @ different performance re%uirements based on the information you collected from the client. ,or example you can say 2. :ny transaction will not take more than 2( seconds# etcD>
2./ Safety and Security Requirements
< pecify those re%uirements that are concerned with possible loss# damage# or harm that could result from the use of the product. .efine any safeguards or actions that must be taken# as well as actions that must be prevented. !efer to any external policies or regulations that state safety issues that affect the product?s design or use. .efine any safety certifications that must be satisfied. pecify any re%uirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. .efine any user identity authentication re%uirements. T-.-/ "rovide at least & different safety re%uirements based on your interview with the client or# on your :A+ related research# and again you need to be creative here. .escribe briefly what level of security is expected from this product by your client and provide a bulleted 5or numbered6 list of the ma0or security re%uirements.>
2.0 Software >ua"ity )ttributes
< pecify any additional %uality characteristics for the product that will be important to either the customers or the developers. ome to consider are/ adaptability# availability# correctness# flexibility# interoperability# maintainability# portability# reliability# reusability# robustness# testability# and usability. 1rite these to be specific# %uantitative# and verifiable when possible. :t the least# clarify the relative preferences for various attributes# such as ease of use over ease of learning. T-.-/ 9se subsections 5e.g.# ).&.2 !eliability# ).&.4 "ortability# etcD6 provide re%uirements related to the different software %uality attributes. Aase the information you include in these subsections on the material you have learned in the class. +ake sure# that you do not 0ust write This software shall be maintainableD Indicate how you plan to achieve it# F etcD.o not forget to include such attributes as the design for change. "lease note that you need to include at least 4 %uality attributes# but it is the mere minimum and it will not receive the full marks.>
Software Requirements Specification for <Project>
Page 8
4 1t%er Requirements
<This section is Optional. .efine any other re%uirements not covered elsewhere in the ! . This might include database re%uirements# internationali7ation re%uirements# legal re%uirements# reuse ob0ectives for the pro0ect# and so on. :dd any new sections that are pertinent to the pro0ect.>
Software Requirements Specification for <Project>
Page 9
)ppendi; ) ? *ata *ictionary
<.ata dictionary is used to track all the different variables# states and functional re%uirements that you described in your document. +ake sure to include the complete list of all constants# state variables 5and their possible states6# inputs and outputs in a table. In the table# include the description of these items as well as all related operations and re%uirements.>
Software Requirements Specification for <Project>
Page 10
)ppendi; = ! Group &o(
<"lease include here all the minutes from your group meetings# your group activities# and any other relevant information that will assist the Teaching :ssistant to determine the effort put forth to produce this document>
