Regulator-organisational rules

Sponsor-approval

Plan-output (specific backlog)

Approach

Top-down:

based on former experience

Bottom-up:

Elaboration, more accuracy

More information needed

Parametric:

Use case

ROM:

Rough, +-50% accuracy

Rolling Wave:

Delphi:

Mutiple elicitation from Domain SMEs and rounds to reach concensus, not really via a vis-a-vis meeting

Combine expert judgement

PERT( Program Evaluation and Review Technique):

3 points estimation (O+P+ML)/3

(O+P+4*ML)/6

SOI

Analogous situation

Archive

Usage consideration:

rationale

Lessons learned

Retro fixed term

Event-driven

variances can be positive or negative > Root cause analysis

Usage consideration:

Trying to assign blame X

Assessment-successive improvement

Deliverable / Work product

Domain knowledge

Allocated time

Approach reviewed and agreed upon by key stkhldrs

Predictive:

step by step

formal change application

defined ahead of implementation

risk low

Formal documentation

Adaptive:

risk high

iterations

User stories

Informal

I. Predictive approaches

Pro:

mitigate uncertainty

Con:

Time-consuming

Rendering of value, not necessarily

II. Adaptive approaches

Pro:

iterative deliverance

The waterfall model: typically predictive

The spiral model: iterative develop

The unified process

Elaboration-bringing more details

Scrum-Agile

Artifact

Sprint (Duration: 1-4 weeks)

Backlog

Product increment

Sprint review & retrospective

The Agile Manifesto

Documentation

Responding to change

Verifiy-quality check

Validate-assurance of value, affirmation of sme, scope

Input requirements / designs

Tester-QC

Stakeholder identification

笔记123 

Requirement Life cycle Management (Pg 42)

           All about requirements/design

• 5.1 input Trace Requirement

Output  Traced Requirement, Link to 7.5 Define Design Output.

• 5.2 Input Maintain Requirement 

Output  Maintained Requirements/ Design

• 5.3 Prioritize Requirements

Output Prioritised Requirements/ Design, Link to 6.3 Assess Risks

• 5.4 Assess Requirements Change, Might also involve proposed change

Output Assessment of Requirements and Design Change

• 5.5 Approve Requirement

​​​​​​​Output Approved Requirements/ Designs  

guidelines don't need remenber,

stakeholders do not need remenber, and techniques either.

key terms

information 3.0 now,but in the older 2.0 it was been definded needs

career

  记忆-输入输出

使用观察法时，会存在霍桑效应（Hawthorne effect）。即是指在研究或观察中，被观察者因为知道自己正被关注而产生的行为改变。

几个图在学完全书之后再回来看

Tasks: is a discrete piece of work that may be performed formally or informally as
part of business analysis.

Each task in the BABOK Guide is presented in the following format: Purpose, Description
Inputs, Elements, Guidelines/Tools, Techniques, Stakeholders, Outputs.

Requirements Classification Schema:

• Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.
• Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.
• Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:
     • functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage, and For more
information, see Non-Functional Requirements Analysis (p. 302).

     • non-functional requirements or quality of service requirements: do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.

• Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.

Requirements and design:

Needs (Problem Owener)

Requirements (Business Analyst)

Design (Implementation SMEs)

Solutions ()

The six core concepts in the BACCM are: Change, Need, Solution, Stakeholder,
Value, and Context.

Needs: A problem or opportunity to be addreeeed.

Change: The act of transformation in response to a need.

Contexts: The circumstances that influence, are inflienced by , and provide understanding of the change.

Solutions: A specific way of statisfying one or more needs in a context.

Stakeholdes: A group or individual with a relationship to the change, the need, or the solution.

Value: The worth, importance. or usefulness of something to a stakeholder within a context.

BA define what, not the one defining how.

What are the kinds of changes we are doing?
What are the needs we are trying to satisfy?
What are the solutions we are creating or changing?

 Who are the stakeholders involved?
What do stakeholders consider to be of value?
What are the contexts that we and the solution are in?

Key terms:

Business Analysis information: the broad and diverse sets of information that business analysts analyze, transform, and report. It is information of any kind—at any level of detail—that is used as an input to, or is an output of,business analysis work.

Design: A design is a usable representation of a solution.

Requirements: A requirement is a usable representation of a need.

Enterprise: An enterprise is a system of one or more organizations and the solutions they useto pursue a shared set of common goals.

Organsization: An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives.

Plan: A plan is a proposal for doing or achieving something.

Risk: Risk is the effect of uncertainty on the value of a change, a solution, or the enterprise.