Skip to content

SOFTWARE REQUIREMENTS SPECIFICATIONS paper (SRS)

Jump to bottom
Gooolbarg edited this page Aug 28, 2022 · 5 revisions

SRS describes:

  1. the content and qualities of a good software requirements specification (SRS) and presents several sample SRS outlines.

  2. the process of creating a product and the content of the product(product=SRS).

Considerations for producing a good SRS:

1) Nature of the SRS

The SRS writer(s) shall address are the following: a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software?

c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.?

d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations?

e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s)

2) Environment of the SRS

a) Should correctly define all of the software requirements. b) Should not describe any design or implementation details. c) Should not impose additional constraints on the software.

3) Characteristics of a good SRS

An SRS should be:

a) Correct

An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet.

b) Unambiguous

An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.

c) Complete

A complete SRS includes functionality, performance, design constraints, attributes, the definition of all terms, and external interfaces.

d) Consistent

Consistency refers to internal consistency. An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict.

e) Ranked for importance and/or stability

All of the requirements that relate to a software product are not equally important. Each requirement in the SRS should be identified to make differences clear and explicit. identifying requirements in the following manner help:

  1. Have customers give more careful consideration to each requirement, which often clarifies any hidden assumptions they may have.
  2. Have developers make correct design decisions.

rank requirements: 1) Essential. Implies that the software will not be acceptable unless these requirements are provided in an agreed manner. 2) Conditional. Implies that these are requirements that would enhance the software product, but would not make it unacceptable if they are absent. 3) Optional. Implies a class of functions that may or may not be worthwhile. This gives the supplier the opportunity to propose something that exceeds the SRS.

f) Verifiable

An SRS is verifiable if, and only if, every requirement stated therein is verifiable. In general, any ambiguous requirement is not verifiable.

g) Modifiable

An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style.

h) Traceable

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. two types of traceability: 1)Backward traceability i.e., to previous stages of development. 2) Forward traceability i.e., to all documents spawned by the SRS.

4) Joint preparation of the SRS;

The customer and the supplier should work together to produce a well-written and completely understood SRS.

5) SRS evolution;

6) Prototyping;

A prototype should be used as a way to elicit software requirements.

7) Embedding design in the SRS;

The SRS writer(s) should clearly distinguish between identifying required design constraints and projecting a specific design. The SRS should not normally specify design items such as the following: a) Partitioning the software into modules; b) Allocating functions to the modules; c) Describing the flow of information or control between modules; d) Choosing data structures

###Necessary design requirements Examples of valid design constraints are physical requirements, performance requirements, software development standards, and software quality assurance.

8) Embedding project requirements in the SRS.

Project requirements such as Cost, Delivery schedules, Reporting procedures, Software development methods, Quality assurance, Validation and verification criteria, and Acceptance procedures should not be included in the SRS.

#The parts of an SRS A good SRS includes: ##1. Introduction ###1.1 Purpose a) Delineate the purpose of the SRS; b) Specify the intended audience for the SRS.

###1.2 Scope a) Identify the software product(s) to be produced by name. b) Explain what the software product(s) will, and, if necessary, will not do; c) Describe the application of the software being specified, including relevant benefits, objectives, and goals; d) Be consistent with similar statements in higher-level specifications (e.g., the system requirements specification), if they exist.

###1.3 Definitions, acronyms, and abbreviations ###1.4 References ###1.5 Overview a) Describe what the rest of the SRS contains; b) Explain how the SRS is organized.

##2. Overall description ###2.1 Product perspective

###2.2 Product functions

###2.3 User characteristics ###2.4 Constraints ###2.5 Assumptions and dependencies ##3. Specific requirements ##Appendixes ##Index

Clone this wiki locally