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 the
users are the operational people—the persons who issue books at the
counter, 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 the
developer.
• 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 by studying 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 requirements
and non-functional requirements.
• For the information in the functional requirements, identify the various
types of users and obtain the perspective of each user on the
functionality of the software.
• Obtain the common features desired by all the users and the optional
features as desired by some users.
• Prioritize the features required. This is an important step, if there is a
time constraint on the implementation, the developer can negotiate
with the client on the features that can be implemented in the given
time frame.
• While obtaining the requirements, lot of assumptions are made. List
each and every assumption made and ensure the validity of the
assumptions by discussing with the client and the users.
• Document all the features with a clear numbering scheme for each and
every 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 which
paper forms are used or a process defined on paper is used. The requirements
engineering team has to study the existing system in detail. Sometimes, a legacy
system may be in place which is either semi-automated or fully automated. The
detailed operation of this system has to be analyzed, and the drawbacks of the
present 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 the
requirements. 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 there
is a clash between the client’s and the users’ requirements, then the issues need to
be 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 the
software 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 standard
methodology such as UML, the requirements have to be documented.
6. Construct a prototype: Even after interviewing the users and the client, if the
requirements are not very clear, the development team may decide to develop a
prototype. This prototype has to be demonstrated to the users and the feedback
obtained. 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 requirements External 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 SRS
and 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 any
national 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 between
the oral and written communication may lead to problems.
• Because of the vagueness of the natural language, the vagueness may
creep 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 to
bring quantitative measures to describe such parameters. The
validation process helps in doing this.
• While obtaining the requirements, enough thought is not given to its
implementation possibilities. There is no point in specifying what
cannot be implemented. During the validation process, the
specifications need to be looked into from design and implementation
points of view and if a specific requirement cannot be implemented, it
needs to be informed to the client.
• We tend to write such phrases such as ‘perhaps’, ‘to the extent
possible’ etc. Such phrases need to be eliminated in a technical
document, the validation process is used for eliminating such
vagueness.
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.
• Because of the communication gap between the users (who may not be
computer literate) and the developers, there may be gaps in the user
requirements.
• Though the development team understands the requirements
completely, because of lack of documentation expertise, many
requirements continue to reside only in the minds of the people who
did the system study, and not on the paper.
• During the system analysis phase, the analysts make many
assumptions and in later phases realize that these assumptions are not
correct.
• Because of our inability to foresee problems (say, in design stage), we
will be confident that a particular requirement can be implemented.
However, in later stages, we realize that we cannot implement it
calling for changes in the SRS document.
So, the project manager has to accept the fact that changes in SRS are very likely and plan for managing the changes. The project manager has to ensure that all the assumptions made during the SRS preparation are documented, and whenever any of the assumptions is proved wrong, study its impact, and also study the impact whenever a change in specification is called for. The impact can be on the time frame, cost or both. Sometimes a small change in requirements may lead to a situation where the whole project has to be abandoned.
In large projects, wherein SRS document runs into hundreds of pages and hundreds of people work on the project, a person may make a change in the requirements without the knowledge of others. This may lead to serious troubles while integration of the software. Each and every person working on the project should be aware of the changes being made to the SRS to ensure that a change initiated by a person does not have adverse impact on the module being developed by another person or on the total system.
To study the impact of changes in SRS and to make the changes through a defined procedure are crucial for the success of the project. These issues are discussed in this section.
Impact of Changing the Specifications
Every change that is proposed to the SRS document will have an impact on the time frame or budget or the quality of the product. Sometimes, a proposed change may lead to a situation where the technology limitations may make it impossible to develop the software even. So, if the proposed change is accepted without studying its implications and impact, the developer may find himself in a difficult situation.
A change can be proposed by the client or it may be initiated within the development team. In either case, each proposal for change should be carefully evaluated. The change can be categorized based on its impact being Small, Medium or High.
Changes with small impact can be incorporated easily. Such changes include changing the format of the GUI screens, changing the navigation in a GUI environment, adding new error messages, adding new help topics etc. If the number of such changes is limited to a certain quantity, there may be no adverse effect on the time frame or budget.
Changes with medium impact such as adding a help engine which was not specified in the requirements, adding new screens in GUI or generating some additional reports, will result in more effort and subsequently affect the time frame as well. In such a case, the additional effort and budget need to be worked out and informed to the customer.
Changes with ‘High’ impact such as introducing new performance specifications (e.g., the database retrieval should be within 5 seconds), interface to an existing legacy database which was not given as a requirement earlier, etc. may call for a total redesign of the software, and sometimes the whole implementation that has been done needs to be abandoned. Such situations arise when the user is naive and gives the project without understanding all the implications and slowly keeps adding new requirements and then the bombshell, which makes the whole system a new one. The development team has a difficult job—the team needs to make the client appreciate the impact of the proposed change and its implications in terms of time and cost. If the client is convinced, then the two can work out a migration plan whereby the present software can be used and the new requirements can be incorporated in a gradual phased manner. If the client cannot be convinced, both the client and developer have to go back and refer to their original agreement as regards the terms and conditions of the contract and based on what is written, meet at the battle ground—the court of law.
Managing Changes in Requirement Specifications
In spite of the best efforts, there are very few projects, in which the specifications will be frozen once for all. It is likely that the specifications will change during the course of the development. However, a baseline specifications document has to be prepared and whenever there is a change in the specifications, the document needs to be modified. In large projects where multiple groups are working on the project, the changes cannot be done on ad hoc basis.
When a change is initiated, the impact of the change has to be studied and only when the impact is minimal, then it can be accepted. If the impact is very high, the effect on the time frame, budget and other factors need to be discussed with the concerned persons (the senior management, client, quality team etc.) and whether the change should be accepted or rejected should be decided.
The SRS has to be kept under configuration management so that the changes made to the SRS are known to everyone and the changes are tracked.
The changes being made to the SRS have to be documented using the format given in Table II.
SRS document change request form Change request serial number Change request details
Stage at which change is proposed (e.g., Design, coding, testing, maintenance) Change initiated by: (client, development group, quality group) Severity of change based on impact (on time or budget): Small/Medium/High Date of approval of the proposed change: Date of communication to the client on the change: Date of acceptance by the client:
Table II. SRS document change request form Metrics for Requirements Change Management
The number of change requests made and the number of change requests approved during various phases of the life cycle are the important metrics in requirements change management. The status of each requirement change and change request frequency must be also recorded.
For each change request made, a record has to be maintained which gives the change number (the id), the impact (small/medium/high) and the effort for implementation of the change. If the total effort exceeds a threshold, then the senior management and the client have to be alerted on the too many changes being made to SRS.
The requirements change management process has to be followed even during the maintenance phase. When a change in functionality or performance parameter is asked for, the developer has to correspondingly make the necessary changes in the SRS document through the change request procedure.
