Results 1 to 8 of 8
  1. #1
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,799

    Re: Boring (copy)

    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 ;-).

  2. #2
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    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.

  3. #3
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by andrewst
    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?
    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



    This is probably why the best analysts are cantankerous, crusty old gits who wouldn't win a popularity contest.
    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

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Quote Originally Posted by r937
    maybe not the best, though, eh, because although i'm fairly old, i will never be crusty
    Yeah, right!

    -PatP

  5. #5
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    Quote Originally Posted by r937
    shoving a signed piece of paper under their noses isn't going to help fix things
    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...".

  6. #6
    Join Date
    Jul 2003
    Posts
    74
    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

  7. #7
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,799
    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.

  8. #8
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    The application designer should be working from the requirements and data model, not the other way around!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •