Software Requirements Specification
   

A software requirements specification (SRS) is a document that captures complete description
about how the system is expected to perform. It is usually signed off at the end of
requirements engineering phase.
     Software requirements specification (SRS) is a detailed description of a software system to be
developed with its functional and non-functional requirements.
The SRS is developed based the agreement between customer and user. It may include the
use cases of how user is going to interact with software system.
The SRS document consistent of all necessary requirements required for project
development.
To develop the software system we should have clear understanding of Software system. To
achieve this we need to continuous communication with customers to gather all
requirements.

NEEDS/IMPORTANCE OF AN SRS:

The goal of the requirement activity is to produce the software requirements specification

(SRS),that describes what the system should do without describing how the software will do it.

 

There are 3 major parties involved in developing software:

USER

 CLIENT

 DEVELOPER

Communication gap between client and developer for requirements is filled by SRS, which

have all needs of user and client.

Need of SRS are:

1. An SRS establishes the basis for agreement between the client and the supplier on what

the software product will do

 A good SRS document specifies all the features required in the final system including

technical requirements and interface requirements.

 SRS document is used by the customer to determine whether the supplier has provided

all the features in the delivered software system.

 Act as a legal contract between client (or customer) and the developer (the supplier).

 With SRS the developer clearly understands what capabilities to build in the software.

 Without SRS , once the development is over, the project will have an unhappy client

which leads to an unhappy developer.

2. A SRS provides a reference for validation of the final product

 The SRS helps the client to determine, is the software meets the requirements.

Without a proper SRS there is no way for a client to determine, if the software being

delivered is ok.

 And there is no way the developer can convince the client that all the requirements

have been fulfill.

 Client determines software being delivered is what was ordered.

 As studies shows many errors occurs during requirement phase. An SRS with error

result in error in the final system even if correct implementation of SRS done.

3. A high-quality SRS is a prerequisite to high-quality software.

 The quality of SRS has an impact on cost, schedule of the project. We can have a incredible

reduction in the project cost by reducing the errors in the SRS.

 With a high quality SRS, requirements changes that come about due to improperly

analyzed requirements should be reduced considerably.

4. A high-quality SRS reduces the development cost.

 The quality of the SRS impacts customer (and developer) satisfaction, system validation,

quality of the final software, and the software development cost.

5. Input for detailed design

 A good SRS enables experienced developers to convert the requirements directly to a

technical design.

 For example, a well defined data dictionary can be easily converted to a database

specification

6. Management of customer expectations –

 Since SRS precisely defines project scope, it ensures that customer expectations don't

change during software development. If they do, SRS can be modified and costing/pricing

can be done again on the changes required.

CHARACTERISTICS OF AN SRS:

An SRS should have certain properties and should contain different types of requirements to

satisfy the basic goals:

They are as follows:

1. Correct :

 An SRS is correct if every requirement included in the SRS represents something

required in the final system.

 Correctness ensures that which is specified is done correctly.

 Correctness is an easier property to establish than completeness as it basically involves

examining each requirement to make sure it represents the user requirements.

2. Complete:

 SRS should be absolute.

Requirements must be complete such that all the required information to implement

the requirement is included.

 SRS must precisely define the entire real world situation that will be encountered and

the capability response to them.

3. Unambiguous:

 Every requirement stated has one and only one interpretation.

 No double meaning exist.

 Must use some formal requirement specification language to avoid ambiguities.

 The disadvantage of using other language is the large effort to write SRS, High costing

and difficulty in reading and understanding.

 example: All screen must load quickly.

Here quickly doesn’t specify how quick. Better one would be

“All screen must load within 5 second”

4. Verifiable:

 An SRS is verifiable (can be proved, demonstrate) if and only if every stated

requirement is verifiable.

 A verifiable/testable requirement can be defined as a requirement, which can be tested

and validated using any of the following methods:

 Inspection

 Walkthrough

 Demonstration

 Testing

 In this manner, it is possible to ensure that the requirement has been implemented

correctly.

 To be testable, requirements should be clear, precise, and unambiguous.

 Verification of requirements is done through reviews.

 Example: :”The system must be user-friendly. “

How will you test it once the software is developed and is ready to be delivered for the

UAT. It is not testable. So a better example would be:

“The user interface should be menu driven on the top of the website along with site

index. A tool tip for all the text boxes must be provided.”

5. Consistent:

 SRS should be dependable.

 SRS capability functions and performance levels are friendly, and the required quality

 No conflicts should be existed for consistency.

 Different requirements may use different terms to refer to the same object. This

should not be happened.

 E.g. Event E occur before event F in 1 module and event F occur before event E in

another module, this is inconsistency and it should not exist in SRS.

6. Ranked for importance and /or stability:

 Generally, all the requirements for software are not of equal importance.

 Some requirements are critical (serious, important), some are important, some are

desirable (wanted) and some are core (interior, center).

 Rank important and less important requirements as all are not same. It Indicates

stability of requirements.

 Stability of a requirement reflects the chances of it changing in future.

7. Modifiable:

 Every SRS Document must be modifiable and change easily.

 In modern software project, requirement are never static and don’t stop after SRS

Document is signoff.

 SRS must have a logical structure to be modifiable.

 In case of any change, specific requirement and dependent ones can be modified

accordingly without impact to others.

8. Traceable:

 Each requirement should be clearly specified and traceable.

 Traceability facilitates the referencing of each requirement in future development.

 There are two types of traceability: forward traceability & backward trace ability.

 Forward traceability: we can design and code with requirements of SRS.

 Backward traceability: we can identify or check requirements with design and code.

 COMPONENTS OF AN SRS:

 Completeness of specifications is difficult to achieve and verify. Having guidelines

about what different things an SRS should specify will help in completely specifying

the requirements.

 Here we describe some of the system properties than an SRS should specify.

 The basic issues an SRS must address

1. Functional Requirements

2. Performance

3. Design constraint

4. External interface.

1.Functional Requirements:

 Functional requirements specify the expected behavior of the system

1. Which outputs should be produced from the given inputs?

2. Relationship between the input and output.

3. A detailed description of all the data inputs and their source, the units of measure.

4. The range of valid inputs.

5. Validity checks on input and output data.

6. It must clearly state what the system should do if any abnormal situations occur like

invalid input and error during computation.

2. Performance

 This part of an SRS specifies the performance constraint.

 There are two types of performance constraints: static and dynamic.

 Static requirements:

 Static requirements are those that do not affect the execution characteristics of

the system. This includes requirements like:

• Number of terminals to be supported.

• Number of simultaneous users to be supported.

• Number of files that can be processed and their sizes

 These are also called capacity requirements of the system.

 Dynamic requirements:

 Dynamic requirements are those that affect the execution characteristics of the

system. This includes response time & throughput time for the system.

• Response time: Expected time for the completion of an operation.

• Throughput time : Expected number of operations to be completed in a

unit time.

 Acceptable ranges for different performance parameters should be specified

 All the requirement should be stated in measurable terms.

3. Design Constraints

 There are a number of factors in the client’s environment that may restrict the

choices of a designer leading to design constraints.

1. Such factors include standards that must be followed,

2. Resource limits and operating environment

3. Reliability

4. Security requirements

5. Policies that may have an impact on the design of the system.

 An SRS should identify and specify all such constraints. Some examples of these

are:

1. Standard Compliance: Specifies the requirements for the standards the system must

follow.

 It may include report format, accounting procedures, audit tracing

requirements etc..

2. Hardware Limitations: the software operates on some predefined hardware ,this

gives restriction on the design.

 Hardware Limitations includes the type of machines to be used, operating

system available, languages supported and limits on primary and secondary

storage.

3. Reliability and Fault Tolerance: It specifies the requirements about system behavior

in case of certain faults. Recovery requirements stating what system should do if

some failure is included. It is very important for critical systems.

 Fault tolerance requirements can make the system more complex and expensive.

4. Security: It must specify the requirements that are important to make the system

safe & secure, like :

i. Place restrictions on use of some commands.

ii. Control access to some data.

iii. Different access condition for different users.

iv. Use of password.

v. Cryptography techniques and

vi. Maintenance of logs for activities.

4. External Interfaces

 It includes all the interactions of the software with people, hardware and

other software.

• User interface.

• Hardware interface

• Other interface

• User Interface: the characteristics of each user interface of the software product should be

specified

• User interface is becoming increasingly important and must be given proper attention

 Characteristics of each user interface.

o A preliminary user manual with all user commands, screen formats and

explanations

o Feedback

o Error messages

• Hardware Interface: These requirements should specify the logical characteristics of

each interface between software product and hardware components.

• If the software is to be executed on predetermined hardware (existing hardware),

• all characteristics of hardware must be given like:

o Memory restrictions.

o The current use

o Load characteristics of hardware

• Other software Interface: it should specify the requirements for interface of the

software with other software that the system will use.

• These requirements should specify the interface with the operating system and other

applications with the message content and the format of each interface.