The Magic Behind Functional Requirements – Data!

For me a good day of gathering requirements is marked by a business user saying, “That’s a very good question.” In the majority of instances the trick of coming up with those questions is the same – while talking to users about their business processes, I am mentally mapping the information those processes involve to a data model.

In a previous life I was a Data Administrator. Relational database technology was new and ‘normalisation’ was a magical art. Apprentice data analysts could get to third normal form. Full data wizards understood fourth and fifth normal form. Hard to believe it now but we ran sessions with business users that focused purely on data. We asked them to put their processes out of mind and focus only on their information requirements. Our deliverables were entity/relationship models intended to support the development of enterprise-wide, reusable databases. It was a VERY painful process for all involved.

I’d estimate that data administrators (myself included) spent about 30% of their time documenting business data requirements and the other 70% debating with other data administrators about such things as naming standards, domains, and whether “Double-headed arrows,” “Crows Feet” or “A Big Dot” was the best way to represent the “Many” end of relationships on Entity/Relationship (E/R) diagrams. I really miss those days – NOT!

Fast forward twenty-something years to today. The Unified Modelling Language has morphed E/R diagrams into Class Diagrams (although Relational databases for the most part are still the norm rather than genuine Object-oriented databases). When people talk about requirements the two main types are Functional and Non-Functional. Data requirements are typically relegated to entries in a glossary or one or more E/R diagrams in an appendix.

Business users now, as then, have zero (or less) interest in looking at a data model. However, they are more than happy to be shown a screen ‘wireframe’ representing the way a system would present data to them in support of their business process. The trick, at least in my case, is applying my data perspective during discussions of these wireframes, but without using the “E” or “R” words. Most typically a screen equates to an entity (e.g. Customer, Contract, Order). So does a displayed table of items (e.g. Order Line Item, Payments). Fields in the screen (or columns in the table) either are ‘facts’ about that entity or reference some other entity (e.g. the Customer ‘named’ in an order or the Product ‘short description’ in an order line item).

OK, back to the magical source of ‘good’ questions. The basic data normalisation technique is ensuring that each attribute is a fact about the most appropriate entity. [“The key, the whole key and nothing but the key, so help me Codd.”] If not, then it is a fact about some other entity.

For example in an Order Line Item, “Quantity” is definitely a fact about the Line Item. The “Product” being ordered is a fact about that Line Item, but because there are a bunch of ‘facts’ about Products irrespective of them being ordered, there needs to be a Product entity. Users entering Line Items need a way to ‘identify the product’, and having done so the screen is populated by fields that are facts taken from the identified instance (e.g. short description, unit price). A “good question” might be, “When a Product is ordered, is the Unit Price the same in all cases, or can the unit price be different (e.g. Customer-specific price schedules)?”

Another ‘good question’ that has its basis in normalisation is, “Can that fact have multiple values at the same time (e.g. an Employee being classified as having multiple Skills)? Or the cardinality of a relationship (e.g. can a Contract involve more than one Supplier?).

If you have data analysis skills, I encourage you to apply them during requirements gathering. If you are light on data modelling skills, I encourage you to learn more about the subject. Regardless, I encourage you to keep these skills hidden from your business users and let them think you have magical abilities to ask ‘good’ questions.

Anyone else, “been there, suffered that”? If so please add any examples and/or tips for gathering requirements without diverting Business Users from their focus on their processes.

Don’t forget to leave your comments below.