PDF Articles
- Accounting for Technical Debt
- Business Analysts, Be Kind to your Stakeholders
- The Business Analyst’s Other Customer
- Corporate Strategy and the Business Analyst
- Does Your Paperwork Add Value?
- Four Key Knowledge Areas for Business Analysts
- Good Requirements are More than Just Accurate
- How “agile” is Important to Business Analysts
- McDonald’s Burgers and High Quality Business Analysis
- My Business Analyst Code of Conduct
- On Business Analysis in an Agile Setting
- Passing Thoughts on Business Analysis and Requirements
- Requirements Visualization Mock-up and Wireframe Goodies
- Vision Statement Form and Function
- What does the Future Hold for the Business Analyst Role?
Graphics
BA, PM, Arch Overlap Venn
This image might be used to describe the closeness and interelationships of tasks between the project manager, business analyst, and architect/designer.
Business Analysis Progression
This visual might be used to describe how business analysts work from symptoms to root cause and higher level problem statements then from objectives to more detailed requirements. Grab the original visio .vsd file if you’d like to manipulate it to suit your circumstances.
People, Process, Technology Diagram
It sometimes gets lost on project stakeholders that technology is only one of the available levers for solving business problems. This graphic might be used to reinforce the notion that people, process and technology should all be considered in devising solutions to business problems. You’re welcome to grab and download the original Visio .vsd file if you’d like to update the diagram to better suit your purposes.
Requirements Model Diagram
My intent with the graphic was to convey the notion that the business analyst’s output shouldn’t be seen simply as a specific document or set of documents in which “done” is defined as having completed all the sections of a canned template. I wanted to show that there are lots of common components which might be part of a good requirements model. I also wanted to emphasize that a good requirements model typically doesn’t need all of the above. In fact, trying to include too much can lessen the communicative value of a requirements model. If you’d like to modify the diagram to suit your purposes, you can grab the original Visio .vsd file.
Templates
- Cornell Note-taking Template (.doc)(.pdf)
- Process Document Template (.docx) – Adapted with permission from Barb Carkenord’s template from Seven Steps to Mastering Business Analysis
- Risk Matrix (Excel) (Google Docs)
- Simple Business Requirements Form
- Use Case/User Story Template (.docx)(.pdf) – Also adapted from Barb Carkenord’s process template from Seven Steps to Mastering Business Analysis. Can be useful for a single use case, or to capture the supporting, “conversation-level” details of a user story.