Knowledge Area Task Elements Input
1. BA analyze the potential value of both requirements & designs.
Model Requirements - Matrices or Diagrams
Inputs:
Elicitation Results (Any State)
Guidelines:
Specify & Model Analyze Requirements - Modelling
Requirements Notations/Standards
- Modelling Tools
- Requirements Architecture
- Req Life Cycle Management
Represent Requirements & Attributes - Solution Scope
Implement the Appropriate level of
Abstraction
Characteristics of Requirement & Designs
Quality
Inputs:
Requirements (Specified &
Modeled)
Verify Requirements
Verification Activities Guidelines:
- Requirement Lifecycle
Management Tool
Checklists (quality control)
Input:
Requirements (Specified &
Identify Assumptions
Modeled)
Validate
Guidelines:
Requirements
- Business Objectives
Define Measurable Evaluation Criteria
- Future State Description
- Potential Value
- Solution Scope
Evaluate Alignment with Solution Scope
Requirement
Analysis & Design
Requirement Viewpoints and Views
Definition
Input:
a. Requirements (Any State)
Template Architecture b. Information Management
Approach
Output Key Point
2. Purpose is to analyze, synthesize, and refine elicitation results into requirements and designs. Practices for analyzing elicitation results and
creating representations of those results. Also, the specifying metadata about the requirements.
3. Needs are specified & modelled as Requirements; Solutions are specified and modelled as Designs.
4. Model is descriptive and visual way to convey information to a specific audience to support analysis, communication,
a. Models may also be used to confirm knowledge, identify information gaps & identify duplicate information.
5. Types : a. Matrices - have a complex but uniform structure, which can be broken down into elements that apply to every entry in the
table. E.g. - data dictionaries, requirements, traceability, or for gap analysis.
b. Diagrams: especially useful to depict complexity that would be difficult to do with words. E.g. - business domains, to categorize and create
Requirements hierarchies of items, and to show components of objects such as data and their relationships.
(Specified & 6. Modelling Categories - People and Roles (Org Modelling, Roles & Perm. Matrix, Personas), Rationale ('Why' - Decision/Scope Modelling,
Modeled) Business Model Canvas, RCA, Business Rule Analysis); Activity Flow (Process Modelling, Use cases, User Stories); Capability (Business
- in form of text, Capability, Functional Decomposition, Prototyping), Data & infor (DFD, Interface analysis). Any combination of models can be used best
diagram or suited to meet stakeholder needs in a context.
matrices 7. Analyze Requirement: conduct to check if - anything must change; anything that should stay; missing components; unnecessary
components; any constraints & assumptions. Level of detail according to SH's knowledge.
8. Requirement Attributes: Identify req & their attributes as part of the elicitation results to show enough details. These attributes are
decided during Information Mgmt Task. E.g. - Absolute Reference, Author, Complexity, Ownership, Priority, Risk, Source, Stability, Status,
Urgency. Can also be classified under Req Schema (Business Req, Stakeholder Req. SOlution Req. - Functional/Non-functional, Transition
Req.)
9. Abstraction based on the type of requirement & audience for the requirement. models. May also produce
different viewpoints of requirements to represent the same need for different stakeholders.
- Business Analysis Approach (Predictive or Adaptive) can also dictate level of abstraction & model used (prototypes)
1. Purpose is requirements & designs specifications & models meet quality standards & usable for the purpose served.
2. Ensures that the requirements and designs have been defined correctly. constitutes a check by the BA and key stakeholders to
determine that the requirements and designs are ready for validation, & if further corrections required.
3. high-quality specification is - a. well written b. easily understood by its intended audience c. A high-quality model follows the formal or
Requirements informal notation standards and effectively represents reality
4. Most important is fitness for use. Quality is ultimately determined by stakeholders
Verified
5. Acceptable quality requirements characteristics - Atomic (self contained & understood independently of others); Complete (detailed
(- requirements or
enough for work to proceed); Concise (no unnecessary content); Consistent (aligned with Stakeholder's need & non conflicting with other
requirements); Feasible (reasonable & possible within agreed risk, cost, budget & schedule or can be investigated through prototypes or
designs that is of
experiments); Unambiguous (Clearly Stated); Testable (able to be verified using a test), Priortized (ranked/grouped based on importance);
sufficient
Understandable (represented using common terminology)
quality to be used
6. Verification Activities: a. compliance with organizational performance standards (tools & methods); b. use of correct modelling notation,
as a basis for
templates, or forms; c. completeness within each model, d. comparing each model against other relevant models,(consistency) e.
further work.)
terminology used is understandable to stakeholders. f. Adding examples for clarification.
7. Checklists are used for quality control when verifying requirements and designs. Aim is to ensure that items determined to be important
are included in final requirements deliverables, or steps req for verification process are followed.
1. Purpose is requirements & designs align to the business requirements and support the delivery of needed value.
2. Ongoing process to ensure that SH, solution & transition requirements align to the business requirements & design satisfy requirements.
Requirements Stakeholders have different, conflicting needs & expectations that may be exposed through validation.
Validated 3. Validation activities may begin before requirements are completely verified. However, validation activities cannot be completed
before requirements are completely verified
4. Stakeholders may have assumed that certain benefits will result from implementation of a requirement. Such assumptions should be
(- validated
identified and defined so that risk can be managed.
requirements and
5. Business analysts define the evaluation criteria that will be used to evaluate how successful the change has been after the solution is
designs which
implemented.
deliver value to SH
& align with
6. A requirement that does not deliver benefit to a stakeholder is a strong candidate for elimination.
7. If requirements do not align, either the future state must be re-evaluated and the solution scope changed, or the requirement removed
business
from the solution scope.
objectives)
8. A design cannot be validated to support a requirement, there might be a missing or misunderstood requirement, or the design must
change
1. Purpose is to ensure that the requirements collectively support one another to fully achieve the objectives.
2. Architecture fits individual models & specifications together to ensure all requirements form a single whole & supports the overall
business objectives and produces a useful outcome for stakeholders.
3. Architecture uses: a. Appropriate Model to be used; b. Organize requirements into relevant structure; c. illustrates how model interact &
relate to each other; d. make trade-off decisions considering objectives; e. ensure req work together to meet objectives.
4. Req. Architecture is not intended to demonstrate traceability,rather to show how elements work in harmony with one another to
support the business requirements. Traceability proves that every requirement links back to an objective and shows
how an objective was met. Traceability does not prove the solution is a cohesive whole that will work.
5. Viewpoints & views: A viewpoint is a set of conventions that define how requirements will be represented, how these representations will
be organized, and how they will be related. 1 View is not sufficient to depict entire model.
a. Viewpoints includes standards that covers: Model type for requirement; attributes that are included; model notation used; analytical
models used to identify & maintain relationship among models.
 models used to identify & maintain relationship among models.
Approach
b. E.g. of viewpoint - Business process model, data model, user interactions (use cases), Audit & security, Business Models
c. Solution Scope 6. View: requirements and designs for a particular solution from a chosen viewpoint are referred to as a view.A collection of views makes
Define Requirements Requirements
Architecture Architecture up the requirements architecture for a specific solution.
Guideline & tools: 7. the viewpoints tell business analysts what information they should provide for each stakeholder group to address their concerns, while
Completeness - Architecture Mgmt Software views describe the actual requirements and designs that are produced.
- Legal Regulatory 8. An architectural framework is a collection of viewpoints that is standard across an industry, sector, or organization whcih can be treated
- Methodologies and as a template.
9. Architecture (with viewpoint) ensures completeness - No requirements should be missing from the set, inconsistent with others, or
Relate and Verify Requirements Relationships Framework contradictory to one another. The requirements architecture should take into account any dependencies between requirements.
- Defined, Necessary, Correct, Unambiguous, 10. Requirements are related to one another in several way that should be assessed defining architecture.
Consistent a. Requirement relationship quality criteria - Defined (relation exist and is defined), Necessary(relationship is necessary to understand),
Correct (relationship described), Unambigous (relationship are not in conflicting ways), Consistent (relationships are consistent with
viewpoints description)
11. The information architecture is a component of the requirements architecture because it describes how all of the business analysis
information for a change relates.(Described in Plan BA Information Management).
Business Analysis Information Architecture It defines relationships for types of information such as requirements, designs, types of models, and elicitation results.
1. Purpose of Define Design Options is to: a. define the solution approach, b. identify opportunities to improve the business,
c. allocate requirements across solution components, d. represent design options that achieve the desired future state
Define Solution Approaches - Create, Purchase Inputs:
2. Design options exist at a lower level than the change strategy, and are tactical rather than strategic.
or Both a. Requirements (Validated, 3. . As initiatives progress and requirements evolve, design options evolve as well & aid in making trade-offs if required.
Priortized) 4. only validated & priortized requirements are considered in design options.
Identify Improvement Opportunities
- Increase: efficiencies, access to information,
b. Change Strategy 5. Solution Approaches are: Create (create a new solution or modify existing one), Purchase (Req & Designs details about which third party
additional capabilities c. Requirements Architecture solution to purchase) or Both . And an integration Approach
Define Solution
Design Options 6. Improvement opportunities- Increase: a. efficiencies (automation, outsourcing, re-engineering), b. access to information (easy acess to
Option users), c. additional capabilities (capabilities of not immediate value but for future).
Guideline:
Requirement Allocation 7. Requirements Allocation: is the process of assigning requirements to solution components & releases to best achieve objective.
- Existing solution
- maximize value & minimize cost The objective of allocation is to maximize value & minimize cost based on availability of the solution to users.
- Future State Description a. Requirements may be allocated between organizational units, job functions, solution components, or releases of a solution.
- Requirement(traced) 8. A design option usually consists of many design components, each described by a design element.
- Solution Scope 9. They may describe: business policies/rules, business processes, people who operate solution, operational business decisions, software
Describe Design Option applications, organizational structures (incl. interactions between the organization, its customers, and its suppliers.)
1. Purpose is to estimate the potential value for each design option and to establish which one is most appropriate to meet req.
2. Potential value is analyzed many times over the course of a change. This may be a planned event, or it may be triggered by a modification
to the context or scope of the change.
3. Afer analysis, there may be no best option to recommend, or there may be a clear best choice or the best option may be to begin work
against more than one design option (perhaps using POCs or prototypes) or proposed designs may be rejected and more analysis may be
Inputs: needed or may be the best recommendation is to do nothing.
Expected Benefits 4. Expected Benefits: Positive value solution is intended to deliver. The total expected benefit is the net benefit of all the
a. Potential Value
b. Design Option requirements a particular design option addresses. Benefits are often realized over a period of time.
5. Expected Costs: is the negative value associated with the solution. Includes - timeline, effort, license cost, operating cost, maintenance
Analyze Potential Solution cost, physical resources, information resource & human resources.
Guidelins:
Value & Recommend Recommendati Opportunity costs are alternative results that might have been achieved if the resources, time, funds devoted to one design option had been
- Business Objectives allocated to another design option.O.C of any design option is equal to the value of the best alternative not selected.
Solution on
Expected Costs - Current State Description 6. Value: Potential Value = Benefits delivered - Associated Costs. Can be positive or negative. P.V from the points of view of SH.
- Future State Description 7. Can increase for some SH group & can increase for some SH group. But overall increase justifies it at enterprise level.
- Risk Analysis Results 8. Potential value is uncertain value. There are always events or conditions that could increase or decrease the actual value if they occur.
The estimate of costs and benefits must take into account the degree of uncertainty.
- Solution Scope
9. Each design option assessment, may become necessary to re-evaluate initial allocation of design elements between components
Determine Value 10. As cost vs benefit is understood, BAs comeup with appropriate tradeoffs. Factors taken into consideration :a. Available Resources; b.
Constraints on the solutions; c. Dependencies between Requirement. Other considerations - relationships with vendors, dependencies on
other intiatives, corporate culture & cash flow. There may be a recommendation after all the assessmentto do nothing.
Assess Design Option & Recommend Solution