• (disco)

    You’ve never been handed a requirements document this bad. I hope.

    Oh @Remy, you poor, innocent soul...

  • (disco)

    Someone set us up the bomb in the Drawing Canvas.

  • (disco)

    A picture says more than a thousand words, so what we have here is a rather wordy requirements document. Too bad it's all the bad words.

  • (disco)

    Knocking up your customers (or even just their information) is considered bad business practice.

  • (disco) in reply to rc4

    Knocking them up against a Belgium list sounds a bit more adventurous than Legal would be comfortable with.

  • (disco)

    You’ve never been handed a requirements document this bad. I hope.

    Requirements document? What kind of fancy newfangled thing is that?

    Also, woulda coulda shoulda been frist if people here weren't cheating all the time.

  • (disco)

    In common practice, it’s more about gorging yourself.

    Well, that is a way of being thankful for what you've got, no? 'Cause, if you didn't have it, you couldn't gorge yourself with it.

  • (disco)

    My requirements docs:

    :older_man: We need the form to ask for this data BEGIN :boy: How should I structure this? What fields are required? What about this edge case? :older_man: Just knock something together, I'm sure it will be fine CODE :clock1: time passes REVIEW :older_man: THIS IS ALL WRONG! GOTO BEGIN

  • (disco)

    I'm sorry, I really can't see where the problem is. That looks like a perfectly cromulent set of requirements. It does, of course, require that the programmer has a modicum of domain knowledge, but that's surely not a problem nowadays. The day of the single-skill computer-programming-only can't-even-spell-my-own-name nincompoop has surely passed?

  • (disco)

    At thanksgiving, of course, you are encouraged to show hospitality to visitors. It doesn't work like that though, all the restaurants have private parties and even in the hotel the dining areas are off-limits to those staying there. Your best bet is to hope that someone you work with has the appropriate attitudes and values to invite you in to his/her home to share their turkey and cranberry sauce,

  • (disco) in reply to JBert
    JBert:
    A picture says more than a thousand words, so what we have here is a rather wordy requirements document. Too bad it's all the bad words.

    I did have an guy say to me once; "A picture says more than a thousand words, but sometimes you also need the thousand words" - he was a wise man...

  • (disco)

    I remember a project at my previous employer. It was a sort of "Project from Hell" that everybody in the dev group was terrified of because nobody (including one colleague who went to the client's office to talk to them) could figure out what was required. It became a sort of hot potato, and (as these things do) it eventually fell on my desk. I read through the requirements document, which was indeed very woolly, and looked at the code. So far, so, um, something.

    And I had one of my favourite meetings ever. We managed to get the client to send some guys in to discuss it. My company was one of those very large suppliers of financial-market information systems, and the client was a small brokerage/hedge fund kind of place. The project itself was a trade feed processor that would run twice a day and do a list of hand-waving to produce processed information that could be fed to a back-end/clearing system.

    So we sat in this meeting room, me, our business people, and four or five of their senior traders. I got up and said that I would describe what I saw them doing, based on the requirements, and that I would then throw it open to allow them to comment, to say that they did this other thing, or to say that they didn't do that, and so on.

    This was the most productive thing I could have done. They said I mostly had it right, but this potential (and seriously awkward) combination of things didn't happen because it didn't make any sense from their point of view.

    So the lesson today, boys and girls, is that there is no substitute for talking to the client directly yourself. It isn't always necessary, but in the real world, it is often very, very important to be able to do this.

  • (disco)

    Somehow I think this flowchart is standard practice for selling ERP project.

    Cannot detect where is the :wtf: .

  • (disco) in reply to Quite
    Quite:
    I'm sorry, I really can't see where the problem is.
    Have you tried to actually *read* the diagram? It makes no fucking sense to me at all. The executive notification thing in bottom is a result of *both* the very first step *and* one of possible third steps. *Aaand*, through different wording, the other result of "yes" is *also* sending notifications! Not to mention that nowhere it says *how many* yes/no answers are needed for either reaction.

    The only way I can think of why it doesn't make you go all :wtf: :doing_it_wrong: :angry: is that the diagrams you encounter at your work are usually far worse.

  • (disco) in reply to skotl
    skotl:
    I did have an guy say to me once; "A picture says more than a thousand words, but sometimes you also need the thousand words" - he was a wise man...

    One word paints more than a thousand pictures. Easily.

  • (disco) in reply to gleemonk
    gleemonk:
    One word paints more than a thousand pictures. Easily.

    Like the word "money" in "I'll pay you money to paint more than a thousand pictures"?

  • (disco) in reply to Onyx
    Onyx:
    Like the word "money" in "I'll pay you money to paint more than a thousand pictures"?

    Well yes in the sense that the word "money" will paint a thousand pictures in the brain of the hopeful receiver which will then act on this incentive. Words are productive man.

  • (disco) in reply to JBert
    JBert:
    A picture says more than a thousand words, so what we have here is a rather wordy requirements document. Too bad it's all the bad words.

    Five hundred words for you. Five hundred for me. Five hundred for PM. Five hundred for management. Five hundred for QA.

    You need some actual words to ensure everyone is thinking the same thing based on your picture.

  • (disco)

    We would prefer our awful requirements be delivered that way.

    Instead, we at WtfCorp have 50-page documents that still don't include basic information. The sole purpose of a document that long appears to be to allow changes to be snuck in during clarifying revisions without telling the developer about them.

    The interesting thing is that a lot of terminology and the specifics of the flow leads me to believe this is one of our sister divisions in the same company. 'Knock up against' is a WtfCorpism for 'use this handy lookup table!'

  • (disco)

    This reminds me of something mildly tangential but perhaps connected in the inane-request area...

    I had a fairly standard requirement for a report to be spec'd. I wasn't sure why they wanted me to spec a report where they knew they wanted a table, and they knew what columns they wanted, or why I was writing a spec for something I was going to be developing, but they didn't make me do much work so I put up with their incoherence.

    I sent them a list of fields, which they should have been able to recognise and got back a response at the standard level of meaninglessness I had come to expect from my company: my manager asked me to 'sketch' an example report. Not really sure why he used the word 'sketch', or why anyone needed an example report, when the people who wanted it had access to the spreadsheets from which they could discern the data. Basically I didn't know what I could provide that they didn't already have.

    So I fell back on being literal and pedantic in an attempt to grant the request. I drew - on paper - a sketch of a table. My manager's response (either he described my way of doing it as 'interesting' or 'novel' or something) indicated he wasn't expecting what I gave him, so I assume a sample spreadsheet would have sufficed, but given that they all handled spreadsheets, and I handled code, I genuinely don't know why I was doing the work. Otherwise the sketch seemed to be enough for their needs.

    Apart from the lack of backchat and snark on my part, my only regret is not including wooden table photography when the opportunity had presented itself.

  • (disco) in reply to Shoreline
    Shoreline:
    sketch

    That's easy, he clearly wanted you to act out a short comedy routine.

  • (disco) in reply to Weng
    Weng:
    'Knock up against' is a WtfCorpism

    That's better than "suck it off [as in, retrieve from a website]" a former boss used.

  • (disco) in reply to ixvedeusi
    ixvedeusi:
    Requirements document? What kind of fancy newfangled thing is that?

    You mean sometimes they actually write down what they want? This technology is too advanced for me. I'll stick to getting vague verbal requests, thank you.

  • (disco) in reply to Fox
    Fox:
    You mean sometimes they actually write down what they want?
    He means that sometimes they write *something* down. It's rarely what they want, though.
  • (disco) in reply to FrostCat
    FrostCat:
    That's better than "suck it off [as in, retrieve from a website]" a former boss used.

    Or "Give it a reach-around" for when you find a way to work around a problem.

  • (disco)

    I had to tell my (female, young-middle-aged) boss (during a high-level requirements and project kick-off meeting) that Customer User Management was not a good name for a project. Why? What's wrong with CUM as an acronym? Google it, I suggested. Having done so, "Oh my GOD!" she screamed down the telephone at a meeting-room of engineers rolling around the room in hysterical giggles like the crowd scene in Life of Brian.

  • (disco) in reply to Gaska

    If you're PM for ERP project and taking requirement from the clients, the process has to go exactly this way.

    ERP is also about the change of organization structure, so it's standard practice that the "question" and "result" has to be sent to executive level of the client. And after "the changes to be made" is determined, they have to check them with legal dept to avoid potential legal problem, especially when some of the department need to be disbanded and people need to be fired. Some staffs who cannot legally be fired need to be transferred to other departments, and for some countries there are laws about whether you can legally layoff people too.

  • (disco) in reply to hungrier
    hungrier:
    Shoreline:
    sketch

    That's easy, he clearly wanted you to act out a short comedy routine.

    AKA a "user story".

  • (disco) in reply to skotl

    "A picture says more than a thousand words." I should hope so; the illustration in this article uses more than six thousand.

  • (disco) in reply to Watson
    Watson:
    "A picture says more than a thousand words." I should hope so; the illustration in this article uses more than six thousand.
    hungrier:
    short comedy routine

    He's here all week.

  • (disco) in reply to cheong
    cheong:
    If you're PM for ERP project and taking requirement from the clients, the process has to go exactly this way.
    The word "exactly" sounds very funny in the context of extremely vague description of the steps of algorithm.
  • (disco) in reply to Gaska

    "Exact" in the essence that each step need to be reported to executive level, and questions produce more questions, price beefy if more customization is needed and standard pricing if no customization is needed.

  • (disco) in reply to cheong
    cheong:
    "Exact" in the essence that each step need to be reported to executive level
    Which is stupid in itself, because if I understand correctly, the choices in second step are non-binding until the full procedure has been completed, and it takes about two minuted from start to end. The intermediate reports would be just spam no one reads - kinda like all devs in our 60-man project get emails if any CI job fails - and since jobs are organized in hierarchy, we get emails for the job itself, its parent job, *its* parent job, and finally the main job itself. Possibly more emails if more children jobs fails (and boy, they fail a lot - mostly due to things like unreachable SVN server). We have about 30 branches, where for each branch, with only 2-6 people caring about any particular one.
    cheong:
    and questions produce more questions
    When the questions end? Do they even end at all? The diagram doesn't say anything about it.
  • (disco) in reply to Gaska
    Gaska:
    The intermediate reports would be just spam no one reads

    This. Producing lots of reporting that nobody will ever read is a good way to stop people from reading the bits of reporting that must be read.

  • (disco) in reply to Gaska
    Gaska:
    Which is stupid in itself, because if I understand correctly, the choices in second step are non-binding until the full procedure has been completed, and it takes about two minuted from start to end. The intermediate reports would be just spam no one reads - kinda like all devs in our 60-man project get emails if any CI job fails - and since jobs are organized in hierarchy, we get emails for the job itself, its parent job, *its* parent job, and finally the main job itself. Possibly more emails if more children jobs fails (and boy, they fail a lot - mostly due to things like unreachable SVN server). We have about 30 branches, where for each branch, with only 2-6 people caring about any particular one.
    True if it's ordinary project, but if it's ERP proposal, it's kind of expected that at some stage it'll face objection from the executive because their "power" will be affected. (especially in cases whether departments will be split and merged. So if they're sane, they will read each and every reports on topics related to them.

    In the ERP project I've participated in the past, the PM have to seek final judgement from their boss to nail the final proposal.

    Gaska:
    When the questions end? Do they even end at all? The diagram doesn't say anything about it.
    Those question are standard questions on what kind of customization can be made. If you read the word in flowchart carefully, their will only be more questions if "yes" has been responded. That means the question themselves is finite. (Compare with what we do in normal requirement taking, where we usually stop asking question when "yes" is responded because that means the client's expectation meets our expectation)
  • (disco) in reply to Matt_Westwood
    Matt_Westwood:
    Customer User Management

    Ours was the Customizable User Managed Management Interface Negotiation Generator project. Nobody came.

  • (disco) in reply to cheong
    cheong:
    True if it's ordinary project, but if it's ERP proposal, it's kind of expected that at some stage it'll face objection from the executive because their "power" will be affected. (especially in cases whether departments will be split and merged. So if they're sane, they will read each and every reports on topics related to them.
    But why make it two reports instead of one, when they contain exactly the same information, the latter makes the former obsolete the instant it's generated, and they're being made at most five minutes apart?
    cheong:
    Those question are standard questions on what kind of customization can be made.
    ISO standard? Industry standard? Standard in our upcoming brand of products? Maybe I simply lack domain expertise, but I have no idea what kind of questions these are if all I know is "they're standard" and "there's 5-7 of them". BTW, how can it be standard questions if they don't know how many there are?
    cheong:
    If you read the word in flowchart carefully, their will only be more questions if "yes" has been responded.
    That's not careful reading, that's educated guess.
    cheong:
    Compare with what we do in normal requirement taking, where we usually stop asking question when "yes" is responded because that means the client's expectation meets our expectation
    The major difference is that, if I educatedly-guess correctly, the result is the same no matter how many "No" answers are given to how many questions, and only if all of them are "Yes", there's different reaction from the system. Which raises further concerns about the design - why are there multiple questions if the result is binary?
  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    Ours was the Customizable User Managed Management Interface Negotiation Generator project. Nobody came.

    The bad jokes thread is :arrows:.

  • (disco) in reply to Gaska

    [quote="Gaska, post:40, topic:52906] But why make it two reports instead of one, when they contain exactly the same information, the latter makes the former obsolete the instant it's generated, and they're being made at most five minutes apart? [/quote] The first one is the proposed change to be discuss so that objection can raise, the second one is actual result.

    [quote="Gaska, post:40, topic:52906] ISO standard? Industry standard? Standard in our upcoming brand of products? Maybe I simply lack domain expertise, but I have no idea what kind of questions these are if all I know is "they're standard" and "there's 5-7 of them". BTW, how can it be standard questions if they don't know how many there are? [/quote] If you seen any ERP software like SAP, they have huge amount of customizable modules for you. Each "Yes" denotes one or more of these module is applicable, and need more questions to see which of them should be chosen and price-quoted in the project.

    And when you held a "requirement taking" meeting to your customer, you won't present "dictionary thick" sheets of questions to them. Instead, you tell them you have "a manageable number" of questions like 10 or 20 to ask in the meeting, then add applicable questions as follow-up questions. If not, you'll just scare them away and they'll send people "who don't have right to decide" to talk with you, resulting in much much slower progress.

    So in the case of ERP requirement taking, I see there is no :wtf: in the flowchart.

  • (disco) in reply to cheong
    cheong:
    The first one is the proposed change to be discuss so that objection can raise, the second one is actual result.
    This makes sense, but only if the procedure takes hours or days. As it is, the first impression is that the first is totally unnecessary.
    cheong:
    If you seen any ERP software like SAP, they have huge amount of customizable modules for you. Each "Yes" denotes one or more of these module is applicable, and need more questions to see which of them should be chosen and price-quoted in the project.

    And when you held a "requirement taking" meeting to your customer, you won't present "dictionary thick" sheets of questions to them. Instead, you tell them you have "a manageable number" of questions like 10 or 20 to ask in the meeting, then add applicable questions as follow-up questions. If not, you'll just scare them away and they'll send people "who don't have right to decide" to talk with you, resulting in much much slower progress.

    OK, so if I understand this correctly, each "yes" generates more questions, but after "no" there are potentially more questions which might be answered "yes". In other words, it's not "all or nothing", and the middle steps repeat over several times. This is ***NOT*** what the graph says.
  • (disco) in reply to cheong
    cheong:
    Instead, you tell them you have "a manageable number" of questions like 10 or 20 to ask in the meeting, then add applicable questions as follow-up questions. If not, you'll just scare them away and they'll send people "who don't have right to decide" to talk with you, resulting in much much slower progress.

    Either you get to deal with people who can decide, or you get to deal with people who know what's actually going on. With SAP, you're inevitably talking about understanding how the business works, and that's often really complicated in practice (and pretty much inevitably includes some crucial bits that management know nothing about, such how some admin people are avoided in person because of their personal hygiene problems).

  • (disco) in reply to Gaska
    Gaska:
    OK, so if I understand this correctly, each "yes" generates more questions, but after "no" there are potentially more questions which might be answered "yes". In other words, it's not "all or nothing", and the middle steps repeat over several times. This is NOT what the graph says.
    No. Any "No" in reply eliminate a whole question tree.

    Consider how the game "web genie" eliminates wrong answer.

  • (disco) in reply to cheong
    cheong:
    Any "No" in reply eliminate a whole question tree.

    You're thinking logic. Think sales. Any “No” means that you need to change a few words for synonyms and ask again.

  • (disco) in reply to Gaska

    Well it didn't look too bad to me either, but I suspect that was because my self-preservation matrix kicked in and killed the process before I could attempt to comprehend the diagram.

  • (disco) in reply to cheong
    cheong:
    No. Any "No" in reply eliminate a whole question tree.
    So does "Yes". But the diagram says nothing about any trees, wooden or otherwise. You can only understand this diagram because you already know what it's supposed to say.

    BTW, look at the redundancy in the diagram. Second box says "if Yes one path, if No a different path". From this, we have two arrows going different ways - one labelled "No's", the other labeled "Yes" (note that "No's" is plural and "Yes" is singular). Then, in the box after "Yes" (not the notification, the other one), it says "Yes's will result in additional questions for each of the original questions". So, there are three places in the diagram which says what action should be taken immediately after getting answer, and all of them mention different - and, under some possible interpretations, conflicting - results.

  • (disco) in reply to Gaska

    Yup, the flowchart didn't state things clearly to be this way. This is just my personal interpretation based one mapping of my personal experience to make some sense out of it. Nothing guarantee sanity to the actual process. :stuck_out_tongue:

  • (disco) in reply to cheong

    It's nice that after nearly 40 posts, you finally admitted you weren't actually reading any of this from the specification.

  • (disco) in reply to rc4

    Yeah, I don't think you should ever knock up a customer, alimony can be a quite costly thing and in most cases defeats the purpose.

    @Maciejasjmj, hope tour saying that everybody's fuckable doesn't mean you utilize this technique. :stuck_out_tongue:

  • (disco) in reply to skotl
    skotl:
    I did have an guy say to me once; "A picture says more than a thousand words, but sometimes you also need the thousand words" - he was a wise man

    Yeah, it's Wordpress that teaches this to people (default post on fresh install), so, as usual, TR :wtf: is PHP.

  • (disco) in reply to Gaska

    FYI, I said in my first reply that "I think this flowchart is standard practice for selling ERP project. Cannot detect where is the WTF."

    My following arguments are all based on assumption that "it were really an ERP project".

Leave a comment on “Be Thankful for Good Requirements”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article