The IIBA (International Institute of Business Analysis) has just released version 1.6 of A Guide to the Business Analysis Body of Knowledge, or the BA BOK. This new release adds over 100 pages of content and is the first “essentially complete” version.
Iron Triangle Kills in Boston…
… Skyline Unharmed Short-sighted demands on software teams usually don’t kill people. Software development is often described with a construction analogy. The Big Dig construction project was under exactly that kind of pressure. On July 10th, 12 tons of tunnel ceiling collapsed and killed a motorist. On July 20th, Mitt […]
Communicating A Release Schedule With Use Cases
We manage release schedules with project management. We manage customer expectations with consulting skills. How do we manage customer expectations about release schedules? With Use Cases. Background We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use […]
Foundation Series: Business Process Modeling
Business Process Modeling allows us to increase our understanding of business processes and improve communication with stakeholders and implementation teams. Business analysts will create diagrams that represent business processes. These diagrams can be used to elicit requirements, define scope, and improve communication within the team.
Communicating Intent With Implementers
Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.
Communicating Intent With Stakeholders
We can build a prototype of what the stakeholders don’t want, and then get feedback and fix it. Or we can review use cases of what we intend to build, confirm that each stakeholder wants it, and build it right the first time.
Foundation Series: Data Dictionary Definition
What is a data dictionary and how is it used when communicating and managing requirements?
Four Assumptions of the Apocalypse
Business Analysts often start with four erroneous assumptions when eliciting requirements. 50% of errors in software projects are caused by requirements errors. These four faulty assumptions, presented by James A. Ward, can exacerbate the error-prone process of gathering requirements.
Outside Reading: Top 10 Signs You Should Not Write Requirements
Seilevel has a post that presents the top 10 signs that you should not pursue a career writing requirements, check it out. Thanks Joy for the great article!
