Ccba Exam

Front 1

What is business rule?

Back 1

A business rule is a specific, actionable, testable directive that is under the control of an organization and that supports a business policy.

Front 2

Business rules principles

Back 2

* Stated in appropriate terminology to enable domain SMEs to validate the rules.
* Documented independently of how they will be enforced.
* Stated at the atomic level and in declarative format.
* Separated from processes that the rule supports or constrains.
* Maintained in a manner that enables the organization to monitor and adapt the rules as the business policies change.

Front 3

Operative B.Rule

Back 3

They are intended to guide the actions of people working within the organization. They may oblige people to take certain actions, prevent people from taking actions, or prescribe the conditions under which an action may be taken.

May be violated

Front 4

Structural B.Rule

Back 4

Structural rules are intended to help determine when something is or is not true, or when things fall into a specific category.

also calculation formulas

Front 5

Data flow diagram

Back 5

1. External entity: rectrangel

2. Data store: two paralle lines

3. Data process: circle or round corners rectangel+verb-noune

4. Data flow: arrow+noun for data transf.

Weakness: difficule to show responcible for performing, no alternative path

Front 6

Purpose of data modelling

Back 6

The purpose of a data model is to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with th

ERD

Class diagrams

Front 7

Data modelling notation

Back 7

1. Concept: person, place, thing, proces, etc

2. Attribute: name,value, description

3. Relationship: connections between concepts, with "cardinality" (multiplicity)

4. Metadata: contctraints on attrib., cardinality,

ERD: entity, attribute, relationships

Class diagram: class, attribute, relationship, operations (process for class)

Front 8

Business Domain Model

Back 8

conceptual view of all or part of an enterprise focusing on products, deliverables and events that are important to the mission of the organization. The domain model is useful to validate the solution scope with the business and technical stakeholders.

Front 9

Prototyping (synonym)

Back 9

Storyboarding, (Navigation Flow,Dialogue Hierarchy, Dialogue map) Paper Prototyping, Screen Flows

Front 10

When is the earliest time to begin a requirements package?

Back 10

Not specifically stated, but implied. There is no set sequence for preparing the requirements package, and this aligns with the concept of iteration implied in the knowledge area graphic in the introduction. BABOK 4.4.4.

Front 11

WBS vs Funvtional decomposition

Back 11

Work Breakdown Structure is a tool to primarily help break down project scope, not product scope. Functional decomposition can help break down product scope,

Decomposition of the tasks in a project (using a work breakdown structure) or product (using a solution breakdown structure)

Front 12

SWOT

Back 12

SWOT analysis is a framework for strategic planning'. BABOK 9.32.2.

Front 13

Requirements Model

Back 13

A representation of requirements using text and diagrams. Requirements models can also be called user requirements models or analysis models and can supplement textual requirements specifications.

Front 14

Problem or Vision Statement

Back 14

A problem or vision statement states the business need (WHAT), identifies key stakeholders (WHO), and briefly describes the positive impact that meeting the business need (WHY) will have on those stakeholders.

Front 15

reason for maintaining req for re-use

Back 15

Maintenance of requirements can facilitate impact analysis of new, proposed changes to the business, reduce analysis time and effort, assist in maintenance of previously implemented solutions, and support other activities, including training, corporate governance, and standards compliance.

Front 16

Expected benefits

Back 16

desired outcomes

Front 17

Requirements packages (reason)

Back 17

Requirements packages may be prepared for a number of reasons, including but not limited to early assessment of quality and planning, evaluation of possible alternatives, formal reviews and approvals, inputs to solution design, conformance to contractual and regulatory obligations, and maintenance for re-use.

Front 18

Solution scope includes:

Back 18

* The scope of analysis
* The capabilities supported by solution components, such as business processes, organizational units, and software applications.
* The capabilities to be supported by individual releases or iterations.
* The enabling capabilities that are required in order for the organization to develop the capabilities required to meet the business need.

Front 19

Rules for conducting req. review

Back 19

1. Supervisor of aouthor should not attend review

1. Participants is prefarebly co-located, but this is not required

Front 20

underlying rationale

Back 20

business need

Front 21

Business policy

Back 21

A non-actionable directive that supports a business goal.

N.B. Business policies are non-actionable. Business rules are actionable.

Front 22

Solution-Product-Deliverable

Back 22

Solution and product are synonymous. BABOK Glossary page 229.

Deliverables are milestones, things that are achieved and needed.

Front 23

What techniques would serve you best in confirming your elicitation results?

Back 23

Interviews and observation.

Workshops are used to elicit, not confirm results. BABOK 3.4.5.

Front 24

Functional decomposition

Back 24

purpose:o decompose processes, functional areas, or deliverables into their component parts and allow each part to be analyzed independently.

Adv:Creates a conceptual model of the work that needs to be completed,consistent view of the scope of the effort,Assists estimating

D/A:not sure all elements are captured, desomposin without undetading relations.

Front 25

Organizational modelling

Back 25

P.: escribe the roles, resp. and reporting within an organization and to align those structures with the organization's goals.

El.: Org. Purp and struct. (functions, market, matrix), roles, interfaces, org. chart (units, lies of reporting,(dotted - inform), roles and people

A.:all org have

D/A.: contentious in implement, not technigues

Front 26

Process modelling

Back 26

P: how work that involves multiple roles and departments is performed within an organization.

El. 1.Notation (Activities (may be subprocess) Flow, Desision (take altern flow), event (action, request or time pass outside process that can affect process),Roles, Swimlines, Pools, Terminl points

2. Process improvements(BPI) (Lean, sigma, BPMN)

A. easy to understnad, for training

D/A: can be complex, can't always show problem

Front 27

Activiti diagram notation (UML)

Back 27

1. Activity Steps (roubnd rect)

2. Control flow (arror)

3. Fork and Joins (for parallel or concurrent process) (parallel lines)

4. Decision points (empty diamond)

5. Guard contdition (fro a decision, yes/no, can be many but one is true)(text in square brackets)

Front 28

Flowcahrt notations

Back 28

Termianl points: starts or end (ovals)

Activity: rectangel

Flow: arrow

Swimlines and roles

Decisions: diamonds

Front 29

What can be process model used for

Back 29

1. Discover req.

2.Stakeholder anal

3. documwnt BA approach

Front 30

Scenario vs. Use case

Back 30

Scenario one instanceof UC (primary or alten),are written as a series of steps performed by actors or by the solution that enable an actor to achieve a goal.

use case describes all the possible outcomes of an attempt to accomplish a particular goal,describes several scenarios in the form of primary and alternate flows

Front 31

Use case elements

Back 31

Name:verb +nou

Actor:person, system, event external to the system that interacts with it, also temporal actor "time"(end of the month)

Pre-conditions

Flow of events: primary, altenate (may join wit prim. or have is own end)exeptions

Post-conditions

Relations: Accociations (etween actor and UC), stereotypes (between UCs, extend, include

Front 32

Feature

Back 32

A cohesive bundle of externally visible functionality that should align with business goals and objectives.

Each feature is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.

Front 33

Scope modelling

Back 33

P: used to describe the scope of analysis or the scope of a solution.

Context D: highlevel or evel "0" DFD, single data process (Gane-Sarson or Yurdon notations)

Features, Use cases,Process modelling

Ad.:hat should be in and out of scope for a solution,

D/A:leave much of the detailed scope still needing to be investigated and detailed.

Front 34

User stories

Back 34

P:brief description of functionality that users need from a solution to meet a business objective.

Needede: Actor, Description, Benefit

Should also hav defined Accept and eval crit

A: Customer ownership, value articulated, may avoid func req.

D/A: Not ok if org have high doc tandarts, stakehold are dispersed, not or non-funct. req

Front 35

Acceptance and aevsl. criteria

Back 35

P: define the requirements that must be met in order for a solution to be considered acceptable to key stakeholders. (accept - for oene sol., eval among no.)

Must be testable

Ranking (importnace of req) and Scoring (how well met)

A: for agile, contractual obigations

D/A:if contractul than dif to chnage

Front 36

Glossary and Data dictionary (DD)

Back 36

P:key terms and data relevant to a bus. dom.

glossary term relevant to the domain and a unique definition for each,

DD definitions of each primitive data element and how they combine into composite data elements.

Primitive: Names, aliases (synonym), meaning values,descriprion

Composite: Sequence, repetition, optional elem (all in regards to primitive)

Front 37

Interface analisys

Back 37

P: To identify interfaces between solutions and/or solution components and define requirements that describe how they will interact.

Include: UI, interfaces to and from ext. applic, to and from ext hardware

A:Affect on delivery date, cooperation with other syste or project, prevent difficuty in itegrat

D/A: do not assess internal components

Front 38

Monitoring and evaluation

Back 38

Monitoring is a continuous process of collecting data to determine how well a solution has been implemented compared to expected results. Evaluation is the systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time, and to identify ways to improve the solution to better meet objectives.

Front 39

Interoperability vs. Data migration

Back 39

Interoperability.Ability of systems to communicate by exchanging data or services.

Data migration. This is not an exchange. This moves data from one system to the other.

Front 40

What must happen to enable requirements re-use?

Back 40

To re-use requirements they must be clearly named and defined and easily available to other analysts.' BABOK 4.3.2.

Front 41

metrics and key performance indicators (technique)

Back 41

P:measure the performance of solutions, solution components, and other matters of interest to stakeholders

A metric is a quantifiable level of an indicator that an organization uses to measure progress.

Indicator identifies a specific numerical measurement that represents the degree of progress toward achieving a goal, objective, output, activity or further input.

Front 42

Characteristic of good indicator

Back 42

Clear

Relevant

Ecomomical

Adequate

Quantifiable

(CREAQ)

Front 43

key factors in assessing the quality of indicators and their metrics

Back 43

There are three key factors in assessing the quality of indicators and their metrics---reliability,

validity

and timeliness.

Front 44

Non-functional requirement teqnique

Back 44

P;describe the required qualities of a system,(important both for users and dev)

E:categoriies (PERMCOST)

measurement (should have measures)

documentation (in declarative)

A.effect acceptance by users

D/A: difficult to artiuculate, overly stringent increase cost of solution

Front 45

where are metrics used

Back 45

model and specify req

define business case

manage Ba perfomance

validate solution

Front 46

Prototyping

Back 46

P;detail UI req and integratet the with others reg(use cases, scen etc

Types: functioal scope (horizontal(exploratory
)and verical)

usage( trow-away, evolutionary or functional)

E: prepare (approach), prototype( often iteratively), evaluate

A;attarct for customer, throw-away is cheap, early feedback, horizontal - technoligy fesibility, evolution-for desingers

D/A: how vs, what, wrong expectations, too much design can contrain technology

Front 47

Sequence diagram

Back 47

P: how classes and objects interact during a scenario. do not show relations. Also use to show UI or soft. comp. interaction

Notation:Object/classes above, messages (stimuli) - pointing arrow between life lines (procedural, asynchronous)

A. validate use case vs. class diagram, specify order of events (not exact timing)

D/A: classes must be pre-defined

Front 48

State diagram

Back 48

P:specifies a sequence of states that an object goes through during its lifetime, and defines which events cause a transition between those states.

Synonym:State machine d., state transition d., entity lifesycle d

E.: state (one at a time, initial, intermidiate,end), transition (buiness rule may define), event that trigger tr., activity nthat apply to current state

A: easy to understand

D/A.: since easy to understnad may creep scope

Front 49

End user.

Back 49

Responsible for the day-to-day operation of the solution and a major source of information on problems or defects. BABOK 7.6.6.

not operatonal support is responcible for day-to-day

Front 50

Checklist

Back 50

A checklist is an example of Qaulity control

Front 51

ways to generate business need

Back 51

* rom the top down
* From the bottom up − a problem with the current state of a process, function or system
* From middle management
* From external drivers − driven by customer demand or business competition in the marketplace, legal chnages

Front 52

Goals and objectives

Back 52

Business goals and objectives describe the ends that the organization is seeking to achieve.

G.-something broad that business seeks to achieve (qualitive)

O - specific taget

Front 53

Desired outcome

Back 53

A desired outcome is not a solution. It describes the business benefits that will result from meeting the business need and the end state desired by stakeholders

e.g. reduced expenses, increased revenue

Front 54

Factors that help to define b.problem or opportunity

Back 54

* Adverse impacts the problem is causing within the organization and quantify those impacts
* Expected benefits
* How quickly the problem could potentially be resolved or the opportunity could be taken, and the cost of doing nothing.
* The underlying source of the problem.

Front 55

Some examples of capabilities include:

Back 55

* Business processes
* Features of a software application
* Tasks that an end user may perform
* Events that a solution must be able to respond to
* Products that an organization creates
* Services that an organization delivers
* Goals that a solution will allow stakeholders to accomplish

Front 56

solution approach may inlude

Back 56

* tilize additional capabilities of existing software/hardware that already is available within the organization
* Purchase or lease software/hardware from a supplier
* Design and develop custom software
* Add resources to the business or make organizational changes
* Change the business procedures/processes
* Partner with other organizations, or outsource work to suppliers

Front 57

A feasibility study

Back 57

A feasibility study is a preliminary analysis of solution alternatives or options to determine whether and how each option can provide an expected business benefit to meet the b,n.

f.s is an integral part of formulating a major business transformation project, e.g., re-engineering a core business process and supporting technology, establishing a new line of business, increasing market share through acquisition, or developing a new product or service.

,y be formal or informal

Front 58

requirements workshop vs. structured walkthrough

Back 58

A requirements workshop is the most efficient way to make all parties familiar with the scope

S.W sed to review requirements and other deliverables, not familiarize people with the scope.

Front 59

Risk analysis: usage consideration

Back 59

A: prepare for the likelihood that at least some things will not go as planned.

D/A: 1. number of risks can easily become unmanageably large.

2. risks uncertain, it may prove difficult to usefully estimate the impact of the risks.

Front 60

Critical eleent of root cause analysis

Back 60

To ensure that current business thinking and business processes are challenged.

Front 61

What reqiurements are managed?

Back 61

1.Requirements may be managed at any point in their lifecycle

2.although stakeholder approval is normally restricted to verified and validated req

3.Req. must be communicated to be managed,

4.Requirements may also be managed if they can be traced to requirements that have been approved,

Front 62

Problem tracking technicue

Back 62

Problems include issues, questions, risks, defects, conflicts, or other

Has to lead to: resoltion, allocatio of res., identific of root cause

Elements: Record, Management (regular reviews or escalations), Measurement ( e.g.no. of problems b status, cycle time)

A: organizaed method for tracking and communic

D/A: outdated list, not available stakeholder, may be considered low priority for toight schedule

Front 63

Reason for requirements package

Back 63

- Rearly assessment of quality and planning,

- evaluation of possible alternatives,

- formal reviews and approvals,

- inputs to solution design,

- conformance to contractual and regulatory obligations,

- and maintenance for re-use.

Front 64

forms for requirements packages

Back 64

* Formal Documentation: Formal documentation is usually based on a template used by the organization, such as a Vision Document or SRS
* Presentation: Delivers a high-level overview of the functionality delivered by the solution.
* Models: The requirements may be presented only in the form of a model, such as a process map, or captured on a whiteboard.

Front 65

most common types of requirements documents include:most common types of requirements documents include:

Back 65

* Business Requirements Document (note: many “Business Requirements Document” templates also include stakeholder requirements)
* Product Roadmap
* Software/System Requirements Specification
* Supplementary Requirements Specification
* Vision Document

Front 66

tip for RFP

Back 66

avoid using closed ended questions (those requiring only short answers). The goal is to stimulate the vendors to provide extensive information regarding their product and service offerings.

Front 67

Requirements workshop

Back 67

Preprare: clarify need, define s-hld, agenda,schedule, arrange room, send mterials i advace, pre-session interview to ensure understanding of purpose

Conduct

Wrap-up: clea openb issues, send summaries

D/A: too mane particip, good facilit needed,too many (slow) or too little (overlooking) particip.

CONSENSUS

Front 68

rules of structured walkthrough

Back 68

* Under normal circumstances, supervisors or managers (especially of the author) should exercise caution if they attend the review. i
* Reviewers must review and comment on the content, not on the author
* Participants must review the document before the session.

Front 69

tructured walkthroug elements

Back 69

Pre-requisite: Req package, attendees, vehicles( in one room or remote0

Process: review scope (checklist of items), organize and schedule (scope in advance), conduct (IPOBRAS), compile notes, re-review if necessary

A:promotes discussion, identtify areas of misunder

DA: re-review may be required, long approval

Front 70

Roles of stryctured walkthroough

Back 70

Author (BA)

Moderator (may be BA but not ok)

Scribe (may be BA)

Peers of AUthor

Reviewers

Front 71

Incremental delivery

Back 71

Creating working software in multiple releases so the entire product is delivered in portions over time.

Front 72

Structural vs. Operative rules

Back 72

Structural rules are intended to help determine when something is or is not true, or when things fall into a specific category.'

Operative rules are rules that the organization chooses to enforce as a matter of policy. BABOK 9.4.3.

Front 73

Structure walk through synonyms

Back 73

Req. Review

Inspection (more formal)

Front 74

who can define assumption and constraints

Back 74

Quote: 'assumptions and constraints can originate from and/or affect any stakeholder' BABOK 6.4.6.

not as stated in stakeholder analysis

Front 75

conerns of release planning

Back 75

-project budget,

-the need to implement a solution or parts of the solution by a certain date,

-resource constraints,

- training schedule

- and ability for the business to absorb changes within a defined timeframe.

Front 76

Operatioal and technical assesment

Back 76

Operaional:Determine if training has been performed, whether new policies and procedures have been defined,

Technical:whether IT systems required to support it are in place, and whether the solution is capable of performing at a required level.

Front 77

assessing defects in the solution

Back 77

- severity of the defect,

- the probability of the occurrence of the defect, - the severity of the business impact,

- and the capacity of the business to absorb the impact of the defects.

Front 78

what i the optional task in Babaok

Back 78

Prepare req. package