Ads
  

Benefits of an SRS | Building the SRS

Benefits of an SRS | Building the SRS

Benefits of an SRS

Using an SRS model provides a specification process that is unequivocal and delivers a complete specification document. This assists the project manager in communicating clearly with the project stakeholders to ensure that:

1.  Software customers accurately describe what they wish to obtain.

2.  Software suppliers understand exactly what the customer wants.

3.  Individuals accomplish the following goals:

a.  Develop a SRS outline for their project and organization;

b.  Define the format and content of their specific software requirements;

c.  Develop additional local supporting items such as an SRS quality checklist, or an SRS best practices handbook.

A good SRS demonstrates these particular benefits to the project stakeholders:

●  The SRS becomes the baseline for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be customized to meet their needs.

●  It reduces the development effort. The preparation of the SRS forces the various concerned groups in the customer's organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting.

●  A careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct.

●  It becomes the basis for estimating costs and schedules. The product description is a realistic basis for estimating project costs. In a public environment where a formal bidding process exists, the SRS is used to obtain approval for bids or price estimates.

●  Organizations can develop their validation and verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured.

●  It facilitates the transfer of the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers.

●  It serves as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, it serves as a basis for later enhancement of the finished product.

Building the SRS

Requirements definition is the most crucial part of the project. The SRS is the mechanism for capturing and containing the project requirements. Incorrect, inaccurate, or excessive definition of requirements will necessarily result in schedule delays, wasted resources, or customer dissatisfaction. Any discussion of requirements analysis methods will quickly become specific to the type of project effort. Many industry areas have specific, proven techniques for obtaining thorough and accurate definition of requirements. Sometimes it is useful to write a draft user's manual as a way to define requirements. While the methods may differ, the principles remain the same across all types and sizes of projects. The requirements analysis should cover the whole scope of the project. It must be comprehensive and thorough. It must consider the views and needs of all the project stakeholders.

It is easy to leave scope out of requirements analysis or to omit necessary clarity or detail thereby making the requirements definition ambiguous. The completed requirements analysis should be reviewed and approved by the customer or project sponsor before work continues. On large projects, the first formal design review is in fact a requirements review.

The SRS can take on any reasonable form for specific project needs. It needs to embody the quality characteristics previously explained. The following template is based on IEEE 830-1998 with modifications from extensive experience with software project definition. It is a basic SRS outline that accommodates the three views of the project problem domain and is a vehicle for capturing and maintaining project requirements.

Title Page

Identify the document as the software requirements specification, and list the project name and author(s). Place the version/revision control table on either the title page or the following page with the enumeration of the releases of the SRS and other comments as determined by the configuration management process.

Table of Contents

Simply use whatever automated table of contents generator is available with the project documentation tool.

Section 1. Introduction

The following subsections of the SRS should provide an overview of the entire SRS. By itself, Section 1 should stand alone as an executive summary.

1.1 Purpose
Identify the purpose of the SRS and its intended audience. Identify why it has been developed at this point in the product life.

1.2 Scope
In this subsection:

1.  Identify the software product(s) produced by name and a one-paragraph description of its function.

2.  Explain what the software product(s) will, and will not, do. This is how the product(s) is (are) to be used. Explaining what it will not do removes ambiguity from the SRS.

3.  Explain the application of the software being specified. A portion of this should:

a.  Explain the relevant benefits, objectives, and goals as precisely as possible.

b.  Be consistent with similar statements in higher-level specifications if they exist.

1.3 Assumptions and Dependencies
List and explain each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but any changes to them can affect the requirements in the SRS. It is critical that these be enumerated at the front of the SRS. Many times managers and executives read only the introduction (executive summary). Because their job is to facilitate the successful execution of this project, if they are aware of all assumptions and dependencies, they can aid in making the project a success.

An assumption might be that a specific operating system will be available on the hardware designated for the software product. If, in reality, the operating system was not available, the SRS would have to change. The most important dependencies like this must be brought to management's attention.

1.4 Overview of the SRS
Explain the rest of the SRS and how it is organized.

Section 2. The General Description

Explain the general factors that affect the product and its requirements. This section does not state specific requirements. Each of the five subsections makes the requirements easier to understand; they do not specify design or express specific requirements. Such detail is given in Section 3.

2.1 Product Perspective
This subsection of the SRS relates the product to other products or projects.

1.  If the product is independent and totally self-contained, it should be stated here.

2.  If the SRS defines a product that is a component of a larger system or project:

a.  Explain the functions of each component of the larger system or project, and identify the interfaces.

b.  Identify the principal external interfaces of the software product (not a detailed description).

c.  Explain the computer hardware and peripheral equipment to be used (overview only).

A block diagram showing the most important components of the larger system or project, interconnections, and external interfaces is important for understanding the domain in which this product operates.

2.2 Product Functions
Provide a summary of the functions that the software will perform. Sometimes the function summary can be taken directly from the system specification section that assigns particular functions to the software product. The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time. Block diagrams showing the different functions and their relationships are essential as an effective explanatory tool.

2.3 User Characteristics
Explain those general characteristics of the eventual users of the product that will affect the specific requirements. Several people interact with a system during the operation and maintenance phase of the software life cycle. Some of these people are users, operators, and maintenance and systems personnel. Certain characteristics of these people, such as educational level, experience, and technical expertise impose important constraints on the system's operating environment. This is the audience for the application's user's manual. It is never too early to begin writing the end-user documentation. By the time the SRS is complete, there should be an understanding of how the user interacts with the system. If the user's manual cannot be written at this time, it is an indication of missing requirements.

2.4 General Constraints
Provide a general description of any other items that will limit the developer's options for designing the system. These can consist of:

1.  Regulatory policies

2.  Hardware limitations (for example, signal timing requirements)

3.  Interface to other applications

4.  Parallel operation

5.  Audit functions

6.  Control functions

7.  Higher-order language requirements

8.  Signal handshake protocols

9.  Criticality of the application

10.  Safety and security considerations

Section 3. Specific Requirements

This section of the SRS should include all the details the software developer needs to create a design. This is usually the largest and most important part of the SRS. It is the section where the three views of the problem domain will be explained (please refer to "Questions the SRS Answers for a Project" Figure 1), along with diagrams and models representing the requirements.

1.  Details should be defined as individual specific requirements, keeping in mind the quality characteristics (correctness, unambiguousness, completeness, consistency, rank of importance and/or stability, verifiability, modifiability, and traceability).

2.  Specific requirements should be organized in a logical and clear fashion.

3.  Each requirement should be stated in such a way that its achievement can be objectively verified by a prescribed method.

4.  Sources of a requirement should be identified where useful for understanding of the requirement.

5.  One way to classify the specific requirements is as follows:

a.  Functional requirements

b.  Performance requirements

c.  Design constraints

d.  Attributes

e.  External interface requirements

The best organization for this section depends on the application area and the nature of the software product being specified. There are four general classes that the organization can assume:

1.  In Figure 1, the functional requirements are specified, followed by the four types of interface requirements and the rest of the requirements.

All Functional Requirements Specified First

2.  Figure 2 shows the four classes of interface requirements applied to each individual functional requirement. This is followed by the specification of the rest of the requirements.

Each Interface Requirement Applied to Each Functional Requirement First

3.  In Figure 3, all of the issues addressed by the functional requirements are specified, followed by the other requirements that apply to them. This pattern is repeated for each of the external interface requirement classifications.

A Functional Requirement the Rest of Its Requirements and All Interface Requirements

4.  In Figure 4, the interface requirements and the rest of the requirements are specified as they pertain to each functional requirement.

A Functional Requirement Its Interface Requirements and Its Other Requirements

The organization of this section of the SRS should be chosen with the goal of properly specifying the requirements in the most readable manner. The template outline that follows uses an organization like Figure 1.

3.1 Functional Requirements
This subsection specifies what the product will do, and to what level or requirement it will do it, what inputs should be transformed to what outputs (not how this is done), and what operations are required. Where the rationale for a requirement is not obvious, provide an explanation. Cite any issues that need to be resolved.

For each function, specify requirements on inputs, processing, and outputs. These are generally organized with these four subparagraphs:

1.  Purpose of the function: provide rationale to clarify the intent of the function

2.  Inputs: sources, valid ranges of values, any timing concerns, operator requirements, special interfaces

3.  Operations to be performed: validity checks, responses to abnormal conditions, types of processing required

4.  Outputs: destinations, valid ranges of values, timing concerns, handling of illegal values, error messages, interfaces required

3.2 External Interface Requirements
This section of the SRS includes all of the information that the designer needs to adequately develop the interfaces to entities outside of the software being specified. Of critical importance is the specification of the requirements for how the end-user will interact with the software system. Where required, specific interfaces to hardware, other software applications, and communication systems are specified in this subsection.

3.2.1 User Interfaces
This should specify:

1.  The characteristics that the software must support for each human interface to the software product. For instance, if the user of the system operates through a display terminal, the following should be specified:

a.  Required screen formats

b.  Page layout and content of any reports or menus

c.  Relative timing of inputs and outputs

d.  Availability of some form of programmable function keys

2.  All the aspects of optimizing the interface with the person who must use the system. This may simply comprise a list of do's and don'ts on how the system will appear to the user.

3.2.2 Hardware Interfaces
Specify the logical characteristics of each interface between the software product and the hardware components of the system. Contain such matters as what devices are to be supported, how they are to be supported, and protocols. A block diagram showing the relationship among the hardware blocks and the software functions hosted in each block is essential here.

3.2.3 Software Interfaces
Specify the use of other required software products (for instance, a data management system, an operating system, or a mathematical package), and interfaces with other application systems.

For each required software product, the following should be provided:

1.  Name

2.  Mnemonic

3.  Specification number

4.  Version number

5.  Source

For each interface:

1.  Discuss the purpose of the interfacing software as related to this software product.

2.  Define the interface in terms of message content and format. It is not necessary to detail any well-documented interface, but a reference to the document defining the interface is required.

3.2.4 Communications Interfaces
Specify the various interfaces to communications, such as local network protocols.

3.3 Performance Requirements
This subsection should specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole.

1.  Static numerical requirements may contain:

a.  The number of terminals to be supported

b.  The number of simultaneous users to be supported

c.  The number of files and records to be handled

d.  The sizes of tables and files

2.  Dynamic numerical requirements may contain, for instance, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.

All of these requirements should be stated in measurable terms, for example, "95 percent of the transactions shall be processed in less than 1 second," rather than, "operator shall not have to wait for the transaction to complete."

Note: Numerical limits applied to one specific function are usually specified as part of the processing subparagraph description of that function.

3.4 Design Constraints
Design constraints can be imposed by other standards, hardware limitations, and the operating environment.

3.4.1 Standards Compliance
Specify the requirements derived from existing standards or regulations. These might contain:

1.  Report format

2.  Data naming

3.  Accounting procedures

4.  Audit tracing (For instance, this could specify the requirement for software to trace processing activity. Such traces are required for some applications to meet minimum government or financial standards. An audit trace requirement might state that all changes to a payroll database must be recorded in a trace file with before and after values.)

3.4.2 Hardware Limitations
Identify requirements for the software to operate inside various hardware constraints.

3.5 Quality Characteristics
There are a number of quality characteristics that can apply to software. Pick those most important to the product and develop a section for each one. Figure 5 has the definitions of the quality characteristics.

Quality Characteristics

3.5.1 Efficiency
Explain the rationale for including the efficiency characteristic for this product.

Explain how the presence, absence, or level of this characteristic will be measured; identify ways to test the characteristic once the product is complete.

3.5.n Usability
As stated in the instructions, there could be several quality characteristics explained in these subsections. Usability is numbered with an "n" prefix to reference the possibility of one or more characteristics.

Explain the rationale for including the usability characteristic for this product.

Explain how the presence, absence, or level of this characteristic will be measured; identify ways to test the characteristic once the product is complete.

3.6 Other Requirements
Certain requirements may, due to the nature of the software, the user organization, and so on, be placed in separate categories such as those below.

3.6.1 Database
This subsection could specify the requirements for any database that is to be developed as part of the product. These might contain:

1.  Types of information

2.  Frequency of use

3.  Accessing capabilities

4.  Data element and file descriptions

5.  Relationship of data elements, records, and files

6.  Static and dynamic organization

7.  Retention requirements for data

If an existing database package is to be used, this package should be named under Subsection 3.2.3., Software Interfaces, and the details of its use specified there.

3.6.2 Operations
This is sometimes specified as part of the User Interfaces section. It could specify the normal and special operations required by the user such as:

1.  The various modes of operations in the user organization; for example, user-initiated operations.

2.  Periods of interactive operations and periods of unattended operations.

3.  Data processing support functions.

4.  Backup and recovery operations.

3.6.3 Site Adaptation Requirements
This section could:

1.  Define the requirements for any data or initialization sequences that are specific to a given site, mission, or operational mode (for instance, safety limits).

2.  Specify features that should be customized to adapt the software to an installation.

Section 4. Supporting Information

The supporting information adds to the completeness of the SRS. This section should always be considered part of the formal requirements specification. The SRS remains a "living document" throughout the life cycle of the product, not just its development. Information included in the document is maintained and placed under version control. It is a critical part of the validation testing and all subsequent regression test suites.

4.1 Definitions, Acronyms, and Abbreviations
Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to an appendix or other document(s).

4.2 References
In this subsection:

1.  Provide a complete list of all documents referenced elsewhere in the SRS.

2.  Identify each document by title, report number (if applicable), date, and publishing organization.

3.  Specify the sources from which the references can be obtained.

4.  Use as many Web sources as possible.

5.  Include a traceability matrix.

The traceability matrix is one of the key deliverables from the requirements phase and a tool that will be used throughout the life cycle of the product. It is an outgrowth of the numbering scheme for the SRS requirements section and takes on the topology of the layout used.

Table 1 shows an example of a requirements traceability matrix with the hardware module in which the requirement is hosted. Traceability matrices can be developed to show any information dimension. Some commonly used ones are:

1.  User interface

2.  Validation tests

3.  Acceptance tests

4.  Contract line items

5.  Training

6.  Design modules

7.  Source code

8.  Documentation

9.  External dependencies

10.  Quality factors

11.  Errors found

4.3 Appendices
The appendices are considered part of the actual requirements specification, although they may not always be required. They might contain:

1.  Sample I/O formats, descriptions of cost analysis studies, results of user surveys.

2.  Supporting or background information that can help the readers of the SRS.

3.  A description of the problems to be solved by the software.

4.  The history, background, experience, and operational characteristics of the organization to be supported.

5.  A cross-reference list, arranged by milestone, of those incomplete software requirements to be completed by specified milestones.

6.  Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements.

4.4 Index
As with the table of contents, simply use the project documentation tool to automatically generate an index for the SRS.

Requirements Traceability Table


Tags

life cycle, srs, software product, project stakeholders, traceability matrix
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus