Software Requirements Specification (SRS) consists of a complete description of the external behavior of the software system. SRS could be written by a potential user of a system or a developer of a system. The two scenarios create different situations.
The following is a SRS template:
1. Introduction
This section provides an overview of the entire requirement document. This document describes all data, functional and behavioral requirements for software.
1.1 Goals and Objectives 1.2 Statements of Scope 1.3 Software Context 1.4 Major Constraints
96 5 Requirements Elicitation
2. Usage Scenario
This section provides a usage scenario for the software. It organized informa-tion collected during requirements elicitainforma-tion into use-cases.
2.1 User Profiles 2.2 Use Cases
2.3 Special Usage Considerations 3. Data Model and Description
3.1 Data Description 3.2 Data Objects 3.3 Relationships
3.4 Complete Data Model 3.5 Data Dictionary
4. Functional Model and Description
4.1 Description for Function n
A description of each major software function, along with data flow or class hierarchy (OO) is presented.
4.1.1 Processing Narrative (PSPEC) for Function n 4.1.2 Function n Flow Diagram
4.1.3 Function n Interface Description 4.1.4 Function n Transforms
4.1.4.1 Transform k Description (processing narrative, PSPEC) 4.1.4.2 Transform k Interface Description
4.1.4.3 Transform k Lower Level Flow Diagrams 4.1.4.4 Transform k Interface Description 4.1.5 Performance Issues
4.1.6 Design Constraints 4.2 Software Interface Description
4.2.1 External Machine Interfaces 4.2.2 External System Interfaces 4.2.3 Human Interface
4.3 Control Flow Description
5. Behavioral Model and Description
A description of the behavior of the software is presented.
5.1 Description for Software Behavior 5.1.1 Events
5.1.2 States
5.2 State Transition Diagrams 5.3 Control Specification (CSPEC)
6. Restrictions, Limitations, and Constraints
Special issues which impact the specification, design, or implementation of the software are noted here.
7. Validation Criteria
The approach to software validation is described.
7.1 Classes of Tests
7.2 Expected Software Response 7.3 Performance Bounds 8. Appendices
Presents information that supplements the Requirements Specification.
8.1 System Traceability Matrix 8.2 Product Strategies
8.3 Analysis Metrics to be Used
8.4 Supplementary Information (as required)
5.8 Chapter Summary and Conclusions
Requirements for a system are the descriptions of the services provided by the system and its operational constraints. Functional requirements are associated with specific functions, tasks or behaviors the system must support. Non-functional requirements are constraints on various attributes of these functions or tasks.
Domain requirements include specialized domain terminology or references to domain concepts. Since these are specialized, software engineers often find it difficult to understand how they are related to other system requirements.
Requirement elicitation is distinguished into two categories as traditional and modern methods.
Communicating with the client involves the developers and customers devel-oping a shared understanding of problems and of technical solutions. Effective requirements definition requires mutual control of process by all players. In tra-ditional methods of requirement elicitation, interviews and questionnaires were the primary technique of fact finding and information gathering. This chapter explains the way to identify the functional and non-functional requirements, as well as
98 5 Requirements Elicitation
domain requirements. Domain analysis is a term used to describe the systematic activity of identifying, formalizing and classifying the knowledge in a problem domain. Problems of requirements elicitation can be grouped into three categories:
problems of scope, problems of understanding, and problems of volatility. Vali-dating requirements is showing that the requirements properly define the system that the customer wants. Then this chapter describes how to derive use cases from the requirements. Creating use cases involves:
• Identifying all the different users of the system
• Creating a user profile for each category of user
Software Requirements Specification (SRS) consists of a complete description of the external behavior of the software system. Finally, this chapter displays the complete template of SRS.
5.9 Exercises
1. Specify which of these are functional and non-functional requirements:
• The ticket distributor must enable a traveler to buy weekly passes
• The ticket distributor must be written in java
• The ticket distributor must be easy to use
• The ticket distributor must always be available
• The ticket distributor must provide a phone number to call when it fails 2. Identify and briefly describe three types of requirements that may be defined
for a computer based system.
3. Describe types of non-functional requirements that may be placed on a sys-tem. Give examples of each of these types of requirement.
4. Write a set of non-functional requirements for the ticket-issuing system.
Suggest how the engineer is responsible for drawing up a system requirements specification and how they might keep track of the relationships between functional and non-functional requirement.
5. Using your knowledge of how an ATM is used, develop a set of use-cases that could serve as a basis for understanding the requirements for an ATM system.
6. Give a non-functional requirement that can be handled without having detailed knowledge about the target software product.
7. Distinguish between a use case and a use case diagram.
8. During requirement elicitation we try to reconcile domain knowledge requirements and use case requirements. Explain the difference between these two kinds of requirement. Should one of them take precedence over the other in the requirement determination process? Give reasons why.
9. Describe the typical structure of a requirement specification document.
10. Requirements specification of a patient monitoring system is given below.
Answer the remaining questions based on this:
a. Patients are taken to the hospital and discharged from a hospital. The patients can be in the regular ward, in the intensive care unit (ICU) or in the monitored aftercare unit (MACU).
b. A patient can be in several wards during his or hers stay in a hospital and within the same ward, different beds can be allocated to him or her.
c. When staying in a ward, it may happen that the patient is outside the bed from time to time (e.g. when an operation is performed). In that case, the moni-toring function has to be interrupted. It has to be resumed as soon as the patient returns into the bed.
d. For each patient the system monitors a set of parameters. Depending on the patient, some patient-specific parameters have to be taken into account as well.
e. New parameters have to be added to the monitoring function when the equipment of the medical practice is changed.
f. The system has to analyze images recorded by the video camera system in order to check the patient’s emotional condition.
g. All ICU- and patients are to be monitored. In the case of MACU-patients, usually the parameters are monitored less when compared to ICU-patients. In all other aspects they are treated the same way.
h. Patients in normal wards are not monitored.
i. ICU-patients are more important than MACU-patients.
j. Patient parameters are monitored by means of analog or digital devices being controlled by software. All devices are equipped with a standard hardware interface providing a digital data output. The data format used in the mes-sages passed at the device’s output depends on the function of the device.
k. The devices are connected to the computer by means of data cables. They are provided by the connector panel that every bed is equipped with. The devices are able to identify themselves; this is way the software can determine which device is connected to which data cable by a simple query.
l. Two limits are assigned to every parameter and every device: standard limits, device limits and patient limits.
m. An ‘‘Excel’’ database application on a PC stores both the parameters of all patients, as well as the messages that came up (alarms and display journal look-up requests).
n. In the nurses room a master display panel is installed. In the ICU room other display panels are used. The MACU rooms are equipped with portable dis-play panels.
o. Three different kinds of messages can be displayed: alarms, status messages and journal look-ups.
p. When requested, the status message of a specific patient can be shown on every display panel.
100 5 Requirements Elicitation
q. A journal look-up returns all journal entries available for a specific patient and can be requested from any display panel.
They system has to be made easy to use and reliable
11. Assign each requirement section to one or more of the following categories:
Functional Requirement Quality Requirement Implementation Requirement Hardware Requirement No Requirement
12. Check if it is possible to meet the requirement in question.
13. Check if the information given by each requirement section is consistent. In the solution table either ‘‘Yes’’ has to be entered, or the number of the requirement section being in contradiction to the current one.
14. Check if the information given by each requirement section is unambiguous.
15. Check if the implementation of the requirement in question can be verified in the system, when the development has been finished.
References
Chung L, Nixon A, Yu E, Mylopoulos J (1999) Non-functional requirements in software engineering. Kluwer Academic Publishers
Christel M G, Kang K C (1992) Issues in requirements elicitation. Technical Report CMU/SEI-92-TR-12
Coleman D (1992) A use case template: draft for discussion. Fusion Newsletter, April 1998 Hill R, Wang J, Nahrstedt K (2004) Quantifying non-functional requirements: a process-oriented
approach. In: Proceedings of the 12th IEEE International Requirements Engineering Conference
Holtzblatt K, Beyer H R (1995) Requirement gathering: the human factor. In: Communication of the ACM, vol 38
Keil M, Carmel E (1995) Requirement gathering: the human factor. In: Communication of the ACM, vol 38
Maciaszek L A (2001) Requirements analysis and system design. Addison Wesley
Malan R, Bredemeyer D (2001) Architecture resources for enterprise advantage. Bredemeyer Consulting, Bloomfield, Indiana
Pressman R (2005) Software engineering: a practitioner’s approach, 6th edn. McGraw-Hill Sommerville I (2004) Software engineering, 7th edn. Peason Education, Ltd., Boston.
Thayer R H, Dorfman M (1990) System and software requirement engineering. IEEE Computer Society: Press Tutorial
Further Reading:
‘Software Requirements Revision, Objects, Functions and States’, This book discusses the latest, highly practical research results from requirements arena (Alan M Davis, 1993, Prentice Hall).
‘Requirements Engineering: Processes and techniques’ This book covers all aspects of the requirement engineering process and discusses specific requirements specification techniques (G. Kotonya and Ian Sommerville, 1999, john wiley and sons)
‘System and software requirement Engineering’ This is a collection of papers on requirement engineering that includes several relevant articles such as ‘verifying and validating Software requirements’, a discussion of the IEEE standard for requirements documents. (R.H Thayer and M. Dorfman, 1990, IEEE computer Society Press).
102 5 Requirements Elicitation