Chapter 1: Introduction (structure of the BABOK)
Chapter 2: Key Concepts (basic context of business analysis)
Chapters 3-8: Knowledge Areas (the basic flow of what gets done)
Chapter 9: Underlying Competencies (Analysis, Behavior, Domain Knowledge, Communication, Interaction, Tools/Tech)
Chapter 10: Techniques (50)
Chapter 11: Perspectives (Agile, BI, IT, Business Architecture, Process Management)
|Bob's Technique||Business Analysis Planning and Monitoring||Elicitation and Collaboration||Requirements Life Cycle Management||Strategy Analysis||Requirements Analysis and Design Definition||Solution Evaluation||Requirements per BABOK|
|Intended Use||x||X||x||x||x||Business Requirements|
|Assumptions, Capabilities, Limitations, and Risks & Impacts||x||X||x|
(To-Be State: Abstract)
(To-Be State: Concrete)
(Functional and Non-Functional)
|Test Operation and Usability
Review every phase with the customer until they agree it's correct, especially for the Conceptual Model (As-Is State).
Needs discovered later could require the creation of earlier elements.
This framework is usable for both Waterfall and Scrum, and really for any management style.
Participants see to aspects of the engagement.
Participants see to non-functional requirements aspects of the solution.
Participants see to functional aspects of the solution.
Link to detailed discussion.
Link to detailed discussion.
How much of either process are you a part of?
Link to detailed discussion.
|4||Team Foundation Server||Engagement|
Link to survey results.
Software greatly aids sharing and communications, so BAs will concentrate on this. However, a huge amount of solutioning will be aided by specific, technical software or will be software, with which BAs will tend to be less involved.
What it IS or what it DOES?
That is, if everything isn't a process, what is your context?
Hint: Everything involves a process, even if it only involves the does-ness of identifying and creating an is-ness.
Sets up and kicks off the project using traditional project management techniques.
Considers intended management framework (Waterfall, Agile, Kanban, etc.) and special requirements for the effort (existing assets/PMO, identify stakeholders).
This step is bookended by a Project Closeout step at the end of the effort.
This defines the customer's goals for what the new or modified process or system will accomplish.
It may describe technical and performance outcomes but must ultimately be expressed in terms of business value.
Each goal can be described in terms of:
This information is included in the Project Charter from the PMBOK.
Define the scope of the project and what capabilities and considerations will and will not be included.
Describe the risks inherent in the effort and the possible impacts of risk items occurring.
Reasons to omit features and capabilities:
If an existing process is to be modified, improved, or automated, discover all operations and data items. This defines the As Is State. (In simulation this is known as building a Conceptual Model.)
If there is not an existing process, work backwards from the desired outcomes to determine what operations and data are required.
Map out the discovered process and document and collect data and parameters for each operation and communication.
The conceptual model is not a specific type of drawing, but is a representation of an existing system using any appropriate techniques.
Iteratively review the maps, data, and descriptions with customers and SMEs until all parties agree that understanding is accurate and complete!
Refers to input items (nouns) processed, not parameters (adjectives) that describe the operation and characteristics of the system.
Map sources, sinks, and messages to Conceptual Model.
Data sources (or assumptions) must be found that support the generation of all required output data items. Trace backwards from desired outputs to required inputs and calculations.
Items must be validated for accuracy, authority, and obtainability.
Interfaces should be abstract initially (e.g., with management and through initial discovery and scoping), and then detailed in design and implementation with proper SMEs.
Ensure that data and flags, states, formats, and metadata are captured in sufficient detail. Work with implementation SMEs as needed.
The requirements include the criteria by which functional and non-functional elements will be judged to be acceptable.
This represents the To-Be State in abstract terms.
All items in the requirements should map to items in the Conceptual Model in both directions. This mapping is contained in the Requirements Traceability Matrix (RTM), which can be implemented in many ways.
The design of the system is a description of how the system will be implemented and what resources will be required.
The design of the system also includes plans for maintenance and governance going forward.
All elements of the design must map in both directions to all elements of the Conceptual Model and Requirements via the Requirements Traceability Matrix (RTM).
BAs may or may not participate in the design of the system directly, but must absolutely ensure that all elements are mapped to previous (and subsequent) elements via the RTM.
This phase is where the implementation is actually carried out, based on the design.
Implementation also means deployment.
Alternatively, deployment and delivery, and even handover, could be considered to be a new phase after testing.
Operation and Usability (Verification)
Additional information about Verification and Validation here.
All elements of the test plan and results must map in both directions to all previous elements in the Requirements Traceability Matrix (RTM).
Specialized test SMEs may conduct the majority of system testing, but implementors, managers, customers, maintainers, and end users should all be involved.
Provisions for testing, V&V, and quality should be built into the process from the beginning.
This phase ensures that the customer's plans and criteria for acceptance are met. All of the stated acceptability criteria must be addressed.
This plan must include the process for handing the system or process over to the customer (internal or external). This process may include documentation, training, hardware, software, backups, licenses, and more.
The customer is the final judge of acceptance and may make three judgments:
The Intended Use drives everything.
Discovery is a qualitative process. It identifies nouns (things) and verbs (actions, transformations, decisions, calculations).
Data Collection is a quantitative process. It identifies adjectives (colors, dimensions, rates, times, volumes, capacities, materials, properties).
Discovery comes first, so you know what data you need to collect.
Imagine you're going to simulate or automate the process. What values do you need? This is the information the implementation teams will need.
Elicitation is discovering the customer's needs. Discovery is about mapping the customer's existing process.
If there is no existing process, i.e., a new (greenfield) process is being built from scratch, then a form of discovery will occur during Requirements and Design.
Processes may be mapped differently based on needs, industry standards, and the information to be represented.
I give specific names to modular components.
Data collection corresponds to the Observation technique in the BABOK. Methods include:
Simple pass-through simulation using basic component types.
The process described includes the greatest amount of detail. All projects and efforts perform all of these steps implicitly, but some may be streamlined or omitted as the size of the effort scales down.
The entire process takes place implicitly or explicitly even if any one participant or group only sees a small fraction of the activity.
Usually best for processes that have a defined beginning and end. Continuous discovery, data collection, redefinition of requirements, update of design, and reimplementation can be carried out for ongoing, reactive, support and maintenance operations.
Works in Waterfall, Agile, and other project management environments.
The framework does not inhibit the ability to explore and test multiple options.
Tell 'em what you're gonna do. Do it. Tell 'em what you did.
|Accreditation Plan||V&V Plan||V&V Report||Accreditation Report|
|Executive Summary||Executive Summary||Executive Summary||Executive Summary|
|1. Problem Statement||1. Problem Statement||1. Problem Statement||1. Problem Statement|
|2. M&S Requirements and Acceptability Criteria||2. M&S Requirements and Acceptability Criteria||2. M&S Requirements and Acceptability Criteria||2. M&S Requirements and Acceptability Criteria|
|3. M&S Assumptions, Capabilities, Limitations, and Risks & Impacts||3. M&S Assumptions, Capabilities, Limitations, and Risks & Impacts||3. M&S Assumptions, Capabilities, Limitations, and Risks & Impacts||3. M&S Assumptions, Capabilities, Limitations, and Risks & Impacts|
|4. Accreditation Methodology||4. V&V Methodology||4. V&V Task Analysis||4. Accreditation Assessment|
|5. Accreditation Issues||5. V&V Issues||5. V&V Recommendations||5. Accreditation Recommendations|
|6. Key Participants||6. Key Participants||6. Key Participants||6. Key Participants|
|7. Planned Accreditation Resources||7. Planned V&V Resources||7. Actual V&V Resources Expended||7. Actual Accreditation Resources Expended|
|8. V&V Lessons Learned||8. Accreditation Lessons Learned|
|Suggested Appendices||Suggested Appendices||Suggested Appendices||Suggested Appendices|
|A. M&S Description||A. M&S Description||A. M&S Description||A. M&S Description|
|B. M&S Requirements Traceability Matrix||B. M&S Requirements Traceability Matrix||B. M&S Requirements Traceability Matrix||B. M&S Requirements Traceability Matrix|
|C. Basis of Comparison||C. Basis of Comparison||C. Basis of Comparison||C. Basis of Comparison|
|D. References||D. References||D. References||D. References|
|E. Acronyms||E. Acronyms||E. Acronyms||E. Acronyms|
|F. Glossary||F. Glossary||F. Glossary||F. Glossary|
|G. Accreditation Programmatics||G. V&V Programmatics||G. V&V Programmatics||G. Accreditation Programmatics|
|H. Distribution List||H. Distribution List||H. Distribution List||H. Distribution List|
|I. Accreditation Plan||I. V&V Plan||I. Accreditation Plan|
|J. Test Information||J. V&V Report|
Involves running multiple trials of complex models including combinations of numerous randomly generated outcomes that yield a range of complex results.
Models may incorporate scheduled and unscheduled elements.
Every activity in an organization must provide value directly or indirectly.
Every object in an organization must provide value directly or indirectly.
Business analysts are a contemporary embodiment of the problem-solving, value-creating aspects of organizations, but there's a lot of overlap with other roles.
Tomorrow the role may be called something different. The Wikipedia page for seemingly every management idea has a section for criticisms.
Facts and Fallacies of Software Engineering describes 50 years of incremental advance.
This presentation and other information can be found at my website: