Business Analysis - Requirement Related Activities

Some of impactful Business Analysis related activities which should be kept in mind from start till end of the project are given below.The approach below fits into any methodology (SCRUM, RUP- Rational Unified Process is an iterative software development process , waterfall, iterative process).

Identify Business Objectives

Business objectives are the single most important thing that every project should understand and define so that all efforts can be prioritized against the value that the project is delivering to the business. Some projects will need additional definition around key performance indicators (KPIs) as well, to ensure that they maintain performance standards from existing systems and processes in place as replacement systems are deployed.

Cut Scope
Most features in software are never used so it is better to cut them up front and never develop requirements for them or implement them in the software. Significant time and money can be saved by making such drastic scope cuts.

Elicit Requirements
There are many different techniques to elicit requirements and their priorities, including workshops, facilitated interviews, observations, or prototypes. The techniques used on a project will be very specific to the type of project, the stakeholders, the stage and even the type of organization. Most projects require some combination of many elicitation techniques.

Visually Model Requirements
Requirements models are essential to communicate requirements in a consumable way and to ensure that requirements are not missing during analysis.

Transition Knowledge 
As requirements efforts progress, the business, the business analysts and product managers increase their knowledge about what they want the end product to be. It’s important though that the development and test team gain that same knowledge rather than tossing some specifications over the wall. It is useful to track issues against requirements throughout this activity to track their questions about requirements because a lack of issues is great indication that teams are not consuming sections of the requirements.

Manage Requirements Change
One thing is constant on all projects - is that requirements and their priorities change. It is important to have a process in place that works for the organization to whatever level or rigor is appropriate. The hardest part of this is as lead stakeholders change or business priorities evolve, requirements might change, but more likely, their priorities will change and the scope of the project will change accordingly.

Deploy Solutions
In order to ensure successful user adoption of the new software - careful attention needs to be paid to training materials and user acceptance tests. Various requirements models like -  Use Cases, can be used to create user acceptance test scripts that the business users can execute. Similarly, many of the models can be converted into training materials so they can learn about the new system while minimizing training material development effort.

Evaluate Success
Excellent requirements are never the goal. The real end goal is to deliver successful products/services. Success is very specific to a business’s needs and the criteria for success is set early by understanding business problems and business objectives. After a project launches, the success should be measured to determine what additional changes are needed, such as additional features, training or maybe marketing support. The goal is to maximize the return on investment and learn for future projects and the only way to do that is to understand what it is after projects are done.

All of these requirements-related activities are important in delivering successful projects at a lower cost and on time.

The content of this post has been taken from various websites.