r2 - 16 Jun 2010 - 09:35:08 - KevinVlaanderen

Software Requirements Specification Document

Introduction
Process description
Example
Further reading

Introduction

This paper elaborates on Requirements Management. More specifically, we deal with Software Requirements Specifications (SRS) and the writing of a Software Requirements Specification Document. The background and origins of the recommended approach for writing an SRS are reviewed in section 1.1. Then the positioning of this process inside the Software Product Management Framewirk will be depicted and analyzed. Then the description of the process will take place in section 2, where the process deliverable diagram accompanied by its activity and deliverable tables, will be shown. Section 3 the situational factors and the maturity level regarding the process will be examined. Then a simplified version of how to write an SRS document will be presented in section 4, followed by an example of the usage of the approach in section 5. Indication for further reading will conlude this article.

Background and origins

An SRS is an organizations’ understanding of a customers’ system requirements and dependencies concerning the software under development. The writing usually takes place before any actual design or development of the product. It is a contract between supplier and customer in which they agree upon the requirements that both parties have.

Software requirements specification is a defined step in the requirements management which in turn is one of the four steps in the software development life cycle or to be more exact in the software product management (SPM). Requirements management is the process of determining the software requirements.

Recommended approaches for developing and completing an SRS document are described by IEEE, 1998. Normally, all the designers of real time, embedded system software use the IEEE approach as a base of all the Software Requirements documents unless they are specifically asked from customers to do otherwise. The software requirements specification is based on a model in which the result of the software requirements specification process is an unambiguous and complete specification document (IEEE, 1998).

This recommended practice was prepared by the Life Cycle Data Harmonization Working Group of the Software Engineering Standards Committee of the IEEE Computer Society (IEEE, 1998). It was first introduced in 1984 and then revised in 1993 before today’s form as described in IEEE Std 830-1998. This IEEE paper also provides guidelines for compliance with IEEE/EIA 12207.1-1997 which is the Standard for Information Technology - Software life cycle processes - Life cycle data. For a Software Specification to be consistent and complete there should also exist a System Specification document. This IEEE standard for a System Specification is the IEEE guide for developing system requirements specifications sometimes referred to as IEEE STD 1233-1998. Furthermore, this recommended practice should be used in conjunction with several publications. Due to space limitations we will not cite these publications and recommend the reader to refer to the IEEE std 830-1998. An SRS document should state in a complete and accurate fashion the functional and non functional requirements regarding the software system, as well as the functions and the capabilities of the system. The constraints that limit the functions and capabilities should also be expressed explicitly and precisely. The SRS document as indicated by Le Vie (1997) is referred as parent document because all subsequent project management documents, such as design specifications, testing and validation plans, and documentation plans, are related to it. Finally we have to stress out that the SRS document should not describe any design or implementation details and should not impose any additional constraints on the software (IEEE, 1998). This recommended approach for writing an SRS document is only an approach and it should not be misinterpreted as a specific method, nomenclature, or tool.

Process description

The following figure is the process deliverable diagram of the construction of an SRS document mostly influenced by the method described in IEEE, 1998. It shows the process-deliverable diagram of the software requirements specification process. The diagram was developed according to the meta-modeling technique. The left part is the meta-process model which is done by adapting the UML activity diagram, the right part is the meta-deliverable model which in fact shows the deliverables of the process diagram (Weerd & Brinkkemper, 2007). This is an adjusted class diagram as described by Booch, Rumbaugh and Jacobson (1999). As you can see in the diagram the Identify Specific Requirements (ISR) activity is depicted as an open one. Weerd and Brinkkemper (2007) define an open activity as a complex one whose (sub) activities are expanded. In the following diagram the activity is a rounded rectangle with a shadow, to indicate that the activities are depicted elsewhere and more specifically in figure 2.

Figure 1: Process Deliverable Diagram of SRS

The main steps of the method presented on figure 2 are:

1. Establish SRS Environment: In this activity the main pro-tasks are undertaken, which are the selection of the language and tools on which the writing of the SRS document is going to be based. The language can be either the natural language or a requirements specification language. A requirements specification language can resolve the ambiguity that characterizes the natural language but it has its pitfalls. One disadvantage in the use of such languages is the length of time required to learn them. Also, many non technical users find these languages unintelligible (IEEE, 1998).

2. Write Introduction: In this activity the purpose and scope of the Software Requirements Specification are defined and developed, constituting the INTRODUCTION SECTION of the SRS DOCUMENT.

3. Write Overall Description: In similar way in this activity, the dependencies, assumptions, constraints, product functions summary and user characteristics are established and written down on the OVERALL DESCRIPTION SECTION.

4. Identify Specific Requirements: Due to the fact that this is the most important activity of the SRS it is isolated and depicted with more detail in an additional process-deliverable diagram in figures 3.

5. Check Requirements: In this activity the requirements are checked for conflicts between them and finally they are assigned with an identifier that depicts their rank according to their prioritization.

6. Write Supporting Information: The supporting information makes the reading easier for whoever concerned. By supporting information we mean the inclusion of appendices, references and glossary to the SRS DOCUMENT.

7. Change Process: This activity is where projected changes are identified and if approved the construction of an accurate and complete audit trail of changes occurs. These two documents then become parts of the REVISION HISTORY which is responsible for incorporating the changes in the SRS DOCUMENT.

8. Finalize SRS: This is where the final version of the SRS DOCUMENT is completed. No more changes can occur and the document is ready for distribution to all interested parts.

In steps 1, 2, 3, 6 and 7 the stakeholders that carry out the process are explicitly stated in the right-down corner of each activity. It is recommended that both the supplier and the customer should be involved in the writing of these sections:

Supplier: The person, or persons, who produce a product for the customer. In the context of this recommended practice, the supplier and the customer may be members of the same organization (IEEE, 1998).
Customers: The person, or persons, who pay for the product and usually decide the requirements. In the context of this recommended practice, the supplier and the customer may be members of the same organization (IEEE, 1998).

Activity table

The next table shows all the main activities and sub activities of the SRS process and their relation to the concepts depicted in the process-deliverable diagram. This table has been constructed according to Weerd & Brinkkemper, (2007).

Activity	Sub activity	Description
Establish SRS Environment	Choose Language	Chooses LANGUAGE that the SRS DOCUMENT is going to be written in.
	Choose Representation Tools	Choose TOOL between different ones based upon the size and complexity of the program.
Write Introduction	Specify Purpose	This sub-activity should delineate the PURPOSE of the SRS DOCUMENT and specify the intended audience for the SRS DOCUMENT.
	Describe Scope	This activity identifies the software product to be produced by name, explains what the software will, and, if necessary, will not do and integrates all in the SCOPE section of the INTRODUCTION.
Write Overall Description	Provide Products' functions Summary	The functions are organized in such a way that the list of the major functions that the software will perform is understandable to anyone who reads the SRS DOCUMENT.
	Describe User Characteristics	Identifies and describes the characteristics of the intended users of the software.
	Describe Assumptions	Describes each ASSUMPTION that can affect each SPECIFIC REQUIREMENT.
	Describes Dependencies	Describes each DEPENDENCY that can affect each SPECIFIC REQUIREMENT.
	Identify Constraints	Examines if there are any other items that limit the developers’ options. Such constraints can be: required standards in effect, implementation language, hardware limitations, regulatory policies, and safety and security issues.
Identify Specific Requirements		Identifies all of the software requirements to a sufficient level of detail.
Check Requirements	Check Internal Consistency	Checks each REQUIREMENT to find possible conflicts between them.
	Rank Requirements	Each requirement is combined with an identifier which indicates either the importance or the stability of that particular requirement.
Write Supporting Information	Write References	Provides a list of all documents referenced elsewhere in the SRS DOCUMENT.
	Write Glossary	Provides a list with the definitions of all terms, acronyms and abbreviations used inside the SRS DOCUMENT.
	Include Appendices	Appendices, concerning relevant information to help the readers of the SRS DOCUMENT, are constructed and included in it.
Change Process	Initialize Change Process	The change process is initialized and additional changes may ensue as deficiencies, shortcomings and inaccuracies are discovered in the SRS DOCUMENT (IEEE, 1998).
	Incorporate Changes	The changes should be incorporated to the SRS in such a way as to provide an accurate and complete AUDIT TRAIL OF CHANGES and permit the REVIEW of current and superseded portions of the SRS DOCUMENT (IEEE, 1998).
Finalize SRS Document	Complete SRS	The SRS DOCUMENT is finalized and the document is ready for distribution.
	Distribute SRS	The SRS DOCUMENT is distributed to the stakeholders.

Concept table

Table 2 contains the concepts that can be seen in the left part of the process deliverable diagram (Figure 1). Each concept in the following table is provided with a description and a reference.

Concept	Description
NATURAL LANGUAGE	Natural language is spoken, written, or signed human language such as French, Japanese, and American Sign Language. On the Web, the natural language of content may be specified by markup or HTTP headers (W3C? , 2003).
REQUIREMENTS SPECIFICATION LANGUAGE	A requirements specification language is the means by which users can make a model of the real world and specify its problems and requirements (Tse & Pong, 1991).
LANGUAGE	A method of specifying the formatting and transformation of the document. (ISO International Standard 10179, 1996).
OBJECT-ORIENTED TOOL	Object oriented tools organize the requirements in terms of real-world objects, their attributes and the services performed by those objects (IEEE, ).
PROCESS-BASED TOOL	They organize the requirements into hierarchies of functions that communicate via data flows (IEEE, 1998).
BEHAVIORAL TOOL	They describe external behaviour of the system in terms of some abstract notion, mathematical functions, or state machines (IEEE, 1998).
TOOL	It is a possibly automated means to support a part of the development process (Brinkkemper, 1996).
PURPOSE	The reason(s) for data collection and use (W3C? , 2003).
SCOPE	Includes the identity of the software product(s), a brief description of the software’s functionality, an explanation what the software will and will not do, a description of the application of the software and a description of the relevant benefits, objectives, and goals of the software (IEEE, 1998).
INTRODUCTION SECTION	Provides an overview of the entire SRS. It contains the following subsections: purpose and scope (IEEE, 1998).
PRODUCT FUNCTIONS SUMMARY	A summary of the major functions that the software will perform (IEEE, ).
USER CHARACTERISTIC	General characteristics of the intended users of the product (IEEE, 1998).
ASSUMPTION	Factor that is believed to be true during the life cycle of the project that, if changed, may affect the project outcomes negatively including, but not limited to, end-user characteristics, known technology infrastructure, resource availability, and funding availability (IEEE, 1998).
DEPENDENCY	Dependencies are outside of project scope and control and must remain true for the project to succeed. For example, a dependency might be that an application relies on a different application to provide specific data or that an interface to a third-party application requires the purchase of an application programming interface (IEEE, 1998).
OVERALL DESCRIPTION SECTION	An overall description specifies the general factors that affect the product and its requirements (IEEE, 1998).
CONSTRAINT	This document focuses on more fundamental design choices: design choices that lead to constraints, i.e., restrictions in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons to achieve desirable properties in the system, such as accessibility, global scope, relative ease of evolution, efficiency, and dynamic extensibility (W3C? , 2003).
SPECIFIC REQUIREMENT	Each identified software requirement (IEEE, 1998).
SPECIFIC REQUIREMENTS SECTION	This section contains all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements and testers to test that the system satisfies those requirements (IEEE, ).
GLOSSARY	The glossary is the subsection where the definitions of all terms, acronyms and abbreviations required to properly interpret the SRS are stated (IEEE. ).
REFERENCE	A reference identifies each document mentioned somewhere in the SRS by title, date, report number and publishing organization (IEEE, 1998).
APPENDIX	An appendix may include: • sample inputs/outputs formats, descriptions of cost analysis studies or results of user surveys • supporting or background information that can help the readers of the SRS • a description of the problem to be solved by the software (IEEE, 1998).
SUPPORTING INFORMATION SECTION	It is information that makes the SRS easier to use (IEEE, 1998)
REVISION HISTORY	If the changes occurred by the change process, are accepted, then this document is used to identify the changes in the SRS (IEEE, 1998).
PROJECTED CHANGES REPORT	Document that comprises the current and superseded portions of the SRS (IEEE, 1998).
AUDIT TRAIL OF CHANGES	A record of transactions in an information system that provides verification of the changes of the system (IEEE, 1998).
SRS DOCUMENT	SRS document is a contract between the supplier and the customer. It is a specification for a particular software product, program or set of programs that performs certain functions in a specific environment. The SRS document is recommended to be written by both the supplier and the customer (IEEE, ).

Description of the ISR (Identify Specific Requirements) activity

As we have already indicated in the main process deliverable diagram, the Identify Specific Requirements activity is an open one and it will be illustrated in detail in the following diagram (figure 3). This is often the largest and most important part of the SRS, so it is presented separately for two reasons. First, because this activity has to be depicted in detail as it is considerably complex and second because the implementation of the detailed activity to the main process deliverable diagram would induce very complex and unreadable diagrams.

Figure 2: Process Deliverable Diagram of the ISR activity

Activity table of the ISR activity

The following table describes the sub-activities of the Identify Specific Requirements activity. This activity is responsible for identifying and gathering all the software requirements such as business requirements, functional requirements and user requirements. The Specific Requirement Section that mainly derives from this activity contains all of these requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements (IEEE, 1998).

Activity	Sub activity	Description
Identify Specific Requirements	Describe Business Requirements	Describes all requirements from a business viewpoint. Business requirements will be defined as USE CASES.
	Describe Functional Requirements	Identifies and describes the FUNCTIONAL REQUIREMENTS.
	Describe Logical Database Requirements	Identifies and describes the SPECIFIC REQUIREMENTS that are placed in a database.
	Describe User Requirements	Describes requirements forced by the users of the software.
	Specify Information Management Requirements	Specifies SPECIFIC REQUIREMENTS concerning the managing of information.
	Describe System Requirements	Describes QUALITY and PERFORMANCE REQUIREMENTS concerning the system.
	Describe Interfaces	Describes logical characteristics of each existing interface.
	Include Additional Requirements	Adds requirements to the SPECIFIC REQUIREMENTS that do not fit in the above mentioned activities.

Concept table

The following table provides definitions and references to the concepts concerning the sub-activities of the ISR activity.

Concept	Description
USE CASE DESCRIPTION	A description of the techniques used to capture the business requirements associated with the system (IEEE, 1998).
FUNCTIONAL REQUIREMENT	A functional requirement defines the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs (IEEE, 1998).
LOGICAL DATABASE REQUIREMENT	The logical database requirement may include the following: • Types of information used by various functions • Frequency of use • Accessing capabilities • Data entities and their relationships • Integrity constraints • Data retention requirements (IEEE, 1998).
USER REQUIREMENT	User requirements for the software application. User requirements capture the intended behavior of the human interface for the application (IEEE, ).
INFORMATION MANAGEMENT REQUIREMENT	Specify requirements for managing the creation, capture, organization, maintenance, use, protection, and disposition of information in accordance with applicable laws, regulations, policies, and standards (IEEE, 1998).
POLICY	A policy is a constraint on the behavior of agents or person or organization (W3C? , 2003).
STANDARD	A set of language or protocol rules serving as a rallying point, as a base for independent agents to communicate together without a specific and a priori agreement (W3C? , 2003).
QUALITY REQUIREMENT	They are requirements for the quality characteristics of the software. Specifies the requirements in measurable and verifiable terms (IEEE, 1998).
PERFORMANCE REQUIREMENT	Specifies the numerical requirements placed on the software or on human interactions with the software as a whole (IEEE, 1998).
SYSTEM REQUIREMENT	Defines what the system is required to do and the constraints under which it is required to operate (Kontoya et al, 1998).
INTERFACE	The point of interaction or communication between a computer and any other entity (W3C? , 2002).
ADDITIONAL REQUIREMENT	Any other requirements that do not fit appropriately into the preceding requirement sections (IEEE, 1998).
SPECIFIC REQUIREMENT	Each software requirement identified from the sub activities of the Identify Specific Requirements activity (IEEE, 1998).

Example

In this section we will construct an example on how to write an SRS document. The development of an SRS document will concern an online educational system.

The scope of this project should be identified in the very start of the process, for example: the scope of this project is to construct an educational system that can be accessed 24/7 from teachers and students via internet. A language and tools are selected in order to write the document, for example a natural language with usage of object oriented tool can be chosen.

The next step is to identify the stakeholders and their characteristics: In this chapter the stakeholders will be defined, described and their concerns per group will be discussed.

IEEE defines the concerns for a system as “…those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders”. In this architectural project representing an online learning environment the stakeholders are the following:
1. Students
2. Educational Stuff
3. Acquirers
4. Development team
5. Maintainers of the system
6. Local administrator For each of the stakeholders their concerns and characteristics should be explicitly identified.

Assumptions and dependencies will be examined in the next section, for example:

We assume that the estimated number of users will grow significantly in the future so the system must be changeable and customizable.

The constraints should be defined. The functional and non-functional requirements are constrained by the following issues:

Technology. The technology limits the response time of the system.
Time. Creating new tools takes time. Instructors can request, or create new tools themselves, but creating and testing tools takes time to develop and test for usability.
Costs. Management controls the amount of money and time to be spent on the system.

In this part we describe the functional requirements, non functional requirements and constraints regarding the system. The functional requirements describe what the system should do. They provide a contract between a stakeholder and the system. There are many tools that should be incorporated in the system each with their own requirements. The general requirements of the tools are listed here. These are the functional requirements starting with the most important ones (explanation of the requirements is omitted due to space limitations):

Up-to-date information
Accessible through the web
Possibility to add new tools
Clear permissions and tool visibility

The non-functional requirements describe with what quality the system should function. The most important issues are:

Functionality
Reliability
Usability
Efficiency
Maintainability

After that, the requirements are checked in order to identify conflicts and exclude requirements if needed.

When the requirements are well defined and the internal and external conflicts have been eliminated then the prioritisation of the requirements takes place. Prioritizing requirements (Karlssona et al., 1998) gives a better view of the most important concerns, which can be useful when, inevitably, problems occur. The following table is a sample of how requirements are prioritized.

Attribute	Sub-characteristic	Priority
Time behavior	Efficiency	1
Operability	Usability	2
Customizability	Usability	2
Security	Functionality	1
Analyzability	Maintainability	3
Reusability	Maintainability	3

If any changes have occurred during these steps a formal change process should be initiated to identify, control, track, and report projected changes as indicated in the IEEE Recommended Practice for Software Requirements Specifications (IEEE, 1998). Approved changes in requirements should be incorporated in the SRS in such a way as to
1) Provide an accurate and complete audit trail of changes;
2) Permit the review of current and superseded portions of the SRS.(IEEE, 1998)

The last section of the document should include references used in the SRS document and if necessary glossary and appendixes. Finally the SRS document is completed and it reports and communicates the software requirements to the technical community who will specify and build the online educational system.

Figure 3: Table of contents of the SRS document