Posted by Karl O'Brien on Tue, Aug 31, 2010 @ 03:54 PM
So the first question would have to be, what does “done” look like? At what part of the requirements process do we go for the all important approval signature and hand over our masterpiece to the development and QA folks? Well don’t get me started on approval signatures, the business community will happily sign a document, as they know full well that if they asked for black and you gave them white, they can always change it later.
As BA’s, we have spent time with our stakeholders to discover what they would like the application to do. Pretty high level at first, we use our industry knowledge and analytical skills to document their needs in Business and Functional Requirements that take various forms from the written requirements, business flows to screen mockups and maybe even use cases. Traceability is a must in moderation, relating artifacts as they are decomposed as well as giving us the insight into impact analysis so that as future changes occur we can see what elements upstream and downstream are affected….but is that enough? I would say that it is a good start, but developers are still left with the task of interpreting these traced artifacts and developing code. There is still some room for interpretation and the quality folks need a way of unraveling all of this to create test cases so they can test not only the “happy path” of our well defined Use Cases but also the many alternate flows.
Simulation or visualization of the requirements can certainly help in overcoming this gap between BA speak and the developer’s interpretation of them. Showing a stakeholder what happens behind the scenes, even just the use case flows and showing them a simulation of the application before development starts has always been a huge benefit in finding gaps and confirming that you have captured their needs in their entirety. But don’t stop there; take advantage of this same visual media to communicate downstream to your developers and QA team. It is like watching a movie versus reading the book, everyone can interpret a book in many ways. If the author has not been descriptive about a certain aspect of a scene, the reader fills in the blanks and uses whatever colors they want; it is part of the pleasure of reading. However, a movie is different. A movie has to take into consideration every aspect of the scene, and the screen writer has to transform the author’s book and bring to life the words spoken, the scenery and the costumes. Nothing is really left to the viewer’s imagination.
So as you write those requirements and transform the business needs into fully developed requirements that can be easily taken, coded and tested from….think of great movies you have seen, take the time to set the scene, build the characters and really bring them to life via simulation.
Agilest…..maybe think about a short film or a series of skits.
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.
