Requirement analysis

This is the procedure wherein the Business Analysts identify the requirements of the business and document them. These requirements are required for the development process; thus it is important that are business analyst always highlights the requirement as per the priority. By this process the techniques are identified where in the stakeholders will be included to view how the requirements are implemented.

a. Managing the requirement
    i.This is the initial stage of the requirement analysis. The requirement is gathered from the requirement owner and then categorized as per the priorities.
    ii.Requirements are separately mentioned in the points are then analyzed; all the questions pertaining to the requirements are also listed.

b. Planning the requirement
    i.In this stage the requirements are planned as in terms of the resources.
    ii.The Business Analyst identifies how the development process needs to be carried.
    iii.How many resources are required and what will be the per FT cost
    iv.The determination of the timelines and the costing of the project is also carried at this stage

c. Requirement elicitation
    i.This is another important process that requires interaction of both the development team and the requirement owner
    ii.At this stage the requirements are discussed technical and technical solutions are identified.
    iii. In case of non-feasible requirements, some candid solutions are also identified.
    iv. In this interaction the development team lead, the client and the Business analyst all are required to be present.
    v. All the points need to be collated properly as listed as decided
    vi. There are many techniques of requirement elicitation as well, these are:
        1. Brainstorming
This is a session where all the stakeholders (internal as well as external) sit and analyze the business requirements. It is more of a group discussion. The BA plays a vital role here. It is the role of the Business Analyst to jot all the points that are being mentioned in the discussion.
        2. Document analysis
The Business analyst needs to identify the initial requirement as received from the requirement owner. The requirements need to be analyzed and then documented. Each and every detail needs to be analyzed and mentioned. It is important to cover all the functionalities and modules.
        3. Focus Group
This is something like deciding priority in the modules. Which area needs to be focused and which area can be completed at the later stage. It is the job of the project manager to deliver the project within the defined timelines; however it is the job of the Business Analyst to make sure that if the project is not delivered on time, however all the important and high priority modules are completed.                

       4. Interface Analysis
In interface analysis the business analyst identifies the requirements and the interfaces that are to be used by the development team that fit in best in terms of cost and quality. Also the Business analyst needs to check the interface with the requirements.
        5. Interviews
The Business needs to take care that the right person having the knowledge about what is to be done and technologies is only included in the development team. To find the same he needs to carry forward the interviews once the requirements are disclosed and the technologies are finalized
        6. Workshops
It’s the job of the Business Analyst to carry workshops on what exactly is required so that the same is produced. Workshops can also be held for the team in case there are some new technologies that are to be used.
        7. Reverse Engineering
After analyzing all the requirement, the Business Analyst needs to sit with the developmental head and discuss how far the reverse engineering of the project is possible. How many of the modules can be made as standard modules which can be used later in some other projects. How many new modules are to be designed etc, all this needs to be understood in this stage.
        8. Surveys
The Business analyst needs to make sure that the requirements he is dealing with, is having some market value. He needs to carry forward all the necessary surveys and also analyze the competitors. After analyzing the survey reports the Business analyst needs to make sure that what all functionalities he is going to document he needs to be the best in the market.
        9. User Task Analysis
This stage is more of less same as defined in #8; the similar functionalities needs to be identified and then Business analyst needs to analyze which form of the functionality most of the users get attracted with. This will give an idea to him that how the things need to be shaped so that the requirements are met in the most qualitative manner.

d. Requirement documentation
To some extent the requirement elicitation and the documentation go hand in hand. In this stage, all the functionalities are required to be defined, in terms of the functionality, user interface and even technology.  The requirements are mostly document by preparing a word doc – which is called “SRS (System / Software Requirement Specifications” or “RUD (Requirement understanding document)”. The document can also be prepared using a matrix (in excel) where in all the functionalities with their sub-functionalities are defined, which is also termed as “Project Plan”.
In this stage there are three main analyses that take place:
        i. Business process analysis
This is the procedure; the input and the output state with the processes involved are documented. The very first step of the Business process analysis involves the understanding of the activities / functionalities with their relation to other activities. Then the process boundaries are marked i.e. the input and the output states are defined. Also in this stage various problems or bottle necks are pre-identified and solutions to these are also documented.
 Also there are many points where the process could get starved. Starvation means that the input is not given however as per the requirements, an output is expected. This is the area of pain and hence needs to be very keenly analyzed. The Business analyst needs to make sure that while creating the interfaces all the modules are related to one another and to every required output there is an input.

        ii. Object oriented analysis
This procedure deals with the analysis of all the modules and their interaction with one another. Thus the software / product / project that is being developed has to be a set of interacting models. Object oriented analysis (OOA) is also used with the Business analyst describes the functionality module wise.
The idea of Object oriented analysis is to conceptually define all the modules as per the requirements and also define all the problems that could be faced while developing a module. It is the job of the Business analyst to answer every question when the product is in the development phase, therefore he needs to make sure that all the portions are covered promptly.

        iii. Structured analysis
This is what we also called software engineering. The structured analysis is used for system analysis. Structured analysis is the procedure of defining how the data will be flowing through the system. This procedure actually makes the Business analyst focus on the pertinent details or the main area or the requirement rather than getting confused from the irrelevant details.

e. Requirement architecture
After the requirement documentation and confirming the same the job of the Business Analyst is to create the architecture of the process to be involved in the development of the product. The requirements are modeled in the form of diagrams. The requirement architecture makes it easier for the internal and the external stakeholders to understand the functionality of the product. The diagrammatic view also helps in defining the relationship of one module with another.
 Thus it decreases the percentage of misunderstanding a functionality of the module.
The techniques for requirement architecture are:
        i. High level diagrams (HLD)
        ii. Low level diagrams (LLD)
        iii. Data flow diagrams (DFD)
        iv. Context diagrams
        v. Entity relationship diagram (ERD)
Tools generally used for requirement architecture are: Visio, Mind Map, Axure etc
The requirement architecture is the pain area for Business analyst, however the easiest way to define the product functionalities in the understandable format. Some important points that are required to be taken care of while requirement architecture are:
        i. Choosing the right bubble to define the data, entity and its relationship
        ii. Segregation of the bubbles
        iii. Document size while defining the module
        iv. Input, Output and flow of the data is required to be identified
        v. Interaction with the other modules
        vi. Mapping of the concepts

f. Requirement prototyping
This phase is mostly recommended for the website designing companies. In this stage the business analyst designs the structure of the pages i.e. how the pages are required to be displayed and which component is required to be displayed where. The prototypes designed by the Business analyst are generally in Grey scale, and not up to the scale. This is just to give an idea to the designers that which component is to be placed where and how the same is to be linked.
After requirement is prototyped, it is sent to the designing stage where the HTML wireframes are created as per the requirements of the client.

g. Requirement communication
After all the defined stages, the Business Analyst communicates the requirements again to the owner as well as to the developer. This is mainly done while giving a demo on the designed wireframes. In this stage the confirmation on the requirement is taken and also the development lead gives the feasibility and confirmation on the development of the module (whether the module can be developed or has to be modified etc.). Requirements should be communicated very wisely thus it may require some series of session. Remember the time given at this stage is the time saved in the implementation phase.
h. Solution analysis and validation
After the development is over, the Business analyst needs to sit with the development lead and analyze the solutions that have been developed. He needs to clearly see that the development has been made as it was documented and also needs to check whether the result is as per the requirements.
This procedure actually needs to be carried eventually after – the development of a module and also after the integration of the two or more modules. Only after the validation the Business analyst needs to forward the same to the client for his final consent.
Remember once the functionality is confirmed and frozen, no changes from the developer’s end should be made. Also the Business analyst needs to make sure that the requirements are met as per the timelines as he had mentioned in the initial stages of the business analysis.
Also the job of the business analyst is to make sure, that in case the project does not meet the timelines; still all the prioritized modules are completed within the given timelines.

i. Final implementation

The presence of Business analyst needs to be present when the product is finally implemented. He needs to be there with the team as the final product might require some minor tweaks. After the implementation, he is required to give the final demo to the client.
Note at this stage, if all the points of business analysis as defined above are ideally followed there are minimal chances of error. After giving a successful demo and getting a final sign off, the job of the Business Analyst is to handover the project to the project manager; and gets assigned to the new project. 

Home :: Disciplines :: Requirement Analysis