Unless otherwise specified, each section should be written in prose format, i.e. descriptive sentences organized into paragraphs.
What is the overall scope and goal of the System under Development (SuD)? One paragraph should suffice. Summarize what this software will do, under what constraints.
Provide a one to two page textual description of your SuD. Elaborate more fully on the functional and non-functional requirements summarized in your opening paragraph.
This should be terms from the domain of the SuD. This will help both the developers on your project team who may not have much initial knowledge of the domain of application, as well as serve as a validation check for the users that you have a sufficient understanding of the domain. List all terms in alphabetical order, and typographically distinguish the terms from their definitions (e.g. use tabular format or italics for the term and regular font for the definition). Also, make each term an internal anchor (using the <a name="sampleName"> tag), and hyperlink to this tag from the other parts of your SRS/SDS that use this term.
Make sure to include any interaction with human secondary actors, or with system actors -- generally servers of some sort, such as database, web, or file servers. The following use case template was adapted from Writing Effective Use Cases, by Alistair Cockburn (pronounced "Coburn"), Addison-Wesley, 2001, ISBN 0-201-70225-8. Bold-face headings should appear in your use cases. Replace bracketed commentary with your text satisfying the description inside the brackets.
Use case name: <the name should be the precision
level 1 description from above>
Context of use: <a longer statement of the goal,
if needed, its normal occurence conditions>
Software product name:
Primary Actor: <a role name for the primary actor
or description>
Precondition: <what should be true of the system
state prior to entry into the use case (may be left blank if no
precondition)>
Trigger: <what starts the use case (may be left
blank if the first step of the use case is the trigger)>
Main Success Scenario: <put here the steps of the
scenario from trigger to goal delivery and any cleanup after. Action
descriptions are of the form "Actor ... action verb ... direct object
... prepositional phrase" >
<step #> <action description>
<step #> <action description>
Extensions: <put here the extensions, one at a
time, each referring to the step of the main scenario>
<step altered> <condition>: <action or sub use case>
<step altered> <condition>: <action or sub use case>
Please see the use case guidelines taken from Cockburn's book for help in completing the use cases.
You should provide detailed information about each input and output that is passed between the user and the system, or between the system and some external system. In database parlance this is sometimes referred to as the metadata.The following is an example.
Data Object Field List or Data Description Field Details and checks Customer Info FirstName
LastName
SSN15 character string
30 character string
10 digit stringOther Users Names of other people authorized to use this account set of 30 character strings
can be empty, but not to exceed 4 namesReturn Date Date video returned dd/mm/yyyy The column labelled "Data Object" refers to objects explicitly mentioned in your use cases, using the same terminology as in your use cases.
If your input is from one or more files then provide detailed information about the legal format of the input file(s) and the syntax checks that you will make on the input file(s). If output is to a file, indicate precisely what data will be output in what format.
Include a text description of any additional functional requirements that none of your use cases or other parts of this document captured, if any.
State any performance guarantees that your program will provide. Performance is generally expressed in terms of response time, or the amount of time between when a user requests a system operation and when the operation completes, and throughput, or the rate at which tasks are completed (i.e. the number of tasks completed for each unit of time). Do not make any guarantees that you are not prepared to meet. That is, it is better to leave this section blank than to make promises you might not meet.
State who has access via what physical and technical means (e.g. 24 hour access when on-site). State any security requirements.
Enumerate all of the users of the system, their assumed capabilities with respect to the domain of application and the computer interactions, and any training that will be required. You should provide as much precision as possible for this, e.g. stating "some basic computer knowledge" provides virtually no information, whereas "must know how to use an Internet browser, such as Netscape Navigator" provides quite specific information. Make sure to include any information that is assumed that the user will have about the domain of application (e.g. "the user is assumed to know the rules for the game of chess"). Further, state any constraints on usability that are part of the requirements, e.g. users might be sight-impaired, or input might only be available via a touch-screen, etc..
Any other requirements that don't seem to fit in the other sections.
Adapted from: