Posted by Keith Barrett on Fri, Feb 12, 2010 @ 09:15 AM
I can see the court room setting - the Business Analyst is on trial because the Business Client isn't happy with the software they just received. At first the Business told Development, "You didn't write the code correctly; the software doesn't do what we want." To which Development quickly said, "Our code is exactly to the requirements specification; it's not our fault." The Business Client then confronts the Business Analyst and says, "Show me the specification." To which the Business Analyst says, "Gladly, that's what I've been trying to do all along."
But here is where the problem occurs. In most organizations the requirements specification isn't "the truth, the whole truth, and nothing but the truth," instead it's a portion of truth in the Word document, and another portion of truth in the Visio diagrams, and another portion of truth in the prototype, and another portion in the spreadsheet. It is a series of disconnected pieces of information that may get bound together in a single document but the sources are separate and distinct from one another and often not in sync. As such, what ends up being bound together to appear as a "single version of truth" is really a bowl of spaghetti that's down-right impossible for the Business Client to digest.
Back to our crime scene - the Business Analyst reprints the 300 page specification and once again plops it on the desk of the Business Client. The Business Analyst then proclaims, "Had you read it from cover to cover and given me the feedback I needed early in the process, your software would be fine." Although this sounds like a good defense, it really isn't. It's flawed for two reasons: 1) it's extremely difficult for the human mind to digest a large amount of information, in a short and pressured timeframe. 2) It's even more difficult to piece together the many parts and pieces in order to truly see and understand the story being told. Yet this is what we ask the Business Client to do with the simple request - "just review my document".
The Business Client replies, "Oh yea, I remember that document, I did scan it, quickly, once, and it seemed okay. I tried to read it but there was so much in it and I couldn't really connect everything together in my mind's eye so I just trusted that you knew what I meant and signed it." The BusinessAnalyst snaps back, "But what about all those review sessions we had, in the conference rooms, where we walked through the document? The Business Client thinks for a moment, "Wait, that does sound familiar, but we had the same problem in the conference room as we did on our own. Even with the Business Analyst walking us through the document it was really hard to connect the dots. The Business Analyst would tell us to hold our finger on page 5 and flip to page 10 to see the business rule for this requirement, then flip to page 20 to see the screen that's related to it, then look at appendix "A" for the workflow diagram. You didn't really expect us to comprehend all that did you?"
Finally, the verdict is given - innocent!!
That's right, the Business Analyst is innocent of the crime because it was determined that they were doing the best that they could do with the sticks and stones they had been given to work with. It was determined that the Business Client provided the best feedback they could, given the time and pressures they were under, and that ultimately the blame fell on the shoulders of the mechanism, or medium, being used to communicate, not the author or reviewer of the story. As a result of this case, the Business Client declared a document free zone, instead of a penalty, and the Business Analysts were provided with tools that allowed them to not only author the many elements of the story in one central location, but review and validate the story in a contextually rich and visual manner that brought high praise, and great feedback, from the Business Client.
Unfortunately the "courtroom trial" portion of this scenario happens on a regular basis in most IT shops. The good news is, with today's technology it is possible to change the medium from big thick documents full of disparate parts and pieces, to visually oriented simulations, that walk through the story in a quick and simple way, so the Business Client can wrap their head around the story and provide the feedback so badly needed early in the process.
Read more about the requirements problem
Read about the most popular requirements workbench
Posted by Tony Higgins on Fri, Jan 22, 2010 @ 08:43 AM
It's one thing to see the latest unemployment statistics on the nightly news but quite another to sit down for a coffee with your brother-in-law who just lost his job. Hearing weather reports of continued freezing temperatures in the south-eastern US is certainly of interest, but it doesn't hit home until you see the segment on the tropical fish-farmer whose family business was all but wiped out in just a few days. Statistics are necessary and useful for analysis, but to really appreciate their meaning - what they translate into ‘on the ground' - you need a few tangible examples.
If you're in the software industry - and I presume you are if you're reading this blog post - then you're well aware of software failure statistics. Seeing these statistics over and over you can get somewhat numb and the numbers become nothing more than, well, numbers. To help remember what these statistics really mean here are some lists of real software failures & issues.
While reading through these remember the findings of a 2006 report1 that found "accurately capturing system requirements is the major factor in the failure of 90% of large software projects,".
To get you started, here's one with a video showing the result of this requirements error:
Company: SAAB
System: JAS 39 Gripen. An advanced figher jet that requires computer control for stable flight.
What Happened: Instability during sixth test flight causes pilot to lose control and crash. Pilot fortunately walks away. Investigation revealed crash was due to a requirements error with the flight control system software. "the flight control system was doing what was specified but not what was required".
Complete Story Video
.. and a few more from SD Times:
"An early version of the Airbus crashed because the pilot could not wrest control away from the computer and restore the airplane to a safe altitude. The software developers apparently knew more about flying an airplane than the pilot."
"A laser-guided missile that depends on a forward ground crew that focuses the laser on a target will go to the coordinates of the laser beam. During the combat operations, the battery on the laser unit begins to fade. No problem. It is designed for a hot-swap capability. The software, however, was not designed for hot-swap and, without notifying the ground crew, resets the coordinates to origin after completing the hot-swap."
When the U.S. Federal Bureau of Investigation completed its Virtual Case File system in 2005, "Everyone looked and said, 'This is not something that we want,' " after seeing that it was incomplete and error prone. Consequently, the FBI had to answer to the U.S. Congress, which scrapped the project in January 2005. The government also failed to assess the cost of those additional requirements and the project cost soared to over US$100 million.
More real-life software failures & issues:
Software Horror Stories
Why Software Fails
History's Worst Software Bugs
Top Ten Corporate Information Technology Failures
Twenty Famous Software Disasters
ZDNet UK's list of top 10 IT Failures
1 - Davis, C.J.; Fuller, R.M; Tremblay, M.C.; Berndt, D. J. (2006) "Communication Challenges in Requirements Elicitation and the Use of the Repertory Grid Technique" Journal of Computer Information Systems. Vol.46, 5; p. 78.
