| Course Topics: |
DAY ONE
1. Business Analysis Body of Knowledge (BABOK) Overview
a. Enterprise Analysis (out of scope for this workshop)
b. Requirements Planning and Management (out of scope for this workshop)
c. Requirements Elicitation (out of scope for this workshop)
d. Requirements Analysis and Documentation (this is the first of three activities from the BABOK as the focus for this workshop)
i) Stakeholder needs are analyzed, structured and specified for use in the design and implementation of a solution. In this workshop, this is addressed briefly in this class as part of documentation and communication.
ii) Define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it. In this workshop, this is addressed as part of solution verification.
iii) Develop the analysis models and determine the gaps in the information provided by the stakeholders. In this workshop, this is addressed only briefly as a method to validate the solution.
iv) Deliverables from this process will be used by the project team to develop estimates for the time, resources, and budget required implementing a solution or solutions that will fulfill the requirements. In this workshop, working with the project manager and team throughout the lifecycle to address the impact of product scope will be addressed.
e. Requirements Communication (this is second of the key activities from the BABOK as the focus for the workshop).
i) Collection of activities and considerations for expressing the output of the requirements analysis and documentation to a broad and diverse audience.
ii) Includes presenting, communicating, verifying, and gaining approval of the requirements from the stakeholders and implementers of the project.
f. Solution Assessment and Validation (this is the third of the key activities from the BABOK as the focus for the workshop).
i) Assist the technology team with detailed design work including splitting a large project into phases,
ii) Review technical design deliverables, and
iii) Help to build usability into the application software.
iv) In the case of a purchased solution, assist with any package customization decisions that need to be made and with interface requirements.
v) As the solution is built and available for testing, support the Quality Assurance activities.
vi) Help business stakeholders with user acceptance testing, defect reporting and resolution.
vii) Making sure production rollout changes are completed which may require supporting the training of business area workers and the communication of change impacts.
viii) Assist the technology team with rollout strategies
ix) Involvement with post implementation support (problem resolution, adjustments to new procedures, and managing change requests including new requirements, next phase issues)
g. Reiterate Workshop Focus – Documentation, Communication, Solution Assessment and Validation.
h. Hands-On Exercise: What is wrong with this Systems Requirement Specification? Objective: To get familiar with the document and the challenges of viewing the document from different perspectives.
2. Challenges in Requirement Communications
a. Terminology and Ambiguity
i) Assumptions Made and Their Impacts
ii) Use of Acronyms
iii) Use of English Language
iv) Hands-On Exercise: Ambiguity. Objective: Go back to the SRS and list terms, acronyms and language that are ambiguous. How would you change it and why?
b. Cross-cultural Understanding
i) Relation to time, communications
ii) Variations to Validation
iii) Inconsistencies in Process
iv) Hands-On Exercise: Cross-Cultural Communication. Objective: Go back to the SRS and list terms, acronyms and language that are cultural specific and may not translate very well. How would you change it?
c. Level of Detail and Usefulness
i) Maintenance Projects
ii) Package Solutions
iii) Outsourced Projects
iv) Volatile Projects
v) Agile Projects
vi) Hands-On Exercise: Level of Detail. Objective: Go back to the SRS. Objective: Is the level of detail appropriate for the type of project?
d. Tool Challenges to Communicating Virtually
i) Virtual Reviews
ii) Use of CASE Tools
iii) Project Lifecycle Repository
iv) Reuse – for Future Use
v) Hands-On Exercise: Conducting the Virtual Review Part I. Objective is to practice preparing for the review by identifying the objective of the review, structuring an agenda for the appropriate tools to use in order to gain clarity virtually.
e. Audience Skill Level (35 min)
i) When Developers have the SME Knowledge
ii) Dealing with New Employees
iii) Educating Your Audience on the Process
iv) Verbalizing Problems with Requirements
v) Various roles on the project from both the WORK and the PROCESS ownership perspectives (introduce RACI chart from a PROCESS OWNERSHIP perspective.
vi) Hands-On Exercise: Conducting the Virtual Review Part II. Objective: Go back to the agenda. Various audience profiles will be provided. Objective: Is the content of the SRS to be presented appropriate for each profile provided?
3. People: Knowing Your Audience for Requirement Communications
a. Understanding the Audience
i) Using the RACI Chart and R&R Definitions for Role Clarity
ii) Sponsor
iii) Project Manager
iv) Subject Matter Expert
v) Designer
vi) Tester
vii) Developer
viii) Architect
ix) Data Administrator
x) Trainer
xi) Implementer
xii) Hands-On Exercise: Build a RACI, R&R and Communication Plan from the BA perspective for a real life project, Ensure approvers are identified.
b. Communication Approaches
i) Negotiating
ii) Medium to Use
iii) Frequency of Communication Needed
iv) Managing Expectations
v) Documentation – Organize by Using the SRS
vi) Consistency in Format
c. Mapping the Right Communication Tools to the Right Audience
i) Create a Requirements Communication Plan
ii) Manage Requirements Conflicts
iii) Hands-On Exercise: Role Play – Provide RACI/R&R, SRS Section and Communication Plan. Find the conflicts and negotiate resolution between two Subject Matter Experts
d. Presenting for Validation and Gaining Approval
i) Inspection – Peer Desk-check, Pass Around, Walkthrough, Workshop
ii) Desk Prototype
iii) Formal Presentations
iv) Hands-On Exercise: Conducting Virtual Review Part IIII. Refine the Agenda using the RACI chart, Communication Plan, Audience Profiles and tools that can be used for reviews. Determine the right method for review, the appropriate tools to use for the review, etc. Role play – Conduct the review and present team observations.
v) Hands-On Exercise: Pick a scenario for a different type of review. Role play to conduct the review and present team observations DAY TWO
4. Documenting Requirements
a. The Project Lifecycle and Future Use of Key Business Analysis Deliverables
i) Project Management and Vendor Management (RFP, SOW, SLA)
ii) Structuring Deliverables for Releases
iii) The System (or Software) Requirement Specification
iv) Business Models and Conceptual Designs
v) Use Cases
b. Documentation and Level of Detail Variances Dependent on
i) Methodologies (Such as Waterfall vs. Iterative)
ii) Audit Requirements and Extent of Traceability
iii) Global Audience
iv) Involvement of Subject Matter Experts
v) Designer and Developer’s Extent of Domain Knowledge
vi) Outsourcing of Work or Package Solution Identification
vii) Prioritization of Project Factors (scope, time, quality, cost)
viii) Future Uses (Vendor Management, Reuse, etc.)
c. Sample Outlines for Documenting
d. Hands-On Exercise: Reorganize - Revisit the SRS from Day 1. Objective: How might you reorganize based on audience profiles? Which sections should be more detailed based on specific scenarios?
e. Hands-On Exercise: Map to the Future - Revisit the SRS from Day 1. Objective: Which parts map to future deliverables (parts provided 5. Process: Touch-Points and Solution Validation
a. Working with the Project Manager Throughout the Project’s Life
i) Rolling Wave Planning and the Triangle of Constraints
ii) Communicating Product Scope Changes
iii) Communicating Risks
iv) Providing Updates to Estimates
v) Validating Priorities
vi) Hands-On Exercise: BA and PM situation role play
b. Transitioning to Designers, Database Administrators and System Architects
i) Solution Ideas: How They Are Considered in Design
ii) Clearly Communicating Constraints that Impact the Design
(1) Existing System Constraints
(2) Enterprise Architecture Constraints
(3) Vendor Product Constraints
(4) Quality Attribute Constraints
iii) The “Gray” Area of Conceptual Design
(1) Using Conceptual Models for the Transition
(2) Reconciling the Data and Processes
iv) Use of Computer Aided Software Engineering (CASE) Tools
v) Hands-On Exercise: BA and Designer situation role play (optional)
c. Working with Developers in the Development Phase
i) Use Case Organization Impact to Developers
ii) Use of Tables and Diagrams to Help in Transition
iii) Code Walkthroughs and Traceability
iv) Working with Developers that are Virtual and Global
(1) Iterative Development
(2) Interim Deliverable Reviews for Work Visibility
(3) Use of Examples and Demos
(4) Importance of Standards and Guidelines
(5) Importance of Glossary, Data Dictionary and Consistent Requirement Formats
v) Hands-On Exercise: BA and Developer situation role play
d. Working with Testers, Trainers and Change Managers
i) Testers Perspective of Requirements Validation
ii) Prioritization of Requirements and the Impact to Testing
iii) Using Use Cases for Test Cases and Training
iv) The Business Analyst and the Acceptance Test
v) Hands-On Exercise: BA and Tester situation role play
vi) Change Management – the Affect on System Acceptance 6. Requirements and Product Selection/Implementation
a. Overview of the Product/Vendor Solicitation Process
b. Variances in Communication and Documentation Methods
c. Variances in Touch-Points and Solution Validation
d. Mapping Requirements to Product Features and Functions
e. Validation of Product Mapping in Conference Room Pilots
f. Using Use Cases for Conference Room Pilots
g. Hands-On Exercise: Planning a Conference Room Pilot 7. Tracing and Managing Change to Requirements
a. Traceability Overview
b. Tracing and Managing Change Virtually and Globally
i) Assessing Requirement Volatility (impact to approach and communications)
ii) Communication, Consistency and Formality of Change Processes
c. Tracing and Managing Change In an Outsourced Environment
d. Hands-On Exercise: Scenarios – Assess and communicate the impact. 8. Technology: Requirements Communications and Solution Assessment Collaboration
a. Tool Feature and Functions that are Most Useful for Requirements Virtual and Global Collaboration
b. Tools for Requirements Collaboration – What is Out There Today
c. Tools for Traceability and Managing Change 9. Solution is Implemented – Now What?
a. Maintaining The Integrity of the Solution
b. Warranty Commitments
c. Ensuring Ongoing Measures are Being Met (Service Level Agreements and Non-Functional Requirements)
d. Analyzing to Improve the Process
e. Hands-On Exercise: Scenarios to Tie it Together
|