You are on page 1of 5

TEMPLATE – Software Requirements Specification (SRS

This is a template (outline) for a Modern Software Requirements Specification derived from the book "Managing Software Requirements" (Leffingwell, Wildrig). You can use this page as a template or guide for creating a new SRS.

Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or subsystem identified, as well as nonfunctional requirements, design constraints, and other factors necessary to provide a complete, comprehensive description of the software requirements.

This section provides a brief description of the software application that the SRS applies to, the features or other subsystem grouping, what use-case model(s) it is associated with, and anything else that is affected or influenced by this document.

Provide a list of project-related references or applicable documents that bear on this project.

Assumptions and Dependencies
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.

Use-Case Model Survey
This section provides an overview of the use-case model. The survey is used by 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 these actors is further defined in the accompanying actor survey.

For many applications. Specify measurable task times for typical tasks. but alternative organization methods. this may constitute the bulk of the package. and thought should be given to the organization of this section. Usability This section should include all of those requirements that affect usability. such as IBM's CUA standards or the GUI standards published by Microsoft for Windows. and so on) are used to capture the functionality. by user or by subsystem. this section of the document will refer to the availability of that data and will indicate the location and name of the tool used to capture the data. Diagram of the use case model. nonfunctional requirements may also be included with a specific use case specification. . However. modeling tools. Where application development tools (requirements tools. This section is typically organized by feature. you should list:   The actor's name A brief description of the actor Requirements Functional Requirements This section describes the functional requirements of the system for those requirements that are expressed in the natural-language style. may also be appropriate. For each actor. Refer to the User's Bill of Rights for additional guidelines. base usability requirements of the new system on other systems that the users know and like. These often include:    Specify the required training time for normal users and power users to become productive at particular operations. alternatively. A diagram of the entire use-case model is included here. Nonfunctional Requirements Most nonfunctional requirements are typically recorded in natural language in this section of the specification. Actor Survey All of the actors mentioned in the use-case model survey are reported here. Specify requirements to conform to common usability standards.

Design constraints represent design decisions that have been mandated and must be adhered to.      Response time for transaction (average. Design Constraints This section should indicate any design constraints on the system being built. for online user documentation. degraded-mode operations. and so on. or years. months. Mean time to repair (MTTR): How long is the system allowed to be out of operation after it has failed? Accuracy: Specify precision (resolution) and accuracy (by some known standard) that is required in the system's output. Where applicable. if any. Performance The performance characteristics of the system should be outlined in this section. naming conventions. reference related use case by name. Examples include software languages. 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 terms of minor. Include specific response times. and so on. and maintenance utilities. The requirement(s) must define what is meant by a "critical" bug (such as complete loss of data or complete inability to use certain parts of the functionality of the system). software process requirements. class libraries. disk. maintenance access. maximum) Throughput (transactions per second) Capacity (the number of customers or transactions the system can accommodate) Degradation modes (the acceptable mode of operation when the system has been degraded) Resource utilization (memory. Online User Documentation and Help System Requirements Describes the requirements. and critical bugs.Reliability Requirements for system reliability should be specified here. help notices.       Availability: Specify percent of time available (xx. help systems. significant. communications) Supportability This section indicates any requirements that will enhance the supportability or maintainability of the system being built including coding standards. maintenance access. Mean time between failures (MTBF): This is usually specified in hours but could also be specified in terms of days.xx%). . hours of use.

These may be purchased components. purchased components. components reused from another application. and expected behavior. ports. and logical addresses. Hardware Interfaces Define any hardware interfaces that are to be supported by the software. Common Examples:     Application server software and version Database software and version J2EE Specification (typically because of app server requirements/supportability) Servlet Specification (typically because of app server requirements/supportability) Interfaces This section defines the interfaces that must be supported by the application. Licensing Requirements Define any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software. architectural and design constraints.prescribed use of development tools. protocols. User Interfaces Describe the user interfaces that are to be implemented by the software. It is good practice to provide a brief description for why each given constraint has been mandated. Software Interfaces Describe software interfaces to other components of the software system. . including logical structure. so that the software can be developed and verified against the interface requirements. physical addresses. Purchased Components This section describes any purchased components to be used with the system. Communications Interfaces Describe any communications interfaces to other systems or devices. and so on. and class libraries. and any associated compatibility/interoperability or interface standards. any applicable licensing or usage restrictions. This section should contain adequate specificity. or components being developed for subsystems outside of the scope of this SRS but with which this software application must interact. such as local area networks or remote serial devices.

Index The index is provided to assist the reader in locating key concepts and topics that occur throughout the document. For example. Glossary Describe any terms that are unique to this application context and any definitions.Legal. patent notice.  Appendix: Use Case Specifications . warranties. or other project or company-specific shorthand that is necessary for an understanding of this document and the application. copyright notices. and Other Notices Describe any necessary legal disclaimers. Copyright. trademark. Note that the following template appendix is provided specifically to allow you to record use cases. interoperability. and regulatory standards. operating system compliance. or logo compliance issues for the software. this could be legal. word mark. quality. as well as industry standards for usability. Applicable Standards Describe by reference any standards (and the specific sections of any such standards) that apply to the system being described. and so on. internationalization. Feel free to insert as many appendixes as you need. acronyms. Appendixes You should insert appendixes here as appropriate. abbreviations.


\^W_U^TWVa_W[XVWbW[\WZ``[[_S^U`WU`a^SSZVVW_YZU[Z_`^SZ`_ \a^US_WVU[\[ZWZ`_SZVUS__T^S^W_ `_Y[[V\^SU`UW`[\^[bVWST^WX VW_U^\`[ZX[^c WSUYbWZU[Z_`^SZ`S_TWWZSZVS`WV 9nf¾ .

¯½° °¾ __WU`[ZVW_U^TW_SZ \a^US_WVU[\[ZWZ`_`[TWa_WVc``W_ _`WSZ  S\\USTWUWZ_ZY[^a_SYW^W_`^U`[Z_SZVSZ S__[US`WV U[\S`T` ÈZ`W^[\W^ST` [^Z`W^XSUW_`SZVS^V_  [[Z S\W_  O \\US`[Z_W^bW^_[X`cS^WSZVbW^_[Z O S`STS_W_[X`cS^WSZVbW^_[Z O \WUXUS`[Z` \US TWUSa_W[XS\\_W^bW^ ^W]a^WWZ`_È_a\\[^`ST`  O W^bW`\WUXUS`[Z` \US TWUSa_W[XS\\_W^bW^ ^W]a^WWZ`_È_a\\[^`ST`  ° €fn ¾ __WU`[ZVWXZW_`WZ`W^XSUW_`S`a_`TW_a\\[^`WVT `WS\\US`[Z_ _WU`[Z_[aVU[Z`SZSVW]aS`W_\WUXU` \^[`[U[_\[^`_SZV[YUSSVV^W__W_ SZV_[[Z_[`S``W_[X`cS^WUSZTWVWbW[\WVSZVbW^XWVSYSZ_``WZ`W^XSUW ^W]a^WWZ`_ D¾ ° €fn ¾ W_U^TW`Wa_W^Z`W^XSUW_`S`S^W`[TW\WWZ`WVT `W_[X`cS^W f f ° €fn ¾ WXZWSZ S^VcS^WZ`W^XSUW_`S`S^W`[TW_a\\[^`WVT `W_[X`cS^WZUaVZY [YUS_`^aU`a^W\ _USSVV^W__W_SZVW \WU`WVTWSb[^ €f ° €fn ¾ W_U^TW_[X`cS^WZ`W^XSUW_`[[`W^U[\[ZWZ`_[X`W_[X`cS^W_ _`WW_W S TW\a^US_WVU[\[ZWZ`_U[\[ZWZ`_^Wa_WVX^[SZ[`W^S\\US`[Z[^ U[\[ZWZ`_TWZYVWbW[\WVX[^_aT_ _`W_[a`_VW[X`W_U[\W[X`_Ta` c`cU`__[X`cS^WS\\US`[Za_`Z`W^SU` .

¯¯°nf°¾° €fn ¾ W_U^TWSZ U[aZUS`[Z_Z`W^XSUW_`[[`W^_ _`W_[^VWbUW__aUS_[US S^WSZW`c[^_[^^W[`W_W^SVWbUW_ n °¾°–  ¯ °¾ WXZWSZ UWZ_ZYWZX[^UWWZ`^W]a^WWZ`_[^[`W^a_SYW^W_`^U`[Z ^W]a^WWZ`_`S`S^W`[TWW T`WVT `W_[X`cS^W .

 –f .

½– f°  -n ¾ W_U^TWSZ ZWUW__S^ WYSV_USW^_cS^^SZ`W_U[\ ^Y`Z[`UW_\S`WZ` Z[`UWc[^VS^`^SVWS^[^[Y[U[\SZUW__aW_X[^`W_[X`cS^W ½½nf  f° f ¾ W_U^TWT ^WXW^WZUWSZ _`SZVS^V_SZV`W_\WUXU_WU`[Z_[XSZ _aU _`SZVS^V_`S`S\\ `[`W_ _`WTWZYVW_U^TWV [^W S\W`_U[aVTW WYS]aS` SZV^WYaS`[^ _`SZVS^V_S_cWS_ZVa_`^ _`SZVS^V_X[^a_ST`  Z`W^[\W^ST` Z`W^ZS`[ZS S`[Z[\W^S`ZY_ _`WU[\SZUWSZV_[[Z °  WZVW _\^[bVWV`[S___``W^WSVW^Z[US`ZYW U[ZUW\`_SZV`[\U_`S` [UUa^`^[aY[a``WV[UaWZ` ¾¾f W_U^TWSZ `W^_`S`S^WaZ]aW`[`_S\\US`[ZU[Z`W `SZVSZ VWXZ`[Z_ SU^[Z _STT^WbS`[Z_[^[`W^\^[WU`[^U[\SZ _\WUXU_[^`SZV`S`_ ZWUW__S^ X[^SZaZVW^_`SZVZY[X`_V[UaWZ`SZV`WS\\US`[Z ½½ °  ¾ [a_[aVZ_W^`S\\WZV W_W^WS_S\\^[\^S`W [`W`S``WX[[cZY`W\S`W S\\WZV _\^[bVWV_\WUXUS `[S[c [a`[^WU[^Va_WUS_W_ WWX^WW`[Z_W^` S_SZ S\\WZV W_S_ [aZWWV  O \\WZV _WS_W\WUXUS`[Z_ .