Requirements Analysis Steps

Understanding the software requirements and converting them into specifications for development is a very detail oriented process. This process requires a complete analysis of the business process that will be addressed by the software that is going to be developed. This means that one needs to obtain a thorough knowledge of the business domain of the stakeholder. Based on that knowledge the various processes for automation will be mapped to the various use cases and the input/output for each function point needs to be defined accurately during this phase.

Software Requirements Analysis is the most important phase in the life cycle of any software development project. However there are several practical challenges during this phase which can only be handled by an experienced software development firm that possesses the knowledge of software engineering. Our approach towards creating an accurate requirements specification document is a multi phased approach. Depending on the level of clarity, we choose the development model for the project. Below are some of the steps taken during this process:

I. Customer/User Identification : We start the process by identifying the users of the proposed system. This is the first step in the process because the users drive the software and the various functionalities added to the software will only be used by its users. Every person or group of people that are going to be affected by the new system in any way are termed as the stakeholders of the system. Nearly all the use cases for the system are derived from the users of the system. This is done by analyzing their role in the system.

II. Customer Interviews: This is an iterative process and usually takes several interviews to gather the requirements to a level that will help formulate the detailed specifications. It is very common for Stakeholders to be confused about what they want in the proposed system. We identify the wish list during each interview and build that wish list into a requirements document by reviewing it with the Stakeholders and modifying it in an iterative manner. The level of clarity during requirements analysis usually forms the basis for the development model that is chosen for the product. We broadly classify these models as Waterfall and Agile even though there are several models defined in the software engineering process. We believe that all the other models are subsets of these two broad categories.

III. Use Case Analysis : Use case analysis is a technique for identifying the various user functions that will be performed in the proposed software. Use cases describe the system from the user's point of view. These use cases are developed as Unified Modeling Language (UML) diagrams. Each use case diagram is a pictorial representation of actors or users and the functions they perform from the outside of the system. The set of use cases formulate the high level requirements specification for the proposed system. The use cases can be divided into business use cases and system use cases to give a more detailed view into the system.

IV. Data Flow Diagram : This is the pictorial representation of the data flow between the different entities of the system. The data flow diagram gives a clear picture of all the data elements that will be flowing through the various input/output channels of the system. This is a very important phase and requires identification and interaction of various data elements the constitute the system to the lowest level.

V. Usability Diagrams : All the web applications are driven through user interfaces. Under this phase we produce the user interface diagrams on the basis of various use cases and the data identified during the DFD phase. Usability diagram is the key to creating a good user experience. All the user interfaces are clearly defined by outlining the various user controls and the flow from one interface to the other.

VI. Software Requirements Specification : Based on all the steps taken above we arrive at the detailed requirements specification that documents the output of all the different steps and combines them into one specification document. This document is the bible for the proposed system and is circulated among all the stakeholders, users, developers and the testing teams. The document usually requires a sign off by the involved parties to ensure that everybody is in agreement about the proposed system requirements. In several cases the requirements document remains a living document throughout the project life cycle and is modified at several instances. The management of system requirements specification document usually depends on the model of the development process.

The above explanation of the requirements analysis process is a broad level description that provides an insight into the process. The actual process may vary depending on the type of project and preferences of its stakeholders. Under all circumstances we ensure that all the basic steps of this process are followed so we can build the proposed system on a solid foundation.