24 System Requirement Specifications

Ms.Vinodini Kapoor

1. Learning Outcome:

• Comprehend what is system requirement specification.
• Understand the need of drafting the SRS before designing the MIS.
• List the various users who require the SRS document.
• Discuss the various components of the SRS document.
• Understand what are software requirements and their types.
• Discuss attributes of a SRS document.

2. Introduction

A well executed and planned life cycle model suggests that before initiating software development, the exact requirements of the customer must be understood and documented. Without proper understanding and documentation of the system requirements the system development should not be started. Else, it would lead to iterative changes in the later life cycle stages and surge up the development cost. Therefore, the requirement analysis and specification stage is considered to be a crucial phase of the software development life cycle. It is important for a team of experts to sit together with the customer and outline the requirements. These experts who work in the domain of capturing the client requirements and writing specification documents are called system analysts.

The system analysts capture relevant data to articulate the requirements and identify any redundancies.

Exhibit 1 highlights the different touch points with whom the system analysts interact.

The SRS document states in a clear manner all functions the new software is expected to perform keeping in mind limiting conditions and assumptions. The SRS is a precursor to all further system documents like system specifications, bill of material, system architecture, product manuals etc. It serves as a blue print drafted with as little cost as possible.

Developing an information system requires the end to end life cycle of a process it intends to fulfill. It requires data base integration, transaction processing, application interface with other programs. It is the platform between the client and developer in realizing an automated process. It clearly outlines what activities are in scope of the system and what are not.

2.1 Why an SRS document is needed?

Preparation of the SRS document before the formal MIS design has various advantages. The advantages of an SRS document are listed below:

• Requirements in SRS documents enable to rectify omissions, misunderstandings, and inconsistencies early in stages of the MIS development cycle.
• Provide a basis for estimating costs and schedules and can be used to obtain the approval of technical bids or price estimates.
• Provide a basis for validation and verification.
• As part of the development contract MIS, SRS provides a basic document compliance with requirements that can be measured.

A well drafted SRS Document finds a variety of usage other than primary intended usage as a basis for starting the primary intended usage as a basis for starting software development work.

• Agreement between Customer and the Developers – A competent SRS Document sets the platform for the customers to build their expectation about the software and developers about what is expected from the software.
• Reduces Rework – SRS Document requires brainstorming and forces stakeholders to think about all requirements before design and development get underway. This reduces the investment in redesign, rework and retesting.

• Cost Estimation and Scheduling – Project managers usually estimate volume of work required on software from an analysis of the SRS requirement. Based on this they make further estimations such as the efforts required to develop the software and total cost of development. The project managers use the SRS document as a reference for project planning and work scheduling.
• Validation and Verification – It provides a basis against which the compliance of the software can be checked. It further helps to verify if the system is being developed as per specifications.
• Facilitates incremental usage – The document serves as a basis for planning future enhancements and scalability as business grows and customer base increases.

3. Users of the SRS Document

Different people use the SRS Document for different purposes. Various categories of users are listed in exhibit 5 below :

• Users, Customers and Marketing Personnel – These stakeholders refer to the SRS document to ensure the system as described in the document adheres to their needs. Customers may not be the direct users of the SRS document but may rely on it to know what product they can expect. Marketing professionals need the understanding of requirements that they can further pass on to the customers.
• Software Developers – The developers refer to the SRS document to make sure they are developing exactly what is required by the customer. Each requirement as a line item here is to be wetted and agreed prior to the start of the development activity.
• Test Engineers, Maintenance and Product Support Staff – The support staff need SRS to understand what software products are supposed to do. The engineers use the document to understand functionalities and based on this they write the test cases to validate the working. The required functionality should be clearly described in terms of input and output identified properly.
• Technical Writers – They use the SRS to ensure the features of the product are understood well enough to be able to write the user’s manuals. Technical writers are skilled information gatherers and are ideal for articulating customer requirements. They know how to determine the questions that are of concern to the user or customer regarding ease of usability.
• Project Managers – They refer to the SRS document to for cost estimation as it contains all the information required to plan the project.
• Maintenance Engineers – To develop an understanding of functionality supported by the system, the SRS is necessary. This enables them to understand the design and the code. It further enables them to determine the specific modifications to the system’s functionalities needed for a specific purpose.

It can be said that the SRS document serves as a contract or binding between the development team and the customer. It is used to resolve any disagreements between developers and customers that may arise in future. Once the SRS document is agreed upon by the customer and development team it is essential to ensure all requirements are conformed before delivering the solution.

4. Characteristics of a good SRS Document

• A good SRS document is drafted with the experienced gained over a period of time by writing for varied projects. The analyst should be aware of the desirable qualities possessed by a good SRS Document. IEEE (Institute of Electrical and Electronics Engineers) recommends the Practices for Software Requirement Specifications. These should be incorporated while drafting the SRS. Various characteristics of a good SRS are as follows:

• Concise – The SRS document is expected to be concise at the same time unambiguous, consistent and complete. It should define all possibilities that shall be encountered and the system’s capability to address them. It should ensure that the SRS capability functions and performance levels are compatible and the required quality features do not negate the capability functions. An unambiguous document suggests that it must contain requirements statements that can be interpreted in one way only.
• Implementation Independent – The document should be independent of implementation decisions. It should only specify what the system should do instead of stating how to do these. The SRS Document should describes the output produced for the different types of input and a description of processing required to produce the output from input and the internal working of the software is not discussed at all.
• Requirement Centric – Each requirement in SRS must be uniquely identified to a source E.g, use cases, government requirements etc. in other words it should be possible to trace a specific requirement to the design elements that implement it and vice versa. Traceability is important to verify the results of a phase with respect to the previous phase and to analyze the impact of changing a requirement o the design elements and the code.
• Modifiable – Customers frequently change the requirements during the software development in line with changing business needs. Therefore in practice the SRS document undergoes several iterations during software development. The SRS is often modified after the project completes to accommodate future enhancements and evolution. To cope up with the requirements changes, SRS document should be easily modifiable.
• Well structured – The document should be well structured. Having the description of a requirement mentioned across many places in the SRS may not be wrong but it tends to make the requirements difficult to understand and any modifications would become difficult as it would require changes to be made at large number of places in the document.
• Verifiable – A verifiable SRS is consistent from one level of abstraction to another. It should be possible to design test cases based on the description of the functionality as to whether or not requirements have been met in an implementation. Any feature of the required system that is not verifiable should be listed separately in the goals of the implementation section of the SRS Document.

5. Components of SRS Documents

Several standard organizations like the IEEE identify the nine components that must be addressed when designing and writing SRS. The IEEE 830 standard intends to serve only as a guideline for organizing a requirements specification document into sections and allows the flexibility of customizing it as require for specific projects. The components and structure of the SRS document to a large extent depends upon the preferences of the system analyst himself and is often guided by policies and standards followed by the development company. The structure also depends upon the type of product it caters to.

1. Introduction

Purpose – This describes where the software should be deployed and how the software would be used.

Project Scope – This should briefly describe the overall context within which the software is being developed. E.g, the parts of the problem that are being automated and parts that would need to be automated during future evolution of the software.

Environmental Characteristics – This section briefly outlines the internal and external integration interfaces (hardware and other software) with which the software will interact.

2. Overall Description

Product Perspective – It briefly states as to whether the software is intended to be a replacement for a certain existing system or it is new software. If software being developed would be used as a component of a larger system, a schematic diagram can be given to show the major components of the overall system, subsystem interconnections and external interfaces.

Product Features – It summaries the major ways in which the software would be used. A brief summary of the product is presented here.

User Classes – Various user classes that are expected to use this software are identified and described here. The different classes of users are identified by types of functionalities that they are expected to involve or their levels of expertise in using computers.

Operating Environment – it describes in detail the hardware platform on which the software would run, the operating system and other application software with which the developed software would interact.

Design and Implementation Constraints – Here the various constraints on design and implementation are discussed. These tend to include the corporate or regulatory policies, hardware limitations, interfaces to other applications, databases, programming language to be used, communication protocols, and security considerations or programming standards.

User Documentation – User manuals, on line help, trouble shooting manuals that will be delivered to the customer with the software.

3. External Interface Requirements

User Interface – This section describes a broad outline of various interfaces and various principles to be followed. The user interface description may include sample screen images, GUI standards or style guides to be followed, screen layout constraints, push buttons, keyboard shortcuts, and error display messages. These should be documented in a separate user interface specification document.

Hardware Interfaces – It describes the interface between the hardware and software components of the system. Description of supported device types, nature of data and control interactions between software and hardware and communication protocols that are to be used.

Software Interfaces – Connections between the software and its components, databases, operating systems, tools, libraries and integrated commercial components etc. The data items that would be input to the software and that would be output should be identified and purpose of each should be described.

Communication Interfaces – this describes the requirements associated with any type of communications required b the software, email, web access, network server, communication protocols etc. It shall also identify and state the communication standards that will be used such as Transmission Control Protocol, File Transfer Protocol, Hypertext Transfer Protocol, and Hypertext Transfer Protocol Secure. Any relevant communication security or encryption issues, data transfer rates may be specified.

4. System Features

Functional Requirements – This section lists the functional requirements in ranked order. Functional requirements describe the possible effects of a software system. It describes what the system must accomplish.

Each functional requirement should be specified in a format similar to:

1. Description – This refers to a full description of the requirement.
2. Criticality – It describes how essential this requirement is to the overall system.
3. Technical Issues – Describe any design or implementation issues involved in satisfying this requirement.
4. Cost & Schedule – Describe the relative or absolute costs associated.
5. Risks – These describe the circumstances under with this requirements might not be able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.
6. Dependencies – These describe interactions with other requirements.

5. Other Non Functional Requirements

The various Non Functional Requirements refer to:

Performance Requirements – Aspects pertaining to number of transactions to be completed per second should be specified here. Some performance requirements may be specific to individual functional requirements or features.

Safety Requirements – Those safety requirements that are concerned with possible loss or damage that could result from the use of the software are specified here. To exemplify, recovery from power failure, handling software and hardware failure may be documented here.

Security Requirements – This section specifies any requirements regarding security or privacy requirements on the data used or created by the software. Any user identity authentication requirements should be well described in this section. It should carry reference to external policies or regulations concerning security issues. Define any security or privacy certifications that must be satisfied.

6. Other Requirements

This section specifies other useful information for understanding the requirements. All SRS documents must include at least the following two appendices:

Appendix A: It lists out definitions, acronyms, abbreviations. It provides definitions of unfamiliar definitions, terms and acronyms.

Appendix B: It provides complete citations to all documents and meetings referenced or used in the preparation of this document.

5.1 Software Requirements and its types.

As per IEEE, a requirement is a condition or a capability needed by the user to solve a problem or achieve an objective. Software requirements are defined during requirements analysis phase of a software lifecycle.

Software requirements fall into four classes. These are explained as under:

• Functional requirements – Should clearly describe each functionality that the system would support along with the corresponding input and output data set. It specifies the actions the system must be able to perform without taking physical constraints into consideration. These are best described in context of the use case model.

E.g., A medical store inventory software, shall have a high level functional requirement such as search – medicine. This involves accepting a set of keywords from the user, running a matching algorithm on the medicine list and finally responding as output to the matched medicine. The generated system response could be in several forms E.g, display on the terminal, a print out, some data transferred to the other systems etc

• Non functional requirements – These describe only attributes of the system or attributes of the system environment. These are the non negotiable obligations that must be supported by the software. The non functional requirements capture those requirements that cannot be expressed as functions. Although some of these may be captured in use cases, those that cannot may be specified in supplementary specifications. The non functional requirements can be critical in the sense that any failure by the developed software to achieve some minimum defined level in these requirements can be considered as a failure and make the software unacceptable. Are usually global in nature. These include performance, reliability, efficiency, usability, portability, testability etc.
• Inverse requirements – These are the requirements that specify what the software system should not do. And are usually found in safety or security requirements.

• Design & constraints requirements – Design constraints such as specifying specific hardware and software or specific architectures i.e client- server. They describe items or issues that will limit the options available to the developers. Some constraints can be corporate or regulatory policies that need to be honored, hardware limitations, and interfaces with other applications, specific technologies, tools and databases to be used, specific communications protocols to be used.

6. Attributes of an ambiguous SRS document

SRS document written by inexperienced personnel may pose a variety of problems such as incompleteness, ambiguity and contradictions. There are many other areas that may be left if documents are drafted by novices.

• Over Specification – It occurs during the phase when the analyst tries to address the “how to” aspects in the SRS Document. This aspect restricts the freedom of the designers in arriving at a good design solution.
• Forward References – One should avoid referring to aspects that are discussed much later in the SRS documents. Forward referencing reduces the readability of the specifications.
• Wishful Thinking – These problems concern description of aspects which would be difficult to implement.
• Noise – It refers to material which is not relevant to the subject matter and software development process. It information only tends to clutter the SRS document diverting the attention from the crucial points.
• Contradictory – If the same information is described at different places in different ways, it may lead to misinterpretation and contradictions in the context they refer to.
• Safety actions – An SRS is incompetent if it fails to address all failure modes and protection requirements. Actions of function do not actually achieve safe state. The measurement may be too slow to pick-up and prevent accident. It does not define all operating regimes, start-up, shut-down and all environmental conditions.

7.  Summary

A software requirements specification is an exhaustive line wise description of the underlying purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform. An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. The SRS document states in precise and explicit manner the functions and capabilities a software should possess as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little investment as possible. The SRS is often referred to as the “parent” document because all subsequent project management documents, such as design specifications, statements of work,software architecture specifications, testing and validation plans, and documentation plans, are related to it. A good SRS defines how an application will interact with interfaces such as hardware, programs and human users in a wide variety of routine situations. Parameters such as operating speed, response time, availability, portability, maintainability, footprint, security and speed of recovery from adverse events are evaluated. Methods of defining an SRS are described by the IEEE Specification 830-1998.

Web Resources

1. http://www.nitc.ac.in/mis_srs_detailed_2.0.pdf