Define and Scope the Project

The Business Analyst must be sure that the project scope is clear and complete before he or she can begin detailed requirements gathering. The Business Analyst may be given the scope which has been defined by the project sponsor or manager 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 Business Analyst to understand why the project has been initiated (project statement of purpose) and the goals of the project (project objectives). An important contribution of the Business Analyst to the project is the discipline to analyze the business problem without "jumping" to a solution.

In addition, a complete project scope will name and define all of the organizations that will be involved with the project; this may include people, systems, internal departments, and outside organizations (project external interactions).

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

Finally the project scope should include a high-level description of the business processes that will be included. 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 Business Analyst will be doing as they move into detailed requirements gathering.

One additional task required of the Business Analyst at this point 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 Needed:

• Facilitation skills to bring multiple groups together to agree on project scope and build consensus
• Ability to clearly document project scope using business terminology
• Project scope documentation techniques

Gather Requirements

The most important task of a Business Analyst is to gather the detailed requirements that completely define the project. We use the word gather rather than invent or assume because the Business Analyst must be sure to ask the right questions of the right people to gather accurate requirements.

B2T Training uses the terms Business Requirements and Functional Requirements to differentiate between the business needs and the software functionality. It is critical that the Business Analyst initially gather Business Requirements and completely understand the business needs before defining a software solution.

The Business Analyst 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. Business Analysts 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 Business Analyst 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 Business Analyst 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 Needed:

• Asking the "right" questions
• Active listening
• Interviewing techniques
• Facilitation techniques
• Note taking/documentation
• Ability to categorize requirements

Analyze and Document Requirements

Requirements are analyzed and documented using an iterative approach. As each requirements is documented, additional questions will arise requiring the analyst to probe deeper. There are many different approaches to documenting requirements. The Business Analyst is responsible for following their organization’s standard documentation format or for creating their own. When developing a documentation format, the Business Analyst 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 Business Analyst 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 Business Analyst is often the person leading the development and maintenance of this standard documentation format.

Typically there are many requirements. To organize them and make them easy to review, they are divided into categories or groupings. B2T Training recommends categorizing requirements into Business, Functional, and Technical.

B2T Training presents students with a Requirements Package that is an example of an effective, complete documentation format. The package includes all of the critical requirements components using structured text, diagrams and tables to make the document easy to review and maintain.

Essential Skills Needed:

• Analysis skills
• Understand the system development methodologies
• Utilize appropriate modeling techniques
• Prototype user interfaces
• Develop a textual template for requirements

Communicate the Requirements

The Business Analyst should be the best communicator on the project team. His or her role is to act as a liaison between the business area experts and the technical team. This role requires the Business Analyst to “speak” both languages. The Business Analyst must also work very closely with the Project Manager to assure that project plan is adhered to and scope changes are approved and documented.

Critical communication skills required are active listening skills, the ability to ask pointed, open-ended questions, and facilitation skills to conduct group meetings and bring a group to consenus on joint requirements. 

As the requirements documentation is being created the Business Analyst will conduct informal and formal requirements reviews. These review sessions increase the quality of the document by helping the Business Analyst find 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 Needed:

• Run effective meetings
• Conduct formal and informal presentations
• Write clear emails, memos, and status reports
• Conduct a comprehensive requirements review
• Write review summaries

Identify a Solution

The Business Analyst 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 Business Analyst 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 Business Analyst 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 Business Analyst may also be responsible for writing the Request for Proposal (RFP).  Detailed business and functional requirements should still be completed to accurately reflect the needs for the software and to conduct a thorough review.

Essential Skills Needed:

• Complete understanding of business problem
• High level of understanding of software design
• Ability to evaluate vendor software packages
• Ability to estimate solution costs and benefits and build a business case for implementation

Verify Solution Meets the Requirements

The Business Analyst should remain involved in the project even after the technical team takes over. The Business Analyst reviews the technical designs proposed by the design team for usability issues and to assure the requirements are being satisfied.

Once the solution is developed into software the Business Analyst is uniquely qualified to assess the software and determine how well it meets the original project objectives.

Some organizations have a Quality Assurance team that is responsible for software testing and quality review. The Business Analyst should work closely with this group to assist with the entire testing process. Testing is based on requirements, so the Business Analyst’s intimate knowledge of the requirements allows accurate design of test cases.

Whether or not a Quality Assurance team is available, the Business Analyst can 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 Business Analyst can clearly document and report defects and variances from requirements. They can also assist the development team with identifying where the defects were introduced and correcting them.

Essential Skills Needed:

• Basic understanding of system design concepts
• Knowledge of software usability principles
• Understanding of testing principles
• Ability to write and review test cases