Good requirements are the foundation for successful IT projects. We've all heard that statement and know there's truth in it, but in practice it is often tough to nail down what makes a good requirement, especially in data projects where requirements mainly consist of data elements and their definitions.
One difficulty in requirements-gathering is the ambiguity of language. In U.S. courts of law, a person who testifies swears to tell "the truth, the whole truth, and nothing but the truth," which is a way of calling for comprehensive truthfulness in the person's testimony. This kind of precision is needed in both setting expectations for the requirements phase of a project and documenting the requirements. Let's follow the courtroom analogy as it applies to data requirements.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access