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.
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.
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.
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.
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:
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).
|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.|
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.
|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, |
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.
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).
|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.|
The following table provides definitions and references to the concepts concerning the sub-activities of the ISR activity.
|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).|
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:
2. Educational Stuff
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:
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):
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.
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.