Requirements analysis is usually the first phase of a large-scale software development project. The purpose of this phase is to identify and document the exact requirements for the system. It is undertaken after a feasibility study has been performed to define the precise costs and benefits of a software system. In cases where the requirements are not clear, much interaction is required between the user and the developer. There are two major activities in this phase: problem understanding or analysis and requirement specification. In problem analysis, the analyst has to understand the problem and its context.
The Software Project is initiated by the client’s need. In the beginning, these needs are in the minds of various people in the client organization. The requirement analyst has to identify the requirements by talking to these people and understand there needs. Analysis also required to add ‘new features’
when automating an existing manual process. Such analysis typically requires a thorough understanding of the existing system, parts of which have to be automated. A clear understanding is needed of the important data entities in the system, major centers where action is taken, the purpose of the different actions that are performed, and the inputs and outputs. This requires interacting with clients and end users, as well as studying the existing manuals and procedures. With the analysis of the current system, the analyst can understand the reasons for automation and what affects the automated system might have.
Understanding the existing system is usually just the starting activity in problem analysis, and it is relatively simple. The goal of this activity is to understand the requirements of the new system that is to be developed. Understanding the properties of a system that does not exist is more difficult and requires creative thinking. The problem is more complex because an automated system offers possibilities that do not exist otherwise. Consequently, even the client may not really know the needs
of the system. The analyst has to make the client aware of the new possibilities, thus helping both, client and analyst, determine the requirements for the new system.
In Software Requirement Analysis, there are two main concepts –
1. State – A state of a system represent some conditions about the system. When using state, a system is first viewed as operating in one of the several possible states, and then objects based analysis is performed for each state.
2. Projection – In projection, a system id defined from multiple points of view. While using projection, the system is analyzed from these different viewpoints. The different ‘projections’ obtained are combined to form the analysis for the complete system.
There is no defined methodology used in the ‘Informal approach of Analysis’. The analyst will have conducted a series of meetings with the clients and end-users. They provide explanations to the analyst about their work, their environment and their needs. Any document describing the work or the organization may be given, along with outputs of the existing methods of performing the tasks. Once the analyst understands the system he conducts the next few meetings to seek clarifications of the parts he does not understand. In the final meeting, the analyst essentially explains to the client what he understands the system should do. Once the problem is analyzed and the essentials understood, the requirements must be specified in the requirement specification document. For requirement specification in the form of a document, some specification language has to be. The requirements document must specify all functional and performance requirements; the formats of inputs and outputs; and all design constraints that exist due to political, economic, environmental, and security reasons. Software Requirement Analysis (SRA) ends with a document called ‘Software Requirement Specification (SRS) which describes the complete external behavior of the proposed software.
The SRS is a document that completely describes what the proposed software should do without describing how the software will do it.
The basic goal of the requirement phase is to produce the SRS, which describe the complete external behavior of the proposed software.
Need of SRS
There are three major parties, interested in a new system – 1. The Client
2. The User and 3. The Developer.
Somehow, the requirements for the system that will satisfy the needs of the clients and the concerns of the users have t be communicated to the developer. The problem is that the client usually does not understand the software and the development process, and the developer often does not understand the client’s problem. This causes a communication gap between the parties involved in the development project. SRS is the medium through which the client and user needs are accurately specified; a good SRS should satisfy all the parties involved in the development process.
Validated SRS Problem
Analysis Product Validation
description Client
/ User needs
Figure 7.2: The Requirement Process
Advantages of SRS
1. SRS establishes the basis for agreement between the client and the supplier on ‘what the software product will do’. Through SRS the client clearly describes that what he expects from the supplier, and the developer clearly understand that what capabilities to build in the software. Without such agreement it is almost guaranteed that once the development is over, the project will have an unhappy client and unhappy developer.
2. SRS provides a reference for validation of the final product. The SRS helps to the client to determine whether the software meets the requirements or not. Without SRS, there is no way for developer to convince the client that all requirements have been fulfilled.
Table 7.1: Cost of fixing requirement errors
Name of the phase Cost (person-hrs) Requirement Analysis
Design Coding
2 5 15 Acceptance test
Operation and Maintenance
50 150
3. If we want a high quality final software that has few errors, we must begin with a high quality SRS.
4. A high quality SRS reduces the development cost. High quality means, customer’s and developer’s satisfaction, system validation, high quality of the final software and the reduced development cost.
7.7 Summary
‘Requirement’ is a condition of capability, needed by a user to solve a problem or achieve an objective. Some requirements are specific to an application domain, these requirements are known as ‘Domain Requirements’. The process of acquiring domain specific knowledge/information through various techniques to build the ‘Requirements Model’ is called ‘Requirement Elicitation’. The
‘Requirements Elicitation’ activity is concerned with understanding of problem domain at the starting of the project. The ‘Requirement Specification’ activity is required to produce formal software requirements models. The ‘Requirement Validation’ activity is usually defined as a process to ensure the constancy of requirements model with respect to user’s needs. ‘Software Requirement Specification (SRS) is a document which describes the complete external behavior of the proposed software.
SRS establishes the basis for agreement between the client and the supplier on ‘what the software product will do’.
7.8 Self Assessment Questions
1. What is meant by ‘Requirement Engineering’? Indicate its importance.
2. Discuss different types of requirements.
3. What are non-functional requirements?
4. What do you understand by requirement elicitation?
5. Differentiate between functional and non-functional requirements.
6. What is Software Requirements Specifications (SRS) document? Outline its goals.
7. Explain and illustrate the ‘Requirement Engineering Process’.
8. What are the effective ways to validate requirements?
9. What are the key challenges in ‘Eliciting Requirements’?
10. Discuss about need and advantages of SRS.
7.9 References
Pressman R.S., ‘Software Engineering: A Practitioner’s Approach’, (Fifth Edition), McGraw-Hill, 2001.
Keswani Bright, ‘Software Engineering’, (First Edition), Genius Publications, 2009.
Jalote, Pankaj, ‘An Integrated Approach to Software Engineering’, (Second Edition), Narosa Publishing House, 1997.
Puri S. and Singh G., ‘Software Engineering Vol. 1’, (Fourth Edition), Genius Publications, 2008.
Sommerville I., ‘Software Engineering’, (Sixth Edition), Pearson Education, 2002.
Schach S.R., ‘Software Engineering’, (Seventh Edition), Tata McGraw-Hill, New Delhi, 2007.
Mall R., ‘Fundamentals of Software Engineering’, (Sixth Edition), Prentice-Hall of India, 2002.
Gill N.S., ‘Software Engineering: Software Reliability, Testing and Quality Assurance’, Khanna Book Publishing Co (P) Ltd, New Delhi, 2002
Sabharwal S., ‘Software Engineering: Principles, Tools and Techniques’, (Second Edition), Umesh Publications, Delhi, 2005.