Business Analysis / Requirements
Live Instructor-Led Classroom Training

Business analysts are responsible for analyzing the workings of an organization along with the design of business methods being used and creating a bridge between management, front line employees and customer needs. It is the analyst's jobs to understand client and market requirements and devise solutions.

Business analysis is a critical process that drives organizational structures and systems within the context of varying stakeholder interests. The business analyst defines and evaluates potential initiatives that best fit organizational goals. When communication between the business and IT sections of a company breaks down, it can be hard for programmers to develop the exact product that the business section is looking for. The most common reasons for project and product failures are problems with requirements. These problems won't go away unless the requirement writers, reviewers, and managers understand what a good requirement is.

Our training for eliciting, analyzing and recording business system requirements is unique because it combines use cases and UML modeling techniques and elicitation skills with an iterative development approach. We bring together the knowledge of best practices and techniques, with an emphasis on how adults learn (highly interactive with hands-on application of the methods and best-practices taught to put it all together). It is our goal to provide a cohesive learning experience that takes the extremely complex elements of business analysis and simplifies them into manageable learning components. Learn from subject matter experts who developed these programs and the workbooks and know the materials so well that they rarely have a need to look at the book in class.

Requirements Gathering Techniques:
The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here's an overview of each one:

1. Brainstorming
   Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack.
2. Document Analysis
   Reviewing the documentation of an existing system can help when creating AS-IS process documents, as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the requirements that drove creation of the existing system - a starting point for documenting current requirements. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness.
3. Focus Group
   A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs / opportunities / problems to identify requirements, or can be gathered to validate and refine already elicited requirements. This form of market research is distinct from brainstorming in that it is a managed process with specific participants. There is danger in "following the crowd", and some people believe focus groups are at best ineffective. One risk is that we end up with the lowest common denominator features.
4. Interface Analysis
   Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. User centric design approaches are very effective at making sure that we create usable software. Interface analysis - reviewing the touch points with other external systems - is important to make sure we don't overlook requirements that aren't immediately visible to users.
5. Interview
   Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. Like a great reporter, listening is the skill that helps a great analyst to get more value from an interview than an average analyst.
6. Observation
   The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked.
7. Prototyping
   Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the "official requirements" in some situations.
8. Requirements Workshop
   More commonly known as a joint application design (JAD) session, workshops can be very effective for gathering requirements. More structured than a brainstorming session, involved parties collaborate to document requirements. One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two analysts than with one, where a facilitator and a scribe work together.
9. Reverse Engineering
   Is this a starting point or a last resort? When a migration project does not have access to sufficient documentation of the existing system, reverse engineering will identify what the system does. It will not identify what the system should do, and will not identify when the system does the wrong thing.
10. Survey
    When collecting information from many people - too many to interview with budget and time constraints - a survey or questionnaire can be used. The survey can force users to select from choices, rate something ("Agree Strongly, Agree…"), or have open ended questions allowing free-form responses. Survey design is hard - questions can bias the respondents. Don't assume that you can create a survey on your own, and get meaningful insight from the results. I would expect that a well designed survey would provide qualitative guidance for characterizing the market. It should not be used for prioritization of features or requirements.

Techniques to specify and model Requirements:
The BABoK (Business Analyst Body of Knowledge) lists 17 techniques that can be used to specify or model requirements:

1. Acceptance and Evaluation Criteria Definition - defines the requirements that must be met in order for a solution to be considered acceptable to key stakeholders. Ensure that requirements are stated clearly enough to devise a set of tests that can prove that the requirement has been met.
2. Business Rules Analysis - business rules may be separated from other requirements for implementation and management in a business rules engine or similar. To define the rules that govern decisions in an organization and that define, constrain, or enable organizational operations.
3. Data Dictionary and Glossary - defines key terms and data relevant to a business domain.
4. Data Flow Diagrams - shows how information flows through a system. Each function that modifies the data should be decomposed into lower levels until the system is sufficiently described.
5. Data Modeling - describes the concepts and relationships relevant to the solution or business domain, the relationships between those concepts, and information associated with them.
6. Functional Decomposition - breaks down an organizational unit, product scope, or similar into its component parts. Each part can have its own set of requirements.
7. Interface Analysis - identifies interfaces between solutions and/or solution components and define requirements that describe how they will interact.
8. Metrics and Key Performance Indicators - measures the performance of solutions, solution components, and other matters of interest to stakeholders.
9. Non-functional Requirements Analysis - describes the required qualities of a system, such as its usability and performance characteristics. These supplement the documentation of functional requirements, which describe the behavior of the system.
10. Organization Modeling - describes the various organizational units, stakeholders, and their relationships. Requirements can be structured around the needs of each stakeholder or group.
11. Process Modeling - requirements may be organized around relevant processes. Processes themselves can embed subprocesses, and describe a hierarchy from the top level, end-to-end processes to the lowest-level individual activities.
12. Prototyping - details user interface requirements and integrates them with other requirements such as use cases, scenarios, data and business rules. Stakeholders often find prototyping to be a concrete means of identifying, describing and validating their interface needs.
13. Scenarios and Use Cases - describes the requirements that support the individual goals of each actor, or the response to the triggering event.
14. Sequence Diagrams - used to model the logic of usage scenarios, by showing the information passed between objects in the system through the execution of the scenario.
15. State Diagrams - shows how the behavior of a concept, entity or object changes in response to events.
16. User Stories - describes the stakeholder objectives that the solution will support.
17. Scope Modeling - requirements may be organized based on the solution components they are related to. Scope models are used to describe the scope of analysis or the scope of a solution.