The Daily WTF: Curious Perversions in Information Technology
Welcome to TDWTF Forums Sign in | Join | Help
in Search

Speechless moments

Last post 03-05-2012 9:53 PM by czedryk. 28 replies.
Page 1 of 1 (29 items)
Sort Posts: Previous Next
  • 03-02-2012 11:59 AM

    Speechless moments

    I haven't had many in my career, but this one just....

    quote:
    Note that the high-level requirements aren’t necessarily intended to be testable.

    *sob*

    (For context: I work in an industry where requirements and their traceability are very important.)

  • 03-02-2012 12:03 PM In reply to

    • Anketam
    • Top 150 Contributor
    • Joined on 10-12-2011
    • Nar Shaddaa
    • Posts 484

    Re: Speechless moments

    *pats too_many_usernames on the back*

    There, there, it will be ok.

    Project Manager: I don't know. I'm not allowed to talk directly to the customer. Apparently my grip on reality is too tight.
    - Weng
  • 03-02-2012 12:04 PM In reply to

    • boog
    • Top 500 Contributor
    • Joined on 10-07-2010
    • Earth
    • Posts 153

    Re: Speechless moments

    It sounds like one of your project's other high-level requirements is "ambiguity".  I suppose you can rest easy knowing it's being met.

    Set your fazers to WTF!
  • 03-02-2012 1:51 PM In reply to

    Re: Speechless moments

    I guess it depends on what "high level requirements" means. The fact that it's qualified at all would lead me to believe that it's something that needs clarification. High level requirements always seem more like objectives than actual, testable requirements.
    this post is bossy
  • 03-02-2012 2:52 PM In reply to

    Re: Speechless moments

    boomzilla:
    I guess it depends on what "high level requirements" means. The fact that it's qualified at all would lead me to believe that it's something that needs clarification. High level requirements always seem more like objectives than actual, testable requirements.
     

    It turns out this is essentially the problem.  While generally speaking our organization says that requirements must be testable, specific, etc., there is a concept of something that needs to be recorded but is not a "requirement" in this technical sense.  Rather than "objectives" a "feature request" might be a better label in this particular situation - basically when a customer says "hey can you do X?" without specifying all the details of what they mean by that.

  • 03-02-2012 2:57 PM In reply to

    Re: Speechless moments

    Our BAs always make requirement #1 an ultra vague one that describes the entire project in one sentence.  It makes traceability extra fun.  They also like to point back to this requirement as the source for anything they pull out of their butts six months later.  It never gets shot down because who's going to vote "decline" to the "H1: Make a web site" requirement of the web site project.

  • 03-02-2012 4:57 PM In reply to

    Re: Speechless moments

    boomzilla:
    I guess it depends on what "high level requirements" means...

    .... High level requirements always seem more like objectives than actual, testable requirements.

    That - if they're not testable, then it is unnecessary to satisfy those requirements - ergo, they're not required.

    Objectives, I can understand.

  • 03-02-2012 9:16 PM In reply to

    • ekolis
    • Top 100 Contributor
    • Joined on 01-09-2008
    • Cincinnati, OH, USA
    • Posts 600

    Re: Speechless moments

    Jaime:

    Our BAs always make requirement #1 an ultra vague one that describes the entire project in one sentence.  It makes traceability extra fun.  They also like to point back to this requirement as the source for anything they pull out of their butts six months later.  It never gets shot down because who's going to vote "decline" to the "H1: Make a web site" requirement of the web site project.

    But it IS a website already, so we've clearly satisfied that requirement! You never told me anything about said website being required to provide downloadable PDF's of the user's last six bank statements, or use corporate branding's stylesheets, or not rickroll the user when he clicks on the "contact us" link...
    I'm Spark Mandrill, and I'll... hey... can I... what, it BOUNCES?... 'kay, I'm splodin' now.
  • 03-02-2012 9:33 PM In reply to

    Re: Speechless moments

    ekolis:
    Jaime:

    Our BAs always make requirement #1 an ultra vague one that describes the entire project in one sentence.  It makes traceability extra fun.  They also like to point back to this requirement as the source for anything they pull out of their butts six months later.  It never gets shot down because who's going to vote "decline" to the "H1: Make a web site" requirement of the web site project.

    But it IS a website already, so we've clearly satisfied that requirement! You never told me anything about said website being required to provide downloadable PDF's of the user's last six bank statements, or use corporate branding's stylesheets, or not rickroll the user when he clicks on the "contact us" link...
    That comes in the detailed requirements, after our first draft estimate - which we cannot exceed by more than 10%.
  • 03-03-2012 12:32 AM In reply to

    Re: Speechless moments

    Can your jet aircraft conttrol software handle a cruise velocity of 299,000 kilometers per second?We want to be ready when ..

     

  • 03-03-2012 3:55 AM In reply to

    Re: Speechless moments

    ekolis:
    ... or not rickroll the user when he clicks on the "contact us" link...

    We come in peace.

    Contact Us.

  • 03-03-2012 5:27 AM In reply to

    Re: Speechless moments

    quote:
    Note that the high-level requirements aren’t necessarily intended to be testable.

    Maybe that's not quite as crazy as it first appears.

    I take the view that it's important that customer-initiated requirements are written in the customer's langauge, and can be compared by the customer against the delivered product during acceptance testing. These "high-level" requirements are invariably full of gaps and ambiguity, which makes them unsuitable as a complete and unambiguous specification. From an engineer's point of view, they're subjective and untestable.

    I generally solve this by working with the customer to translate them into "system requirements" (functional and non-functional), which are precise enough to be usable at system testing. The trade-off is usually one of readability, substituting detail for the "spirit" of the requirement, which is why you get the customer involved in doing the translation, and maintain a traceability matrix.

     

    TLDR: too much detail early on means the customer doesn't know what they're buying

  • 03-03-2012 8:27 AM In reply to

    Re: Speechless moments

    asquithea:
    From an engineer's point of view, they're subjective and untestable.

    From a tester's POV, there's no way to ascertain quality and provide assurance. From a PM's POV, vague requirements mean increased risk and cost, trying to fulfil an unclear scope, ie: chasing after ever-moving goalposts.

    From the business/supplier POV:  recipe for disaster. I think it was Ross Perot that highlighted how many organisations aren't completely clear about their own business processes - and if the customer doesn't fully understand how they themselves work, what hope does an external supplier have of providing an outsourced service?

    asquithea:
    I generally solve this by

    ... translating, refining and clarifying the requirements, basically.

    asquithea:
    TLDR: too much detail early on means the customer doesn't know what they're buying

    And the flipside: not enough detail means the customer is uncertain of what they actually want, but they'll happily allow you to waste time, effort and money developing something they don't want.

  • 03-04-2012 8:03 PM In reply to

    Re: Speechless moments

    too_many_usernames:

    I haven't had many in my career, but this one just....

    quote:
    Note that the high-level requirements aren’t necessarily intended to be testable.

    *sob*

    (For context: I work in an industry where requirements and their traceability are very important.)

    While there are sematic issues with the above, I believe it to be quite accurate (especially if one replaces "requirements" with "objectives"  as other have for easy of reading).

    For example "Imrpove efficiency"...this can be virtually impossible to test. Efficiency before and after may be measurable, but proving a single caual relationship can be virtually impossible. Not to mention that "testing" is usually done before deployment, and metrics such as these can not be gathered until a significant period of time has elapsed since deployment.

  • 03-05-2012 12:04 AM In reply to

    Re: Speechless moments

    Our senior executives once told us that 'Procedures should not always be followed'... WTF!!!

  • 03-05-2012 12:50 AM In reply to

    Re: Speechless moments

    czedryk:

    Our senior executives once told us that 'Procedures should not always be followed'... WTF!!!

     Blindly/Always following proceedures is the real WTF. There will inevitably be cases where the proceedure is not appropritate, and the correct action is to either modify the procedure (so that the new proceedure can be followed) or obtain an official waiver of the proceedure.

  • 03-05-2012 3:38 AM In reply to

    Re: Speechless moments

    TheCPUWizard:
    czedryk:

    Our senior executives once told us that 'Procedures should not always be followed'... WTF!!!

     Blindly/Always following proceedures is the real WTF. There will inevitably be cases where the proceedure is not appropritate, and the correct action is to either modify the procedure (so that the new proceedure can be followed) or obtain an official waiver of the proceedure.

    That. Procedures refactor the majority of situations, modelling expected output for usual input... but there are exceptions.

    The process docs should have some guidance to when the process doesn't apply, or when deviations require additional management engagement.

    "why didn't you use your initiative?"

    "nobody told me to..."

  • 03-05-2012 8:34 AM In reply to

    • erikal
    • Top 500 Contributor
    • Joined on 12-23-2011
    • Netherlands
    • Posts 137

    Re: Speechless moments

    Cassidy:

    "why didn't you use your initiative?"

    "nobody told me to..."

     

    Dangerous one that. The same people that demand initiative tend to let the whip lash when people show initiative "because they should have discussed about it first". Initiative really only exists outside of working hours, doing things on your own dime. IMO of course, or should I say "in my experience".

     

  • 03-05-2012 8:58 AM In reply to

    Re: Speechless moments

    erikal:
    Cassidy:
    "why didn't you use your initiative?"

    "nobody told me to..."

    Dangerous one that. The same people that demand initiative tend to let the whip lash when people show initiative "because they should have discussed about it first". Initiative really only exists outside of working hours, doing things on your own dime. IMO of course, or should I say "in my experience".

    I would have thought "using your initiative" meant bringing up these new ideas for improvement for discussion, not a cowboy implementation behind the team's and the customer's back. Of course, every situation is different, but there's nothing you said that's really incompatible with showing initiative in general.
    this post is bossy
  • 03-05-2012 9:14 AM In reply to

    Re: Speechless moments

    From a SQA perspective, all requirements need to be testable.  In general, a requirement needs to have the following attributes:

    • Correct (Does it satisfies input documents and applicable regulations, standards, etc?)
    • Consistent (Does is use standard language within doc and with input document?  Does it conflict with another req?)
    • Complete (Do all the requirements define the system as a whole?)
    • Accurate (Do the calculations and interfaces statisy the input documents accuracy requirements?)
    • Unambiguous (Is the requirement unique within the document and only have one interpretation?)
    • Testable (Does there exist some cost-effective process to confirm the product meets the requirement?)
    • Traceable (Both backward to input documents and foward via a unique reference?)

    Customer requirements whether they come from use cases or user requiements specs, need to follow these rules.  (Though I truely understand how difficult that is).  Other posters have touched on the reason.  If your contract is based on the user requirements, then the less fudge factor in them means more contractual arguments and more rework by the programmers without additional funds from change orders.

    In an ideal world, the user requirements would be the bid document and the programmers would provide a (functional/requirement/insert term here) spec to state what they will do to meet those user requirements.  When the programmers are rewarded the contract, it is this spec which is the contractual document.  This usually makes it easier to control costs and features.

    There are many industries that require this control: pharmaceutical, medical device, nuclear, aerospace, financial, etc.  However most don't get this lucky even within these industries.  That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

  • 03-05-2012 12:43 PM In reply to

    Re: Speechless moments

    TheCPUWizard:
    While there are sematic issues with the above, I believe it to be quite accurate (especially if one replaces "requirements" with "objectives"  as other have for easy of reading)

    DaarkWing:
    In general, a requirement needs to have the following attributes:

    Ohhh.. I like those. SMART++ ...?

    DaarkWing:
    That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

    I thought Agile was more about embracing change throughout the project lifecycle, rather than be a stickler for the original specs and thus deliver what the customer wanted then, rather than what the customer needs now - which suits the fast pace of IT-based projects (are you listening, 3D Realms?) Isn't there also something about the customer using prototypes early so reaping earier returns whilst continuing to refining it (spiral evolution?)

     

  • 03-05-2012 2:35 PM In reply to

    Re: Speechless moments

    Cassidy:

    DaarkWing:
    That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

    I thought Agile was more about embracing change throughout the project lifecycle, rather than be a stickler for the original specs and thus deliver what the customer wanted then, rather than what the customer needs now - which suits the fast pace of IT-based projects (are you listening, 3D Realms?) Isn't there also something about the customer using prototypes early so reaping earier returns whilst continuing to refining it (spiral evolution?)

    You are correct. That doesn't mean agile is always done correctly, but the idea is that hard-coded requirements often create an inferior product, outside of a few industries (medical, nuclear, warfare..) Users rarely know what they want up-front and specifying detailed requirements in-depth results in wasted time and incorrect requirements. Additionally, requirements evolve over time which is why it's important to get prototypes into user hands ASAP and then refine from there.
    God has cursed the blind.

    "I confess. I've always been a humorist. It is not an accident that the Flounder is usually shown with a smile."
  • 03-05-2012 2:52 PM In reply to

    Re: Speechless moments

    morbiuswilters:
    Cassidy:

    DaarkWing:
    That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

    I thought Agile was more about embracing change throughout the project lifecycle, rather than be a stickler for the original specs and thus deliver what the customer wanted then, rather than what the customer needs now - which suits the fast pace of IT-based projects (are you listening, 3D Realms?) Isn't there also something about the customer using prototypes early so reaping earier returns whilst continuing to refining it (spiral evolution?)

    You are correct. That doesn't mean agile is always done correctly, but the idea is that hard-coded requirements often create an inferior product, outside of a few industries (medical, nuclear, warfare..) Users rarely know what they want up-front and specifying detailed requirements in-depth results in wasted time and incorrect requirements. Additionally, requirements evolve over time which is why it's important to get prototypes into user hands ASAP and then refine from there.

    Correctly done, Agile does indeed capture all of the requirements. The primary difference being that they are captured "just in time" rather than at the begining of the project. The secondary difference is how they are captured. In most cases, it is by interacting with Iteration "n" that the requirements  for Iteration "n+1" are finalized. 

    A good rule of thumb, is that if "a requirement is captured" and then no specific action is taken on the requirement for a significant period of time (typically days), then the capture was too early. If the capture triggers "rework" (not refinement) of something that could have been avoided by earlier capture, then the capture was too late.

  • 03-05-2012 3:48 PM In reply to

    Re: Speechless moments

    TheCPUWizard:
    Correctly done, Agile does indeed capture all of the requirements.
    Where did I imply otherwise? Also, I've never seen all of the requirements for a project being captured. That's because projects adapt over time. If a piece of software is done, it's because nobody is using it any more.

    TheCPUWizard:
    If the capture triggers "rework" (not refinement) of something that could have been avoided by earlier capture, then the capture was too late.
    Wouldn't refactoring be rework? Refactoring is an integral part of agile. Also, you seem to still be of the impression that requirements don't change. All you're suggesting is capturing them on-the-fly rather than up-front; you still believe them to be static. Requirements change all of the time. A requirement triggering rework wasn't necessarily "captured late", it didn't even exist previously.
    God has cursed the blind.

    "I confess. I've always been a humorist. It is not an accident that the Flounder is usually shown with a smile."
  • 03-05-2012 3:56 PM In reply to

    Re: Speechless moments

    morbiuswilters:
    Also, I've never seen all of the requirements for a project being captured. That's because projects adapt over time. If a piece of software is done, it's because nobody is using it any more.
    It's also very difficult (impossible in all but the most trivial cases?) to foresee all if the issues you need to in order to fully capture the requirements.
    this post is bossy
  • 03-05-2012 4:56 PM In reply to

    Re: Speechless moments

    morbiuswilters:
    That doesn't mean agile is always done correctly...

    Additionally, requirements evolve over time which is why it's important to get prototypes into user hands ASAP and then refine from there.

    TheCPUWizard:
    Correctly done, Agile does indeed capture all of the requirements. The primary difference being that they are captured "just in time" rather than at the begining of the project.

    I think you've just agreed with Morbs there. Didn't know that part about "when" they're captured, though - I just took it as read that the requirements were treated as being fluid.

    boomzilla:
    It's also very difficult (impossible in all but the most trivial cases?) to foresee all if the issues you need to in order to fully capture the requirements.

    This was cited as a major drawback of waterfall (as well as the concept that reqs would never change throughout the project lifecycle) and spawned Agile, wasn't it?

  • 03-05-2012 5:32 PM In reply to

    Re: Speechless moments

    boomzilla:
    morbiuswilters:
    Also, I've never seen all of the requirements for a project being captured. That's because projects adapt over time. If a piece of software is done, it's because nobody is using it any more.
    It's also very difficult (impossible in all but the most trivial cases?) to foresee all if the issues you need to in order to fully capture the requirements.

    The point of Agile, is that you do not "foresee" them, as they become known, theyt get "captured".  But one can not write proper code, until one knows what the code is supposed to do; therefore the requirements must be captured at some point.

    ps: 100% agreement that software *might* be done when no one is using it anymore, but not always - consider systems that have been "retired" only to find that some critical piece of data needs to be retrieved, perhaps years later - I have made some very good money during my career doing such forensics on "extinct" systems.

  • 03-05-2012 6:46 PM In reply to

    Re: Speechless moments

    TheCPUWizard:
    ps: 100% agreement that software *might* be done when no one is using it anymore, but not always - consider systems that have been "retired" only to find that some critical piece of data needs to be retrieved, perhaps years later - I have made some very good money during my career doing such forensics on "extinct" systems.
    Too true.
    God has cursed the blind.

    "I confess. I've always been a humorist. It is not an accident that the Flounder is usually shown with a smile."
  • 03-05-2012 9:53 PM In reply to

    Re: Speechless moments

     Yes I agree that not all procedures should be followed blindly, that there are exceptions but if management saw that a certain procedure is not achieving its goal, why let it stay?

    But in our case, our procedure is working well. It's just that management is so focused in making the customers happy (sort of) by delivering softwares earlier than necessary by bypassing most of the development procedures that was implemented.

Page 1 of 1 (29 items)
Powered by Community Server (Non-Commercial Edition), by Telligent Systems