Business Analysis Tools, Techniques, Templates and Tips February 17, 2008 Prepared by Daugherty Business Solutions for confidential review
Agenda • • What is Business Analysis? Role of the Business Analyst IIBA Industry Standards – – Software Tools Metrics Methods Techniques Page 2 Prepared by Daugherty Business Solutions for confidential review
What is Business Analysis? The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Page 3 Prepared by Daugherty Business Solutions for confidential review
What is Business Analysis? Solutions may include: Ø Systems development Ø Process improvement Ø Organizational change Business analysis is distinct from, but may include, these related functions: Ø Financial analysis Ø Project management Ø Quality assurance Ø Organizational development Ø Testing Ø Training Ø Documentation development Page 4 Prepared by Daugherty Business Solutions for confidential review
What is a Business Analyst? 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. Page 5 Prepared by Daugherty Business Solutions for confidential review
The Role of the Daugherty Business Analyst Four areas* of responsibility: Ø Requirements Gathering and Reconciliation Ø Analyze, Solve Business Problems, Test Ø Leadership Ø Specific Line of Service (LOS) Knowledge *Daugherty Role Description – Business Analyst III Page 6 Prepared by Daugherty Business Solutions for confidential review
The Role of the Daugherty Business Analyst – Requirements Gathering and Reconciliation Ø Serve as subject matter expert and or lead large sessions of several business analysts to analyze, diagnose, and resolve complex problems using diverse methods and tools. Ø Prioritize integrated requirements to ensure that requirements are complete and documented. Ø Advise client users on application design alternatives and business process change opportunities. Ø Connect user needs to emerging technology in order to acquire or design tools, techniques and approaches that allow client users to realize optimal project delivery results. Page 7 Prepared by Daugherty Business Solutions for confidential review
The Role of the Daugherty Business Analyst – Analyze, Solve Business Problems, Test (Part 1) Ø Shape requirements into valuable business solutions and presentations using strong documentation skills. Ø Deliver integrated business systems support to users (internal and external to IT), applying an expert understanding of the business issues and the impact of technology. Ø Advocate the initiation of projects, when necessary, to achieve business and IT objectives. Ø Oversee the development of the business cases and solution proposals in support of improved functionality with regard to Return on Investment (ROI) and long-term firm benefit. Ø Lead the root cause analysis and resolution for complex problems. Page 8 Prepared by Daugherty Business Solutions for confidential review
The Role of the Daugherty Business Analyst – Analyze, Solve Business Problems, Test (Part 2) Ø Provide reliable top-down and bottom-up estimates. Ø Effectively and efficiently use all applications in the Microsoft Office Suite to deliver created documents. Ø Lead Change Control and Scope Management efforts. Ø Lead test planning and all test cycles using proven testing techniques. Ø Successfully identify, address, manage and escalate Risks and Issues. Ø Experienced in one or more project management tools such as MS Project. Page 9 Prepared by Daugherty Business Solutions for confidential review
The Role of the Daugherty Business Analyst – Leadership Ø Effectively leads a team of several business analysts. Ø Maintain experience in tracking and managing projects using MS Project or similar PM software. Ø Coach less senior Business Analysts in analysis techniques, problem solving and business knowledge. Page 10 Prepared by Daugherty Business Solutions for confidential review
The Role of the Daugherty Business Analyst – Specific Line of Service (LOS) Knowledge Ø Custom Application Development: Maintains strong SQL skills with the ability to write complex SQL statements to analyze data and create prototypes. Ø Business Intelligence: Has experience working on a few data warehouse and/or data reporting projects but requires guidance in more complex situations. Maintains strong SQL skills with the ability to write complex SQL statements to analyze data and create prototypes. Can interpret data models (conceptual, logical, physical) Ø ERP Integration: Maintains strong understanding and technical skills in multiple modules (FI, CO, SD, MM, PP, HR). Completed multiple full life cycle projects. Understanding of SAP business processes and solution for multiple clients and/or industries. Page 11 Prepared by Daugherty Business Solutions for confidential review
A Knowledge Framework for the Business Analyst Page 12 Prepared by Daugherty Business Solutions for confidential review
What is the IIBA? The International Institute of Business Analysis (IIBA) is an international notfor-profit professional association for Business Analysis professionals. The IIBA vision is to be the leading world-wide professional association that develops and maintains standards for the practice of business analysis and for the certification of practitioners. The Business Analysis Body of Knowledge (BABOK) is the sum of knowledge within the profession of Business Analysis and reflects what is considered currently accepted practice. Page 13 Prepared by Daugherty Business Solutions for confidential review
IIBA Areas of Knowledge There are six knowledge areas defined, that combined, cover the core areas where the IIBA will set professional standards for those performing business analysis: Page 14 Prepared by Daugherty Business Solutions for confidential review
IIBA Areas of Knowledge – Enterprise Analysis Early project activities for capturing the necessary view of the business to provide context to requirements, such as: Ø Ø Ø Ø Creating and maintaining the Business Architecture Conducting feasibility studies to determine the optimum business solution Identifying new business opportunities Scoping and defining the new business opportunity Preparing the Business Case Conducting the initial Risk Assessment Preparing the Decision Package Page 15 Prepared by Daugherty Business Solutions for confidential review
IIBA Areas of Knowledge – Requirements Planning and Management Defines the resources and tasks associated with the planning and management of requirements gathering activities throughout the requirements process. Activities include: Ø Identifying key roles Ø Selecting requirements activities Ø Managing the requirements scope Ø Ongoing communication of the requirements gathering status Page 16 Prepared by Daugherty Business Solutions for confidential review
IIBA Areas of Knowledge – Requirements Elicitation This knowledge area defines standard techniques used to collect the requirements of the system. Eliciting requirements is a key task in business analysis - it is essential that the requirements be complete, clear, correct, and consistent. The business analyst should understand the commonly used techniques to elicit requirements, should be able to select appropriate technique(s) for a given situation, and be knowledgeable of what is required to prepare, execute and complete each technique. Page 17 Prepared by Daugherty Business Solutions for confidential review
IIBA Areas of Knowledge – Requirements Analysis and Documentation Requirements analysis defines the methods, tools and techniques used to: Ø Ø Ø Structure the raw data collected during Requirements Elicitation Identify gaps in the information Define the capabilities of the solution, which must be documented The objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it. Page 18 Prepared by Daugherty Business Solutions for confidential review
IIBA Areas of Knowledge – Requirements Communication The collection of activities and considerations for expressing the output of the requirements analysis and documentation to a broad and diverse audience. An ongoing, iterative activity that is done in parallel with Requirements Gathering and Requirements Analysis and Documentation. Includes presenting, communicating, verifying, and gaining approval of the requirements from the stakeholders and implementers of the project. Page 19 Prepared by Daugherty Business Solutions for confidential review
IIBA Areas of Knowledge – Solution Assessment and Validation Once the solution has been identified, the BA must contribute to the activities of three groups, monitoring and assisting them where needed to support the project. Technology Team: Ø Detailed design Ø Phase/Iteration plans Ø Review deliverables Ø Usability Ø Rollout strategies Business Stakeholders: Ø User acceptance testing Ø Defect resolution Ø Production rollout Ø Training Ø Documentation Ø Change requests Quality Assurance Team: Ø Understand QA tasks Ø Answer questions Ø Review test plans Page 20 Prepared by Daugherty Business Solutions for confidential review
Business Analysis Software Tools and Metrics Page 21 Prepared by Daugherty Business Solutions for confidential review
Software Tools Requirements Management Ø Analyst Pro - Goda Software Ø Blueprint - Blueprint Systems Ø Contour - Jama Software Ø Caliber. RM - Borland Ø Doors - Telelogic Ø Optimal Trace - Compuware Ø Rational Suite - IBM Ø Serena RTM - Serena Other Ø Ideascope - Orasi Stakeholder surveys Ø i. Rise Application simulation platform Ø i. Server - Orbus Software Repository Ø Pro. Vision Enterprise – Meta. Storm Repository Ø Reconcile – Compuware Project goal tracking Modeling Ø Visio - Microsoft Ø System Architect - Telelogic Ø Enterprise Architect - Sparx Systems Ø RAVEN - Ravenflow Ø Smart. Draw - smartdraw. com Page 22 Prepared by Daugherty Business Solutions for confidential review
Metrics to Consider • Feature availability – Map of system requirements (use cases, business rules, stories, etc. ) to releases. This will allow the BA to communicate clearly to the stakeholders regarding the progression of the product. • # of features that are new in current release • # of features remaining • % of features implemented to date • Defect tracking – It is one thing to say a feature is available in a release. It is another to say it is working correctly. There needs to be an effective way to track known defects and their resolutions. • # of resolved defects • # of open defects • % of features with no defects • Test coverage – The BA needs to be able to identify what cases have been tested against a given release. • % of test cases run as compared to the number that could run • % of test cases passing based on the number that should pass • % of test cases that have never run or passed
Business Analysis Techniques (presented in order of IIBA Phases) Page 24 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9 Zachman Framework Provides common language and common structure for describing an enterprise. The columns represent the questions that must be answered to design a business entity - what, how, where, who, when, why. The rows describe the different perspectives of the enterprise scope, business model, system model, technology model, detailed representations. Resource: http: //www. zifa. com Page 25 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9 Zachman Framework – Business Analysis Activities What Scope How Where Who When Why (Data) (Function) (Location) (People) (Time) (Motivation) Entity Process List Locations of the Enterprise List of Organizations / Divisions Major Business Events or Cycles Business Strategy Entity / Relationship Overall Process Model Interactions between locations Organization Chart, List of Roles Detailed Schedule Business Plan Project Objectives Logical Data Model Detailed Process Description Detailed Interaction Model Entity History Processing Business Rule Model Level 1 Describes general scope of Business Analysis Activities in the Zachman Framework. Business Model Level 2 System Model Level 3 The empty cells fall outside the scope of the BA role. User Interface Design and Flow Level 4 Detailed Representation Business Rule Specification Detailed UI, Security Technology Model Business Rule Design Level 5 Functioning Enterprise Level 6 Resource: The Bridge, Fall 2006 Page 26 Prepared by Daugherty Business Solutions for confidential review
Techniques and the Zachman Framework Technique What How Where Who When Why (Data) (Function) (Location) (People) (Time) (Motivation) Activity Diagram 2, 3 3 3 * 1, 2, 3 Business Rules * * Class Model 1, 2, 3 CRUD MATRIX * Data Dictionary 1, 2, 3, 4, 5 refers to the Framework level that the technique addresses Business Process/ Workflow Diagram 3 Data Flow Diagram * Data Transformation and Mapping * * 3, 4, 5 5 1, 2. 3 Deployment Diagram * 4, 5 * * 1, 2 Entity Relationship Diagrams 1, 2, 3 * Event Identification Asterisk(*) indicates that the technique can address * * Flowchart 2, 3 1, 2 * * * Goal Oriented Requirements Language 3, 4 1, 2, 3 Metadata Definition * * * Sequence Diagram * 5 3 State Machine Diagram * * 1, 2, 3 Story boards / Screen Flows 3, 4, 5 Use Cases 1, 2, 3, 4 * * User Interface Designs 3, 4, 5 User Profiles 1, 2 * * * User Stories * Page 27 Prepared by Daugherty Business Solutions for confidential review
Work Approach and Techniques Catalog Ø Ø Ø Ø Ø Zachman Framework The POLDAT Framework Component Business Model Business Process Model / Process Flow Diagram Class Model Use Case Model Business Scenario Knowledge Management Organizational Chart Geographic Map Ø Ø Ø Ø Ø Page 28 Data Flow Diagrams Technology Architecture Diagram Domain Model Six Sigma Root Cause Analysis Work Breakdown Structure Brainstorming Business Process Reengineering Cause and Effect Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9 The POLDAT Framework Each element in the POLDAT hexagon in the previous figure represents a domain of change. If equilibrium is to be retained when a change project is launched within one area, change must also take place in the other five areas. Resource: http: //dk. country. csc. com/da/kl/uploads/181_1. pdf Page 29 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9 Component Business Model IBM's Component Business Model is a simplified way of looking at an enterprise, showing activities across lines of business. Identifies which components of the business really create differentiation and value. Identifies opportunities to improve efficiency and lower costs across the entire enterprise. Identifies the components where you can realize the greatest impact. Resource: http: //www-935. ibm. com/services/us/igs/cbm/html/bizmodel. html Page 30 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9, 2. 3. 8 Business Process Model / Process Flow Diagram A business process is a collection of activities designed to produce a specific output for a particular customer or market. A process model captures the activities performed in a business process, and the inputs, outputs, and resources used of those activities. Not constrained by functional areas or business units. Also known as Activity Models. Resource: http: //www. sparxsystems. com. au/downloads/whitepapers/The_Business_Process_Model. pdf Page 31 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9, 5. 12. 2 Class Model The Class Model is at the core of object-oriented development and design. Static view of the objects and classes that make up the design/analysis space. Expresses both the persistent state of the system and the behavior of the system. Three diagrams shown here: class definition, class inheritance, and package definition. Resource: http: //www. sparxsystems. com. au/downloads/whitepapers/The_Logical_Model. pdf Page 32 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9 Use Case Model A Use Case represents a discrete unit of interaction between an "actor" and the system. An actor is a human or machine entity that interacts with the system to perform meaningful work. A Use Case may 'include' or 'extend' another Use Case with its own behavior. The complete set of Use Cases defines the whole functionality of the new system. Resource: http: //www. sparxsystems. com. au/downloads/whitepapers/The_Use_Case_Model. pdf Page 33 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9 Business Scenario A good business scenario is representative of a significant business need or problem. Used to derive the characteristics of the architecture directly from the high-level requirements of the business. A business scenario describes: • Processes and applications • Business and technology environment • Actors • Desired outcome Resource: http: //www. opengroup. org/architecture/togaf 8 -doc/arch/chap 34. html Page 34 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 2. 9 Knowledge Management The process of transforming intellectual property into a permanent asset. Systematically managing, storing and using the vast array of knowledge that has emerged within an organization. With on-demand access to managed knowledge, every situation is addressed with the sum total of everything anyone in the organization has ever learned about a situation of a similar nature. A collection of data is not information. A collection of information is not knowledge. A collection of knowledge is not wisdom. A collection of wisdom is not truth. Fleming, Neil. Coping with a Revolution: Will the Internet Change Learning? Resource: http: //www. systems-thinking. org/kmgmt. htm Page 35 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – 2. 3. 8 Organizational Chart Represents the structure of an organization in terms of rank. Three types of organizations: Hierarchical - every entity in the organization, except one, is subordinate to a single other entity. Matrix - people with similar skills are pooled for work assignments, and report to multiple managers. Flat - few or no levels of intervening management between staff and managers. Resource: http: //en. wikipedia. org/wiki/Organizational_chart Page 36 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Geographic Map A map is a visual representation of an area—a symbolic depiction highlighting relationships between elements of that space Depicts the physical locations of business entities. One of an array of techniques used to capture the current state of the business. Resource: http: //local. live. com Page 37 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Data Flow Diagrams Depicts a system as a network of functional processes, connected to one another by pipelines and holding tanks of data. Describes the major types of information required by the business processes that will be impacted. Used particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates. Resource: http: //www. yourdon. com/strucanalysis/wiki/index. php? title=Chapter_9 Page 38 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Technology Architecture Diagram Depicts the interfaces between current business technologies. Shows the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another. Also known as Deployment Diagrams. Resource: http: //www. agilemodeling. com/artifacts/deployment. Diagram. htm Page 39 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Domain Model An object model of the domain that incorporates both behavior and data. Each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form. Most useful when business logic is very complex. Resource: http: //martinfowler. com/eaa. Catalog/domain. Model. html Page 40 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Six Sigma is a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a company's operational performance by identifying and eliminating "defects" in manufacturing and service-related processes. Six Sigma = Six standard deviations from the mean = 3. 4 defects per million Over 25 tools and templates described on website below. Resource: http: //www. isixsigma. com/tt/ Page 41 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Root Cause Analysis A class of problem solving methods aimed at identifying the root causes of problems or events. It is better to correct or eliminate root causes instead of addressing immediately obvious symptoms. The 5 Why's - the practice of asking, five times, why the failure has occurred in order to get to the root cause(s) of the problem. • Problem: • Why? • Why so many pigeons? • Why so many spiders? • Why so many gnats? • Solution: – The Washington Monument was disintegrating – Use of harsh chemicals. – To clean pigeon poop. – Presence of many spiders to eat. – Presence of many gnats to eat. – They are attracted to the light at dusk. – Turn on the lights at a later time. Resources: http: //www. systems-thinking. org/rca/rootca. htm http: //www. isixsigma. com/library/content/c 020610 a. asp Page 42 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Work Breakdown Structure The foundation of project planning. Hierarchical structure depicting the breaking down of a complex project into individual components. May be organized around deliverables or phases of the project life cycle. Work Packages, at lowest level, can be completed independently, facilitating resource allocation, assignment of responsibilities, and measurement and control of the project. Resource: http: //www. netmba. com/operations/project/wbs/ Page 43 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8, 4. 3 Brainstorming Popular tool to develop highly creative solutions to a problem Helps to break out of established patterns of thinking, and develop new ways of looking at things Effective group brainstorming uses experience and creativity of all members of the group. Encourages sharing crazy thoughts, immune from criticism, that are refined into useful and original ideas. Resource: http: //www. mindtools. com/brainstm. html Page 44 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Business Process Reengineering Continuous Process Improvement is for gradual, incremental improvements to an existing process. BPR is different - it assumes the current process is broken. BPR is a clean slate perspective enabling the designers of business processes to disassociate themselves from today's process, create a vision for the future, and design new business processes. Resource: http: //www. isixsigma. com/me/bpr/ Page 45 Prepared by Daugherty Business Solutions for confidential review
Enterprise Analysis – BABOK 2. 3. 8 Cause and Effect Ishikawa Diagram - used to explore potential or real causes that result in a single effect. Causes arranged according to level of importance or detail, depicting relationships and hierarchy of events. Used to search for root causes, identify problem areas, compare relative importance of causes. Also known as Fishbone diagram Resource: http: //www. skymark. com/resources/tools/cause. asp Page 46 Prepared by Daugherty Business Solutions for confidential review
Tools and Techniques Catalog Requirements Planning and Management Ø Ø Ø Consult Reference Material Questionnaire to Identified Stakeholders Interview Stakeholders to Solicit Description Business Analyst Work Division Strategy Coordination of Information within the Team Knowledge Transfer Ø Ø Ø Page 47 Requirements Risk Planning Requirements Risk Monitoring Requirements Risk Control Use documentation from past requirements activities to estimate duration Measure and Report on Requirements Activity Manage Requirements Change Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 2. 4 Consult Reference Material Use existing project reference materials to identify people associated with the project and determine if they are project stakeholders. This listing will be reviewed by project management to identify the project stakeholders. Page 48 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 2. 5 Questionnaire to Identified Stakeholders A questionnaire sent to identified stakeholders will determine if any additional stakeholders exist. Questions should be open ended and require more than a Yes or No response: • • • Who is initiating the change that will result from the project? Who owns the problem(s) to be solved or goals to be achieved by the project? Who is directly impacted by the project? What are their roles? Who executes activities in the immediate business process affected by the project? Resource: http: //www. surveysystem. com/sdesign. htm Page 49 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 2. 7 Interview Stakeholders to Solicit Description An discussion with each stakeholder will solicit information used to document the stakeholder description. Questions are intended to describe each stakeholder’s involvement in the project, their authority in the project, and how the project will impact them. Requires direct contact with the stakeholder, either face to face, via telephone, or video teleconferencing. Page 50 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 3. 2 Business Analyst Work Division Strategy Allocation of activities among Business Analysts according to some distinct characteristic, such as: • • Subject Matter Expertise Complexity Previous Work Experience with Stakeholders Geography and Culture Area of Interests Physical Limitation Availability Page 51 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 3. 3 Co-ordination of Information within the Team has platform for sharing understanding, information and tools needed to successfully deliver requirements. New members receive training and/or "welcome package”. • • • Organization Standards and Policies Methodology Processes/Procedural Knowledge Document Templates Terminology Functional and Non-Functional Requirements Page 52 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 3. 4 Knowledge Transfer A systematic approach to capture, collect and share tacit knowledge in order for it to become explicit (documented) knowledge. • • Verbal Non Verbal Structured Walk-Through/Peer Reviews Status Meetings Debriefing Meetings Central Repository Mentorship Page 53 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 4. 3 Requirements Risk Planning Provides information about each identified risk so that it can be managed in a methodical and logical manner. The following is determined for each risk: • Likelihood • Impact • Intervention Difficulty • Precision of Assessment • Mitigation Strategy • Action Plan • Contingency Plan • Risk Response Plan Resource: http: //www. cvr-it. com/PM_Templates/Risk_Management_Plan_Template. doc Page 54 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 4. 4 Requirements Risk Monitoring Provides a current status of each identified risk so that it can be controlled in a methodical, logical, and timely manner. Execute the following steps: • Perform weekly checks of risk status (red, yellow, green). • Determine observed assessment if risk materializes. • Determine how to react to a risk when it materializes. • Ensure action plan is in place. • Document the monitoring results. Resource: http: //www. cvr-it. com/PM_Templates/Risk_Management_Plan_Template. doc Page 55 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 4. 5 Requirements Risk Control Careful control can lead to reducing the impact of risks throughout the requirements process. Prevents surprises that would induce working in reactive, fire -fighting mode. • • • Describe Impact Execute Mitigation Strategy Execute Action Plan Execute Contingency Plan/Corrective Action Document Lessons Learned Resource: http: //www. cvr-it. com/PM_Templates/Risk_Management_Plan_Template. doc Page 56 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 7. 5 Use documentation from past requirements activities to estimate duration Review documentation and artifacts created from other recent projects within the organization. Document the duration for each task in the current project, based on the actual duration of a similar task completed in a recent project. Page 57 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 9 Measure and Report on Requirements Activity In order to make effective decisions about the project, accurate, meaningful data is required. Metrics collection and analysis must be regularly monitored and measured. • Are we on schedule? • How are we doing compared to the budget? • What is the quality of the product? • Do we have enough people assigned to the project? Page 58 Prepared by Daugherty Business Solutions for confidential review
Requirements Planning and Management – BABOK 3. 10 Manage Requirements Change Plan Requirements Change • Who should be involved • How administered Understand the changes • Identify issues • Impact Analysis Document the changes • Formal change request • Links to other requirements Analyze change requests • Prioritize • Submit for approval Page 59 Prepared by Daugherty Business Solutions for confidential review
Tools and Techniques Catalog Requirements Elicitation Ø Ø Ø Ø Ø Brainstorming Document Analysis Focus Group Interface Analysis Interviews Observation Prototyping Requirements Workshops Reverse Engineering Survey / Questionnaire Page 60 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 2. 3. 8, 4. 3 Brainstorming Popular tool to develop highly creative solutions to a problem Helps to break out of established patterns of thinking, and develop new ways of looking at things Effective group brainstorming uses experience and creativity of all members of the group. Encourages sharing crazy thoughts, immune from criticism, that are refined into useful and original ideas. Resource: http: //www. mindtools. com/brainstm. html Page 61 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 4 Document Analysis Elicit requirements of an existing system by studying available documentation and identifying relevant information. When to use this technique: • Existing business rules to be included in new system • Subject matter experts not available during elicitation process. Page 62 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 5 Focus Group A focus group is a means to elicit ideas and attitudes about a specific product, service or opportunity in an interactive group environment. The participants share their impressions, preferences and needs, guided by a moderator. Qualitative Research - session results are analyzed and reported as themes and perspectives, rather than numerical findings. Resource: http: //www. useit. com/papers/focusgroups. html Page 63 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 6 Interface Analysis Interface analysis helps to clarify the boundaries of the system. It distinguishes which system provides specific functionality along with the input and output data needs. By clearly separating the requirements for each system, while defining the shared interface requirements, a basis for successful interoperability is established. A comprehensive glossary and data dictionary is critical. Resource: http: //www. sei. cmu. edu/domain-engineering/context_diag. html Page 64 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 7 Interviews A systematic approach to elicit information from a person or group of people in an informal or formal setting by talking to the person, asking relevant questions and documenting the responses. Two basic types • Structured - pre-defined questions. • Unstructured - open-ended discussion. Page 65 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 8 Observation Conducting an assessment of the subject matter expert’s work environment, watching them perform their work. Some people have their work routine down to such a habit that they have difficulty explaining what they do or why. Two basic approaches: Passive/invisible - take notes, but do not ask questions. Active/visible - ask questions, and participate in work process. Page 66 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 9 Prototyping Visualize interface requirements before the application is designed, using mock-ups of screens and reports. Business users find prototyping to be a comfortable means to identify and verify their interface needs. Horizontal: shallow view of system with no business logic. Vertical: deep slice of entire functionality. Throw-away: paper and pencil. Evolutionary: functioning system. Resource: http: //www. agilemodeling. com/artifacts/ui. Prototype. htm Page 67 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 10 Requirements Workshops One of the most effective ways to deliver high quality requirements quickly. Not a traditional meeting, rather a focused event attended by key stakeholders. A facilitator guides the meeting, and a scribe documents requirements and outstanding issues. Resource: http: //www. brcommunity. com/p-b 121 b. php Page 68 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 11 Reverse Engineering Analyzing a system/product to identify underlying business processes, data and rules. Extracting implemented requirements from the code. Appropriate when existing system has inadequate documentation and it is necessary to understand what the system actually does Black Box: Study system without examining internal structure. White Box: System inner workings are studied. Page 69 Prepared by Daugherty Business Solutions for confidential review
Requirements Elicitation – BABOK 4. 12 Survey / Questionnaire Means of eliciting information from many people in a relatively short time. Send surveys to project team, marketing, subject matter experts, stakeholders, users Collect information about customers, products, work practices and attitudes. Open-ended questions may provide more detail and a wider range of responses, but are more difficult to quantify and summarize. Resource: http: //www. surveysystem. com/sdesign. htm Page 70 Prepared by Daugherty Business Solutions for confidential review
Tools and Techniques Catalog Requirements Analysis and Documentation Ø Ø Ø Ø Ø Business Rules Class Model CRUD Matrix Data Dictionary Data Transformation and Mapping Entity Relationship Diagrams Metadata Definition Activity Diagram Data Flow Diagram Event Identification Ø Ø Ø Page 71 Flowchart Sequence Diagram State Machine Diagram Workflow Models Prototyping Storyboards / Screen Flows Use Case Description Use Case Model User Interface Designs User Profiles User Stories Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 12. 1 Business Rules Business rules describe a policy, guideline, standard, or regulation upon which the business operates. Business Rules Usually captured as a textual statement defining the rule exactly and unambiguously. Because each rule may impact several processes, they are documented separately in a Business Rule Catalog. The Catalog is managed continuously, and may be supported by software. Functional Capabilities Resource: http: //www. agilemodeling. com/artifacts/business. Rule. htm Page 72 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 12. 2 Class Model The Class Model is at the core of object-oriented development and design. Static view of the objects and classes that make up the design/analysis space. Expresses both the persistent state of the system and the behavior of the system. Three diagrams shown here: class definition, class inheritance, and package definition. Resource: http: //www. sparxsystems. com. au/downloads/whitepapers/The_Logical_Model. pdf Page 73 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 12. 3 CRUD Matrix The CRUD (Create, Read, Update, Delete) Matrix crossreferences user groups against the entities managed within a system. For each data element, it states which user groups are allowed to create, read, update, delete, or list those entities. Used by the development team to implement system security. Resource: http: //databaseanswers. org/data_migration/crud_matrix. htm Page 74 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 12. 4 Data Dictionary Centralized repository of information about data. such as meaning, relationships to other data, origin, usage, and format. Ensures that all stakeholders are in agreement on format and content. Contains definitions of each primitive data element and indicates how those elements combine into composite data elements. Resources: http: //en. wikipedia. org/wiki/Data_dictionary Page 75 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 12. 5 Data Transformation and Mapping Required to make existing data records available in a new business process. Identify data issues, business rules issues and a framework for moving data with minimal disruption to the users. Must include the following: • High level data model • Data business rules • Data cleansing plan • Environment plan Resources: http: //en. wikipedia. org/wiki/Data_transformation Page 76 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 12. 5 Entity Relationship Diagrams Visual representation of the entities of interest to the solution, the information that must be retained about each entity, and the relationship between them. Useful in describing the structure of the business and its rules. Four main components: • Entities • Attributes • Unique Identifiers • Relationships Resource: http: //www. threesl. com/pages/reference/diagrams/entity-relationship-diagram. php Page 77 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 12. 7 Metadata Definition Metadata is structured information about an information resource - “Data about data”. Three types of metadata: • Descriptive - attributes to identify a resource, such as title or author. • Structural - how compound objects are put together, such as pages and chapters • Administrative - information manage a resource, such as file type and date created. Resource: http: //www. niso. org/standards/resources/Understanding. Metadata. pdf Page 78 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 13. 1 Activity Diagram Graphically represents the flow of a sequence of activities, and the logic that controls the flow. Useful whenever it is necessary to communicate the details of a complex process. Key Features: Activities (rectangles) Flow (arrow-headed line) Start and End points (filled circle) Branches and Merges (diamond) Forks and Joins (bar) Responsibility (swim-lanes) Resource: http: //www. agilemodeling. com/style/activity. Diagram. htm Page 79 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 13. 2 Data Flow Diagrams Depicts a system as a network of functional processes, connected to one another by pipelines and holding tanks of data. Describes the major types of information required by the business processes that will be impacted. Used particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates. Resource: http: //www. yourdon. com/strucanalysis/wiki/index. php? title=Chapter_9 Page 80 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 13. 3 Event Identification What are the events to which the system must provide a response? Three types: external, temporal, internal What processes are required to provide a complete response to this event? These processes may then be documented, and further analyzed, using a process modeling technique. Page 81 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 13. 4 Flowchart One of the seven basic tools of quality control. Graphically represents the flow of a sequence of activities, and the logic that controls the flow. Resource: http: //en. wikipedia. org/wiki/Flowchart Page 82 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 13. 5 Sequence Diagram A sequence diagram shows how a use case scenario is executed by the class model. The classes required to execute the scenario are displayed on the diagram, as are the messages they pass to one another (triggered by steps in the use case). The sequence diagram shows how objects used in the scenario interact but not how they are related to one another. Resource: http: //www. agilemodeling. com/style/sequence. Diagram. htm Page 83 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 13. 6 State Machine Diagram A State Machine Diagram specifies a sequence of states that an object goes through during its lifetime, in response to events, and also the responses that the given object makes to those events. Also known as a State Chart Diagram States - boxes with round corners Transitions - line with arrow Events - labels on the lines Resource: http: //www. agilemodeling. com/style/state. Chart. Diagram. htm Page 84 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 13. 7 Workflow Models Visual representation of the flow of work in a business area. Includes: • Business activities • Sequential flow of activities • Persons performing the work • Key business decisions • Start and end points Used to clarify use cases and find opportunities for process improvement. Resources: http: //www. agilemodeling. com/style/activity. Diagram. htm Page 85 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 14. 1 Prototyping Visualize interface requirements before the application is designed, using mock-ups of screens and reports. Business users find prototyping to be a comfortable means to identify and verify their interface needs. Horizontal: shallow view of system with no business logic. Vertical: deep slice of entire functionality. Throw-away: paper and pencil. Evolutionary: functioning system. Resource: http: //www. agilemodeling. com/artifacts/ui. Prototype. htm Page 86 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 14. 2 Storyboards / Screen Flows A storyboard provides a simple simulation of an interface or a use case using commonly available office tools, e. g. , white board, markers, index cards, post-it™ notes, scissors, or transparency film. This is a low cost modeling technique that provides early design feedback from users and is quicker than providing a working, coded user interface prototype. Resource: http: //www. agilemodeling. com/artifacts/ui. Flow. Diagram. htm Page 87 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 14. 3 Use Case Descriptions are written as a series of steps performed by actors or by the system that enable an actor to achieve a goal. The primary or basic flow represents the simplest way to accomplish the goal of the use case. Special circumstances and exceptions that result in a failure to complete the goal of the use case are documented in alternate flows. Resource: http: //alistair. cockburn. us/index. php/Resources_for_writing_use_cases Page 88 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 14. 4 Use Case Model A Use Case represents a discrete unit of interaction between an "actor" and the system. An actor is a human or machine entity that interacts with the system to perform meaningful work. A Use Case may 'include' or 'extend' another Use Case with its own behavior. The complete set of Use Cases defines the whole functionality of the new system. Resource: http: //www. sparxsystems. com. au/downloads/whitepapers/The_Use_Case_Model. pdf Page 89 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 14. 5 User Interface Designs Modeling of user interaction with specific system elements. Improves usability by involving users early in the requirements process. General ideas, not a detailed design implementation. Allows users to state their preference for navigating a specific element, how to achieve their goals, and how to accomplish their work. Resource: http: //www. agilemodeling. com/artifacts/ui. Prototype. htm Page 90 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 14. 6 User Profiles Gather all known information about end users of the proposed business solution, and break them into specific profiles. Highlight differences in user groups that require different user interface solutions or use cases. The goal is to propose business solutions that provide positive and effective user experiences. Related to Task Analysis. Resource: http: //www. usabilitynet. org/tools/taskanalysis. htm Page 91 Prepared by Daugherty Business Solutions for confidential review
Requirements Analysis and Documentation – BABOK 5. 14. 7 User Stories High-level definition of a requirement, containing just enough information so developers can produce a reasonable estimate of the effort to implement it. Used by the project team to: • Get agreement between project stakeholders on key features • Gain time estimates needed to accomplish the coding of that feature. • Facilitate feature prioritization for each release cycle. Resource: http: //www. agilemodeling. com/artifacts/user. Story. htm Page 92 Prepared by Daugherty Business Solutions for confidential review
Appendix Page 93 Prepared by Daugherty Business Solutions for confidential review
Development Methodology Example ELABORATION INCEPTION Understand the business Confirm Vision of Company / Organization • Vision Statement Confirm Near-Term Business Objectives • Business & Project Objectives • Critical Success Factors Model Business • Business Context Scope Diagram • Business Activity Diagrams & Outlines • Business Rules & Functional Capabilities • Gap Analysis Plan Elaboration Establish System Scope & Approach Estimate & Plan Elaboration Identify Actors & Use Cases • Inventory of Actors & Use Cases • Use Case Diagram(s) and Descriptions Analyze Requirements & Design Solution • Elaboration work plan Establish Architectural Approach • Existing technology and application standards • Packaged software/tool assumptions • Architecture framework and design patterns • Key non-functional system characteristics CONSTRUCTION Plan Construction Analyze Use Cases • • • Detailed Use Cases Screen Flow Diagrams Sequence Diagrams Screen Designs Business Rules & Functional Capabilities • Supplemental Specifications Define Architecture & Components • System Components • Class Models • Entity Relationship Diagrams • Orthogonal View Prototype Use Cases & Architecture Estimate & Plan Construction • Identify Resources • Resource Build & Test Solution Establish Construction Approach • Team Culture • “Construction Allocation & Week” Leveling • Deliverables Set • Develop Iteration Plan & Project Plan Iterative Design, Development and Testing • • Class Models Business Logic Screens, Reports Views, SP’s Physical Databases Test Scripts Builds TRANSITION User Acceptance Testing Perform Initial One-Time Tasks Deliver Solution Transition Planning • Environment setup • Initial Components Training and Support Manage Feedback Documentation Change Management Package Components & Deliver • Test Strategy & Approach • Test Plans, Cases, & Results Id, Eval, Select, & Implement Packages Project Management / Requirements Management Software Quality Assurance / Software Configuration Management
Phase Control Points INCEPTION Phase ELABORATION CONSTRUCTION TRANSITION Approval Requirements Inception Scope Review – The scope is reviewed with the stakeholders to ensure agreement on system boundaries Elaboration Requirements Review – The goal is to ensure the detailed requirements of each system feature accurately reflects the stakeholder’s vision. In a methodology like RPM, this is done at the end of elaboration. In a methodology like XP or RUP, this is done during each iteration for the features that part of that iteration. Construction Test Case Review – The goal of this review is to ensure what will be tested matches the requirements. In some methodologies, this is done concurrently with development but must be finished prior to finishing development. In other methodologies, this must be complete on a feature by feature basis prior to the start of development. Test Result Review – The goal of this review is monitor the results of the tests and ensure an adequate amount of the system is tested. Transition User Acceptance Review – The BA should work with the stakeholders to determine the final readiness of the product. This typically happens prior to each release. However, some methodologies have this occur at the end of each iteratioin whether it results in a release or not.
Скачать презентацию Business Analysis Tools Techniques Templates and Tips February
62e0b525c5082ae96e0c75a9aad63db5.ppt