Requirements Specification Document

COVER PAGE

Table of Contents

1. Introduction 1.1 Purpose of SRS 1.2 Scope of Product 1.3 Product Overview 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the remainder of the document 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3. Specific requirements (Note that 3.1 can come after 3.2, ie. you can have 3.1 as Functional reqs. and 3.2 as External interface reqs., both are correct) 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 ABCD 3.2.1.1 Inputs 3.2.1.2 Processing 3.2.1.3 Outputs 3.2.2 XYZ 3.2.2.1 CDE 3.2.2.1.1 Inputs 3.2.2.1.2 Processing 3.2.2.1.3 Outputs 3.2.2.2 DEF 3.2.2.2.1 Inputs 3.2.2.2.2 Processing 3.2.2.2.3 Outputs 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements Requirements Specification Document

4. NOTES...... ERROR: REFERENCE SOURCE NOT FOUND

APPENDIX ...... ERROR: REFERENCE SOURCE NOT FOUND Index (optional)

Few Notes:

* SRS document’s organization - follow IEEE standard (format may vary a little), like shown above.

* “Notes” section contains revisions and any additional comments that did not fit anywhere else in the document. This section is required esp. when writing the newer versions of SRS, since you might change/add something to the 1st draft SRS.

2 Requirements Specification Document

Some More theoretical Understanding

Software Requirement Specification (SRS) is a fundamental document, which forms the foundation of software development process. SRS not only lists the requirements of a system but also has a description of its major features. These recommendations extend the IEEE standards and include diagrams to incorporate UML standards. The recommendations would form basis for providing clear visibility of the product to be developed serving as baseline for execution of a contract between client and developer.

The idea is to help and assist the software engineers and to promote a scalable structured format to ensure uniformity of concept and practice.

Typically, SRS constitutes the agreement between clients and developers regarding the contents of the software product that is going to be developed. SRS should accurately and completely represent the system requirements as it makes a huge contribution to the overall project plan.

FEATURES OF AN SRS

SRS comprise specifications for a software product, program, or set of programs that perform a certain function in a specific environment. Some integral features a typical SRS should support are:

1. Functionality What the software is supposed to do. C h a p t e r 3 S o f t w a r e R e q u o n 2. External Interfaces How the system interacts with the people using it, or with other systems that would use it, or other hardware that would invoke it.

3. Performance Speed, availability, response time, recovery time, recovery time of various software functions etc.

4. Attributes What is the portability, correctness, maintainability and security considerations etc.

5. Design Constraints Standards to be followed, resource limits, operating environments, policies for database integrity etc.

6. Non functional Requirements Non functional requirements are the business rules, software quality attributes, safety requirements, security requirements and performance parameters etc.

To ensure an error and ambiguity free SRS, it is imperative to identify all major characteristics of a good SRS. Essentially, SRS should comprehensively cover every requirement that the software has to meet. It is important to note that while writing SRS, the terminology used for a particular component should be consistent throughout the document. Every term should represent only one meaning to avoid confusion. It is recommended that language and grammar of SRS be reviewed by an expert to eliminate ambiguity.

Each requirement in SRS should be identified to clarify the difference between necessary and optional components. Clarity ensures better understanding and correct design in the later stages of development.

An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation. Nevertheless a quality SRS ensures end-to-end traceability.

It is recommended that UML notation be followed in the SRS document. It would not only preserve the universality of the concept, but would also be understandable to a diverse audience at the same time.

Software Scope Provide a short description of the software being specified and its purpose, including benefits and goals. Relate the software to corporate goals or business strategies.

Software Perspective Describe the context and origin of the product being specified in the SRS. State whether this product is the next member of a product family, the next release of a mature product, a replacement for existing applications, or a new, self-contained product. If this SRS defines a component of a larger system, state how this software relates to the overall system and identify the overall system interfaces between the two.

Document conventions and definitions List all, · Typographic conventions used in the SRS other than the ones not mentioned in the glossary of terms (if included). · Text styles, highlighting other than those specified in the glossary (if included). · Significant notations used and what they mean in the context of this document.

Intended audience and reading suggestions You may provide a description of the intended audience i.e., the personnel who will be reading this document.

References Provide all text and electronic document resources to which the SRS refers.

OVERALL DESCRIPTION

Operating environment Describe the environment in which the software will operate, including the hardware platform, operating system versions, and other software components or applications with which it must coexist.

User characteristics Provide the various user classes that you anticipate will use this product and describe their characteristics. Distinguish the most important user classes for this product from those whom it is less critical to satisfy.

Design and implementation constraints Identify any issues that will restrict the options available to the developers and describe why they are constraints. Constraints may include the following: · Specific technologies, tools, programming languages, and databases that must be used or avoided · Required development conventions or standards · Corporate policies and government rules that influence design and implementation phases. · Hardware limitations, such as timing requirement or memory specifications or constraints. · Standard data interchange formats · Transaction rate required · Local and network security · Downtime in terms of: o Existing environment o Support · Scalability in terms of hardware and performance.

Assumptions and dependencies List any assumed factors that could affect the requirements stated in the SRS. These could include commercial components that you plan to use, or issues around the development or operating environment. The project could be affected if these assumptions are incorrect, are not shared, or change. Also, identify any dependencies the project has on external factors. For example, if you expect to integrate into the system some components that are being developed by another project, you are dependent upon that project to supply the correctly operating components on schedule.

EXTERNAL INTERFACE REQUIREMENTS

This section is intended to specify any requirements that ensure that the new product will connect properly to external components. You may place a context diagram showing the external interfaces at a high level of abstraction. Place detailed descriptions of the data and control components of the interfaces in the data dictionary. If different portions of the product have

5 Requirements Specification Document different external interfaces incorporate an instance of this section within the detailed requirements for each such portion.

Note that you are not expected to go in great detail in this section and do not provide any design/implementation details. The following is explained with respect to fairly big industrial projects.

Hardware Interfaces Describe the characteristics of each interface between the software and hardware components of the system. This description might include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.

Software Interfaces Describe the connections between this product and other external software components (identified by name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify and describe the purpose of the data items or messages exchanged among the software components. Describe the services needed and the nature of the inter-component communications.

Identify data that will be shared across software components. If the data-sharing mechanism must be implemented in a specific way, such as a global data area in a multitasking operating system, specify this as an implementation constraint.

Communications Interfaces Describe the requirements associated with any communication functions the product will use, including email, web browser, network communications standards or protocols, electronic forms, and so on. Define any pertinent message formatting. Specify communication security or encryption issues, data transfer rates, and synchronization mechanisms.

NONFUNCTIONAL REQUIREMENTS

Performance Requirements State any product performance requirements for various usage scenarios, and explain their rationale to help the developers make suitable design choices. Specify the number of concurrent users or operations to be supported, response times for systems. Specify memory capacity requirements and quantify the performance requirements as specifically as possible.

Safety Requirements Specify the requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as potentially dangerous actions that must be prevented. Identify any safety certifications, policies, or regulations to which the product must conform.

Security Requirements

Specify any requirements regarding security, integrity, or privacy issues that affect the use of the product and protection of the data used or created by the product. Define all user authentication or authorization requirements, if any. Identify any security or privacy policies or certifications the product must satisfy. Software Quality Attributes Specify any additional product quality characteristics that will be important to either customers or developers. These characteristics should be specific, quantitative, and verifiable when possible. Also, indicate the relative preferences for various attributes, such as ease of use over ease of learning, or portability over efficiency.

User Documentation List the user documentation components that will be delivered along with the software, such as user manuals, online help, and tutorials. Identify any known user documentation delivery formats or standards.

TECHNOLOGY OPTIONS

This section is just for your information/understanding how detailed the industrial SRSs are. You are not expected to provide use cases or such great detail as mentioned here.

Technology options and recommendation are derivatives of the non functional requirements discussed in the software requirement specifications.

Existing system Give a description of the existing system. Define whether the new system being developed is a part of the existing system, is an add-on or an integrated component. Draw a diagram showing the detailed system architecture. If the system being developed has no relationship with the existing system, mention it clearly.

Performance Mention the average response time for the system. Show a breakup of the system into use cases and mention response time for each use case. Some use cases may require more time than others, nevertheless it should be within realistic limits.

Number of Concurrent users Mention the number of concurrent users. Show a breakup of the system into use cases and predict how many users will be using each GUI at the same time. Also, mention how many users will be accessing the system at one instant. Explicitly mention how many users can access the database concurrently.

Data volume Mention the following. Period, Total No. of tables in DB, No. of records in largest table in DB, Avg. No. of records per table, Size of DB in terms of bytes of data

Availability

Mention the permitted downtime of the system in terms of average and maximum downtime.

Usability Mention the network latency of the system. Mention if the system will be a web based system. 4. Notes

Revisions: 3.1.1.1 original ……… (like xyz was there in SRS draft 1, provide section numbering as well)

3.1.1.2.2 revised …….... (now you modified xyz to wxy, provide section numbering as well)

Or in original you can up with a concept ‘X’. Now you dropped the idea of doing so. Report that and possibly explain why you dropped that. Similar is the case for adding some requirements.