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.

The Truth

Prior to the start of the requirements phase, come to an agreement to what constitutes "the truth" for your project’s requirements phase. It is important to be clear in outlining what deliverables are expected as well as the level of quality in the deliverables. Avoid vague statements such as, "all the requirements must be complete at the end of the requirements phase." Instead, explain exactly what is required. For example:

By the end of the requirements phase, the following deliverables will be baselined:

  • A data requirements document for each subject area in the data warehouse that lists each data element required, its definition, a sample valu, and the data type in the provided template.
  • A non-functional requirements document that lists timeliness, frequency, scalability, reliability, security and auditability requirements for the data warehouse in the provided template.
  • An updated project plan with detailed tasks for the next phase of the project.
  • Updated risk and issue logs.

In addition to clearly defining what documents should be delivered by the end of the requirements phase, it is also important to be explicit about what constitutes a good requirement versus a poor requirement. A good way to do this is through use of examples of both good and poor requirements (see the article here for tips on data element requirements). Another technique is to require peer reviews and iterations involving downstream customers of the requirements during the requirements phase. For example, have the ETL lead review the data requirements and provide feedback throughout the requirements phase.

The Whole Truth

During the requirements-gathering phase, be sure to record all valuable information that is uncovered. If it was tough to get a business definition for a data element, make sure to document why that happened. Maybe a term is used inconsistently across departments, or maybe a concept doesn't physically exist in the system today but is derived from other concepts. There are many ways to make sure this information is not lost, including keeping meeting minutes, keeping a log of decisions made, or adding notes to the requirements themselves. Pick what works best for your team, but more importantly, make sure all your research is not lost.

A healthy dose of common sense goes a long way in adding value and avoiding waste. Requirements-gathering should never be considered a "check the box" activity that involves filling out all blanks in a template. The analyst's job is to make sure every part of every document adds value. If it turns out that part of the requirements template is consistently copied/pasted or filled with a formula, remove it from the template. If the business request is not clear to you, it will almost certainly not be clear to the next person who needs the document, so dig and get the clarity that's needed. The more you can anticipate and answer the questions you think other stakeholders will have, the more comprehensive the requirements will be.

Nothing but the Truth

The final key to successful requirements documentation is to be single-minded (and sometimes ruthless) in keeping the requirements phase focused on requirements. After defining what's expected to come out of the requirements phase, keep the focus on achieving what is expected and moving on to the next phase. For example, if the project defined conceptual modeling as following requirements and being a high-level design activity, don't let any modeling work creep into the requirements documentation. Similarly, ETL source-to-target mapping typically follows requirements and should not be mixed in to the requirements work.
It's tempting to look ahead, whether to modeling or mapping, but there are a couple big problems with letting that happen. First, solving multiple problems simultaneously is often harder than decomposing complex problems and solving them one at a time. Typically, the requirements should focus on what is needed. Then, in the ETL mapping, the focus can shift to where to get what is needed.

Second, allowing the requirements phase to envelop design work leads to requirements that drag on because the requirements are asked to address everyone's problems all at once. To avoid these problems, be sure to decide what chunks of work are going to be done where, and be ruthless when necessary in enforcing that delineation.

Baseline and Move On

When the requirements work has been documented and reviewed, baseline the requirements and move forward to the next phase. My choice of the word "baseline" here rather than "complete" is intentional. It is not feasible or realistic to have requirements 100 percent completed prior to design (let alone subsequent phases). Rather, it is much better to put forward a good-faith effort, review with key stakeholders, and then jump into design, recognizing that design will uncover requirements gaps. Getting everyone on the project to agree that the requirements are 100 percent complete is not only a waste of time but it is also an illusion that will be shattered as soon as the modelers and ETL developers start designing and asking questions. And that’s okay – the requirements should be viewed as a way of getting as much of the “what” that can be known to the right people and as a subsequent foundation for intelligent discussions about the “where” and the “how.”

If you implement these recommendations on your project, you will be well on your way to producing solid data requirements that are the foundation for a successful project - just don't say they are "done" yet.

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

Don't have an account? Register for Free Unlimited Access