IIBA Definition of a business analyst role

A Business Analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The Business Analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

22 Steps to a successful project

1. Clear,complete,accurate,consistent,compact documents.

2. Redundancy of information should be avoided always.

3. Scope Creep. Almost always happens. Tough to deal with but be prepared.

4. Document all communications/evidence/proof. If you don't, it bites you back later on.

5. Never commit/promise to users just based on what YOU think could be an easy turnaround. Always discuss with the correct parties involved first.

6. Keep things as simple as you can. You don't want to explain code to a business user necessarily and confuse them. Talk the language accordingly. Remember, your customers are more interested in the WHAT and not the HOW.

7.Create a context diagram, which defines our system and things that'll interact with our system.

8.Define actors and their goals.Ask questions like Does anyone will get any info from the system,Who'll maintain/install the system etc.

9.Identify how each actor will initiate or interact with the system to find out basic course of event.

10.Maintain a glossary of all the business terms.

11.Identify business rules and constraints.

12.Identify nonfunctional requirements like GUI look and feel,security,reliability,data retention etc.

13.Try to ask question in client's language because if you ask questions in their language they can understand your question better so try to learn business domain of client,their business terms etc.

14. Perform Functional & Source Data Flow Review. Keep the client in loop of whats feasible & whats not feasible

15. Document and keep the client in loop on all the assumptions in design / development phase

16. Before final delivery its very essential for a BA to perform a high level funtional review / testing of the client requirement

17. Identifying dependencies / Escalation of risks / issues likely to affect the design / development / testing phase & follow-up with the risk mitigation, resolution of issues with respective teams well in time.

18. Follow-up for a signoff & request feedback once the requirement is delivered / freezed & in use for a substancial period.

19. Keep Monitoring & try to suggest better solutuions / approaches for deliverables incase of recurring requirements (eg: reports).

20. Always try to identify the risk items at early stage. Try to build the prototype of those to seek appropriate clarifications at early stage of the project

21. Try to find out the improvement areas which can be modified/improved/enhanced in further phases.

22. Don't give surprises, instead keep your project team and clients informed about your progress and the solution you are working on.

Been a long time since i posted ... will make a resolution to be more active.

Just came across this paragraph, which neatly defines what a software should be.

Great software should do what it is supposed to do, while remaining highly maintainable, scalable and adaptable to change. It should be bug free, and easy for the users to use.

What approach should a business analyst take when gathering requirements from high level executives versus the end users?

For the most part, the methods and techniques for gathering requirements are the same regardless of whom the stakeholders are: interviews, focus groups, questionnaires, requirements workshops.


However, there are definite things that the business analyst should consider when gathering requirements from high-level executives vs. the end users. The business analyst should tailor his approach and expectations based on the stakeholder type.


Here are some ideas, side by side:

	High-Level Executives	End Users
Requirement Types	Generally provide vision and high-level guidance on the direction of the project. They address key features and major problems to be addressed by the software.	Can provide detailed needs and requirements as related to their specific day-to-day jobs.
Usability	Are less focused on detailed usability issues but may be interested in general UI and usability guidelines.	Are more interested in the usability of the system as they are the power-users. They want the system to be easy to use and efficient (ex: minimize keystrokes and clicks)
Budget/Cost	Are very concerned with the cost and budget of the system therefore will be more likely to prioritize requirements and focus on the ones with higher ROI.	Less concerned with cost, therefore might provide all kinds of “nice to have” suggestions which may not solve real business problems.
Interviews	Effective method of gathering requirements from this group.	Effective method of gathering requirements from this group.
Questionnaire	Not a good way to gather requirements from executives. The execs may actually be the ones approving the questionnaires before sent to end users.	A valuable tool when certain statistics need to be collected from a very large number of potential end users and stakeholders.
Requirements Workshop	Effective method of gathering requirements from this group. It is desirable to have all the decision-making stakeholders in the room when identifying the requirement rankings and when making key design decisions.	Effective method of gathering requirements from this group. It is a good idea to have a number of workshops one for each user type (ex: advanced users vs. most users vs. new/inexperienced user).
Time Availability	High-level executives are very busy so the business analyst must be very well prepared before meeting with this group of stakeholders. Be prepared to focus on the most important problems, issues, questions, etc. The business analyst should use this group to ensure that the direction and goal of the project is clear and well understood.	With this stakeholder group, you might have the luxury of time and ability to cycle back later to clarify requirements. Having said that, these users tend to be less experienced so the business analyst must be able to present the information in simpler and easier to understand ways.

Source: ModernAnalyst.com

What does a requirements document contain?

The reality is that there isn't such as thing as a standard requirements document template to help guide the business analyst in the creation of this document.

The format of a Requirements Document vary depending on the type and size of project, type of organization, maturity of the business analysis team, use of specialized requirements management tools, type of methodology and development process(agile vs. RUP vs. structured analysis), etc.

Having said that, here are some common types of information found in many requirements documents:

* Background/History
* Scope and Objectives
* Regulatory Requirements
* Business Level Requirements
o Strategic
o Tactical (Interoperability)
o Operational (Process related mostly)
* Stakeholder and User Analysis
* User Requirements (the abilities that the users need)
* Functional Requirements
* Non-functional Level User Requirements
* Assumptions/Constraints
* Risks and Dependencies
* Solution Options
* Business Glossary (the nouns and noun-verb phrases of the business)
* Reference to Business Rules
* Reference to Business Case/Vision
* Use Case Models

One more observation: requirements documents are also known by a variety of names which, at times, mean the same thing and, other times, refer to totally different documents:

* Requirements Document
* Business Requirements Document (BRD)
* Software Requirements Document
* Software Requirements Specification (SRS)


Source ModernAnalyst.com

Requirements Prioritization

Once a set of requirements has been identified, it is often the case that they need to be prioritized. Due to time and budget constraints, it is often difficult to implement all the requirements that have been elicited for a system. It may also be the case that the requirements are implemented in stages, and prioritization can help to determine which ones should be implemented first. Many organizations pick the lowest cost requirements to implement first, without regard to importance. Others pick the requirements that are easiest to implement. These ad hoc approaches are not likely to achieve the goals of the organization or the project. To prioritize requirements, one needs a very systematic prioritization approach. One needs to have a mature trade-off analysis that can be done to select a suitable requirements prioritization method and which reflects the goals of the project within the resource constraints. While results may vary from one organization to another, or for that matter one analyst to another, prioritization absolutely should have stakeholders involvement. Much work needs to be done before requirements prioritization is a mature area, but it is one that we must start to address.

Analysis Time Creep

Business analysts are rarely allowed enough time to elicit, analyze, and confirm requirements. Why? One reason may be that we don't ask for it. An important BA skill is the ability to accurately estimate the amount of time required to perform analysis work and be able to explain and justify it to project managers and sponsors. Often they don't know why requirements take so long to "gather" because the word "gather" implies a BA with an Easter basket walking along the grass scooping up brightly colored eggs! It looks so easy!!

The best way to request and receive enough time is to build your case. You must be able to explain to the sponsor what you will be doing during that time and why your work is important. My suggestion is that you develop estimates by breaking tasks down into very small pieces. The smaller the task, the easier and more accurate the estimate. This detail also helps you justify the time. Let me give a small example - if one of my requirements deliverables is a Use Case diagram my task list might be:

Review project initiation documentation and draft UC Diagram 3 hours

Schedule stakeholder meeting (find room, call participants, prepare agenda) 1 hour

Conduct stakeholder meeting (present draft UC, get revisions) 2 hours

Revise UC diagram based on meeting 1 hour

Consult with IT architect to confirm feasibility 1 hour

Schedule review meetings with key stakeholders 2 hours

Conduct review meetings and ask for approval of UC Diagram 4 hours

By listing everything that you will have to do (including setting up meetings, etc) you will get an accurate picture of the time required. Remember these are work times - not lapse time. This is the amount of time that you would need if you were not working on ANYTHING else. Be sure to built in reviews and revisions as they will always be necessary. The less confident you are about the expected outcome of elicitation meetings, the more reviews/revisions cycles you should build it. Once you estimate, keep track of your actual work time so that you can learn and estimate even more accurately in the future.