Wouldn’t it be very nice to keep in mind that stakeholders’ time is crucial? And is there a technique that can support us in minimizing the stakeholder time commitments? check out more information at business analyst and cbap training
Yes, it is hard to get enough time as much as we would like to have. Secondly, verifying what the stakeholders are saying is the correct thing to do. Sometimes they may be making mistakes themselves.
Here is another business analysis techniques blog called document analysis with worked-out examples from the Adaptive US.
In fact, as an individual preference, one should always put document analysis as the first technique in their elicitation journey because this technique has a significant advantage in not requiring step orders time, which is always premiere.
Let us read further to have a better understanding of the technique.
Document analysis technique elicits business analysis information by examining materials describing business environment or organizational assets. Document analysis helps in understanding context of a business need or understanding how existing solutions are implemented based on business analysis information being explored, purpose, scope and topics to be researched are determined. Data mining analyzes data to group it into categories, determine patterns and opportunities for change.
Background research comprises of reviewing materials like marketing studies, industry standards, guidelines etc. Document analysis about an existing solution may comprise of reviewing business rules, technical documentation, previous requirements, problem reports etc. to determine how existing solution works and reason for implementing it way it is.
Steps for conducting document analysis
1. Prepare
- Consider content relevance, credibility, and ease with which content can be conveyed and understood.
2. Perform document review and analysis
- Conduct detailed review of each document’s content and record relevant notes.
- Identify conflicting or duplicate notes.
- Note gaps in knowledge.
3. Record findings
- Check whether content and level of detail is appropriate.
- Create visual aids to improve understanding.
Strengths
- Analysis without creating new content.
- Useful when Subject Matter Experts are not available.
- Determine what is current and what has changed.
- Results can be validated against results of other elicitation techniques. (A common theme)
- Findings can be presented in visual formats.
Limitations
- Limited to “AS-IS” perspective.
- May not be up-to-date or valid.
- Authors may not be available for clarification.
- Time-consuming.
Worked out Example:
| # | CMMI Process Area | Requirement |
| 1 | Requirements Management | Clear definition of acceptance criteria |
| 2 | Requirements Management | Adequacy of planning based on the specified requirements |
| 3 | Requirements Management | Capture of information related to requirements’ change |
| 4 | Requirements Management | Maintenance of bi-directional traceability matrix |
| 5 | Requirements Management | Consistency of requirements, plans, activities and work products |
| 6 | Requirements Management | Approval of change requests after due impact analysis |
| 7 | Requirements Management | Adequacy of measurement and analysis activities with respect to Requirements Management |
| 8 | Project Planning | Availability of granular WBS |
| 9 | Project Planning | Estimation of size / task complexities |
| 10 | Project Planning | Identification of project life cycle phases |
| 11 | Project Planning | Estimation of effort -Usage of historical data -Documentation of estimation rationale |
| 12 | Project Planning | Availability of granular schedule – Identification of milestones – Dependencies – Documentation of assumptions |
| 13 | Project Planning | Identification, analysis (Impact, Probability of occurrence & Timeframe) and prioritization of risks |
| 14 | Project Planning | Availability of Resource Plan – Definition of Project-specific processes – Determination of Staffing Requirements – Identification of lead-time for resources – Determination of H/W and S/W requirements |
| 15 | Project Planning | Knowledge and Skill Management – Identification of Knowledge and Skills required – Skills Database – Training Plans |
| 16 | Project Planning | Identification of stakeholders’ involvement (commitments) throughout the lifecycle |
| 17 | Project Planning | Review of Software Project Plan by Process Facilitator and approval by Program Manager |
| 18 | Project Planning | Review of internal and external commitments |
| 19 | Project Monitoring and Control | Monitoring of Planning Parameters – Schedule – Effort – Size / Task complexities – Resources – Knowledge & Skill needs (Skills, Hire plans) |
| 20 | Project Monitoring and Control | Monitoring of commitments including those that are at the significant risk of not being satisfied. Monitoring of status of action items from meetings |
| 21 | Project Monitoring and Control | Evidence of Risk monitoring |
| 22 | Project Monitoring and Control | Collection and analysis of metrics as per the metrics plan |
| 23 | Project Monitoring and Control | Monitoring of stakeholders’ involvement |
| 24 | Project Monitoring and Control | Conduct of Dashboard review meetings as per the process |
| 26 | Project Monitoring and Control | Management of Corrective actions – Status of planned corrective actions – Effectiveness of corrective actions |
| 27 | Measurement and Analysis | Completeness of Metrics Plan – Metrics in line with the Business Unit Quality Objectives – Data collection procedures – Data analysis procedures |
| 28 | Measurement and Analysis | Data collection – Integrity – Timely collection |
| 29 | Measurement and Analysis | Metrics analysis as per the plan |
| 30 | Measurement and Analysis | Distribution of Dashboards – Timeliness – Understanding of analysis and interpretation results |
| 31 | Configuration Management | Availability of approved configuration management plan |
| Configuration Management | Definition of folder organization as per the approved configuration management plan | |
| 32 | Configuration Management | Identification of Configuration Items – Completeness |
| Configuration Management | Identification of Non-Configuration Items – Completeness |
|
| 33 | Configuration Management | Adherence to naming conventions |
| 34 | Configuration Management | Proper setting of access rights |
| 35 | Configuration Management | Adherence of Configuration Management activities to the defined confidentiality, integrity and availability ratings besides the Information Classification. |
| 36 | Configuration Management | Addressing of Special Considerations with respect to Configuration Management |
| 37 | Configuration Management | Backups as per the approved CM Plan – Updating of Backup Register |
| 38 | Configuration Management | Taking of Baselines as per the approved CM Plan -Approval -Completeness of baselines -Correctness of baselines -Integrity of baselines -Communication on status of baselines (Baseline Record) |
| 39 | Configuration Management | Migration of Configuration Items as per the approved CM Plan – Reviews – Recording of change history |
| 40 | Configuration Management | Availability of report on status of Configuration Items |
| 41 | Configuration Management | Adherence to the defined release management strategy |
| – Availability of approved Project Delivery Notes | ||
| 42. | Configuration Management | Conduct of Configuration / Baseline audits as per the approved CM Plan |
| 43. | Configuration Management | Implementation of Record Control Plan |
| 43 | Requirements Development | Elicitation of stakeholder needs, expectations, constraints and interfaces for all life cycle phases |
| 44. | Requirements Development | Translation of stakeholder requirements into customer requirements – Completeness of requirements – Non-conflicting nature – Constraints for verification and validation (as evidenced by records) |
| 45 | Requirements Development | Translation of requirements into product and product-component requirements |
| 46 | Requirements Development | Identification of interface (external and internal) requirements |
| 47 | Requirements Development | Analysis and validation of requirements – Operational concepts and scenarios – Documentation of defined functionality – Analysis of requirements (Technical feasibility, Risks) – Validation records |
| 48 | Technical Solution | Selection of product / product-component / service / process solution – Alternative solution screening criteria – Evaluation of new technologies – Generation of alternative solutions – Criteria for selection of the best solution – Evolution of operational concepts and scenarios – Selection |
| 49 | Technical Solution | – Availability of High-level Design |
| – Availability of Detailed Design | ||
| – Consideration of reuse | ||
| 50 | Technical Solution | Adherence of the implemented design to applicable standards and criteria |
| 51 | Technical Solution | Review and unit testing (if applicable) of the implemented design |
| 52 | Technical Solution | Adherence of the end-use documentation to applicable standards |
| 53 | Technical Solution | Review of the end-use documentation |
| 54 | Product Integration | Selection and review of the best product-component integration sequence |
| 55 | Product Integration | Product Integration environment – Documented requirements of the environment – Verification criteria and procedures – Details of verification carried out on the Integration environment |
| 56 | Product Integration | Availability and business analysts use of product integration procedures |
| 57 | Product Integration | Availability and business analysts use of product integration criteria |
| 58 | Product Integration | Availability and business analysts use of criteria for validation and delivery of the integrated product |
| 59 | Product Integration | Review of interface descriptions for completeness and correctness |
| 60 | Product Integration | Interface compatibility – Traceability – Consistency |
| 61 | Product Integration | Performance of readiness check before integration |
| 62 | Product Integration | Builds are made as per the procedure |
| 63 | Product Integration | Availability of verification and validation records for each build |
| 64 | Product Integration | Availability of delivery documentation for each release |
| 65 | Verification | Adequacy of verification plan – identification of candidate work products – Verification methods for each selected work product – Verification criteria – Schedule – Entry Criteria – Exit Criteria – Usage of approved checklists |
| 66 | Verification | Definition of verification environment |
| 67 | Verification | Availability of verification procedures |
| 68 | Verification | Conduct of verification activities as per the plan |
| 69 | Verification | Capture of verification data, analysis and corrective actions |
| 70 | Validation | Adequacy of validation plan – Identification of candidate work products – Scope of validation – Validation methods for each selected work product – Validation criteria – Schedule – Entry Criteria – Exit Criteria – Validation constraints |
| 71 | Validation | Definition of validation environment |
| 72 | Validation | Availability of validation procedures |
| 73 | Validation | Conduct of validation activities as per the plan |
| 74 | Validation | Capture of validation data, analysis and corrective actions |
| 75 | Integrated Project Management | Appropriateness of tailoring |
| 76 | Integrated Project Management | Usage of Process Assets and artifacts from the Process Asset library |
| 77 | Integrated Project Management | Review and approval of tailoring |
| 78 | Integrated Project Management | Adequacy of the environment to meet the project’s needs |
| 79 | Integrated Project Management | Contribution of the project to the organizational process assets |
| 80 | Integrated Project Management | Establishment of agendas and schedules for collaborative activities involving stakeholders |
| 81 | Integrated Project Management | Identification and management of critical dependencies |
| 82 | Integrated Project Management | Management of stakeholder coordination issues – Identification – Communication – Resolution – Escalation |
| 83 | Risk Management | Determination of risk sources and categories based on the organizational processes |
| 84 | Risk Management | Definition of various risk parameters – Probability of risk occurrence – Severity and impact – Thresholds to trigger management activities |
| 85 | Risk Management | Availability of risk management strategy |
| 86 | Risk Management | Usage of risk identification checklist |
| 87 | Risk Management | Implementation of risk mitigation plans |
| 88 | Decision Analysis and resolution | Appropriateness of project-specific guidelines on the application of a formal evaluation process |
| 89 | Decision Analysis and resolution | List of qualifying issues for the formal evaluation process |
| 90 | Decision Analysis and resolution | Recommended solution for issues – Identification of alternative solutions – Selection of evaluation methods – Evaluation using criteria and methods – Risks associated with the recommended solution |
| 91 | Process and Product Quality Assurance | Check the adherence of the performed process to the defined standards and process |
| 92 | Process and Product Quality Assurance | Check if the non compliance identified is tracked to closure |
| 93 | Process and Product Quality Assurance | Is the new /modified process standardized and institutionalized |
| 94 | Supplier Agreement Management | Check for formal agreement between the supplier is established and maintained |
| 95 | Organization Process Definition | Organization assets are established and maintained -Processes -Standards -Descriptions of Life Cycle Models -Measurement Repository -Process Asset Library -Work Environment Standards |
| 96 | Organization Process Focus | Periodically identify strenghts, weakness , improvement opportunities for the organizational process -Action Plans maintained and implemented for process improvement |
| 97 | Organizational Training | Training needs identified based on organizational business objectives – Training Planned – Training Material -Training feedback collected |
| 101 | Quantitative Project Management | Organizations , customers and stake holders objectives for quality and process performance needs are defined |
| 102 | Quantitative Project Management | Sub Process metrics identified and statistically managed |
| 103 | Quantitative Project Management | Identify variations in performance – Special Causes |
| 104 | Quantitative Project Management | Sub Process metrics appraised to achieve quality goals |
About Adaptive US
Adaptive US is the World’s #1 Provider of IIBA Certifications Courses and Study Aids on CBAP, CCBA, ECBA, CBDA, CPOA, AAC and CCA. It is the ONLY training institute to provide a 100% Success Guarantee or 100% Refund promise for all IIBA certifications Instructor Led Training. It also provide skill-based training to business analysts on business analysis tools and templates.
