All IT Courses 50% Off
QA Tutorials

Characteristics of Software requirement specifications

1. Correctness

2. Complete

3. Unambiguous

4. Verifiable

5. Consistent

6. Modifiable

7. Traceable

1. Correctness: This will be the genuine requirements which will be the part of SRS

2. Complete: software system will perform each and every functions as per the SRS

3. Unambiguous: which means not confusing, every requirement will be specified in the SRS which will have only one meaning.

4. Verifiable: this will do the cross verifying of the SRS which is understood by software

5. Consistent: which means stable due to the non conflicting requirement

6. Modifiable: if necessary changes can be made which doesn’t affect the consistency and also the completeness

7. Traceable: origin of the requirement should be clear that the future assist verification and also validates.

All the characteristics will be desirable and the complete one since addition or the deletion of the requirement at later stages of the software development which will be quite expensive and also the same job. This might happen due to missing of the requirement and in requirement specifications from the client side during requirement analysis activity at initial stage.

Components of SRS:

It’s difficult to arrive at the complete requirements specifications. Instead it’s better to indicate the necessary components which is good SRS to posses and a good SRS should specify all the necessary functions that the software needs to support:

1. Functionality: These are the function requirements which will specify the relationship between input and output of the system. They will verify the behaviour of the system for invalid inputs and invalid output. Functional requirements will suggest the various outputs which are being produced from the given input.

2. Performance: There will be two types of performance requirements one is static and other is dynamic.

Static requirements examples: number of terminals or number of users which are to be supported which will not impose constraints on the execution behaviour of the system.

Dynamic requirement example: response time, throughput constraints on the system.

3. Design: restrictions on implementation

Designers choices will be restricted on the various factors which will be existed in the client working environment like standard to be observed  and the limitations on the resources.

Restrictions will be identified and grouped:

1. Standard compliance

2. Hardware limitations

3. Reliable and fault tolerance

4. Security

Structure of requirement documents

The requirement document has to be prepared, which has to include the complete requirements specifications of the system developed for many of the methods and standard. The recommended structure of an SRS is as below :

General structure

1 Introduction

  1.1 purpose

  1.2 scope

  1.3 definitions, acronyms

  1.4 references

  1.5 overviews

2. Overall description

  2.1 product perspective

  2.2 product functions

  2.3 user characteristics

  2.4 general constraints

  2.5 assumption and dependency

3. Specific requirements

  3.1 external interface requirements

  3.1.1 user interface

  3.1.2 hardware interface

  3.1.3 software interface

  3.1.4 communication interface

3.2 functional requirements

  3.2.1 mode 1 functional requirements 1.1

  3.2.1 functional requirements 1.n

  3.2 m mode

  3.3 performance requirements

  3.4 design constraints

  3.5 system attribute

  3.6 other requirements

Functional specifications with the use case

Functional specifications will be the requirement specifications which has to be specified for the proposed software systems which is being developed. As the end users have to be specified well before the software system then they realise via functionality of the proposed software which is being developed.

Basics of use case

These are the general methods for describing the functional requirements

1. Use case will be textual description which will specify the behaviour in the usual manner followed by stakeholders or the clients to feel the familiarity of the system behaviour. Use cases which represent the behaviour requirement of the software system and this kind of behaviour specifications will gather most of the functional requirements of the software system which is being developed

Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Articles

Back to top button

Get Python Course
worth 499$ for FREE!

Offer valid for 1st 20 seats only, Hurry up!!

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

H2kinfosys Blog will use the information you provide on this form to be in touch with you and to provide updates and marketing.