Software Requirement Specification(SRS)

Introduction SRS is: Requirements specification for a software system May include a set of use cases.  Also contains non-functional requirements.

Topics IEEE 830 format explored under 5 subtopics: Scope of SRS. References made to other standards. Consideration of good SRS. Definitions of specific terms used. Essential part of SRS.

Scope of SRS SRS is recommended in important part of software development cycle as: Used in design implementation Used in Project Monitoring Used in Verification Used in Validation Used as legal documents of agreement

References List of few references for writing a SRS: IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans. IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning. IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans. IEEE Std 1028-1997, IEEE Standard for Software Reviews.

Nature of SRS: The SRS should address following issues: Functionality External Interfaces Performance Attributes Design Constraints. Should avoid: Design and implementation details Additional constraints

Characteristics of Good SRS(Contd).. Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable

Other Consideration of Good SRS Environment of the SRS. Joint preparation of the SRS. SRS evolution. Prototyping. Embedding design in the SRS. Embedding project requirements in the SRS.

Definitions contract: A legally binding document includes the technical and organizational requirements, cost, and schedule for a product.

Parts of SRS

Introduction (Section 1 of the SRS) It should contain the following subsections: a) Purpose; b) Scope; c) Definitions, acronyms, and abbreviations; d) References; e) Overview.

Overall description (Section 2 of the SRS) This section usually consists of six subsections, as follows: a) Product perspective; b) Product functions; c) User characteristics; d) Constraints; e) Assumptions and dependencies; f) Apportioning of requirements.

Product perspective (2.1 of the SRS) Describe how the software operates inside various constraints. For example, these constraints could include a) System interfaces b) User interfaces c) Hardware interfaces d) Software interfaces e) Communications interfaces f) Memory h) Site adaptation requirements

Hardware Interfaces e.g. from iTest SRS For the communication protocol the program needs these protocols to be installed: Tcp for the client to connect to the server in online mode. Storing devices(flash,optical disks etc.) for the client to take a test in offline mode.

Product functions (2.2 of the SRS) This subsection of the SRS should provide a summary of the major functions that the software will perform. e.g. from iTest SRS Sorting questions: Sort questions from A-Z or Z- A. Filter questions: Show questions based on their difficulty or flag category.

User characteristics (2.3 of the SRS) This subsection of the SRS should describe those general characteristics of the intended users of the product including educational level, experience, and technical expertise. It should not be used to state specific requirements, but rather should provide the reasons why certain specific requirements are later specified in Section 3 of the SRS.

Constraints (2.4 of the SRS) This subsection of the SRS should provide a general description of any other items that will limit the developer’s options like a) Hardware limitations (e.g., signal timing requirements); b) Interfaces to other applications; c) Control functions; d) Reliability requirements; e) Safety and security considerations.

Assumptions and dependencies (2.5 of the SRS) 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. e.g. from iTest SRS Language editor for additional translations.

Apportioning of requirements (2.6 of the SRS) This subsection of the SRS should identify requirements that may be delayed until future versions of the system.

Specific requirements (Section 3 of the SRS) This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.

External Interface This should be a detailed description of all inputs into and outputs from the software system

Functional Requirements Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed as ‘shall’ statements

Logical database requirements This should specify the logical requirements for any information that is to be placed into a database. This may include the following: a) Types of information used by various functions b) Frequency of use c) Accessing capabilities d) Data entities and their relationships e) Integrity constraints f) Data retention requirements

Design Constraints This should specify design constraints that can be imposed by other standards, hardware limitations, etc. e.g. from iTest SRS This program is created using C++ programming language and uses the Qt4 libraries for the main iTestClient and iTestServer modules. So a minimum PC having at least 64mb of RAM and CPU over 400mhz is required to run the program with good speed. Also the program uses at least 15 megabytes of hard disk space to store the program libraries.

Standard Compliance This subsection should specify the requirements derived from existing standards or regulations.

Software system attributes There are a number of attributes of software that can serve as requirements. Reliability Availability Security Maintainability Portability

Organizing the specific requirements Different classes of systems lend themselves to different organizations of requirements in Section 3 of the SRS. System mode User class Objects Features Stimulus Response Functional Hierarchy

e.g. from iTest organised by system feature

Supporting information The supporting information makes the SRS easier to use. It includes the following: Table of contents and index Appendixes.

References [1] IEEE-SRS-format-830-1998 [2] Software_Requirements_Specification-iTest