├── README.md ├── appendixes ├── analysis-models.md ├── glossary.md └── to-be-determined-list.md ├── external-interface-requirements.md ├── introduction.md ├── other-non-functional-requirements.md ├── other-requirements.md ├── overall-description.md └── system-features.md /README.md: -------------------------------------------------------------------------------- 1 | Software Requirements Specification for *PROJECT NAME* 2 | ====================================================== 3 | 4 | Version *NUMBER* *STATUS* 5 | 6 | Prepared by *AUTHOR* 7 | 8 | *ORGANIZATION* 9 | 10 | *DATE* 11 | 12 | Table of Contents 13 | ----------------- 14 | 15 | 1. [Introduction](introduction.md) 16 | 2. [Overall Description](overall-description.md) 17 | 3. [External Interface Requirements](external-interface-requirements.md) 18 | 4. [System Features](system-features.md) 19 | 5. [Other Non-Functional Requirements](other-non-functional-Requirements.md) 20 | 6. [Other Requirements](other-requirements.md) 21 | 7. [Appendix A: Glossary](appendixes/glossary.md) 22 | 8. [Appendix B: Analysis Models](appendixes/analysis-models.md) 23 | 9. [Appendix C: To Be Determined List](appendixes/to-be-determined-list.md) 24 | -------------------------------------------------------------------------------- /appendixes/analysis-models.md: -------------------------------------------------------------------------------- 1 | Appendix B: Analysis Models 2 | =========================== 3 | 4 | *Optionally, include any pertinent analysis models, such as data flow 5 | diagrams, class diagrams, state-transition diagrams, or entity-relationship 6 | diagrams.* 7 | -------------------------------------------------------------------------------- /appendixes/glossary.md: -------------------------------------------------------------------------------- 1 | Appendix A: Glossary 2 | ==================== 3 | 4 | *Define all the terms necessary to properly interpret the SRS, including 5 | acronyms and abbreviations. You may wish to build a separate glossary 6 | that spans multiple projects or the entire organization, and just include 7 | terms specific to a single project in each SRS.* 8 | 9 | -------------------------------------------------------------------------------- /appendixes/to-be-determined-list.md: -------------------------------------------------------------------------------- 1 | Appendix C: To Be Determined List 2 | ================================= 3 | 4 | *Collect a numbered list of the TBD (to be determined) references 5 | that remain in the SRS so they can be tracked to closure.* 6 | -------------------------------------------------------------------------------- /external-interface-requirements.md: -------------------------------------------------------------------------------- 1 | External Interface Requirements 2 | =============================== 3 | 4 | User Interfaces 5 | --------------- 6 | *Describe the logical characteristics of each interface between the software 7 | product and the users. This may include sample screen images, any GUI standards 8 | or product family style guides that are to be followed, screen layout constraints, 9 | standard buttons and functions (e.g., help) that will appear on every screen, 10 | keyboard shortcuts, error message display standards, and so on. Define the 11 | software components for which a user interface is needed. Details of the user 12 | interface design should be documented in a separate user interface specification.* 13 | 14 | Hardware Interfaces 15 | ------------------- 16 | *Describe the logical and physical characteristics of each interface between the 17 | software product and the hardware components of the system. This may include the 18 | supported device types, the nature of the data and control interactions between 19 | the software and the hardware, and communication protocols to be used.* 20 | 21 | Software Interfaces 22 | ------------------- 23 | *Describe the connections between this product and other specific software 24 | components (name and version), including databases, operating systems, tools, 25 | libraries, and integrated commercial components. Identify the data items or 26 | messages coming into the system and going out and describe the purpose of each. 27 | Describe the services needed and the nature of communications. Refer to documents 28 | that describe detailed application programming interface protocols. Identify data 29 | that will be shared across software components. If the data sharing mechanism must 30 | be implemented in a specific way (for example, use of a global data area in a 31 | multitasking operating system), specify this as an implementation constraint.* 32 | 33 | Communications Interfaces 34 | ------------------------- 35 | *Describe the requirements associated with any communications functions required 36 | by this product, including e-mail, web browser, network server communications 37 | protocols, electronic forms, and so on. Define any pertinent message formatting. 38 | Identify any communication standards that will be used, such as FTP or HTTP. 39 | Specify any communication security or encryption issues, data transfer rates, 40 | and synchronization mechanisms.* 41 | -------------------------------------------------------------------------------- /introduction.md: -------------------------------------------------------------------------------- 1 | Introduction 2 | ============ 3 | 4 | Purpose 5 | ------- 6 | *Identify the product whose software requirements are specified in this document, 7 | including the revision or release number. Describe the scope of the product that is 8 | covered by this SRS, particularly if this SRS describes only part of the system or 9 | a single subsystem.* 10 | 11 | Document Conventions 12 | -------------------- 13 | *Describe any standards or typographical conventions that were followed when writing 14 | this SRS, such as fonts or highlighting that have special significance. For example, 15 | state whether priorities for higher-level requirements are assumed to be inherited 16 | by detailed requirements, or whether every requirement statement is to have its own 17 | priority.* 18 | 19 | Intended Audience and Reading Suggestions 20 | ----------------------------------------- 21 | *Describe the different types of reader that the document is intended for, such as 22 | developers, project managers, marketing staff, users, testers, and documentation 23 | writers. Describe what the rest of this SRS contains and how it is organized. Suggest 24 | a sequence for reading the document, beginning with the overview sections and 25 | proceeding through the sections that are most pertinent to each reader type.* 26 | 27 | Product Scope 28 | ------------- 29 | *Provide a short description of the software being specified and its purpose, 30 | including relevant benefits, objectives, and goals. Relate the software to corporate 31 | goals or business strategies. If a separate vision and scope document is available, 32 | refer to it rather than duplicating its contents here.* 33 | 34 | References 35 | ---------- 36 | *List any other documents or Web addresses to which this SRS refers. These may 37 | include user interface style guides, contracts, standards, system requirements 38 | specifications, use case documents, or a vision and scope document. Provide enough 39 | information so that the reader could access a copy of each reference, including title, 40 | author, version number, date, and source or location.* 41 | -------------------------------------------------------------------------------- /other-non-functional-requirements.md: -------------------------------------------------------------------------------- 1 | Other Non-Functional Requirements 2 | ================================ 3 | 4 | Performance Requirements 5 | ------------------------ 6 | 7 | *If there are performance requirements for the product under various circumstances, 8 | state them here and explain their rationale, to help the developers understand the 9 | intent and make suitable design choices. Specify the timing relationships for real 10 | time systems. Make such requirements as specific as possible. You may need to state 11 | performance requirements for individual functional requirements or features.* 12 | 13 | Safety Requirements 14 | ------------------- 15 | 16 | *Specify those requirements that are concerned with possible loss, damage, or harm 17 | that could result from the use of the product. Define any safeguards or actions that 18 | must be taken, as well as actions that must be prevented. Refer to any external 19 | policies or regulations that state safety issues that affect the product’s design or 20 | use. Define any safety certifications that must be satisfied.* 21 | 22 | Security Requirements 23 | --------------------- 24 | 25 | *Specify any requirements regarding security or privacy issues surrounding use of 26 | the product or protection of the data used or created by the product. Define any user 27 | identity authentication requirements. Refer to any external policies or regulations 28 | containing security issues that affect the product. Define any security or privacy 29 | certifications that must be satisfied.* 30 | 31 | Software Quality Attributes 32 | --------------------------- 33 | 34 | *Specify any additional quality characteristics for the product that will be important 35 | to either the customers or the developers. Some to consider are: adaptability, 36 | availability, correctness, flexibility, interoperability, maintainability, portability, 37 | reliability, reusability, robustness, testability, and usability. Write these to be 38 | specific, quantitative, and verifiable when possible. At the least, clarify the 39 | relative preferences for various attributes, such as ease of use over ease of learning.* 40 | 41 | Business Rules 42 | -------------- 43 | 44 | *List any operating principles about the product, such as which individuals or roles 45 | can perform which functions under specific circumstances. These are not functional 46 | requirements in themselves, but they may imply certain functional requirements to 47 | enforce the rules.* 48 | -------------------------------------------------------------------------------- /other-requirements.md: -------------------------------------------------------------------------------- 1 | Other Requirements 2 | ================== 3 | 4 | *Define any other requirements not covered elsewhere in the SRS. This 5 | might include database requirements, internationalization requirements, 6 | legal requirements, reuse objectives for the project, and so on. Add 7 | any new sections that are pertinent to the project.* 8 | -------------------------------------------------------------------------------- /overall-description.md: -------------------------------------------------------------------------------- 1 | Overall Description 2 | =================== 3 | 4 | Product Perspective 5 | ------------------- 6 | *Describe the context and origin of the product being specified in this SRS. 7 | For example, state whether this product is a follow-on member of a product 8 | family, a replacement for certain existing systems, or a new, self-contained 9 | product. If the SRS defines a component of a larger system, relate the requirements 10 | of the larger system to the functionality of this software and identify interfaces 11 | between the two. A simple diagram that shows the major components of the overall 12 | system, subsystem interconnections, and external interfaces can be helpful.* 13 | 14 | Product Functions 15 | ----------------- 16 | *Summarize the major functions the product must perform or must let the user perform. 17 | Details will be provided in Section 3, so only a high level summary (such as a bullet 18 | list) is needed here. Organize the functions to make them understandable to any 19 | reader of the SRS. A picture of the major groups of related requirements and how they 20 | relate, such as a top level data flow diagram or object class diagram, is often 21 | effective.* 22 | 23 | User Classes and Characteristics 24 | -------------------------------- 25 | *Identify the various user classes that you anticipate will use this product. User 26 | classes may be differentiated based on frequency of use, subset of product functions 27 | used, technical expertise, security or privilege levels, educational level, or 28 | experience. Describe the pertinent characteristics of each user class. Certain 29 | requirements may pertain only to certain user classes. Distinguish the most important 30 | user classes for this product from those who are less important to satisfy.* 31 | 32 | Operating Environment 33 | --------------------- 34 | *Describe the environment in which the software will operate, including the hardware 35 | platform, operating system and versions, and any other software components or 36 | applications with which it must peacefully coexist.* 37 | 38 | Design and Implementation Constraints 39 | ------------------------------------- 40 | *Describe any items or issues that will limit the options available to the developers. 41 | These might include: corporate or regulatory policies; hardware limitations (timing 42 | requirements, memory requirements); interfaces to other applications; specific 43 | technologies, tools, and databases to be used; parallel operations; language 44 | requirements; communications protocols; security considerations; design conventions 45 | or programming standards (for example, if the customer’s organization will be 46 | responsible for maintaining the delivered software).* 47 | 48 | User Documentation 49 | ------------------ 50 | *List the user documentation components (such as user manuals, on-line help, and 51 | tutorials) that will be delivered along with the software. Identify any known user 52 | documentation delivery formats or standards.* 53 | 54 | Assumptions and Dependencies 55 | ---------------------------- 56 | *List any assumed factors (as opposed to known facts) that could affect the 57 | requirements stated in the SRS. These could include third-party or commercial 58 | components that you plan to use, issues around the development or operating 59 | environment, or constraints. The project could be affected if these assumptions 60 | are incorrect, are not shared, or change. Also identify any dependencies the 61 | project has on external factors, such as software components that you intend to 62 | reuse from another project, unless they are already documented elsewhere (for 63 | example, in the vision and scope document or the project plan).* 64 | -------------------------------------------------------------------------------- /system-features.md: -------------------------------------------------------------------------------- 1 | System Features 2 | =============== 3 | *This template illustrates organizing the functional requirements 4 | for the product by system features, the major services provided by 5 | the product. You may prefer to organize this section by use case, 6 | mode of operation, user class, object class, functional hierarchy, 7 | or combinations of these, whatever makes the most logical sense for 8 | your product.* 9 | 10 | System Feature 1 11 | ---------------- 12 | *Don't really say "System Feature 1." State the feature name in just 13 | a few words.* 14 | 15 | ### Description and Priority 16 | *Provide a short description of the feature and indicate whether it is 17 | of High, Medium, or Low priority. You could also include specific priority 18 | component ratings, such as benefit, penalty, cost, and risk (each rated on 19 | a relative scale from a low of 1 to a high of 9).* 20 | 21 | ### Stimulus/Response Sequences 22 | *List the sequences of user actions and system responses that stimulate the 23 | behavior defined for this feature. These will correspond to the dialog 24 | elements associated with use cases.* 25 | 26 | ### Functional Requirements 27 | *Itemize the detailed functional requirements associated with this feature. 28 | These are the software capabilities that must be present in order for the 29 | user to carry out the services provided by the feature, or to execute the 30 | use case. Include how the product should respond to anticipated error 31 | conditions or invalid inputs. Requirements should be concise, complete, 32 | unambiguous, verifiable, and necessary. Use "TBD" as a placeholder to 33 | indicate when necessary information is not yet available.* 34 | 35 | *Each requirement should be uniquely identified with a sequence number or a 36 | meaningful tag of some kind.* 37 | 38 | #### REQ-1 39 | 40 | #### REQ-2 41 | 42 | System Feature 2 (and so on) 43 | ---------------------------- 44 | --------------------------------------------------------------------------------