Skip to main content
Mediacurrent logo
Hero Background Image

Blog Post

Capturing Data Requirements

by Bill Shaouy
July 6, 2021

For a web project to be successful, we must ensure that the right solution is being delivered, one that is in line with organizational goals and stakeholders’ priorities. 

My role as a Business Analyst is to elicit and analyze project stakeholder requirements and to convey what the desired solution will do both at a high level and at a detailed level. One task to accomplish this goal is to communicate how an organization’s business processes are conducted and how these processes relate to one another. This is expressed by a functional decomposition diagram, which is a work product that formalizes the processes, or “verbs,” of a proposed system.

However, this provides an incomplete picture. We must also capture and describe the “nouns” of the system; that is, we need to formalize what data entities the system will manage and how they interrelate. 

An entity relationship diagram (ERD) is the work product that achieves this aim. The ERD is used to build a data model, which is a visual representation of the data needed for the solution. Often an organization’s data is stored in a legacy database that needs to be migrated to a new one, and often critical data isn’t being properly stored at all. 

Who Benefits from an ERD?

The ERD is useful to both developers and stakeholders. For developers, it provides a data specification from which to construct a database schema. Further, it serves as a decision aid when choosing between platforms to migrate to; a particular schema may fit in better with one platform over another. For stakeholders, it formally describes their information needs in clear, unambiguous terms, confirming that the stakeholders’ needs are understood correctly and completely.

How to Interpret an ERD

Here's a small example Entity Relationship Diagram:

Example ERD

Example ERD

This compact notation represents data entities (the rectangles), their relationships (the connecting lines), and their attributes (the list of fields per entity). Think of it as an abstract database schema and an excellent framework on which to create an actual, more detailed data schema. The ERD serves as a bridge between the stakeholders and the database designer, translating their verbally-expressed data requirements into a specification. 

Let’s take a closer look at what the above notation means. Each of the three rectangles is a data entity - Customer, Email, and Address. Each entity has its own attributes’ for example, Customer has the attributes ID, Name, and Phone. Relationships are more complex to convey. When one object references another, a foreign key needs to be an attribute of the object. In our example, Email has a field called Customer ID, which is a reference to a particular Customer data entity with that same ID. In an ERD, when any two entities are related, they are connected with a line with “crow’s foot” symbols on them that define cardinality thusly:

ERD Example 2

If any two related entities are viewed as subject and object, then the cardinal relationship between them is expressed at the far end of the connecting line. So, in our example, for any Customer entity, there must be one to many associated Email entities, and for any Email entity, there must be a reference to one and only one customer. Likewise, for any Customer entity, there must be zero to many Address entities associated with it, and for any Address entity, it must reference one and only one Customer entity. 

So, although an ERD doesn’t get into the level of detail of a database schema, it bridges the gap between a stakeholder’s expressed data requirements and the developer’s data schema in a format that both parties can understand and find useful. 

We at Mediacurrent provide many other deliverables that clarify and formalize your requirements. Reach out to us to learn more!

Headshot

Meet team member, Bill Shaouy

Bill is a senior technical professional who has been working with Drupal for over ten years. He has innovated client-centered, Drupal-based solutions for non-profit and for-profit organizations, placing a premium on fostering lasting relationships with clients and teammates in equal measure.

Bill was first introduced to Drupal in 2007, when he served as I/T Architect and Development Lead for the DC Comics Zuda web content management system. Since then, Bill has led Drupal projects in both the profit and nonprofit space, for such organizations as the State of Georgia, Jane Addams Hull House, the Mohonk Nature Preserve, the New York Hall of Science, Mentorplace, the World Bank, and most recently, the Atlanta Falcons. He also served as one of the original board members of the Atlanta Drupal User’s Group, giving multiple presentations there and contributing to the running of the early Atlanta Drupalcamps, and was also the founder and long time chairman of the IBM Drupal User's Group. Bill has also conducted many technology roadmap consulting engagements over the past several years, many from the nonprofit space. These engagements helped clients form a long term technology strategy based on current and projected requirements. 

When he’s not working, Bill is an active musician and songwriter, with two albums of his own and several more with him accompanying on piano.

Learn more about Bill >

Related Insights

  • Headshot
  • Headshot
  • Jessie Golombiecki
    Blog from Jessie Golombiecki

    How to Foster a Data-Driven Culture Hollow right arrow icon

  • Headshot