If human communication and human memory were perfect, we may not need deliberation and documentation of requirements. Alas, neither is close to true. It is the iterative exercise of modeling requirements, and then documenting them that enables shared understanding to be affirmed, and then shared with those who use requirements to guide design, construction and quality assurance. Requirements are the link between concept and product, and an important standard for measuring solution success.
About The Author
Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he's learned, and for interacting with solution delivery professionals across the globe.
September 16, 2008
February 16, 2009
August 20, 2009
May 8, 2014
- Tweets of the Week – 20180713
- The Real Value of Visuals in Solution Delivery – A Reprise
- Hippocrates on Clarity of Language
- The Book, The Movie, and the Business Document
- Interview with Ryland Leyton, author of “The Agile Business Analyst”
- John Dewey on Starting with a Problem to be Solved
- Business analyst, these are the reasons your project will succeed
- Four Critical Components of a Meeting Invitation
- Benjamin L. Kovitz on Requirements
- Business Analysts and Grammar Police
- Visionary Leadership and You
- Alistair Cockburn – Agile is an Attitude
- Business Analysis Success is . . .
- Harold Evans on Creating Understanding
- The “Obviousness” Danger that Kills Projects
- Jabian Journal and Visual Communication
- Distinguishing between Business Rules and Software Requirements
- Roughly Right, or Precisely Wrong?
- 6 Guidelines for Building a Reputation with Your New Employer
- Why Stakeholders Don’t Tell You Everything