In order to stir things up in here, how about I ask a question on a topic I know almost nothing about?

How do you go about the interview process when you are coming up with a logical design? What questions (if any) are the ones that you always have to ask? How many ways can you get bit in gathering the requirements?

This may not be as controversial as type/subtype discussions, or the Natural vs Surrogate key debate, but still, let's see no hitting below the belt ;-).

What I find is that you need to be quite thick skinned, and prepared to ask the same question more than once until you are sure you have got the right answer. Quite often an interviewee will respond "no, that never happens" about some scenario you think might happen. But there is a big difference between "no, that could never happen, ever" and "no, I've never known that to happen". Sometimes you feel like an annoying idiot, asking too many questions that have "obvious" answers, or that they think they have answered already. It's tempting to shut up, but you should not.

Once you get an answer you think is definitive, you must then get it documented and signed off by the business experts; otherwise when it turns out to be wrong, guess who gets the blame for not anticipating that scenario?

This is probably why the best analysts are cantankerous, crusty old gits who wouldn't win a popularity contest.

that's like saying that you need to get your fiancée to sign off on how many times she will have sex with you after the third year of marriage

when it turns out that your business sytem doesn't satisfy the users, or you and your wife's sexual needs are mismatched, no piece of paper is gonna help anyway

business people are hugely reluctant to sign off on "specifications" because they have been burned too many times, getting a system that doesn't do what they need

shoving a signed piece of paper under their noses isn't going to help fix things



hey, careful, i consider myself a really good analyst

maybe not the best, though, eh, because although i'm fairly old, i will never be crusty

Yeah, right!

-PatP

No, and I accept that in practice you won't get them to sign off on everything anyway. But at least make sure you put all the requirements and assumptions and what isn't in scope etc. on record (even if it's just an email) in case they later say "you never said..." or "we expected...".

I have had success with adopting an approach that facilitates evolution in response to user requests for change, (which is a fact of life, so has to be planned for and can't be ignored).

My approach uses a Data Model, and maintains a normalized Database design, generated from the Data Model, and if you have a separate physical denormalized Database design,(which is usual), then always maintain an audit trail of changes.

B.Dimple
DBA

Should the specifications be limited to just the features that will be delivered, then? This would limit "scope creep" to a degree. But if that is the case, then isn't the data modeler entirely dependent (for his/her model) on what the application designer comes up with? The specifications that the user would be signing off on would be all related to the interface.

The application designer should be working from the requirements and data model, not the other way around!