Structuring an SRS

Software Requirements Specification (SRS) is a requirements specification for a software system, in other words it is a complete description of the behavior of a system to be developed. It is includes a set of use cases that describes the interactions between system actors (System Users) with the Software system. Also SRS contains list of functional and non-functional software requirements.

This document lists all necessary requirements for application development, so it is written after a meeting or detailed communication between project manager and customer. A general structure of an SRS will be as follows:
Introduction:
This part provide an overview of the SRS document, and it should contain all information needed by a software engineer to design and implement the software product described by the requirements listed in this document.
Purpose:
What is the purpose of this SRS and the (intended) audience for which it is written.

Scope:
Here we will identify software product by its name, and explain what the software product(s) will, and, if necessary, will not do. Then we can describe the application of the software being specified. As a portion of this, it should be consistent with similar statements in higher-level specifications, and describe all relevant benefits, objectives, and goals as precisely as possible.

Definitions and Abbreviations:
Provide the definitions of all terms, 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.

References:
This subsection should provide a complete list of all documents referenced elsewhere in the SRS, or in a separate, specified document. Identify each document by title, report number, and publishing organization. And specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.

Overview:
Describe what the rest of the SRS contains and explain how it is organized.

Overall Description:
Describe the general factors that affect the product and its requirements. It should also be made clear that this section does not state specific requirements, it only makes those requirements easier to understand.

Product Perspective:
Puts the product into perspective with other related products or projects.

Product Functions:
Provide a summary of the functions that the software will perform.

User Characteristics:
Describe general characteristics of the eventual users of the product that will affect the specific requirements.

General Constraints:
Provide a general description of any other items that will limit the developer’s options for designing the system.

Assumptions and Dependecniescies:
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.

Specific Requirements:
Give the detailed requirements (D-requirements) that are used to guide the project’s software design, implementation, and testing. Each requirement in this section should be correct, unambiguous, verifiable, prioritized, complete, consistent, and uniquely identifiable. Attention should be paid to the carefully organize the requirements presented in this section so that they may easily accessed and understood. Furthermore, this SRS is not the software design document, therefore one should avoid the tendency to over-constrain (and therefore design) the software project within this SRS.

External Interface Requirements:
Include user, hardware, software, and communication interfaces.

Functional Requirements:
Describes specific features of the software project. If desired, some requirements may be specified in the use-case format and listed in the Use Cases Section.

Use Cases:
Describe all applicable use cases in the system.

Classes and Objects:Describe all classes by expressing its functions and attributes in the system.

Non-Functional Requirements:
Requirements may exist for performance, reliability, availability, security, maintainability and portability. For example (95% of transaction shall be processed in less than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc).

Design Constraints:
Specify design constrains imposed by other standards, company policies, hardware limitation, etc. that will impact this software project.

Other Requirements:
Catchall section for any additional requirements.

Analysis Models:
List all analysis models used in developing specific requirements previously given in this SRS. Each model should include an introduction and a narrative description. Furthermore, each model should be traceable the SRS’s requirements.

Sequence Diagrams:
It is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams typically are associated with use case realizations in the Logical View of the system under development.

Data Flow Diagrams:
It is a graphical representation of the “flow” of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated.

State-Transition Diagrams:
Describe the system as finite number of states.

Change Management Process:
Identify and describe the process that will be used to update the SRS, as needed, when project scope or requirements change. Who can submit changes and by what means, and how will these changes be approved.

Appendices:
Provide additional (and hopefully helpful) information. If present, the SRS should explicitly state whether the information contained within an appendix is to be considered as a part of the SRS’s overall set of requirements. Example Appendices could include (initial) conceptual documents for the software project, marketing materials, minutes of meetings with the customer(s), etc.

Thanks for referring to our Knowledgebase for information!

Add a Comment

Your email address will not be published. Required fields are marked *