Business Analysis Skills Assessment

  Technique Description Skill Level
1 Define Acceptance and Evaluation Criteria Specifies tests and decisions regarding the approach or methodology, tools and techniques, priorities and risks associated with the acceptance phase of project.
0   1   2   3   4   5
2 Competitive Analysis and Benchmark Studies Competitive analysis is a process which identifies key information to predict the actions of your most significant competitors. Competitive analysis is a process which identifies the key information to predict the actions of your most significant competitors. Benchmarks are created to allow you to compare your practices to best-in-class practices.
0   1   2   3   4   5
3 Facilitate Brainstorming Sessions This is a general technique for eliciting many creative ideas for a target area of interest.
0   1   2   3   4   5
4 Identify Business Rules Business rules are a set of operative or structural statements (facts, inferences, or calculations) that define how a business will operate independent of technology. Rules also document complex business logic or control flows.
0   1   2   3   4   5
5 Data Dictionary and Glossary A data dictionary (glossary) is used to ensure that stakeholders agree on the format, properties, and content of desired information. Record the definitions and agreements in an appropriate repository or tool to manage the consistent use of these elements.
0   1   2   3   4   5
6 Diagramming Data Flow A Data Flow Diagram (DFD) provides a visual model of how information and physical material moves through a system. It shows inputs, processes, storage, and outputs from a system, and the external entities that interface to the system.
0   1   2   3   4   5
7 Perform Data Modeling A data model: represents data entities, key attributes, relationships between entities, and the nature of those relationships. Information Usage Analysis: is a technique to elicit requirements that identify or quantify data that the solution has to maintain and/or track. Class Diagrams: Depicts the attributes, methods and relationships amongst all classes of objects for the area in question. Normalization: Groups attributes into logical units based upon established rules of normalization. The most common, desired in 3rd normal form.
0   1   2   3   4   5
8 Apply Decision Analysis Decision Analysis is a formal, structured approach to determine the most desired opportunity from candidate opportunities.
0   1   2   3   4   5
9 Analyze Documents Document analysis determines requirements by studying existing documents and extracting data, functions, business rules, interfaces, and constraints.
0   1   2   3   4   5
10 Estimate Effort, Duration and Cost There are eleven recognized techniques: Analogous, Parametric, Bottom-up, Rolling Wave, 3-point, Vendor Bid, Historic Analysis, Expert, Delphi, Function Points, and Comparison to closed projects. You should have experience in a minimum of five of them.
0   1   2   3   4   5
11 Perform Focus Groups Studies Focus groups are a means to capture ideas and attitudes about products, opportunities, or services. The group is often not part of the company , but they do have an interest in the topic.
0   1   2   3   4   5
12 Decompose Requirements Decompose business requirements into functional, informational, performing, constraining, and subjective requirements.
0   1   2   3   4   5
13 Identify Interfaces (aka: System Usage Matrixes) A table showing the interaction between all impacted systems.
0   1   2   3   4   5
14 Perform Interviews (five types) Solicit and capture business and information system requirements through various interview techniques.
0   1   2   3   4   5
15 Identify and Evaluate Lessons Learned Lessons learned analysis exists to compile and documents what went wrong and what went well and how this information can be used to improve the future.
0   1   2   3   4   5
16 Develop Indicators, Metrics, and Reporting Use Structured walkthroughs, Feasibility studies, Stakeholder defined acceptance criteria, Metrics, Prototyping, etc.
0   1   2   3   4   5
17 Document Non-Functional Requirements (aka: Quality, Performance, or Service Level Requirements) A list of measures that will be used once the solution is in production to ensure that it performs at acceptable levels. A specific statement that describes a qualitatively or quantitatively measurable behavior of the solution. They often end in "ability"; (Usability, Reliability, etc).
0   1   2   3   4   5
18 Observe the working environment Observe the Visible, Working Components of the System and how the SMEs and users act. aka: Analysis by walking around.
0   1   2   3   4   5
19 Model the Organization This is the use of Org models to determine who does what and how they are related to other elements of the org. This helps answer the question of "Who does what to whom, when, and why?"
0   1   2   3   4   5
20 Record Defects and Issues (aka: Problem Report Defines an error situation that arose during a walkthrough, user acceptance testing, or during the productive use of an application.
0   1   2   3   4   5
21 Perform Process Modeling (Function Modeling) Shows the control and/or data transfer between activities. Context Diagram: A high-level Business Process model depicting the information exchange between various organizational units or specific individuals within the organization. CRUD Matrices: A table that shows the creation, retrieval, update and deletion of attributes of entities by processes; commonly used in affinity analysis. Swim lane (aka: Activity Diagrams) or Business Process Models: Documents business or system processes, data transformations, transportation, storage, and indicates the scope of the project using external entities. Work Flow Diagrams: A representation of the sequence in which people do their jobs including their interaction with or reliance upon information technology. Sequence Diagrams: A representation of communication between individual objects of an application, their creation and destruction, in the sequence in which they are carried out. Process Mini Specs: Represent the inner workings of a process typically expressed in business rules, logic or algorithms or similar tools.
0   1   2   3   4   5
22 Prototype (aka: UI, User Interface) A representative view of the look, feel and usability of the solution, typically showing screens, reports, interaction, etc.)
0   1   2   3   4   5
23 Plan and Execute Requirements Workshops Prepare and facilitate a Joint Application Development (JAD) session.
0   1   2   3   4   5
24 Risk Analysis Risk analysis involves analyzing systems and projects for uncertainties that can impact an initiative, solution, or organization. Risk analysis attempts to identify, prioritize, and plans for mitigation or elimination fof the identified risks. Risk analysis requires assessment, response and costs.
0   1   2   3   4   5
25 Analyze Problem / Symptoms, AKA Root causes Based on problem analysis, list real (business) problems, symptoms of problems, potential solutions, and out-of-scope problems which will not be solved by the project.
0   1   2   3   4   5
26 Develop Use Cases and Scenarios USE Case: a single interaction between the user (which may be a human or another automated system) and the system in question depicting a basic course of events, alternate and exception paths with other relevant information: also has a diagram component, and is also part of UML. Scenarios: a specific example (instance) of the use case.
0   1   2   3   4   5
27 Perform Scope Modeling Scope models are used to clearly define the scope of analysis or the scope of a project. Scope models define and bound the scope of business analysis and project. Scope models define the “complete” scope"—that is, the boundaries of the scope correspond with the natural boundaries of a business domain. They can be Context Models, Events models, and Use Case Diagrams.
0   1   2   3   4   5
28 Model Events and States (diagrams) Event: Represents business and/or system events with the related responses as a way of delineating the system from its environment. State: Represents the status of an object in any given point, the potential for transforming the object into a different status, and the conditions/events that can trigger the transformation.
0   1   2   3   4   5
29 Perform Structured Walkthroughs and Create Reports Describes the process, the product, the participants, and the results of a meeting designed to identify errors or omissions in a specific deliverable, its impact, and recommended resolutions.
0   1   2   3   4   5
30 Create and Analyze Surveys and Questionnaires (closed and open) This is a set of questions for stakeholders and SMEs. The results are analyzed and distributed to other parties for confirmation.
0   1   2   3   4   5
31 Perform SWOT Analysis Identify strengths, weaknesses, opportunities, and threats and propose improvements in how the organization could use its information resource.
0   1   2   3   4   5
32 Manage User Stories Workshop These are descriptions of functionality written by and valuable to the customer. They is used to extract requirements and use cases.
0   1   2   3   4   5
33 Vendor Assessment If solutions are provided by external vendors or the solution is outsourced, then there may be specific requirements related to the involvement and relationships of the vendor. There could be requirements of the vendor to prove financial security, meeting specific staffing levels, to identify appropriately skilled staff, to meet regulatory compliance, etcetera. Non-functional requirements are often used to define the service levels requirements. You should be able to create and evaluate the responses to these documents, RFI, Request for Information, RFQ, Request for Quote, and RFP, Request for Proposal. Vendor assessment is conducted to ensure that the vendor is reliable and that service levels will meet an organization’s expectations.
0   1   2   3   4   5
34 RACI Matrix The RACI matrix describes the roles of those involved in business analysis activities. It describes stakeholders as having one or more of the following responsibilities for a given task or deliverable: Responsible, Accountable, Contributor, or Informed.
0   1   2   3   4   5
35 Stakeholder Map Stakeholder maps are visual diagrams that depict the relationship of stakeholders to the solution and to one another. There are many forms of stakeholder maps, but two common ones include the simple org chart and the more complex stakeholder analysis matrix.
0   1   2   3   4   5
36 Variance Analysis The purpose of this technique is to analyze discrepancies between planned and actual performance, determine the magnitude of those discrepancies, and recommend corrective and preventive action as required. Variances can be related to planned versus actual estimates, cost, scope, product expectations, or any measures that have been established during the planning process.
0   1   2   3   4   5
37 Baselining Once requirements are approved, they may be baselined, meaning that all future changes are recorded and tracked, and the current state may be compared to the baselined state. Subsequent changes to the requirement must follow the change control process.
0   1   2   3   4   5
38 Signoff Requirements signoff formalizes agreement by stakeholders that the content and presentation of documented requirements is accurate and complete. A formal sign-off of requirements documentation may be required by organizational standards or for regulatory reasons
0   1   2   3   4   5
39 Coverage Matrix A coverage matrix is a table or spreadsheet used to manage tracing. It is typically used when there are relatively few requirements or when tracing is limited to high-level requirements (e.g. features or models).
0   1   2   3   4   5
40 Feasibility Analysis For small, relatively straightforward efforts, the solution approach can be determined by the business analyst alone or with a small team of experts examining the approaches in an informal working session. For larger change initiatives requiring significant investment, a more formal feasibility study may assist with determining the most viable solution option.
0   1   2   3   4   5
41 Problem or Vision Statement A problem or vision statement states the business need, identifies key stakeholders, and briefly describes the positive impact that meeting the business need will have on those stakeholders.
0   1   2   3   4   5
42 MoSCoW Analysis MoSCoW analysis divides requirements into four categories: Must, Should, Could, and Won’t.
0   1   2   3   4   5
43 Timeboxing / Budgeting Timeboxing or budgeting prioritizes requirements for investigation and implementation based on allocation of a fixed resource. It is used when the solution approach has been determined. Timeboxing prioritizes requirements based on the amount of work that the project team is capable of delivering in a set period of time. By contrast, budgeting is used when the project team has been allocated a fixed amount of money. The approach is most often used when a fixed deadline must be met or for solutions that are enhanced on a regular and frequent basis. There are a number of approaches that can be taken to determine which requirements can be included in a timeboxed iteration:
0   1   2   3   4   5
44 Voting Voting is a prioritization method that allocates a fixed amount of resources (votes, play money, or other tokens) to each participant for them to distribute among proposed features or requirements.
0   1   2   3   4   5
45 Checklists Checklists are useful as a quality control technique for requirements documentation. They may include a standard set of quality elements that the business analyst or other reviewers use to validate the requirements or be specifically developed to capture issues of concern to the project. The purpose of a checklist is to ensure that items that the organization or project team has determined are important are included in the final requirements deliverable(s), or that process steps that the organization or project team has determined must be followed are addressed. Checklists may also be developed on a project basis to help ensure consistency of approach and outcomes, particularly on large projects where multiple sub-project teams are working.
0   1   2   3   4   5
46 Force Field Analysis Force field analysis is a graphical method for depicting the forces that support and oppose a change. It involves identifying the forces that support and oppose a change, depicting them on opposite sides of a line, and then estimating the strength of each force in order to assess which set of forces are stronger. Once this analysis is complete, the next step is to look for ways to strengthen the forces that support the desired outcome or generate new forces.
0   1   2   3   4   5
47 Requirements Documentation Requirements are frequently captured in a formal document. Many templates for requirements document exist and are in common use. The selection of templates and documents is dependent on the business analysis approach chosen.
0   1   2   3   4   5
48 Requirements for Vendor Selection If the solution team thinks that a potential solution is available from an outside party, the business analyst may capture the requirements in the form of a Request for Information (RFI), Request for Quote (RFQ), or Request for Proposal (RFP).
0   1   2   3   4   5
    

 

 

 

 

 

 

INSTRUCTIONS: You are self evaluating your skills. Please indicate what you consider to be your current skill level with each technique based on the description. If you cannot decide between two values, select the button between them and your score will be set at the halfway mark (i.e. 2.5). What the skill levels indicate:
0 I am not familiar with this technique 1 I have seen results from this technique, but not used it 2 I can use this technique with help
3 I have applied this technique successfully according to standards 4 I have used this technique extensively in analysis and documentation 5 I am an expert in this technique and could mentor or train others

 

Our recommendations can advance your business analysis career up to and including the "Roadmap to the CBAP®".

Please send me my personalized Roadmap to the CBAP® at:

 

 

  Click on a Knowledge Area (KA) in the chart above to see which of our training offers support that KA.  

 

 This chart gives you an immediate sense of the difference between your perceived skill levels compared to the International Institute of Business Analysis® (IIBA®) Certified Business Analysis Professional® (CBAP®) test expectation which is 80% or above for 4 of the 6 areas in the current BABOK® version, 2.0. A red line indicates that you placed yourself below 55% for that knowledge area and a yellow line indicates between 56-80%. A green line indicates that you exceed the 80% for that particular knowledge area.
 

 
You can improve your skills as much as 40% with training. Interestingly, the higher you are, the harder it is to make progress. This is one of the reasons that the IIBA® has strict requirements that must be met prior to taking the CBAP®. You can see their requirements on the IIBA® website at by looking for CBAP® requirements.

If you would like to receive your personalized roadmap to the CBAP® based on your current knowledge levels, please click on the "Submit" button, above.
 

 
We thank you for visiting our website today
and trust that your visit was enjoyable and productive.