Topic 3 – The Business Analysis Project Lifecycle – Flashcards

Stage 1: Define the Business Needs Stage 2: Business Domain Scope Definition Stage 3: Requirement Elicitation and Discovery Stage 4: Requirement Analysis Stage 5: Requirement Specification Stage 6: Requirement Documentation Stage 7:Requirement Validation Stage 8: Requirement Management Stage 9: System Maintenance and Enhancement

The Waterfall Method is a heavyweight model requiring rigorous documentation and the completion of each stage before proceeding to the next. This means that in the typical BA lifecycle described below, the Business Analyst will follow stages 1 through 9 in sequence - that is one iteration. The tasks and techniques accomplished within each stage will have some variation from project to project. For example, in the analysis stage, we may do a series of focus group sessions and then put together the requirements. Or we can do one focus group, model the requirements and take it to the next focus group. When working under Agile Methodology, however, unknown requirements are the norm, and both analysis and development are highly iterative. Here, the Business Analyst will oversee multiple iterations of the BA lifecycle to accommodate the changing dynamics of the Agile method.

A pre-analysis stage to determine key motives behind the project. Looks at strategic goals, project's critical success factors; how will they be measured? For Waterfall, findings will be summarized in formal documentation For Agile methodology, just enough documentation to proceed to the next iteration

1. Gain perspective of the needs, goals, and objectives of customers, users, and stakeholders 2. Develop the Business Case, Project Charter, and Statement of Work 3. Understand the business' vision, driver, goals, and objectives for the new or enhanced system 4. Assemble and educate a requirements team comprised of key business and technical stakeholders 5. Understand and document the scope of the project as per BABOK® Guide Enterprise Analysis Task 4: Define the Solution Scope) 6. Define the documents and models to be produced and begin to develop the Requirements Management Plan (or the Requirements Work Plan [RWP] in other BA project lifecycles) 7. Define and refine the checklist of requirements activities, deliverables, and schedule 8. Plan for change throughout the lifecycle

Requirements are always unclear at the initial stages of a project. This is expected. It is through iterative cycles and feedback from key team members that the requirements are defined and refined. It is through the process of progressive elaboration that requirements evolve to maturity. Requirements elicitation can consist of any combination of the following activities and techniques: Requirements workshops as gathering sessions with customers, users, and stakeholders. These are also known as Elicitation Workshops, Facilitated Workshops, and Joint Application Design. Workshops results are documented and distributed. (BABOK® Guide Elicitation Technique: Requirements Workshop) Interviews (BABOK® Guide Elicitation Technique: Interviews) Surveys (BABOK® Guide Elicitation Technique: Surveys and Questionnaires) Prototyping (BABOK® Guide Elicitation Technique: Prototyping) Review existing system and documents (BABOK® Guide Elicitation Technique: Document Analysis) Brainstorming (BABOK® Guide Elicitation Technique: Brainstorming) Focus Groups (BABOK® Guide Elicitation Technique: Focus Groups) Reverse Engineering (BABOK® Guide Elicitation Technique: Engineering) Observation (BABOK® Guide Elicitation Technique: Observation) Iterative feedback to customers, users and stakeholders. Selecting which method to use to do requirements elicitation is covered in the "Planning the Business Analysis Activities" section of BABOK® Guide Business Analysis Planning and Monitoring Task: Plan Business Analysis Activities. TIP #1: Requirements elicitation can go on forever When working on a project, it may seem like rounds of requirements elaboration go on forever. How do you know when to stop? Answer: The elaborations can stop when the business and development teams are both comfortable with the level of detail (or when the time limit for requirements elaboration is up!). TIP #2: Keep your target on the goal Keep in mind that business requirements are derived from the business problem (or new opportunity). The requirements should work to satisfy the organization's strategic goals. This hint is key as the processing of requirements elicitation is a vital step in discovering ways to bring value to the organization and satisfy the strategic goals. Do not be fooled by stakeholders' or management's personal agendas, unspoken politics, or conflicting organizational cultures. These only distract from the ultimate goal. Stay diplomatic and ethical to gain the trust of team members. TIP #3: Do not go into "how to solve the problem" mode Focus on eliciting the information needed to satisfy the business problem or new opportunity. At workshops, it can be easy for developers to try to solve the requirement by suggesting how to design the functionality. Don't blame them, that's their job! The Business Analyst's role is to document what the requirements are, not how to solve the problem. Solving the problem is done in later stages, when proposed solutions are assessed. The analyst and the architects/developers have two very distinct roles. Make sure each stays on their side of the fence. Analysis Design Business Analyst Architect, Developers "What" is the requirement "How" to solve the problem Requirements Specifications Technology neutral Browser vendors selected, software languages selected, web toolkits pre-selected Looks at information to make decisions, required by the organization Looks at how to do the database design (i.e., Detailed Logical Data design, Use Cases, Entity Relationship Design diagrams, decision tables, SQL queries) Customer perspective "From anywhere in the world, I want to see all my global accounts online so I can transfer money from Canada to Asia with no hassle. ..." Design perspective "Connect all back-end banking systems from UK, Canada, Asia, Australia, United States using Oracle as the middle tier... " Activities in Requirement Elicitation and Discovery (BABOK® Guide Tasks) Identify stakeholders, customers, and users needed to be involved. Understand business goals to identify user tasks to support it. This task is similar to BABOK® Guide Elicitation Task 1: Prepare for Elicitation This is the equivalent to doing these tasks in BABOK® Guide: BABOK® Guide Elicitation Task 2: Conduct Elicitation Activity BABOK® Guide Elicitation Task 3: Document Results of Elicitation Activity BABOK® Guide Elicitation Task 4: Confirm Elicitation Results BABOK® Guide Requirements Analysis Task 3: Specify and Model Requirements BABOK® Guide Requirements Analysis Technique: Scenarios and Use Cases Deliverables (BABOK® Guide Output) Key inputs for Business Requirements Document and Requirements Management Plan. (BABOK® Guide BA Planning & Monitoring KA Task: Plan Requirements Management Process)

After having stated the requirements, they are further analyzed, verified, and validated for clarity. The Business Analyst converts the stated requirements into a description of the required capabilities of a potential solution that will fulfill the actual needs of the stakeholders. Requirements analysis and business domain/scope (known as Enterprise Analysis in BABOK® Guide) are closely related as they use the same knowledge, skills, and principals. In Stage 2, the goals and objectives of stakeholders, users, and customers are understood and the business context in which the change is affected. Requirements analysis is performed in order to describe the nature and characteristics of a solution that can be met. Analysis is the middle ground between requirements and design (Ambler, 2005). Prioritize Requirements (BABOK® Guide, p. 99, Requirements Analysis Task 1) The fact is that all requirements are not equal in business value. Priorities need to be set for each requirement, but the relative importance of each requirement must be based on value, risk, difficulty of implementation, and other agreed upon criteria. There are different techniques to prioritize requirements, each with its own pros and cons. It may not be as simple as assigning low, medium, and high priority requirements. Part of the challenge is determining a technique in prioritizing requirements that gives a sense of fairness. Organize Requirements (BABOK® Guide, p. 103, Requirements Analysis Task 2) To ensure all requirements are satisfied: Structure the requirements information into relevant categories. This allows requirement components to be strategically allocated in solution modules, thus ensuring that all requirements are satisfied. Identify the relationship and interdependencies among requirements. Specify and Model Requirements (BABOK® Guide, p. 107, Requirements Analysis Task 3) Document requirements by using a combination of textual statements, matrices, diagrams, and formal models using natural business language. The purpose of this step is to model the requirement so that it facilitates communication between team members and stakeholders to identify an appropriate solution. As models represent an abstraction and simplification of reality, one model would not likely represent the entirety of the business domain. Therefore, several different models may be needed to adequately capture the requirements. Define Assumptions and Constraint (BABOK® Guide, p. 111, Requirements Analysis Task 4) Identify the assumptions made and constraints identified during the requirements analysis stage that will impact the solution design. Assumptions help the Business Analyst continually validate their accuracy of the assumption and help them manage risks to the ability of the solution to meet the business need. Constraints inform the project team that options they would normally consider are not available, thus placing limitations on how the problem may be solved. Constraints can be business, stakeholder, or technical in nature. Verify Requirements (BABOK® Guide, p. 114, Requirements Analysis Task 5) This task ensures that the requirements given to the development team are sufficiently defined and structured so they can be incorporated in the design, development, and implementation of the solution. Verifying means that the requirement must be of good quality based on relevant quality standards set by selected stakeholders. Validate Requirements (BABOK® Guide, p. 114, Requirements Analysis Task 6) It is ultimately the BA's responsibility to ensure that requirements are validated, which means that they are correct, appropriate for stakeholders and align to business requirements. Otherwise, the project may be at risk with insufficient or incorrect requirements.

(BABOK® Guide Requirements Analysis Task 3: Specify and Model Requirements) Requirements specifications are further elaborated and linked to structured requirements with a completed attribute set. Attributes are used for explanation, selection, validating, and filtering. They also act as an aid to enable the association of data with objects, table markers, table cells, modules, and the project as a whole (Stevens, Brook, Jackson, Arnold, 1998)1. This makes it easier to associate information in related requirement groupings. As a result of the requirements analysis process done in Stage 4, the system specification document is the deliverable for Stage 5. Typical attributes are: Unique Identifier Acceptance criteria to prove to customers, users, and stakeholders that the requirement is met Author of requirement Complexity to determine level of difficulty to implement (not necessarily just technical implementation) Ownership Performance addresses how the requirement must be met Priority Source of requirement who has authority to specify requirements Stability to indicate how mature the requirement is used to determine if requirement is firm enough to begin Urgency refers to how soon the requirement is needed (Haas, K., 2003). Deliverable: System Specification Document

(BABOK® Guide Requirements Analysis Task 3: Specify and Model Requirements) Requirements documentation must be clear and concise using natural business language. Documentation is used by everyone on the project so keep it simple wherever possible. Documentation can be textual, graphical or a combination of both. In some cases, a diagram can express structure and relationships more clearly than text. In other cases, clearly articulating a concept is more precise. At times, to make it understandable for different audiences, a textual representation of a requirement together with a graphical representation can make the requirement clear and explainable across a wide audience. Requirements can be categorized by different types (BABOK® Guide, p. 5). Typically there are: Business Requirements - high level statements of goals, objectives, or needs of enterprise. Ask why the project initiated, how success is measured. Stakeholder Requirements - statements of the needs of stakeholder(s). Describes needs the stakeholder has and how that stakeholder will interact with the solution. Solution Requirements: Functional Requirements - describes the capability the system will be able to perform. It is described in terms of behaviour or operations. Non-functional Requirements (also called supplemental requirements) - defines the overall qualities or attributes of the resulting system, and can relate to safety, security, usability, reliability and performance requirements. Transition Requirements - describe the capabilities a solution must facilitate before and after it is implemented. In the Agile methodology, one of the elements is keeping documentation to a level that is "just enough" - no more, no less - whereas with Waterfall methodology, documentation is more complete and rigorous

(BABOK® Guide Requirements Analysis Task 6: Validate Requirements) Requirement Validation ensures that all the requirements deliver good value to the business, fulfill business goals and objectives, and meet stakeholder needs (BABOK® Guide, p. 117). This validation occurs iteratively throughout the project to determine the elaborated requirements, and later to ensure the design and development deliverables continue to be aligned with strategic goals and objectives. The validation of each requirement continues even in User Acceptance Testing to confirm the solution is fully completed and can be delivered to the customer.

(BABOK® Guide BA Planning and Monitoring Task 5: Requirements Management Process) This is setting up the control gate for when the requirements phase is completed and a process needs to be set in place to manage new requirements being received. A review process would need to be established to present the requirements and steps for approval. Each new requirement would need to be reviewed to predict any impact on project schedule, cost, estimates, and the business case. If approval is secured, the new requirement would trigger the project's change control process. The control gate would be also used for any updated existing requirements. This process would be worked out collaboratively between the Business Analyst and the Project Manager. Also included in Requirement Management are choosing the approach to how requirements will be traced and determining which requirement attributes will be captured.

When the IT solution is delivered and operational, the Business Analyst's job does not end but maintains key responsibilities in the following areas (Mooz, Forsberg, Cotterman, 2003): Maintenance - service provided to prevent and correct defects in the IT system Enhancements - changes to increase the value provided by the system to the business Operations and Maintenance - the phase in which the system is operated and maintained for the benefit of the business. The Business Analyst plays a major role in managing enhancements to the system, and in determining when the system should be replaced and deactivated.

BABOK® Guide Enterprise Analysis Task 1: Determine the Business Need and New Opportunities. Task 2: Determine the Gap in Capabilities to Meet the Business Need. Feasibility studies Benchmark studies Competitive Analysis Report