Menu

Software requirements document

  1. Both customer as well as system requirements specifications can be integrated to form one document.
    (or)
    Customer requirements specification can be provided in the initial phase or at the introduction of the document. This step is followed by detailed system requirement specification.
    (or)
    If the application is complex and probably large then system requirement specifications can be included at separate locations or document. Usually, in each software requirements document the details of large sets of stakeholders involved in the development are included.

Following is a list of stakeholders and illustrations related to their involvement in the development,

(a) System customer and end user

These are the people to whom software is being delivered. They are authenticated to supply their requirements and also read the current document (software requirement document) in order to ensure that the (document) is built in accordance to their needs.

(b) System managers

System managers usually consider the document to decide on the cost of development and to plan out the consequences of entire project.

(c) Development team or engineers

They usually decide on the tasks to be accomplished.

(d) Testers

They use the documents in order to develop suitable test cases.

(e) Maintenance engineers

They consider the document as a mode to understand as well as generalize the relationship existing between various modules of the system.

In general, the level of details to be provided in the document depends on the type of system being developed and also on the process being implemented on this occasion.

By considering various aspects, IEEE has launched following format for generating the software requirements documents,

1. Introduction

  • Purpose of requirements document

  • Product scope

  • Definitions, acronyms and abbreviations

  • References

  • Overview of rest of the requirements document

2. General description

  • Product perspective

  • Product functions

  • User characteristics

  • General constraints

  • Assumptions and dependencies

3. Specific requirements

  • Functional

  • Non-functional

  • External interface requirements

  • System functionality and performance

  • Logical database requirements

  • Design constraints

  • Emergent system properties

  • Quality characteristics

4. Appendices

Here, the details of the application are included. The fundamental issues which can be addressed in this regard are hardware requirements as well as database requirements.

5. Index

Indexes are usually included to provide ease in locating appropriate entities. The most fundamental index is given in alphabetical order. There are many ways to represent indexes and any of them can be followed. The above mentioned format is a standard notation for developing the software requirement specification. But it is assumed that the above format defines only general characteristics when considered along with the organization developing the software. Hence, the above format is further in matured and certain new specifications are added to it. This helps in directly applying preparation of SRS at the organization level. Hence, the improved format is given below,

1. Preface

Here, the fundamentals of the document are defined (say) the current version and its history. Also the details include the reasons for introducing the current documents along with the summary of changes made to the previous version in bringing up the current version.

2. Introduction

Summary of details under this side heading are given below,
The need for the system
The major functionality within the system and with other systems.
The way the given system remains compatible with the business objectives of the organization involved in developing the given system

3. Glossary

Glossary includes definitions for various technical terms used in requirements document.

4. User requirements definition

Here, usually the services delivered by a given system to the users are specified along with non-functional requirements of the system. This illustration is usually made in most elucidating style using the formal language constructs, diagrams or user understandable notations.

5. System architecture

Here, usually the overall system architecture is presented in an abstract format. This includes the distribution of modules throughout the architecture along with the relationships existing between them. The components (within the architecture) which are used more than once, should be represented along with the same signature (representation) so that they can be recognized easily.

6. SRS or System requirement specification

In this case both functional as well as nonfunctional requirements are described in a more detailed manner.

7. System models

One or more models depicting the relationship between the system, its environment and its components, along with their vicinity where they are highlighted. The most commonly used models in this case are semantic, data, dataflow and object models.

8. System evolution

In this case usually the assumptions based on which the current system is brought up is summarized. Also, the probable changes which can be made to the system on the account of hardware trends and future user needs are also addressed.

9. Appendices

Here, the details of the application are included. The fundamental issues which can be addressed in this regard are hardware requirements and database requirements.

10. Index

Indexes are usually included to provide ease in locating appropriate entities. The most fundamental index is given in alphabetical order. There are many ways to represent indexes and any of them can be followed.

Characteristics of a good software requirement specification

A good SRS document must possess the following characteristics

(i) Concise

The SRS document must be up to the point, unique and consistent because lengthy and irrelevant descriptions decrease the readability and increase the possibility of errors.

(ii) Organized

The SRS document must be well-organized because it becomes simple to understand and one can make the necessary changes easily as per the customer requirements.

(iii) Black-box view

The SRS document should represent only the physical behaviour of the system rather than describing its implementation issues. In other words the system which is being developed must be considered as a black box and its external behaviour should be defined. Due to this reason, the SRS document is also known as black-box specification of a system.

(iv) Conceptual integrity

A good SRS document must possess conceptual integrity so that the contents of the document can be understood easily by a reader.

(v) Response to undesired events

The document must describe the system responses to exceptional conditions.

(vi) Verifiable

All requirements of the system must be verified in order to determine whether all the requirements are met during implementation or not. If any feature is not verifiable then it should be mentioned separately in the “goals of implementation” section of the SRS document.

Role of software requirement specification in software engineering

Software Requirement Specification (SRS) document is the final outcome that comes after problem analysis. But, both problem analysis and SRS are carried out simultaneously due to which these activities overlap with movement from both the activities to the other. The information regarding the SRS is obtained from analysis therefore, specification activity follows the analysis activity.

The formal modeling performed in problem analysis is not treated as SRS as it lays stress on the problem structure than the external behaviour. The things like modeling of user interfaces, minor issues, performance, design constraints, recovery etc., are rarely modeled. But these things should be specified in SRS, these all constraints are needed to be modeled to design a system easily and clearly. On the other hand, it is difficult for some structures to be translated into external behaviour specification due to their limit use.