Software Requriment Specification

1. Purpose. This document specifies the requirements for a system and the methods to be used to ensure that each requirement has been met.
2. Scope. This paragraph describes the scope of requirements covered by this document. It shall depict the context of the covered requirements with respect to other related and interfacing systems to illustrate what requirements are not covered herein.
3. Documentation Conventions. This section provides a list of notational and other document conventions used within the document. Include a depiction of symbology used in diagrams along with the meaning of each symbol. Provide a description of special text usage such as fixed width fonts, alert, and warning icons.
4. System Identification and Overview. This paragraph shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; and identify current and planned operating and user sites.

5. Required States and Modes.:-a) If the system is required to operate in more than one state or mode having requirements distinct from other states or modes, this paragraph shall identify and define each state and mode.
b) Examples of states and modes include: idle, ready, active, post-use analysis, training, degraded, emergency, back up, wartime, peacetime.
c) The distinction between states and modes is arbitrary.
d) A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful.
e) If no states or modes are required, this paragraph shall so state, without the need to create artificial distinctions.
f)If states and/or modes are required, each requirement or group of requirements in this specification shall be correlated to the states and modes.

6. Requirements
6.1.Functional and Performance. a)This paragraph shall be divided into subparagraphs to itemize the requirements associated with each capability of the system.
b) A "capability" is defined as a group of related requirements. The word "capability" may be replaced with "function," "subject," "object," or other term useful for presenting the requirements.
c)This paragraph shall identify a required system capability and shall itemize and uniquely identify the requirements associated with the capability.
d) If the capability can be more clearly specified by dividing it into constituent capabilities, the constituent capabilities shall be specified in subparagraphs.
e) The requirements shall specify required behavior of the system and shall include applicable parameters, such as response times, throughput times, other timing constraints, sequencing, accuracy, capacities (how much/how many), priorities, continuous operation requirements, and allowable deviations based on operating conditions.
f) The requirements shall include, as applicable, required behavior under unexpected, unallowed, or "out of bounds" conditions; user roles responsible for performing functions; requirements for error handling; and any provisions to be incorporated into the system to provide continuity of operations in the event of emergencies.

6.2. Organizational. This paragraph shall specify organizations, locations, roles and other user attributes and the functional requirements that each must execute.

6.3. Security and Privacy Protection.a) This paragraph shall specify the system requirements, if any, concerned with maintaining security and privacy.
b)These requirements shall include, as applicable, the security/privacy environment in which the system must operate, the type and degree of security or privacy to be provided, the security/privacy risks the system must withstand, required safeguards to reduce those risks, the security/privacy policy that must be met, the security/privacy accountability the system must provide, access instructions for user roles, and the criteria that must be met for security/privacy certification/accreditation.

6.4. Human-Factors Engineering (Ergonomics). a)This paragraph shall specify the system requirements, if any, included to accommodate the number, skill levels, duty cycles, training needs, or other information about the personnel who will use or support the system.
b) Examples include requirements for number of simultaneous users and for built-in help or training features.
c) Also included shall be the human factors engineering requirements, if any, imposed on the system.
d) These requirements shall include, as applicable, considerations for the capabilities and limitations of humans; foreseeable human errors under both normal and extreme conditions; and specific areas where the effects of human error would be particularly serious.
e) Examples include requirements for color and duration of error messages, physical placement of critical indicators or keys, and use of auditory signals.

6.5. Operations and Maintenance. This paragraph shall state requirements associated with operations and maintenance such as system availability, backup and recovery, monitoring and tuning, installation and configuration, auditing, batch scheduling, support, enhancement, and defect repairs.

6.6. System External Interface. a)This paragraph shall identify the required external interfaces of the system (that is, relationships with other systems that involve sharing, providing or exchanging data).
b) The identification of each interface shall include an application-unique identifier and shall designate the interfacing systems by name, number, version, and documentation references, as applicable.
c) The identification shall state which systems have fixed interface characteristics (and therefore impose interface requirements on interfacing systems) and which are being developed or modified (thus having interface requirements imposed on them).
d)One or more interface diagrams shall be provided to depict the interfaces.

6.7.Application-unique identifier of interface. a)This paragraph shall identify a system external interface by application-unique identifier, shall briefly identify the interfacing system, and shall be divided into subparagraphs as needed to state the requirements imposed on the system to achieve the interface.
b)Interface characteristics of the other systems involved in the interface shall be stated as assumptions or as "When [the system not covered] does this, the system shall..," not as requirements on the other systems.
c)This paragraph may reference other documents (such as data dictionaries, standards for communication protocols, and standards for user interfaces) in place of stating the information here.
d)The requirements shall include the following, as applicable, presented in any order suited to the requirements, and shall note any differences in these characteristics from the point of view of the interfacing system (such as different expectations about the size, frequency, or other characteristics of data elements):

More on Software Requirements Specification Document