Software requirement specification
Software projects, for which the development starts without a clear and detailed understanding of the requirements of the customer, are bound to result in failure. And, if the project manager takes a stand that the development will not start till the customer gives all the requirements, the project may not take off at all. To obtain the ‘minimum necessary’ requirements is crucial for the project to move forward and at the same time, it has to be ascertained that no major risk is being taken through a wrong assessment of the complexity of the project.
The Requirements Engineering Process
The requirements engineering process involves preliminary study (elicitation), analysis,specification, verification and management of the requirements of the customer. This is the most important stage in software development life cycle as the success of the project is largely dependent on this stage.
The input to this process is broad problem definition e.g., “develop library automation software”. The output of this process is an SRS document that can be used by the design team to carry out the detailed design.
Why SRS?
SRS bridges the gap between the customer/client and the developer. Specifically, with SRS,
• Client and user are clear of what is expected of the software [Note: it is
very important to distinguish between the client and user. For instance,for the library automation software, the client is the librarian, but theusers are the operational people—the persons who issue books at thecounter, the persons who verify the stock etc.]
• Developer is clear about the scope of the work.
• SRS acts as a formal (legal) document between the client and thedeveloper.
• SRS phase reduces the overall development cost.
• SRS provides a reference for validating the final product.
Tasks in software requirements engineering stage: Software requirements engineering stage can be further divided into three stages viz., requirements analysis, requirements specifications, requirements validation, as shown in Fig. 1.
Requirements Analysis
The first step in requirements engineering is to obtain the requirements from the user.This is a very complex task. The user gives a very vague problem definition. From the definition, the development team has to obtain clarity. This is done through formal and informal interactions with the client and the users, internal discussions amongst the team members and again interaction with the client. This is an iterative process that results in more and more clarity at the end of each iteration.
In this section, we discuss how the requirements analysis can be done in a structured way and the various methodologies used at this stage.
Structuring Information
To carry out the requirements analysis by interviewing the client and the users or bystudying the existing system (manual or semi-automated), lot of formal methods are used, notable among them being the context diagrams and data flow diagrams.
The following guidelines help in structuring the information.
• Divide the requirements into two main parts: functional requirementsand non-functional requirements.
• For the information in the functional requirements, identify the varioustypes of users and obtain the perspective of each user on thefunctionality of the software.
• Obtain the common features desired by all the users and the optionalfeatures as desired by some users.
• Prioritize the features required. This is an important step, if there is atime constraint on the implementation, the developer can negotiate
with the client on the features that can be implemented in the giventime frame.
• While obtaining the requirements, lot of assumptions are made. List
each and every assumption made and ensure the validity of theassumptions by discussing with the client and the users.
• Document all the features with a clear numbering scheme for each andevery feature. The numbering scheme would facilitate easy tracking
while doing the design and implementation.
Natural language continues to be the main vehicle for communicating the requirements particularly for business applications; though formal methods such as finite state machines, regular expressions etc. are used for projects involving development of software tools or embedded system software.
Requirements Analysis Methodologies
To analyze the requirements, the following methodologies are used.
1. Study the existing system: The existing system may be a manual system in whichpaper forms are used or a process defined on paper is used. The requirementsengineering team has to study the existing system in detail. Sometimes, a legacysystem may be in place which is either semi-automated or fully automated. Thedetailed operation of this system has to be analyzed, and the drawbacks of thepresent system and the enhancements required need to be studied in detail and
documented.
2. Interview the end users: The end user perspective is very important for therequirements. The end users have to be interviewed on the functionality required.
3. Interview the client: The client’s expectations are not necessarily same as those of
the users. The client has to be interviewed and the requirements obtained. If thereis a clash between the client’s and the users’ requirements, then the issues need tobe sorted out.
4. Construct use-case scenarios: The use-case scenarios need to be constructed.Assume that the software has already been developed. How a typical user uses thesoftware has to be captured in the use-case scenarios. Each use-case scenario will
be in the form
Pre-conditions Operations Post conditions
The pre-conditions are the status of the software before using a particular functionality. Operations give details of the functions to be performed by the user and the outputs obtained after performing the functions. Post-conditions are the status of the software after using the functionality.
5. Model the system using Unified Modeling Language: Using a standardmethodology such as UML, the requirements have to be documented.
6. Construct a prototype: Even after interviewing the users and the client, if therequirements are not very clear, the development team may decide to develop aprototype. This prototype has to be demonstrated to the users and the feedbackobtained. Using the feedback, the requirements can be finalized.
In the case of a product development, the process is essentially the same except that the users are the marketing persons or the market research analysts.
After obtaining the requirements, the development team has to document the requirements and obtain the approval of the client and the users.
Requirements Specifications
Requirements can be categorized into functional requirements and non-functional requirements. While documenting the specifications, these two requirements need to be documented separately. We discuss these two types of requirements in this section.
Functional Requirements
The functional requirements form the core of the specifications. The client gives a very broad problem definition such as “develop an order entry system” or “develop an inventory management system” or “develop a knowledge management tool”. From this problem definition, the process involves writing the detailed functional requirements.
For writing the functional requirements, the first step is to identify the target users of the software and divide the users based on the functionality they require. For instance, the database management software consists of the following types of users: administrators, developers and operators. Again the operators can be further divided into different categories, those who generate reports, those who modify the database etc. After categorizing the types of users, for each type of users, the functional requirements have to be identified. This is best done by the use-case scenario construction.
In all applications, the user interface is of utmost importance. The user interface is also likely to undergo many changes. For a user-friendly interface, the two important requirements are help and error messages. The requirements for the help and error handling are to be obtained from the users.
Though formal methods are available, natural language continues to be the best way of representing the functional requirements.
As shown in Fig. 2, the non-functional requirements [Ian Sommerville, Software Engineering (5th Edition), Addison Wesley Publishing Co., 1996] can be categorized as
Product requirements Process requirementsExternal requirements
Product requirements: The product requirements are
Reliability: The goal is to develop highly reliable software. However, while writing the requirements, one has to be more specific and quantitative. For example, a reliability requirement can be in terms of the Mean Time Between Failures (MTBF). For instance, an MTBF value of at least 10,000 hours can be one quantitative measure for reliability i.e., the software should not fail more than once in 10,000 hours of operation. In such a case, the total testing time has to be measured (when a large number of users are testing the software) and the cumulative test time has to be taken and there should not be a failure for at least 10,000 hours.
Portability: If the software has to work on different platforms (hardware or Operating Systems), the list of all such platforms has to be given in the requirements.
Usability: It is difficult to measure the usability or user-friendliness of the software package. So, a feedback form has to be designed which can be filled up by the users. This feedback form will have provision for comments by the users on various aspects, the help provided, whether the error messages are meaningful, whether the number of key strokes can be reduced or the number of mouse clicks can be reduced etc. However, it is better to avoid subjective descriptions such as the interface is ‘good’ or ‘not user-friendly’.
Performance: The performance parameters include response time (for example, when a database query is given) and throughput i.e., the effective data rate in case of data transmission. Space required (secondary storage i.e., disk space or primary storage i.e., RAM) to run the application is also an important requirement. The performance and space requirements together come under the category of efficiency requirements.
Process requirements are
Delivery time (timeframe for commissioning the software)
Implementation requirements (hardware, software environments in which the
software has to be developed, the special tools required etc.)
Standards to be followed if any (for example, IEEE or Department of Defense
standards for documentation, International Telecommunications Union standards
for protocol implementation etc.)
External requirements are
Safety requirements
Privacy, security requirements (whether encryption is required to store or transmit
data)
Interoperability requirements (whether the software has to operate in conjunction
with any other software and/or hardware)
Ethical requirements (confidentiality of the product etc.)
Legal or legislative requirements
Some of these non-functional requirements may not be applicable for the project/product under consideration. However, the project manager has to study whether any of these non-functional requirements need to be specified, and if yes, discuss with the client and document them.
Structure of SRS Document
The format of the SRS document is given in Table I which is derived from IEEE Software Engineering Standards Collection (1994 Edition), IEEE Press, 1994.
1. Introduction
1.1 Purpose of the SRS document
1.2 Scope of the document
1.3 Definitions, acronyms, abbreviations used in the document
1.4 References
1.5 Overview of the document
2. General description
2.1 Product description giving the overall product features
2.2 Functionality of the product
2.3 User characteristics (types of users, such as administrators, operators)
2.4 General constraints in the development of the product
2.5 Assumptions and dependencies (assumptions made in the preparation of the SRSand the external systems on which the software is dependent)
3. Functional requirements
3.1 Introduction
3.2 Inputs
3.3 Outputs
3.4 Processing details
4. External interface requirements
4.1 User interface
4.2 Hardware interface
4.3 Software interface
5. Non-functional requirements
5.1 Product requirements
5.1.1 Reliability
5.1.2 Portability
5.1.3 Usability
5.1.4 Performance requirements
5.2 Process requirements
5.2.1 Delivery schedule
5.2.2 Hardware/Software requirements
5.2.3 Standards compliance (whether the software has to conform to anynational or international standards)
5.3 External requirements
5.3.1 S afety requirements
5.3.2 Privacy/Security requirements
5.3.3 Interoperability requirements
5.3.4 Ethical requirements
5.3.5 Legal or legislative requirements
6. Design constraints
7. Hardware limitations
8. Version related issues (whether all the features will be implemented in Version 1.0 or
any future versions are foreseen).
Table I. Structure of SRS document
Requirements Validation
After preparation of the SRS document, the next step is to validate the document i.e., to ensure that the document captures all the necessary information. This step is important because
• During oral interaction with the customer, information is obtained.The same interpretation may not be put in writing. The gap betweenthe oral and written communication may lead to problems.
• Because of the vagueness of the natural language, the vagueness maycreep into the specification document as well. To the extent possible,the vagueness needs to be removed.
• While writing the specifications, we tend to use adjectives such as‘fast’ response time, ‘minimum’ execution time etc. One has to try tobring quantitative measures to describe such parameters. Thevalidation process helps in doing this.
• While obtaining the requirements, enough thought is not given to itsimplementation possibilities. There is no point in specifying whatcannot be implemented. During the validation process, thespecifications need to be looked into from design and implementation
points of view and if a specific requirement cannot be implemented, itneeds to be informed to the client.
• We tend to write such phrases such as ‘perhaps’, ‘to the extentpossible’ etc. Such phrases need to be eliminated in a technicaldocument, the validation process is used for eliminating suchvagueness.
So, validation is an important step to eliminate the vagueness, to ensure that the document is complete and also to ensure that the specifications can be implemented.
Characteristics of a Good SRS Document
The SRS document should have the following characteristics [IEEE Standards Collection, 1994]:
Unambiguous: Ensure that the document has no ambiguities because of the natural language used for writing the document.
Complete: Ensure that all the requirements of the client are covered in the SRS.
Verifiable: Ensure that every functional and non-functional requirement specified in the SRS can be verified while testing the software.
Consistent: Ensure that there is no inconsistency in different portions of the document.
