Speechless moments



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

    @quote said:

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



  • *pats too_many_usernames on the back*

    There, there, it will be ok.



  • 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.


  • ♿ (Parody)

    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.



  • @boomzilla said:

    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.



  • 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.



  • @boomzilla said:

    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.



  • @Jaime said:

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



  • @ekolis said:

    @Jaime said:

    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%.



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

     



  • @ekolis said:

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

    We come in peace.

    Contact Us.



  • @quote said:

    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 [i]by the customer[/i] 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



  • @asquithea said:

    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 said:

    I generally solve this by

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

    @asquithea said:

    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.



  • @too_many_usernames said:

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

    @quote said:

    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.



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



  • @czedryk said:

    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.



  • @TheCPUWizard said:

    @czedryk said:

    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..."



  • @Cassidy said:

    "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".

     


  • ♿ (Parody)

    @erikal said:

    @Cassidy said:
    "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.



  • 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.



  • @TheCPUWizard said:

    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 said:

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

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

    @DaarkWing said:

    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?)

     



  • @Cassidy said:

    @DaarkWing said:

    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.



  • @morbiuswilters said:

    @Cassidy said:

    @DaarkWing said:

    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.



  • @TheCPUWizard said:

    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 said:

    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.


  • ♿ (Parody)

    @morbiuswilters said:

    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.



  • @morbiuswilters said:

    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 said:

    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 said:

    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?



  • @boomzilla said:

    @morbiuswilters said:
    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.



  • @TheCPUWizard said:

    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.



  •  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.


Log in to reply