PM Articles > Kent McDonald > Requirements for Requirements

Requirements for Requirements

by Kent McDonald

This week I found myself in a conversation that seemed surreal at the time. A data analyst had just suggested that we add a business requirement to capture metadata for all the data elements being added on a data warehouse project. Put another way, she was suggesting that we create a requirement to capture data about data that are requirements. Once I wrapped my brain around why someone would suggest identifying a requirement to identify requirements, I realized it was worth discussing the concept for a couple of minutes. It gave me an opportunity to discuss when to create requirements for a deliverable, as well as the various forms requirements can take.

Our data analyst indicated that project sponsors on past projects she'd worked on had required that metadata be created for specific elements, because sometimes they wanted to revise, correct, or add metadata for data elements that otherwise weren't getting touched, but which were in the same general subject area (i.e. claims, eligibility, etc.). That in itself made sense. The SME's were requesting a deliverable for a particular data warehouse project in addition to the actual software being produced; in this case metadata for the impacted data elements.

You want the project sponsor to define scope, which would include the expected deliverables of the project. One of those deliverables may be specific information that goes along with a system so people know how to use it—think user manuals, online help, release notes, and, you guessed it, metadata. Makes perfect sense.

Fairly mature organizations have software development life cycle standards that require that sort of information for all systems. If those items do become part of standards, then the sponsor on a particular project should not have to indicate that things mentioned in standards are deliverables. The standards themselves are actually requirements (you could say constraints) spelling out what the project must produce. Let the sponsor worry about the business outcome they need, rather than specific system-related deliverables the team has to produce anyway. Of course, standards should be considered guidelines and not hard and fast rules. If the nature of the project does not require the creation of a particular deliverable, there's no reason to produce it. For example if no data elements are being added or revised, the project team probably won't need to create any additional metadata.

My organization does have a standard that calls for creating metadata for any project related to data warehousing. Because it's a process standard, the project team is expected to produce metadata regardless of whether the requirement was spelled out or not. So the data analyst's suggestion to create a specific requirement to create metadata was redundant. It took me a few minutes to convince her that the team will still be expected to create metadata because it's part of the process standard, and that people producing reports will have a resource to refer to, assuming they take advantage of that resource.

Then the data analyst went on to say, "Yeah, we document all the information in the user requirements so that we can then turn around and update the metadata worksheet."

Whoa there camper, hold on just a second.... Even if there wasn't a pre-existing process standard to create metadata, you certainly don't want to find yourself in a situation where you are doing extra work. Writing all the information about data elements in a standard requirements specification and then duplicating all of that information in the metadata deliverable makes no sense. Metadata is actually a different representation of data requirements. Think of a data dictionary that provides information about a data element's definition, data type, valid values, and default values. Similarly, a logical data model is actually a way of representing requirements that provides information about how the data is organized in terms of entities, attributes, and relationships. Both of these representations, which add context to the information, are much better at describing data than a requirements specification that tries to convey everything using only text statements.

The idea that the data dictionary and logical data model were really different and more appropriate forms of requirements was a new concept to the data analyst. I think a lot of people performing analyst roles find themselves using the same tool to describe everything about the system under development, be it shall statements, use cases, or user stories. It often takes some convincing that there are different ways to represent, i.e. model, requirements based on the type of requirement you are describing.

In this case, we needed to represent requirements related to data. There are several ways of doing this:

  • Data dictionaries
  • Logical models
  • Context diagrams
  • State change diagrams
  • Report prototypes
  • File layouts
  • Business rules

The context of these methods provides as much information as the content, and often can more clearly portray the information the team needs in order to approve or implement the desired development activities.

As I described this concept to the data analyst, I pointed out the value of using these different representations: information is not duplicated in different artifacts, making the maintenance of these requirements much easier, and reducing the risk of errors caused when the same requirement is listed in multiple places which get out of sync. I think I said something like, "Leave it to someone lazy like me to find a way to do the least amount of work and still accomplish the desired goal." Of course it's not really laziness. You have to consider how the information will be used and who will be using is before you decide the best approach to use for representing requirements. So there is some effort involved, but it is certainly worth it in the long run, and it may help avoid, or at least minimize, surreal conversations like the one I found myself having.

Related Resources
The ProjectConnections library includes templates and guidelines for meta-requirements documents like data dictionaries, context diagrams, and business rules management. As you're sorting through them all, make sure you also have a Requirements Management Plan, and that you (and your team) know how to use it.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.