A look back at the best from a year ago.
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.
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.
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.