How to ask a business user for cardinality information?

Question

When collecting requirements from business users, I run into a point where I need to understand the cardinality between two concepts in the business user's domain.

This is usually something I want to know early in the process, since it affects database design which is hard to change later.

For example, the busines user may have a domain-specific concept of a "Lead" and a "Reference". It's not always easy to get them to tell me how many References a Lead has, or vice versa.

If I was asking a DB programmer, I may simply ask, "what's the cardinality between a Lead and a Reference?" However, this doesn't always make sense to a business user.

Answer 1

I can't see your problem here. You shouldn't use terms like cardinality to business people, you'll just get a blank stare or someone who thinks you're a pretentious &%^$#$@. :-)

The two questions:

• How many leads can a reference have?
• How many references can a lead have?

are simple English, understandable by anyone who speaks the language.

But, as always, requirements gathering is a teasing-out process. If you can't get clear answers to those simple questions, you need to:

• make it clear to the person you're asking that it's necessary to know (and that not knowing will delay the delivery).
• sit them down in front of a whiteboard and walk through the possibilities (there's only four, assuming they have a relationship at all: one-one, one-many, many-one, many-many).

Sitting down with them is a good idea for both of you. It makes them understand why you need to know and it gives you the information you need and more domain knowledge.

Answer 2

The only way you can do it is to work through the use cases and determine the cardinality as they explain what's supposed to happen.

You: Who needs a "Lead"? What's it used for?

Them: A lead is what we get from a reference.

You: How should that work?

Them: Well, as part of something or other, we'll get a reference. We want to put those into some kind of list so we can segment and prioritize them and then do cold calling on the reference. A cold call that has interest becomes a "lead".

You: So one reference becomes one lead?

Them: No. Sometimes a reference doesn't generate a lead [Optionality]

You: So one reference might become a lead, or might go no where?

Them: Absolutely.

You: What else happens with a reference? Anything other than creating a possible lead?

Them: Nothing.

You: Nothing?

Them: Except when send out for credit scoring and re-rank all the references.

You: So there are two use cases? Initial reference and credit scoring?

Them: I guess so.

You: And the credit scoring of a reference can create a lead?

Them: Yes. Does all the time.

You: So a reference can generate zero, one or many leads? [Cardinality]

Them: Nope. Zero or one.

You: Unless it gets scored, then it might generate a second lead.

Them: Right. Zero, one or two. Never more than three of four. Call it six at the absolute upper limit. Give us six leads per reference. We'll never need any more than that.

You: How about an infinite number through the magic of foreign key references?

Them: Never. It's only zero or one. Except when it's two. [Attempted Repudiation]

---

I think the only way you can meaningfully engage users is to discuss the use cases. Not the data model.

You derive the data model from the use cases.

Answer 3

And don't forget to ask the other users. Other departments might have different views.