The IEEE Guide to Software Requirements Specification (ANSI/IEEE Standard 830-1984) was used to create this template.

 

Software Requirement Specification 

for 

<Project Name> 

Version 1.0 approved 

Prepared by <author> 

<Organization> 

<Date Created> 

Table of Contents 

1. Introduction.............................................................................................................................................

1.1 Purpose...................................................................................................................................................

1.2 Scope......................................................................................................................................................

1.3 Definitions, Acronyms, and Abbreviations...............................................................................................

1.4 References.............................................................................................................................................

1.5 Overview.................................................................................................................................................

2. General Description................................................................................................................................

2.1 Product Perspectives..............................................................................................................................

2.2 User Characteristics................................................................................................................................

2.3 General Constraints................................................................................................................................

2.4 Assumptions and Dependencies............................................................................................................

3. Specific Requirements..........................................................................................................................

3.1 External Interface Requirements........................................................................................................

3.1.1 User Interfaces....................................................................................................................................

3.1.2 Hardware Interfaces............................................................................................................................

3.1.3 Software Interfaces..............................................................................................................................

3.1.4 Communications Interfaces..................................................................................................................

3.2 Functional Requirements......................................................................................................................

3.2.1 Epics/User Stories................................................................................................................................

3.2.2 Use Cases and System Level Diagrams (Use Case Diagrams, Activity Diagrams and Data Flow Diagrams) 

3.2.3 Expanded Use Case for Selected Use Cases ( including use case-level activity diagram and data flow diagram)

3.3 Non-Functional Requirements …….....................................................................................................

3.3.1 Performance.........................................................................................................................................

3.3.2 Reliability...............................................................................................................................................

3.3.3 Availability..............................................................................................................................................

3.3.4 Security..................................................................................................................................................

3.3.5 Maintainability........................................................................................................................................

3.3.6 Portability...............................................................................................................................................

3.4 Other Requirements.................................................................................................................................

4. Change Management Process...................................................................................................................

Appendices....................................................................................................................................................

A.1 Issue List.................................................................................................................................................

A.2 Team Meeting Minutes............................................................................................................................

 

1. Introduction 

An overview of the entire Software Requirement Specification (SRS) document should be included in the introduction.Please keep in mind that while you write this document, it should include all the information a software engineer needs to properly build and implement the software product that is outlined by the requirements you have included in it. (Note: most of the annotations in the ensuing subsections are derived from the IEEE Guide to SRS.)

1.1 Purpose 

What is the intended audience for this SRS, and what is its purpose?

1.2 Scope 

The following should be included in this subsection:

(1) Name the software product (s) that will be generated, such as Report Generator, Host DBMS, etc.
(2) Describe the features that the software product(s) will and won't do, if applicable.
(3) Explain how the program being supplied is used. As part of this, it should:

(a) Clearly state all pertinent advantages, goals, and objectives. Saying that one objective is to provide excellent reporting capabilities, for instance, is not as good as saying that one wants to deliver parameter-driven, user-definable reports that can be generated in two hours or less and allow for online user parameter insertion.
(b) If comparable statements are found in higher-level specifications, such as the System Requirement Specification, adhere to them. What does this software product cover?

1.3 Definitions, Acronyms, and Abbreviations 

This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents. 

1.4 References 

This subsection should:

(1) Provide a comprehensive list of all papers cited in another part of the SRS or in another document that is specifically mentioned in this paragraph.
(2) List each document's title, publishing organization, date, and report number, if appropriate.
(3) Name the sources where the references are available.
A document or an appendix may be cited in order to convey this information.

1.5 Overview 
This subsection should:
(1) Describe what the rest of the SRS contains 
(2) Explain how the SRS is organized. 

2. General Description 

This section of the SRS should describe the general factors that affect the product and its requirements. ?It should be made clear that this section does not state specific requirements; it only makes those requirements easier to understand. 

2.1 Product Perspective 

This subsection of the SRS puts the product into perspective with other related products or 
projects. ?(See the IEEE Guide to SRS for more details). 

2.2 User Characteristics 

This subsection of the SRS should describe those general characteristics of the eventual users of the product that will affect the specific requirements. ?(See the IEEE Guide to SRS for more details). 

2.3 General Constraints 

This subsection of the SRS should provide a general description of any other items that will 
limit the developer’s options for designing the system. (See the IEEE Guide to SRS for a partial list of possible general constraints). 

2.4 Assumptions and Dependencies 

This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption might be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly. 

3. Specific Requirements 

This will be the largest and most important section of the SRS. The customer requirements will be embodied within Section 2, but this section will give the requirements that are used to guide the project’s software design, implementation, and testing. 

Each requirement in this section should be: 
• Correct 
• Traceable (both forward and backward to prior or future artifacts) 
• Unambiguous 
• Verifiable (i.e., testable) 
• Prioritized (with respect to importance and/or stability) 
• Complete 
• Consistent 
• Uniquely identifiable (usually via numbering like 3.4.5.6) 

It is important to pay close attention to how the requirements listed in this section are arranged so that they are accessible and clear. Moreover, it should be avoided to overly confine (and hence design) the software project within this SRS, as this SRS is not the software design document.

3.1 External Interface Requirements 

3.1.1 User Interfaces 

Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.

3.1.2 Hardware Interfaces 

Describe the logical and physical characteristics of each interface between 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 between the software and the hardware, and the communication protocols to be used.

3.1.3 Software Interfaces 

Explain how this product is related to other software components (name and version) such as operating systems, databases, tools, libraries, and integrated commercial components. List the messages or data items entering and leaving the system, along with their respective purposes. Describe the type of communication and the services that are required. Consult the documentation for a thorough explanation of the application programming interface protocols. Determine which data will be shared by different program components. Indicate this as an implementation constraint if the data-sharing mechanism needs to be implemented in a particular way (using a global data area in an operating system that supports multitasking, for example).

3.1.4 Communications Interfaces 

Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms. 

3.2 Functional Requirements 

3.2.1 Epics/User Stories 

A list of all epics and user stories (user requirements definition) 

3.2.2 Use Cases and System Level Diagrams (Use Case Diagrams, Activity Diagrams, and Data Flow Diagrams) 

Provide a high-level overview of each use case and create the necessary use case diagram(s). Create activity and Data Flow Diagrams at the system level, depending on these particular requirements.A narrative description and an introduction ought to be included in every model.Every model should also be traceable to the SRS standards and cited if needed.

3.2.2 Expanded Use Case for Selected Epics and User Stories 

A description of the normal flow of events in the story (scenarios) and variations (system requirements specification)

1. Use case-level

2, Activity Diagram 

3. Data Flow Diagram 

3.3 Non-Functional Requirements 

There can be non-functional requirements for the following characteristics: Frequently, rather than at the unit level, these requirements must be met at the system level. Give a quantifiable explanation of the requirements in the following sections (e.g., > 30-day MTBF value, system downtime not to exceed 1 minute daily, 95% of transactions to be processed in less than a second, etc.).

3.3.1 Performance 
3.3.2 Reliability 
3.3.3 Availability 
3.3.4 Security 
3.3.5 Maintainability 
3.3.6 Portability 
…… 
3.4 Other Requirements 

Catch-all area for any further specifications. This could contain the project's reuse goals, internationalization requirements, database requirements, and legal requirements, among other things.

4. Change Management Process 

Determine and explain the procedure that has been used, or that needs to be followed, to update the SRS when the needs or scope of the project change. Who can make adjustments, how can they do so, and how will they be approved?

Appendices 
You can find extra (and hopefully useful) information in the appendices. If an appendix is included, the SRS should make it clear whether or not the data in it should be regarded as part of the SRS's overall set of requirements.

A.1 Issues List?

This is a dynamic list of the unresolved open requirements concerns, such as TBDs, decisions that are still pending, information that is required, disputes that need to be resolved, and similar difficulties.

A.2 Team meeting minutes