Monday, February 25, 2008

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 TypesGenerally 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.
UsabilityAre 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/CostAre 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.
InterviewsEffective method of gathering requirements from this group.Effective method of gathering requirements from this group.
QuestionnaireNot 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 WorkshopEffective 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 AvailabilityHigh-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.

A "Business Analyst" (BA) is a role that can mean different things to different people. In some companies, the BA plays a technical role with very little business knowledge; while in other companies, the BA has a full understanding of the business with very little knowledge of the IT systems and architecture.

In today's times - the BA has come to become a person of great value to an organization, and who is a generalist capable of functioning competently in diverse roles. Typically, these people have a broad educational background and a diverse skill set with a wide range of work experience in different jobs and industries. In essence, they are able to visualize the "big picture" - that is - understand the business from different perspectives, as well as the technology side of what can be effectively used to improve the business.

The Business Analyst Skills in a broad perspective comprises of the person being a Business Planner, Systems Analyst, Project Manager, Subject Area Expert, Organization Analyst, Financial Analyst, Technology Architect, Data Analyst, Application Analyst, Application Designer, and Process Analyst.

As we drill down deeper into the specific roles of a BA and understand the essential skills required for each of the roles, it would give a clear picture.

The major roles of a BA, as defined by certification experts are:-


1. Define and Scope Business Areas

The BA must be sure that the project scope is clear and complete before the start of detailed requirements gathering. The BA may be given the scope pre-defined by the project sponsor or may be responsible for defining and documenting the scope as part of the requirements gathering task.

Defining and documenting the project scope requires the BA to understand why the project has been initiated, and the objectives of the project. An important contribution of the BA to the project is the analyzing of the business problem without "jumping" to a solution.

In addition, a complete project scope will name and define all the stakeholders that will be involved with the project, including people, systems, internal departments, and external organizations.

Other important components of the project scope documentation include the project viewpoint, project assumptions, and business risks. These components give the BA the information necessary to prioritize and focus the requirements gathering.

Finally the project scope should include a high-level description of the business processes. It may also include a list of items that specifically will not be included in the scope. This gives the entire project team a complete understanding of the work that the BA will be doing during the detailed requirements gathering phase.

One additional task required of the BA, is the creation of an organized system for maintaining project information. A glossary should be started along with a filing system for maintaining all of the information that will be gathered during the project.

Essential Skills Required:

  1. Facilitation skills to bring multiple groups together to scope project and get consensus
  2. Ability to document the project scope using business terminology
  3. Project scope documentation techniques

2. Elicit Requirements

The most important task of a BA is to gather the detailed requirements that clearly and completely define the project. We use the word gather because the BA must be sure to ask the right questions of the right people to gather accurate requirements. Further, we use the word elicit, since the BA must be able to get people to say all that they have to and not leave anything as assumptions.

It is critical that the BA initially gathers Business Requirements and completely understand the business needs before defining a software solution.

The BA must assess the type of project, the people involved, and the volume of information required; and then determine how and where to find the requirements. BAs have a variety of techniques available to them including interviews, facilitated information gathering sessions, surveys, questionnaires, observation, and existing documentation from which to choose. In addition, the BA will often have many people with whom to talk and several existing automated systems about which to learn.

Gathering complete, detailed requirements is an iterative process that involves the BA asking questions, pondering answers, asking follow-up questions, and bringing divergent opinions to consensus. It also involves prioritizing the requirements to assure that the most critical issues are addressed by the project solution.

Essential Skills Required:

  1. Asking the right questions
  2. Active listening
  3. Interviewing techniques
  4. Facilitation techniques
  5. Documentation
  6. Ability to categorize requirements

3. Analyze and Document Requirements

Requirements are analyzed and documented using an iterative approach. As each of the requirements is documented, additional questions will arise requiring the analyst to probe deeper. There are many different approaches to documenting requirements. The BA is responsible for following their organization's standard documentation format or for creating their own. When developing a documentation format, the BA must consider the best format for communicating with the information technology team and the best format for communicating with the business area experts. Both groups must be able to read and review the document and clearly understand the requirements. Some requirements are more appropriately documented in textual descriptions, others in diagrams or graphical displays. The BA must also determine the appropriate level of detail for the documentation.

Ideally, the entire organization uses a consistent documentation format and approach. This makes the review process easier for people working on multiple projects. It also allows the organization to constantly improve the format as quality enhancements are discovered. The BA is often the person leading the development and maintaining the standard documentation format.

Typically there are many requirements. To organize them and make them easy to review, they are divided into categories or groupings. It may be good to categorize requirements into Business, Functional, and Technical.

Essential Skills Required:

  1. Analysis Skills
  2. Understand the system development methodology
  3. Utilize modelling techniques
  4. Categorization skills
  5. Prototype user interfaces
  6. Develop a textual template for requirements

4. Communicate Requirements

The BA should be the best communicator on the project team. The role is to act as a liaison between the business area experts and the technical team. This role requires the BA to "speak" both languages. The BA must also work very closely with the Project Manager to ensure that the project plan is adhered to and scope creeps / changes are approved and documented.

As the requirements documentation is being created, the BA will conduct informal and formal requirements reviews. These review sessions increase the quality of the document by finding missing or unclear requirements. It is important that the information is presented to the business and technical audiences in a manner that is most appropriate for their understanding. Summaries of the requirements or various graphical representations may be appropriate as part of the reviews. Understanding your audience is critical to the successful communication of the requirements.

Essential Skills Required:

  1. Run effective meetings
  2. Active listening skills
  3. Precision questioning techniques
  4. Conduct formal and informal presentations
  5. Write clear emails, memos, and status reports
  6. Conduct a comprehensive requirements review
  7. Change management
  8. Write review summaries
5. Identify Solution

The BA should work closely with the Business Area Experts to make a recommendation for a solution and work with the technical team to design it. This recommendation may include software changes to existing systems, new software, procedural or workflow changes, or some combination of the above. If software automation is part of the solution, the BA should assist with the screen design, report design, and all user interface issues by providing detailed functional requirements.

If a software package is going to be purchased, the BA works with the Business Area Experts, IT personnel, and the potential vendors to discuss the requirements and verify that the package selected will meet the needs. The BA may also be responsible for writing the Request for Proposal (RFP). Detailed business and functional requirements should be completed to accurately reflect the needs for the software and a thorough review should be conducted.

Essential Skills Required:

  1. High level understanding of the software design
  2. Ability to evaluate vendor software packages
  3. Ability to estimate solution costs and benefits and build a business case for implementation
6.Verify Solution meets the Requirements

The BA should remain involved in the project even after the technical team takes over. The BA reviews the technical designs proposed by the design team for usability issues and to assure that the requirements are being satisfied. Once the solution is developed into software, the BA is uniquely qualified to assess the software and determine how well it meets the original project objectives.

The BA should work closely with the Quality Assurance team and to assist with the entire testing process. Testing is based on requirements, so the BA's intimate knowledge of the requirements allows accurate design of test cases. If there is no Quality Assurance team available, the BA can still assist with User Acceptance testing, the time when the Business Area Experts are asked to approve the software for implementation. As the software is tested, the BA ensures that it is clearly documented and reports defects and variances from requirements.

Essential Skills Required:

  1. Basic understanding of system design concepts
  2. Knowledge of software usability principles
  3. Understanding of testing principles
  4. Ability to write and review test cases
Article Originally written by Sanjay Dugar, Post Source BusinessGyan.com