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;
78 Cards in this Set
- Front
- Back
What is business rule? |
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 principles |
* Stated in appropriate terminology to enable domain SMEs to validate the rules. |
|
Operative B.Rule |
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 |
|
Structural B.Rule |
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 |
|
Data flow diagram |
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 |
|
Purpose of data modelling |
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
|
|
Data modelling notation |
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) |
|
Business Domain Model |
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. |
|
Prototyping (synonym) |
Storyboarding, (Navigation Flow,Dialogue Hierarchy, Dialogue map) Paper Prototyping, Screen Flows |
|
When is the earliest time to begin a requirements package? |
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. |
|
WBS vs Funvtional decomposition |
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) |
|
SWOT |
SWOT analysis is a framework for strategic planning'. BABOK 9.32.2. |
|
Requirements Model
|
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. |
|
Problem or Vision Statement
|
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. |
|
reason for maintaining req for re-use |
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. |
|
Expected benefits |
desired outcomes |
|
Requirements packages (reason) |
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. |
|
Solution scope includes: |
* The scope of analysis |
|
Rules for conducting req. review |
1. Supervisor of aouthor should not attend review
1. Participants is prefarebly co-located, but this is not required |
|
underlying rationale |
business need |
|
Business policy |
A non-actionable directive that supports a business goal.
N.B. Business policies are non-actionable. Business rules are actionable. |
|
Solution-Product-Deliverable |
Solution and product are synonymous. BABOK Glossary page 229.
Deliverables are milestones, things that are achieved and needed. |
|
What techniques would serve you best in confirming your elicitation results? |
Interviews and observation.
Workshops are used to elicit, not confirm results. BABOK 3.4.5. |
|
Functional decomposition |
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. |
|
Organizational modelling |
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 |
|
Process modelling |
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 |
|
Activiti diagram notation (UML) |
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)
|
|
Flowcahrt notations |
Termianl points: starts or end (ovals) Activity: rectangel Flow: arrow Swimlines and roles Decisions: diamonds
|
|
What can be process model used for |
1. Discover req. 2.Stakeholder anal 3. documwnt BA approach |
|
Scenario vs. Use case |
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 |
|
Use case elements |
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 |
|
Feature |
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. |
|
Scope modelling |
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. |
|
User stories |
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
|
|
Acceptance and aevsl. criteria |
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
|
|
Glossary and Data dictionary (DD) |
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) |
|
Interface analisys |
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 |
|
Monitoring and evaluation |
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. |
|
Interoperability vs. Data migration
|
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. |
|
What must happen to enable requirements re-use? |
To re-use requirements they must be clearly named and defined and easily available to other analysts.' BABOK 4.3.2. |
|
metrics and key performance indicators (technique) |
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. |
|
Characteristic of good indicator |
Clear Relevant Ecomomical Adequate Quantifiable (CREAQ) |
|
key factors in assessing the quality of indicators and their metrics |
There are three key factors in assessing the quality of indicators and their metrics---reliability, validity and timeliness. |
|
Non-functional requirement teqnique |
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 |
|
where are metrics used |
model and specify req define business case manage Ba perfomance validate solution |
|
Prototyping |
P;detail UI req and integratet the with others reg(use cases, scen etc Types: functioal scope (horizontal(exploratory 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 |
|
Sequence diagram |
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 |
|
State diagram |
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 |
|
End user. |
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 |
|
Checklist |
A checklist is an example of Qaulity control |
|
ways to generate business need |
* 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 |
|
Goals and objectives |
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 |
|
Desired outcome |
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 |
|
Factors that help to define b.problem or opportunity |
* 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. |
|
Some examples of capabilities include: |
* 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 |
|
solution approach may inlude |
* 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 |
|
A feasibility study |
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 |
|
requirements workshop vs. structured walkthrough |
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. |
|
Risk analysis: usage consideration |
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. |
|
Critical eleent of root cause analysis |
To ensure that current business thinking and business processes are challenged. |
|
What reqiurements are managed? |
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, |
|
Problem tracking technicue |
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 |
|
Reason for requirements package |
- 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. |
|
forms for requirements packages |
* 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. |
|
most common types of requirements documents include:most common types of requirements documents include: |
* Business Requirements Document (note: many “Business Requirements Document” templates also include stakeholder requirements) |
|
tip for RFP |
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. |
|
Requirements workshop |
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 |
|
rules of structured walkthrough |
* Under normal circumstances, supervisors or managers (especially of the author) should exercise caution if they attend the review. i |
|
tructured walkthroug elements |
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 |
|
Roles of stryctured walkthroough |
Author (BA) Moderator (may be BA but not ok) Scribe (may be BA) Peers of AUthor Reviewers |
|
Incremental delivery |
Creating working software in multiple releases so the entire product is delivered in portions over time. |
|
Structural vs. Operative rules |
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. |
|
Structure walk through synonyms |
Req. Review Inspection (more formal) |
|
who can define assumption and constraints |
Quote: 'assumptions and constraints can originate from and/or affect any stakeholder' BABOK 6.4.6.
not as stated in stakeholder analysis |
|
conerns of release planning |
-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. |
|
Operatioal and technical assesment |
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. |
|
assessing defects in the solution |
- 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. |
|
what i the optional task in Babaok |
Prepare req. package |