1. BA Activities & Techniques:
Solution Validation & Assessment

2. BA Activities & Techniques: Solution Validation & Assessment
Julen C Mohanty
Citicorp Services India Ltd

3. DISCLAIMERS
Any views or opinions showcased in this presentation
are solely those of the author and may not
necessarily represent those of the Citigroup.
This document is meant for use of Business Analyst World or
it’s members. Has to be used within Business Analyst World
or it’s members and not to be forwarded to anyone outside
Business Analyst World or it’s members.

4. INDEX
 Solution Assessment & Validation - Fundamentals
 Importance of Solution Assessment & Validation in CMMI
 Tasks by BA in Solution Assessment & Validation
 Activities Done By BA in Assessment & validation
 BA in Post production deployment
 BABoK Fundamentals
 Actual tasks to be done
 Industry best Practices activities

5. Learning Objectives:
Deciding on a Solution that best fits the business
Validating the Solution to add value to the business
Testing, Implementing & Communicating Solution to the respective stakeholders

6. Knowledge Areas - BABoK
Business Analysis Planning
& Monitoring
Solution
Enterprise Requirements
Assessment &
Elicitation Analysis Management &
Validation
Communication
Requirement
Analysis
Underlying Competencies
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

7. Solution Assessment & Validation - BABoK
Stakeholder Solution Identified Mitigating
Concerns Scope Defects Actions
Assess Proposed Allocate
Solution Requirements
Organization Assessment of
Requirements Assumptions & Readiness proposed
Constraints Assessment Solution
Assess Define
Organization Transitions Requirements
Transitions
Readiness Requirements Requirements [Allocated]
Solution Solution Options
Evaluate
Validate Solution Solution
Solution
Solution Performance Enterprise Solution Performance Validation
Metrics Architecture Performance
Assessment Assessment
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

8. Solution Assessment & Validation
Software "Are we building the product right”.
Assessment The software should conform to its specification.
Software "Are we building the right product”.
Validation The software should do what the user really requires.
Business Analyst is most Knowledgeable Team Member about Business Requirements,
the Environment, can best Assess the impact of the Proposed Solution to the
Environment
BA Can best assess impact of change on workers, since BA Observed/ Analyzed
Current Work Environment.
BA Assists with Implementation Plan when Project Includes
(a) Business Worker Training,
(b) Conversion of Existing Info,
(c) Creation of New Employee Procedure Manuals,
(d) User Acceptance Testing of Software/Hardware Component of Solution.

9. Importance of Solution Assessment & Validation in CMMI
Requirements
Development
Alternative
Solutions Product
Requirements Technical Components Product Product
Development
Customer
Solution Integration
Requirements
Product Components, Work Products
Assessment & Validation Report
Assessment Validation
Customer Needs

10. Tasks by BA in Solution Assessment & Validation
(1) Develop Alternate Solutions;
(2) Evaluate Technology Options;
(3) Facilitate the Selection of Solution;
(4) Ensure Usability of Solution;
(5) Support QA Process;
(6) Support Implementation of Solution;
(7) Communicate Solution Impacts;
(8) Post Implementation Review / Assessment

11. Solution Assessment - BABoK
Assumptions & Requirements
[Prioritized & Solution Options
Constraints Approved]
Assess Proposed Solution
Solution Selection
Assessment of
proposed Solution
Solution Design
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

12. Solution Assessment
1. Ranking the Solution Options - Should use a set of evaluation criteria to rank the
solution options
2. Identifying Additional Solution Capabilities - If the option offers more capabilities
than required, you should decide if they provide value now or in the future
Major work Should be done by business analysts
 Splitting a Large Project into Phases,
 Reviewing Technical Design Deliverables,
 Help Build Usability into Application Software.

13. Solution Assessment
(1) BA Highly Involved in Design Strategy;
(2) Tasks include What is actually done to Develop Alternate Solutions?
(a) Mapping Design Plan;
(b) Help Resolve Automated Processes;
(c) Determine how System Interacts with End Users;
(3) Technical Team Designer Constructs Software & are Key Drivers of Implementation Process;
(4) BA Ensures Requirements are Fulfilled by Technical Design Solution.
BA Responsible for in Developing Alternate Solutions
(1) Communicating Proposed Design Solution to Stakeholders;
(2) Guide Decisions Regarding Tradeoffs that Impact Requirements;
(3) Mediate Discuss/ Negotiate Alternative Solutions AFTER Impact to Requirements is Known
(4) Help Stakeholders and Technicians Scope Design Phases of Project;
BA Works with Tech Team to Evaluate Options Available to Solve Business Problem/ Opportunity.
BA is Able to Assess Each Option for its Applicability to Business Area.

14. Solution Assessment
Business
Recommendations
Requirements
[Aligned with
[Approved, Requirements]
Prioritized]
Assured
Evaluate
Technical Compliance with
Technology Organization
Constraints
Options Standards
High Level
Evaluated Feedback
Understanding
[Problems/ issues/
of Technology
Concerns]
Capabilities
BA Helps Evaluate Options/ Assess Applicability of each option for Business.

15. Solution Assessment
Business
Requirements
[Approved,
Prioritized]
RFP/RFQ
High Level Facilitate the
Understanding
Selection of a
of Technology
Capabilities Solution
Ensure the Usability
Organizations of the Solution
RFP/RFQ
Standards
Solution must be as Usable as possible. BA Assists Technology Team in
Designing Usability into the Solution

16. Solution Assessment
Business
Requirements
[Approved,
Prioritized]
Usability
Requirements
Facilitate the
Assessment of
Solution Solution Usability
Usability
Test Plan
Test Plan
Solution must be as Usable as possible. BA Assists Technology Team in
Designing Usability into the Solution

17. Solution Assessment
• Doesn’t only mean jazzy UI, but must • Does the solution address the
have usability, flexibility and accessibility existing risks of the business
• Internalization must be considered for • Does the solution create any
global applications potential Risk for the
• Creating early code, prototyping, or other company
various techniques, the graphical user • Address/ create risk for other
interface can be utilized for early applications
assessment Rich RISK • Address/ create risk for other
Customer functions within the
Experience applications (if enhanced)
4R
Regulation
ROI
&
Compliance • Maximize ROI by using
• Need to make sure their software data is  Automation
protected.  Environment optimization
• No negotiation on regulatory compliance  Reducing dependencies
& must be compliant • Depending on the business,
• Integration must be done with overall some manual work may be
compliance perspective necessary, should be kept.
• Different entities within the organization Automating as much as possible
will be responsible for regulation and in all phases of the lifecycle
compliance but should have independent would reduce operational errors
assessment and verification services.

18. Solution Assessment
• Doesn’t only mean jazzy UI, but must • Does the solution address the
have usability, flexibility and accessibility existing risks of the business
• Internalization must be considered for • Does the solution create any
global applications potential Risk for the
• Creating early code, prototyping, or other company
various techniques, the graphical user • Address/ create risk for other
interface can be utilized for early applications
assessment Rich RISK • Address/ create risk for other
Customer functions within the
Experience applications (if enhanced)
4R
Regulation
ROI
&
Compliance • Maximize ROI by using
• Need to make sure their software data is  Automation
protected.  Environment optimization
• No negotiation on regulatory compliance  Reducing dependencies
& must be compliant • Depending on the business,
• Integration must be done with overall some manual work may be
compliance perspective necessary, should be kept.
• Different entities within the organization Automating as much as possible
will be responsible for regulation and in all phases of the lifecycle
compliance but should have independent would reduce operational errors
assessment and verification services.

19. Allocate Requirements - BABoK
Requirements
[Prioritized & Solution Designed Solution Scope
Approved]
Allocate Requirements
Requirements
Management &
Communication
Solution Selection
Requirements
[Allocated]
Solution Design
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

20. Allocate Requirements
• The requirements are allocated to product functions and product components
including objects, people, and processes.
• The traceability of requirements to functions, objects, tests, issues, or other entities is
documented.
• The allocated requirements and functions are the basis for the synthesis of the
technical solution.
• As internal components are developed, additional interfaces are defined and
interface requirements established.
Tasks to be done are:
 Allocate requirements to functions
 Allocate requirements to product components
 Allocate design constraints to product components
 Document relationships among allocated requirements
 Allocate customer requirements to functional partitions, objects, people, or
support elements to support the synthesis of solutions
 Allocate functional and performance requirements to functions and sub-functions

21. Allocate Requirements
* Allocation of User Requirements
In this activity, the total User Requirements and Marginal Conditions for the System have
to be allocated to the elements of the technical architecture.
This allocation of requirements is the basis for the requirements analyses and design steps
taking place on the lower levels.
It is necessary to observe that the allocation of requirements and Marginal Conditions to
the elements of the technical architecture must fulfil the following criteria:
 Every requirement must be allocated to at least one element of the technical
architecture, ideally exactly to one architecture element.
 Each requirement is allocated to the lowest element in the refinement levels
which makes it possible to meet the requirement completely. Normally, the total of
the requirements have to be allocated to various refinement levels.
Technical and organizational specifications that have to be considered within the scope of system generation. Marginal conditions
may anticipate or limit design decisions.

22. Allocate Requirements
 Provided that a requirement is of general importance to elements, it
must be considered within the scope of the allocation which individual
architecture elements this requirement really has to fulfil.
 The allocation must be realized in such a manner that it will be possible
to prove the fulfilment of the requirement by checking the corresponding
architecture element.
* Allocation of IT Security Requirements to the IT Security Measures
With the allocation of the IT security requirements to the IT security measures it must be
proven that each IT security requirement is covered by at least one IT security measure &
if the specified IT security objective can be reached with the selected security measures.
Requirements to functions and sub-functions
Ensure that satisfaction of the set of requirements at the lower level will
guarantee satisfaction of the higher level requirement.

23. Allocate Requirements
Determine how many Construction Phases a Project will Undergo
(1) Review User Classes;
(2) Review Functions and Features List;
(3) Map the Requirements to Design -
(a) Functional Requirements;
(b) Quality of Service Requirements;
(4) Propose Design Phases;
(5) Determine Number of Design Phases;
(6) Map Requirements to Design Phases;
(7) Update Requirements Traceability Matrix:
(a) Examples of Traceability Mapping Tools,
(b) Tracing Features to Use Cases;
(8) Recommend Improvements for Non-Automated Processes

24. Assess Organization Readiness
Enterprise Stakeholder
Solution Designed Solution Scope
Architecture Concerns
Assess Organization
Readiness
Organizational Readiness Define Transitions
Assessment Requirements
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

25. Assess Organization Readiness
Experts estimate that 50% of all change efforts fail because leaders do not sufficiently
assess organizational readiness for change.
To assess whether the organization is ready to make effective use of the solution.
The internal ability and willingness to move in a new direction.
 Ability - accessing new skill sets necessary to successfully implement a change.
 Willingness - desire of the organization and its employees to change.
Assessing organizational readiness will identify any major challenges that could
delay or prevent your new program’s successful start-up.
Organizational strengths can be leveraged to assist in program development and
acceptance.

26. Assess Organization Readiness
Key concepts to consider when assessing the organizational readiness are:
1. Cultural Assessment
2. Operational or Technical Assessment
3. Stakeholder Impact Analysis
To identify impacts the business analyst should understand the Solution [Designed]
in order to communicate the effect a new solution will have on an organization
The output of an Organizational Readiness Assessment document describes
whether stakeholders & the organization are prepared to accept the change
associated with a solution and are able to use it effectively

27. Assess Organization Readiness Identify the Anticipated or Desired Change
- Clearly reiterate the desired change
- Develop a short paragraph that specifically describes the action or program that the
organization is considering.
This may seem rather basic, it will assure that the stakeholders see the same vision.
Determine Current State of the Organization in Relation to the Desired Change
Significant Minimal
Major Substantial Full
Changes Changes
Barrier Barrier Support
Needed Needed
Alignment With Organizational Vision & Mission
Alignment With Strategic plan
Alignment with organizational value & culture
Resource Availability
Decision Maker Interest
Support for the Initiative
Stakeholder Program Perception
Stakeholder Program Education
Internal Factors (Skills, Strength, Weakness)
External Factor (Opportunity, Challenges)

28. Assess Organization Readiness - Force Field Analysis
Current Desired
State State
Pushing/ Driving Forces Pulling/ Restraining Forces
Driving Force 1 Restraining Force 1
Driving Force 2 Restraining Force 2
Driving Force 3 Restraining Force 3

29. Assess Organization Readiness - Force Field Analysis
Managers Unhappy with
1 Eliminates Operational Error
clerical work
1
Relative Forces Strength
Implementing
Relative Forces Strength
Faster Execution of Admin Requires Training of More
1 Works a HR system people
2
Enables employees
Online Documentation to self manage Some activity costs shift to
3 Eliminates Paper work their personal high paid staff
1
information such
as Payroll
Deductions,
Reduces Need of Clerical Cost of eliminating clerical
2 Staff
Benefit
staff
3
participation
Increases Control / auditing
3 Capabilities
Start-up costs 1
TOTAL = 10 TOTAL = 8
force field analysis helps you:
Decide if you have the right support for the change initiative
Identify what obstacles are standing in your way
Find ways to reduce or marginalize those obstacles

30. Define Transitions Requirements
Organizational
Requirements Solution Solution
Readiness
[ Stated ] Deployed Designed
Assessment
Define Transitions
Requirements
Prioritize
Requirements
Verify
Transitions Requirements
Requirements
Requirements
Management &
Communication
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

31. Define Transitions Requirements
To define requirements for capabilities needed to transition from the existing to
the new solution.
Transition Requirements define characteristics that a solution must have in
order to transition from the current state to the desired future state
- A solution is implemented within an enterprise in order to enhance
- Replace an existing solution.
During the transition period (the time when both the old and new solutions are operational)
- The enterprise may need to operate both solutions in parallel,
- Move information between the new and old solution,
- Conduct training to enable stakeholders to effectively operate the new solution
- Retain All data in old system in new system

32. Define Transitions Requirements
Activities done by in this phase are:
Identify project activities to be completed before transition can start
Conduct skill gap analysis against all IS staff
Determine actual training needed, based on gap analysis
Develop training plans
• Identify necessary training courses
• Schedule classes
• Identify necessary knowledge to transfer activities
•
Determine measurable tasks to validate that knowledge transfer is
acceptable
Stakeholder Analysis for all Transition Requirements
Reference : http://www.batimes.com/images/stories/nov15ewan1.jpg

33. Solution Validation - BABOK
Requirements Solution
[Prioritized &
Validated]
Constructed
Validate Solution
Solution Validation
Identified Defects Mitigating Actions
Assessment
Evaluate Solution Solution
Performance Implementation
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

34. Solution Validation
Validate that a solution meets the business need and determine the most
appropriate response to identified defects
Solution validation is required to ensure that a delivered solution meets the
business needs on an ongoing basis.
Problems that are identified through solution validation will be reported and
prioritized for resolution. BA will be able to help the team determine the
most appropriate action
The documented act of proving that any procedure, process, equipment,
material, activity or system actually leads to the expected results.
Action of proving, that any procedure, process, equipment, material, activity,
or system actually leads to the expected results.

35. Solution Validation - Accuracy VS Precision
What you would like to see!
Poor accuracy Poor precision
Good precision Good accuracy
confirmation by examination and provision of objective evidence that software
specifications conform to user needs and intended uses, and that the particular
requirements implemented through software can be consistently fulfilled.

36. Solution Validation - Purpose of Validation
Fewer
Rejects
Customer Reduced
Satisfaction Cost
Effective handling Reduction of Maximize
of Requirements Quality Costs Yield
Fewer Retest Fewer
Rework
Fewer Wastage
& Scrap

37. Solution Validation
General Task to be considered are
 Audits, Reviews, and Inspection
 Analytic Techniques
 Dynamic Techniques
Techniques to verify the software during its development process
 Peer Reviews
 Documentation inspections (User sign off on specification)
 Traceability of Requirements
 Requirements/design/code reading (Prototypes too)
 Test witnessing (Unit Test, SIT, UAT, Test Cases Too)
 Installation audits
Sufficient replication of the testing and challenging of each defined critical Stage of a
system, process, etc. that has to be performed to give valid levels of assurance
An adequate System of referenced documentation is essential.
Flow diagrams and schematics should define the system, process, etc. The critical
areas must be highlighted, and the written experimental design defined by a protocol.

38. Solution Validation - QA process V-MODEL
Quality Product Delivery Finished
New Idea Conform to all Requirements
Product for
business Use
Test Against
Feasibility Study Review
Test Against
User Requirements User Acceptance
Test Against
System Design System Test
Test Against
Development Program (UNIT) Test
Coding

39. Solution Validation
BA task Quality Assurance Activities
(1) Understand Tasks Performed by QA;
(2) Be Available to Answer Questions about the Testing of the Solution;
(3) Review QA Deliverables (test plans, test cases) to Assure Business risks are mitigated
by Thorough Testing;
(4) Help Business Stakeholders with User Acceptance Testing, Defect Reporting, and
Resolution.

40. Solution Validation  Business SME to do Testing
 SIT & UAT
People &  Maintains standard process & related docs
 Can foresee business timelines, helps in Process  Have E2E knowledge of solution for testing
getting preparedness
 Can help in better time to market with
domain knowledge
 Can optimize staffing by maintaining
knowledge management
Strategic
Tools &
Business BA Automations
Activities
 Helps in automating Test cycles
 Can maintain Testing data management
 Maintains Standard for testing across project
 BA can maintain reporting standards for Governance
testing cycles
 Maintain Governance across Business &
testers

41. Evaluate Solution Performance
Business Identified Business Identified
Requirements Defects Requirements Defects
Evaluate Solution
Performance
Solution performance Assess Capability
Assessment Gaps
Start- Initi- Concept Func Tech
Design Build / Test Deploy
up ation Design Design

42. Evaluate Solution Performance
To evaluate functioning solutions to
1) understand the value they deliver
2) identify opportunities for improvement.
Solution evaluation involves investigating how a solution is actually used after
it is deployed, and assessing the effect it has had
It may also be referred to as post-implementation assessment when performed
immediately following the completion of a project.
Key concepts to consider when evaluating a solution performance can include:
– Understand Value Delivered by Solution
– Validate Solution Metrics
– Solution Replacement or Elimination
• Ongoing Cost versus Initial Investment
• Opportunity Cost
• Necessity
• Sunk Cost

43. Evaluate Solution Performance - Risk Based Testing
The Risk Based Testing (RBT) approach addresses the size & complexity parameters of
a regression testing in a methodical manner by:
This technique prioritizes the functions to be tested based on their risk
Risk = Impact * Probability
 Prioritize test cases by clearly defining importance
of a functionality or feature
 Impact assessment to identify likelihood of failure.
Thus addressing the testability of a requirement
 Improving testing effectiveness by ensuring testing
of all critical functionalities, which are used most
often
 Increasing test case effectiveness by eliminating
non-productive test cases
 Identifying test data need during the planning or
requirement gathering phase itself.
Pareto Principle (80-20 Rule)

44. Evaluate Solution Performance - 360o Testing Assessment
Requirement
Prioritization
Post Live Analysis
Test Plan
Coverage
Defect Metrics
Analysis
Test Execution
Coverage

45. ASSESSMENT & VALIDATION CYCLE
START
Is Goal Stakeholder Analysis
Attained
END PROCESS
Validation
Validation
Set Requirements =
Attainable METRIC + Target Value
Complete?
Functional
Delivered Solution Assessment
Deployment
Delivered Goals =
Intended
METRIC + Delivered Value ASSESSMENT Function
Model
Model Concept
Design
Consistent ?` Solution Solvable?

46. BA should be Involved with Solution Rollout
(1) Make Sure Production Rollout Changes are Completed as Smoothly as Possible;
(2) Help Training of Business Area Workers on
(a) New procedures and Software,
(b) Creation of Employee Procedure Manuals,
(c) Communication of Change Impacts to Employees/ Customers;
(d) Development of Conversion Plans;
(e) Assist IT Team in Rollout Strategies to Lessen Negative Impact to Business Area.

47. BA should be Involved Production Implementation
(1) Problem Resolution;
(2) Adjustments to New Procedures;
(3) Managing Change Requests Including
(a) New Requirements,
(b) Next Phase Issues,
(c) Any Other Post Implementation Support Analysis.

48. Thank You
julenmohanty@gmail.com
www.twitter.com/julenmohanty
www.linkedin.com/julenmohanty
julenmohanty