<=
span
style=3D'mso-bookmark:_Toc63328106'>Managi=
ng Software
Requirements; First Edition - A Unified Approach - Appendix C – Moder=
n Software
Requirements Specification Template
This template provides an outline for a Modern Software
Requirements Specification (SRS) Package that may be used for a project usi=
ng
use-case modeling. For large systems, optional packaging is recommended at =
the
feature (or other appropriate subsystem grouping) level. For example, if fe=
ature-level
packaging is used, then this specification will include or reference all software requirements related=
to
the implementation of that feature. In some cases, an SRS Package may be
Company
Name
Division Name, if appropriate
Project
Name
Software Requirements Specification
Document Number, if appropriate
=
Ó 1999 Company Name
=
Revision History
|
Date |
Revision |
Description |
Author |
|
mm/dd/yyyy |
1.0 |
Initial Version |
Author Name |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This element is the start of t= he document body. Traditionally, this begins on page 1. The pages are numbered= in Arabic numerals. Specify the purpose of this SRS. The SRS should fully desc= ribe the external behavior of the application or subsystem identified. It also describes non-functional requirements, design constraints, and other factor necessary to provide a complete and comprehensive description of the requirements for the software.
A brief description of the sof= tware application that the SRS applies to; the feature or other subsystem groupin= g, what use-case model(s) it is associated with, and anything else that is affected or influenced by this document.
A list of project-related refe= rences or applicable documents that bear on this project.
This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the software described by this SRS may be based.
This section provides an overv= iew of the use-case model. The survey is used by various people interested in the behavior of the system, such as the customer, users, architects, use-case authors, designers, use-case designers, testers, managers, reviewers, and writers. This section lists for each use-case:
· The use case Name
· A Brief Description explaining the use case’s function and role in the system
· A list of actors for the use case. The aggregation of all these actors is further defined in the accompanying Actor Survey (see below)
· D= iagram of the Use-Case Model. A diagram of the entire use-case mod= el is included here
All of the actors mentioned in= the Use-Case Model Survey are reported here. For each actor, you should list:
· The actor’s Name
· A Brief Description of the actor
This section describes the fun= ctional requirements of the system for those requirements that are expressed in the natural language style. For many applications, this may constitute the bulk= of the SRS Package and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods, for example organization by user, or organization by subsystem may also be appropriate.
Where application development = tools (requirements tools, modeling tools, etc) are employed to capture the functionality, this section document will refer to the availability of that data and indicate the location and name of the tool which is used to capture the data.
Most non-functional requiremen= ts are typically recorded in the natural language style in this section of the specification. However, non-functional requirements may also be included wi= th a specific use case specification where applicable to that specific use case.=
This section should include all= of those requirements that affect usability. Examples:
· Specify the required training time for a nor= mal users and power users to become productive at particular operations.
· Specify measurable task times for typical ta= sks, or
· Base usability requirements of the new syste= m on other systems that the users know and like.
· Specify requirements to conform to common usability standards —e.g., IBM’s CUA standards, or the GUI standards published by Microsoft for Windows 98.
Refer to User’s Bill of R= ights in Team Skill 5 for additional guidelines.
Requirem= ents for reliability of the system should be specified here. Suggestions:
· Availability – specify % of time avail= able (xx.xx%), hours of use, maintenance access, degraded mode operations etc.
· Mean Time Between Failures (MTBF) – th= is is usually specified in hours, but it could also be specified in terms of d= ays, months, or years.
· Mean Time To Repair (MTTR) – how long = is the system allowed to be out of operation after it has failed?.
· Accuracy – specify precision (resoluti= on) and accuracy (by some known standard) that is required in the systems outpu= t.
· Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs per function-point.
· Bugs or defect rate – categorized in t= erms of minor, significant, and critical bugs: the requirement(s) must define wh= at is meant by a “critical” bug (e.g., complete loss of data, comp= lete inability to use certain parts of the functionality of the system).
The performance characteristics= of the system should be outlined in this section. Include specific response times. Where applicable, reference related use cases by name.
· Response time for a transaction(average, max= imum)
· Throughput (e.g., transactions per second)
· Capacity (e.g., the number of customers or transactions the system can accommodate)
· Degradation modes (what is the acceptable mo= de of operation when the system has been degraded in some manner)
· Resource utilization: memory, disk, communications, etc.
This section indicates any requ= irements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, mai= ntenance access, maintenance utilities.
Describes the requirements, if= any, for online user documentation, help systems, help about notices, etc.
This section should indicate a= ny design constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, class libraries, etc.
This section describes any pur= chased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.
This section defines the inter= faces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, etc, so that the softw= are can be developed and verified against the interface requirements.
Describe the user interfaces t= hat are to be implemented by the software.
This section defines any hardw= are interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc.
This section describes software interfaces to other components of the software system. These may be purchas= ed components, components reused from another application, or components being developed for subsystems outside of the scope of this SRS, but with which t= his software application must interact.
Describe any communications in= terfaces to other systems or devices such as local area networks, remote serial devi= ces, etc.
Defines any licensing enforcem= ent requirements or other usage restriction requirements that are to be exhibit= ed by the software.
This section describes any nec= essary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, or logo compliance issues for the software.
This section describes by refe= rence any applicable standards, (and the specific sections of any such standards = that apply to the system being described). For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, etc.
The index is provided to assist the reader in locating key concepts and topics that occur throughout the document.
Describe any terms that are unique to this application cont= ext and any definitions, acronyms, abbreviations or other project or company sp= ecific shorthand that is necessary for an understanding of this document and the application.
You should insert Appendices here as appropriate. Note that= the following template Appendix is provided specifically to allow you to record= use cases. Feel free to insert as many Appendices as you need.
Revision History
|
Date |
Issue |
Description |
Author |
|
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that the Revision History is provided for each us= e case included in the Appendices. The current Revision History block should be on= the first page of each Use Case Appendix.
Normally, a use case specification will not be long enough = to warrant the use of a Table of Contents for the use case. This element may be required if the use case presents unusual problems in finding portions of t= he specification.
The description should briefly convey the role and purpose = of the use case. A single paragraph should suffice for this description.
This use case starts when the actor does something. An actor always initiates use cases. The use case should describe what the actor does and what the system does in response. It should be phrased in the form of a= dialog between the actor and the system.
The use case should describe what happens inside the system= , but not how or why. If information is exchanged, be specific about what is pass= ed back and forth. For example, it is not very illuminating to say that the ac= tor enters customer information; it is better to say the actor enters the customer’s name and address. A Glossary of Terms is often useful to k= eep the complexity of the use case manageable; you may want to define things li= ke customer information there, to keep the use case from drowning in details.<= /p>
Simple alternatives may be presented within the text of the= use case. If it only takes a few sentences to describe what happens when there = is an alternative, do it directly within the flow of events section. If the alternative flows are more complex, use a separate section to describe it. = For example, an Alternative Flow describes how to describe more complex alternatives.
A picture is sometimes worth a thousand words (though there= is no substitute for clean, clear prose). If it improves clarity, feel free to pa= ste graphical depictions of user interfaces, process flows, or other figures in= to the use case to improve its clarity. If a flow chart is useful to present a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-transition diagram often clarifies the behavior of a syst= em better than pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notation, or figures that y= our audience may not understand. Remember that your purpose is to clarify, not obscure.
More complex alternatives should be described in a separate section, which is referred to in the basic flow of events section. Think of the alternative flow sections like alternative behavior – each alternative flow represents alternative behavior (many times, because of exceptions that occur in the main flow). They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the eve= nts of the main flow of events are resumed unless otherwise stated.
< An alternative sub-flow >
Alternative flows may, in turn, be broken down into sub-sec= tions if it improves clarity
There may be, and most likely will be, a number of alternat= ive flows in a use case. Keep each alternative separate to improve clarity. Usi= ng alternative flows improves the readability of the use case, as well as preventing use cases from being dec= omposed into hierarchies of use cases. Keep in mind that use cases are just tex= tual descriptions, and their main purpose is to document the behavior of a syste= m in a clear, concise and understandable way.
Special Requirement is typically a non-functional requireme= nt that is specific to a use case but is not easily or naturally specified in = the text of the use case’s event flow. Examples of special requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built, including usability, reliability, performance, or supportability requirements. Additionally, other requirements such as operating systems and environments, compatibility requirements, and design constraints should be captured in this section.
Pre-condition (of a use case) is the state of the system th= at must be present prior to a use case being performed.
Post-condition (of a use case) is a list of possible states= the system can be in immediately after a use case has finished.
Extension points of the use case.
Definition of the location of the extension point in the fl= ow of events.