Flashback: A Year Ago This Week on Tyner Blain [2006-07-13]

side view mirror

A look back at the best from a year ago.

Verify Correct Requirements With Use Cases

puzzle piece

One of the challenges of writing requirements is assuring that we are capturing the requirements correctly. Correctness represents two elements. First we must document the requirement as articulated for it to be correct – any errors are “typographic” in nature. Second, we must document the valid requirement. This requires understanding the business objectives, as well as the source of ROI associated with a proposed requirement. If we properly record a stakeholder’s desire for a low-value requirement, that does not mean that the requirement is correct – it is only correctly documented.

Four Assumptions of the Apocolypse

four horsemen

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.

Foundation Series: Data Dictionary Definition


What is a data dictionary and how is it used when communicating and managing requirements?


A data dictionary is a collection of the definitions of the structure of information that is relevant to a set of requirements. That’s a lot of words for a simple concept. We need to know (and constrain) a set of information about some business element when managing our requirements. We use a data dictionary to define what that information is, and any constraints on how it must be used.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.