a guest Feb 16th, 2020 196 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  2. ## Introduction
  4. ### Purpose
  5. Identify the product whose software requirements are specified in this
  6. document, including the revision or release number. Describe the scope of the
  7. product that is covered by this SRS, particularly if this SRS describes only
  8. part of the system or a single subsystem.
  10. ### Document Conventions
  11. Describe any standards or typographical conventions that were followed when
  12. writing this SRS, such as fonts or highlighting that have special significance.  
  13. For example, state whether priorities  for higher-level requirements are assumed
  14. to be inherited by detailed requirements, or whether every requirement statement
  15. is to have its own priority.
  17. ### Intended Audience and Reading Suggestions
  18. Describe the different types of reader that the document is intended for,
  19. such as developers, project managers, marketing staff, users, testers, and
  20. documentation writers. Describe what the rest of this SRS contains and how it is
  21. organized. Suggest a sequence for reading the document, beginning with the
  22. overview sections and proceeding through the sections that are most pertinent to
  23. each reader type.
  25. ### Project Scope
  26. Provide a short description of the software being specified and its purpose,
  27. including relevant benefits, objectives, and goals. Relate the software to
  28. corporate goals or business strategies. If a separate vision and scope document
  29. is available, refer to it rather than duplicating its contents here.
  31. ### References
  32. List any other documents or Web addresses to which this SRS refers. These may
  33. include user interface style guides, contracts, standards, system requirements
  34. specifications, use case documents, or a vision and scope document. Provide
  35. enough information so that the reader could access a copy of each reference,
  36. including title, author, version number, date, and source or location.
  39. ## Overall Description
  41. ### Product Perspective
  42. Describe the context and origin of the product being specified in this SRS.  
  43. For example, state whether this product is a follow-on member of a product
  44. family, a replacement for certain existing systems, or a new, self-contained
  45. product. If the SRS defines a component of a larger system, relate the
  46. requirements of the larger system to the functionality of this software and
  47. identify interfaces between the two. A simple diagram that shows the major
  48. components of the overall system, subsystem interconnections, and external
  49. interfaces can be helpful.
  51. ### Product Functions
  52. Summarize the major functions the product must perform or must let the user
  53. perform. Details will be provided in Section 3, so only a high level summary
  54. (such as a bullet list) is needed here. Organize the functions to make them
  55. understandable to any reader of the SRS. A picture of the major groups of
  56. related requirements and how they relate, such as a top level data flow diagram
  57. or object class diagram, is often effective.
  59. ### User Classes and Characteristics
  60. Identify the various user classes that you anticipate will use this product.  
  61. User classes may be differentiated based on frequency of use, subset of product
  62. functions used, technical expertise, security or privilege levels, educational
  63. level, or experience. Describe the pertinent characteristics of each user class.  
  64. Certain requirements may pertain only to certain user classes. Distinguish the
  65. most important user classes for this product from those who are less important
  66. to satisfy.
  68. ### Operating Environment
  69. Describe the environment in which the software will operate, including the
  70. hardware platform, operating system and versions, and any other software
  71. components or applications with which it must peacefully coexist.
  73. ### Design and Implementation Constraints
  74. Describe any items or issues that will limit the options available to the
  75. developers. These might include: corporate or regulatory policies; hardware
  76. limitations (timing requirements, memory requirements); interfaces to other
  77. applications; specific technologies, tools, and databases to be used; parallel
  78. operations; language requirements; communications protocols; security
  79. considerations; design conventions or programming standards (for example, if the
  80. customer's organization will be responsible for maintaining the delivered
  81. software).
  83. ### User Documentation
  84. List the user documentation components (such as user manuals, on-line help,
  85. and tutorials) that will be delivered along with the software. Identify any
  86. known user documentation delivery formats or standards.
  87. ### Assumptions and Dependencies
  89. List any assumed factors (as opposed to known facts) that could affect the
  90. requirements stated in the SRS. These could include third-party or commercial
  91. components that you plan to use, issues around the development or operating
  92. environment, or constraints. The project could be affected if these assumptions
  93. are incorrect, are not shared, or change. Also identify any dependencies the
  94. project has on external factors, such as software components that you intend to
  95. reuse from another project, unless they are already documented elsewhere (for
  96. example, in the vision and scope document or the project plan).
  99. ## External Interface Requirements
  101. ### User Interfaces
  102. Describe the logical characteristics of each interface between the software
  103. product and the users. This may include sample screen images, any GUI standards
  104. or product family style guides that are to be followed, screen layout
  105. constraints, standard buttons and functions (e.g., help) that will appear on
  106. every screen, keyboard shortcuts, error message display standards, and so on.  
  107. Define the software components for which a user interface is needed. Details of
  108. the user interface design should be documented in a separate user interface
  109. specification.
  111. ### Hardware Interfaces
  112. Describe the logical and physical characteristics of each interface between
  113. 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
  114. between the software and the hardware, and communication protocols to be
  115. used.
  117. ### Software Interfaces
  118. Describe the connections between this product and other specific software
  119. components (name and version), including databases, operating systems, tools,
  120. libraries, and integrated commercial components. Identify the data items or
  121. messages coming into the system and going out and describe the purpose of each.  
  122. Describe the services needed and the nature of communications. Refer to
  123. documents that describe detailed application programming interface protocols.  
  124. Identify data that will be shared across software components. If the data
  125. sharing mechanism must be implemented in a specific way (for example, use of a
  126. global data area in a multitasking operating system), specify this as an
  127. implementation constraint.
  129. ### Communications Interfaces
  130. Describe the requirements associated with any communications functions
  131. required by this product, including e-mail, web browser, network server
  132. communications protocols, electronic forms, and so on. Define any pertinent
  133. message formatting. Identify any communication standards that will be used, such
  134. as FTP or HTTP. Specify any communication security or encryption issues, data
  135. transfer rates, and synchronization mechanisms.
  138. ## System Features
  139. This template illustrates organizing the functional requirements for the
  140. product by system features, the major services provided by the product. You may
  141. prefer to organize this section by use case, mode of operation, user class,
  142. object class, functional hierarchy, or combinations of these, whatever makes the
  143. most logical sense for your product.
  145. ### System Feature 1
  146. Don't really say "System Feature 1." State the feature name in just a few
  147. words.
  149. #### Description and Priority
  150. Provide a short description of the feature and indicate whether it is of
  151. High, Medium, or Low priority. You could also include specific priority
  152. component ratings, such as benefit, penalty, cost, and risk (each rated on a
  153. relative scale from a low of 1 to a high of 9).
  155. #### Stimulus/Response Sequences
  156. List the sequences of user actions and system responses that stimulate the
  157. behavior defined for this feature. These will correspond to the dialog elements
  158. associated with use cases.
  160. #### Functional Requirements
  161. Itemize the detailed functional requirements associated with this feature.  
  162. These are the software capabilities that must be present in order for the user
  163. to carry out the services provided by the feature, or to execute the use case.  
  164. Include how the product should respond to anticipated error conditions or
  165. invalid inputs. Requirements should be concise, complete, unambiguous,
  166. verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary
  167. information is not yet available.
  169. Each requirement should be uniquely identified with a sequence number or a
  170. meaningful tag of some kind.
  172. REQ-1:  REQ-2:
  174. ### System Feature 2 (and so on)
  177. ## Other Nonfunctional Requirements
  179. ### Performance Requirements
  180. If there are performance requirements for the product under various
  181. circumstances, state them here and explain their rationale, to help the
  182. developers understand the intent and make suitable design choices. Specify the
  183. timing relationships for real time systems. Make such requirements as specific
  184. as possible. You may need to state performance requirements for individual
  185. functional requirements or features.
  187. ### Safety Requirements
  188. Specify those requirements that are concerned with possible loss, damage, or
  189. harm that could result from the use of the product. Define any safeguards or
  190. actions that must be taken, as well as actions that must be prevented. Refer to
  191. any external policies or regulations that state safety issues that affect the
  192. product's design or use. Define any safety certifications that must be
  193. satisfied.
  195. ### Security Requirements
  196. Specify any requirements regarding security or privacy issues surrounding use
  197. of the product or protection of the data used or created by the product. Define
  198. any user identity authentication requirements. Refer to any external policies or
  199. regulations containing security issues that affect the product. Define any
  200. security or privacy certifications that must be satisfied.
  202. ### Software Quality Attributes
  203. Specify any additional quality characteristics for the product that will be
  204. important to either the customers or the developers. Some to consider are:
  205. adaptability, availability, correctness, flexibility, interoperability,
  206. maintainability, portability, reliability, reusability, robustness, testability,
  207. and usability. Write these to be specific, quantitative, and verifiable when
  208. possible. At the least, clarify the relative preferences for various attributes,
  209. such as ease of use over ease of learning.
  211. ### Business Rules
  212. List any operating principles about the product, such as which individuals or
  213. roles can perform which functions under specific circumstances. These are not
  214. functional requirements in themselves, but they may imply certain functional
  215. requirements to enforce the rules.
  218. ## Other Requirements
  219. Define any other requirements not covered elsewhere in the SRS. This might
  220. include database requirements, internationalization requirements, legal
  221. requirements, reuse objectives for the project, and so on. Add any new sections
  222. that are pertinent to the project.
  224. ### Appendix A: Glossary
  225. Define all the terms necessary to properly interpret the SRS, including
  226. acronyms and abbreviations. You may wish to build a separate glossary that spans
  227. multiple projects or the entire organization, and just include terms specific to
  228. a single project in each SRS.
  230. ### Appendix B: Analysis Models
  231. Optionally, include any pertinent analysis models, such as data flow
  232. diagrams, class diagrams, state-transition diagrams, or entity-relationship
  233. diagrams.
  235. ### Appendix C: To Be Determined List
  236. Collect a numbered list of the TBD (to be determined) references that remain
  237. in the SRS so they can be tracked to closure.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand