Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
35 Cards in this Set
- Front
- Back
|
What are the tools of the BA? List them. |
Acceptance and Evaluation Criteria Benchmarking Brainstorming Business Rules Analysis Data Dictionary Data Flow Diagrams Data Modeling Decision Analysis Document Analysis Estimation Focus Group Functional Decomposition Interface Analysis Interviews Lessons Learned Process Metrics and Key Performance Indicators (KPIs) Non-Functional Analysis Observation Organizational Modeling Problem Tracking Process Modeling Prototyping Requirements Workshop Risk Analysis
|
|
|
Acceptance Criteria is what? |
equirements that must be met. Determine which requirements can be used as acceptance criteria. These are the minimal set of requirements for the solution to be worth implementing. (Pass/Fail)R |
|
|
Brainstorming, discuss |
Fosters creative thinking and aims to produce numerous new ideas and derive themes. - What factors constrain the group from moving ahead with an approach. - What could be causing a delay in X?
Prep: Develop a clear, concise definition of an area of interest. Determine a time limit to generate ideas. Set expectations with participants
In the Session: Encourage creativity and participation. Don't limit ideas.
Wrap Create a condensed list of combined ideas. Rate the ideas. |
|
|
Business Rules Analysis |
Define the rules that govern decisions in an organization and that define, constrain or enable organization operations.
A business policy is a non-actionable directive that supports a business goal.
A business rule is a specific, actionable, testable directive that is under the control of an organization and that supports a business policy.
Business Rules should be - Stated in appropriate terminology to enable the domain SMEs to validate them. - Documented independently of how they will be enforced. - Stated at the atomic level and in declarative form. - Separated from processes that the rule supports or constrains. - Maintained, so that they can be monitored and adapted as policies change.
They should be independent of implementation or any other info.
Types of business rules: - Operative - Rules an organization enforces as a matter of policy. These guide actions. "An order may not be place when the customer address does not match the credit card address." - Structural - determine when something is or is not true. They cannot be violated. Not about people's behavior. These may be calculations or inference rules. "An order must have one and only one associated payment method."
Determine the sanctions imposed when the rule is violated, when a rule can be overridden, when there are exceptions. |
|
|
Data Dictionary |
Glossary of terms in the organization. e.g. client vs. customer.
It includes the allowable values. - Primitive Data Element: unique names, aliases, values/meanings, description. - Composite Data Element: assembled from primitive data elements. - sequences: shows primitive data elements in order - repetitions: show that one or more primitive elements occur multiple times.
|
|
|
Data Flow Diagrams |
Visual representation of how data flows through the system. It includes to, from, data stores, external entities and external stores.
- Data Store - Data Process (transforms data) verb object. Filter, conversion, reorder, combine. Represented by circle or rounded rect. - Data Flow - noun phrase. |
|
|
Data Modeling |
Describes the concepts relevant to the domain, relationships between them and the info associated to them.
Represents people, places, things, and concepts important to the organization and their attributes.
ERD (entity relationship diagram) for relational db. Class diagram for OO development.
Logical model describes the entities, attributes and their relationships of most importance. Physical model describes how data is stored.
Concept is something of significance to the domain being described. Unique ID, entity in ERD, classes in class diagrams.
Attributes define the particular piece of info associated with a concept. Allowable values, type of info.
Rectangle Entity, next box ID, next attribute.
Attribute - name - unique name for an attribute - values/meanings - list of acceptable values - description
Relationship significant business association between concepts
Metadata
Class box, attribute data type, next box operations. |
|
|
Decision Analysis |
For dealing with complex, difficult, or uncertain situations. Examines the and models possible consequences of different decisions.
Requires understanding of: - values, goals, and objectives relevant to the problem. - nature of the decision that must be made. - areas of uncertainty that affect the decision - consequences of the decision
Outcomes: Usually requires math model. Financial analysis (p. 167). and Non-financial - uses some metric to compare models.
Uncertainty - calculate the expected value of outcomes. Involves estimating % chance of each outcome occurring and then multiplying numeric value associated. Trade-offs: when there are multiple conflicting objectives. - Elimination of dominant alternatives. Any option that is clearly inferior to some other option. (The better option dominates it.)
Rank objectives on a similar scale. |
|
|
Document Analysis |
Elicit requirements by studying documentation on existing and comparable solutions.
Business plans, market studies, contracts, requests for proposals, SOWs, memos, existing guidelines, procedures, training guides, competing product literature, published & comparable product reviews, problem reports, customer suggestion logs, existing sys. specifications.
1. Prep: What documentation is available. 2. Doc Review: doc the business details for follow up with SMEs 3. Wrap up: review details with SMEs. Organize info req. format. |
|
|
Estimation |
Forecast the cost and effort in pursuing a course of action. Possible range of costs.
Analagous Estimation: use of similar project for developing estimates. ROM (Rough order of magnitude) or top down estimating, done at the beginning of a project.
Parametric Evaluation - use of parameters, multiplied by a number of hours, eg. BA has decided 10 use cases will be developed and uses past estimates to determine length of time.
Bottom Up Estimate: BA has collected all the deliverables, activities, tasks and estimates.
Rolling Wave. 3 Pt Estimation - uses scenarios for most optimistic, most pessimistic and most likely.
Historical Analysis - Expert judgment or delphi estimation. |
|
|
Focus Groups |
Means to elicit ideas and attitudes in interactive group environment. Pre-qualified individuals to discuss and comment on a topic. More structured than brainstorming.
Prep: 1-2 hour session. - Recruit participants 6-12 people - Homogeneous or Heterogeneous backgrounds. In hetero, people may self-censor.
- Assign Moderator and Recorder. Mod promote discussion, ask open questions, facilitate interactions, keep focus, remain neutral.
- Create a discussion Guide - Reserve logistics
Run the session and then produce the report.
|
|
|
Functional Decomposition |
Decompose processes, functional areas, or deliverables into component parts.
Break down large probes into smaller functions or deliverables so that work is independent.
Function Sub Function Sub Function Process Activities
Identifies high-level functions of an org or solution and breaks it down until sub-function cannot be broken down.
Creates a conceptual model of the work to be delivered. |
|
|
Interface Analysis |
Interfaces between solutions and how they interact. User interfaces, humans, reports, to and from external apps and external hardware.
Clarifies the boundaries of the interfacing applications.
It distinguishes which application provides specific functionality along with input and output needs.
Early detection uncovers interfacing stakeholders and sub. requirements.
Describe the purpose of each interface. Evaluate which type may be appropriate. Elicit high-level details. Define inputs and outputs for the interface, validation rules that govern the input and output and events that trigger interactions. |
|
|
Interviews |
Elicits info from a person or group of people in an informal or formal setting.
Structured - predefined questions. Unstructured - Open-ended discussion.
Who has the most authentic and current info on the subject of interest. What is their stake in the interface? What is the relative importance of the info. held by one person relative to another? |
|
|
Lessons Learned |
Compile and document successes, opportunities for improvement, failures and recommendations to improving.
Sessions can review BA activities, deliverables, final product, BA process, managerial issues, variances and corrective measures. |
|
|
Metrics |
Measure performance indicators to measure performance of solutions and other matters of interest to stakeholders. -Quantifiable level of an indicator that the org uses to measure progress.
Indicators -specific numerical measurement for a goal, impact, output, activity or input. A goal has five characteristics: Clear - precise and unambiguous Relevant - appropriate to teh factor Economical - available at a reasonable cost Adequate - provides a sufficient basis to assess performance Quantifiable - can be independently validated
Proxies can be used for data when direct indicators absent. e.g. cust survey missing, use the renewed contracts
2 metrics - specific point in time Structure - establishing a monitoring and evaluation system requires data collection procedure, a data analysis, reporting and collection of baseline.
Three factors in assessing the quality of indicators and their metrics: Reliability - how stable and consistent data is across time. Validity - Extent to which data clearly and directly measures performance the org intends to measure. Timeliness - data is a fit of frequency and latency of data.
Reporting: Trends are more credible than absolute metrics. |
|
|
Non-Functional Analysis |
Describe the required qualities of a system such as usability performance. These supplement functional requirements: usability, learnability, reliability, scalability, maintainability, reusability.
Can also include non-computer: hours of service, cycle time to deal with customer req. SLA (QoS).
ISO 912
- Reliability - available when needed. ability to recover from errors. - Performance Efficiency - time taken to perform activity, and resource prioritization levels. - Operability - understandable to users. - Security - confidentiality of info, integrity of data, verify user actions. - Compatibility - coexist and interact with other applications - Maintainability - can it be modified after implementation Transferability - can app be installed in another environment, ease of installing and maintaining it. 90% of operators will be able to use the functions after 6 hours of training. |
|
|
Organizational Modeling |
Describes roles, responsibilities, and reporting, structures within an org. and align them to the org's goals. The model will define the scope of the organization unit, formal relationships between people who are members of the unit. roles people fill, interfaces between stakeholders. |
|
|
Problem Tracking |
Organized approach to tracking, management and resolution of defects, issues, problems, and risks throughout BA activities.
Includes issues, questions, risks, defects, conflicts, or other concerns to be tracked to resolution. Tracking tool may include an identification of problem, status, assigning of related actions, that are required to team members, and tracking expected resolution, on dates, resolution, results, actions, decisions, priority and impacts.
Problem record, description, raised by, date identified, impact, priority, need by date, owner, status, action to resolve, assignee, completion, outcome.
Root cause analysis can be time consuming. |
|
|
Process Modeling |
To understand how work that involves multiple roles and depts is performed within an org. Describes how multiple people or groups collaborate and perform work. Processes are linked by a sequence flow. Swim lane chart.
Process initiated by an event in the business domain. Events can be actions taken by a person, rules which cause an action to be taken, or simply the passage of time. - Activities - individual steps to execute the business process. - Decisions - forks where flow of work diverges. - Events - outside the scope of a process, may create, interrupt, or terminate a process. - Flow - direction of workflow - Roles - type of person or group. - Swimlanes or pools - (pool org boundary) - Terminal points - start or end of a proces
|
|
|
Process Improvement |
Six sigma for eg. Analysis of a process to identify and remove activities that don't add value. - Reduce of time required to complete process. - Improve interfaces or handoffs - Reduce bottlenecks and backlogs. |
|
|
Prototyping |
Details user interface requirements and integrates them with other requirements such as use cases, scenarios, and business rules. - Functional scope - Use through Sys Dev Lifecycle.
Determine whether to use a throw-away prototype or evolutionary functional vs. vertical vs. horizontal.
Identify functionality to be modeled.
Iterative process, add details as needed.
- Storyboard (dialog map, navigation flow) portrays nav paths across components. Visual includes abstractions of each screen with directional arrows. - Screen prototypes provide data attributes, selection criteria, and business rules. - Screen layout or mockup, graphical rep of elements.
Throw away quick way to uncover and confirm requirements. |
|
|
Observation |
Watching user in work environment. Good for documenting as-is and to-be.
Good for experienced users who aren't good at explaining what they do or why.
Approaches: passive/invisible - doesn't ask questions, records observations. May ask after done. Active/visible: may even be hands on.
Prepare questions. Introduce yourself, reassure user not questioning their work. Using data as input for requirements. "will stop at any time if this is interfering" "you can think aloud to share intentions, challenges, and conerns"
Take detailed notes Doc and confirm findings. If observing multiple users, note commonalities and differences. Review findings with group as whole. |
|
|
Requirements Workshop |
To scope, discover, define, prioritize, and reach closure on requirements for the target application.
Prepare for the workshop: - Clarify stakeholders needs and purpose of the workshop. - Identify critical stakeholders who should participate. - Define the agenda. - Determine how to document the workshop. - Schedule arrange logistics. - Send materials in advance. - Conduct pre-workshop interviews.
Validate freq. if session is aligning with requirements. |
|
|
Root Cause Analysis |
Determine the underlying source of the problem. Critical element is to ensure that the current processes and business thinking is challenged. Do they provide good value in light of realities.
Two methods: - Fishbone Diagram - Primary, secondary and tertiary causes organized by categories. - Five Whys - explore the nature and cause of the problem. Why do you think this problem occurs? capture idea of the problm. Keep asking why until you get to the root cause. |
|
|
Risk Analysis |
Identify and manage areas of uncertainty that can impact and initiative, solution or organization. A risk is an uncertain event that can impact the ability to achieive an objects. Risk can be positive or negative.
1. Risk Tolerance: Risk averse, neutral, or risk seeking (to maximize benefits, may accept low chance of success).
2. Assessment 3. Response Acceptance- no effort madet o deal with risk. Transfer- possible effects moved to third party. Avoidance - takes measures to ensure risk can't occur. Mitigation - reduce probability.
|
|
|
Scenarios and Use Cases |
Written to describe how an actor interacts with a solution to accomplish one or more of the actor's goals or to respond to an event.
Scenario- just one way that an actor can accomplish a particular goal. Scenarios are a series of steps, performed by actors or the solution so actor can achieve goal. Use Case - describes all so possible outcomes of an attempt to accomplish a goal the solution will support. Primary and alternate flows. Primary is the simplest way to accomplish the goal.
Elements: Name: unique name within the project. Describe which goal or event it will deal with and generally includes a verb and noun.
Actor: Person, system, or event external to the system that interacts with the system through a use case. Actor is the role. Time can be an actor. Preconditions: Any fact that the solution can assume to be true when the use case begins. "User must be logged in." or Item must exist in catalog."
Flow of Events - Describes what the actor and system do during execution of the scenario or use case. Basic flow, and alternate flows. Exception is when a flow does not allow actor to achieve the goal.
Post Conditions: Any fact that must be true when the use case is complete. Post conditions must be true. There may be separate post-conditions for successful and unsuccessful executions.
Relationships: Relationships between actors and use cases are called associations. They do not represent input, output, or dependency. An association line only indicates that an actor has access to the functionality.
Relationships between use cases are called sterotypes: Extend: allows for insertion of additional behavior into the use case. Use case being extended must completely function on its own.
Include: Allows for the base use case to make use of functionality present in another use case. The included uc does not need to be a complete use case.
|
|
|
Scope Modeling |
Scope models serve as a basis for defining and delimiting the scope of BA and project work.
Elements 2. Events - External events happen in external entity. 3. Features - Service to fulfill a need. 4. Use Case Diagram - 5. Business Processes |
|
|
Sequence Diagrams |
Classes required to execute the scenario are displayed on the diagram. Shows how objects interact but not how they are related to one another.
Procedural Flow Asynchronous Flow |
|
|
State Diagrams |
Shows how behavior of a concept, entity, or object changes in response to events. Specifies a sequence of states that an object goes through during its lifetime and defines which events cause a transition. Allowable behavior for an object depends on its current state.
States: a unique condition an object can be in or a status that it may have. All states are mutually exclusive.
Transitions: Dynamic behavior that moves an item from one state to another. Transitions are triggered by completed activities, events, or other stimuli. Event may only cause a transition if an object is affected by the event in its current state.
|
|
|
Structured Walkthrough |
To communicate, verify, and validate requirements.
Prerequisite: Complete requirements package. Must be complete to schedule a review. May cover one requirement document, several or package.
Reviewers project stakeholders or equivalent proxy. Sponsors.
Review scope. Checklist should include requirements out of scope, |
|
|
Survey/Questionnaire |
Ask questions. Closed or open ended. |
|
|
SWOT |
Strengths, Weaknesses, Opportunities, and Threats. Framework for strategic planning, competitive analysis.
Opportunities are external factors that assessed group may take advantage of. Threats may be a competitor.
Draw a grid. |
|
|
User Stories |
Functionality users need from a solution to meet a business objective. Actor: stakeholder who benefits. Description: High level overview of functionality. Benefit: Business value the story describes. |
|
|
Vendor Assessment |
Knowledge and expertise Licensing and pricing models Product reputation and market position Terms and conditions Vendor experience and reputation Vendor stabilty |
