Technically oriented samples from my time as a business analyst with "Acme Corporation" - pseudonym for a small company that is now more-or-less defunct:
UML Diagrams for a Teller Application
Specification and UI design for Data Dictionary Word function
The product described in these samples was regarded by many of us as the best system we never completed.
Below is an excerpt from a article ("Black Swan in Corner of Room") that describes the development of this system. The article appears on my blog (http://writerstories.blogspot.com/2008/12/black-swan-in-corner-of-room.html) and in my book "fear and loathing with bill and tom in NYC (notes from the underside)":
From 1998 to 2002 I worked as a Senior Business Analyst for Acme Corp (not the real name), a little company supplying tools and applications to the banking industry. At that time we were developing Business Portal, a collection of web-based applications and management tools. My job was gathering requirements for the Administrative channel.
Although none of us knew the term “Black Swan”, we had all been around. We had seen projects go awry because of unexpected events. However, most of us still believed that successful projects were possible if everybody - the managers, project leaders, architects, programmers, writers, and analysts just took their time and planned for everything.
Such an approach had several effects, all of them unexpected.
First was a prolonged period of “analysis paralysis”. Because everyone was afraid of getting the design wrong, nobody could agree on anything. We spent weeks and months fighting about basic architecture. Company management finally forced a decision, although by this time, the new technology on which our architecture was based was no longer new.
The second effect was the time it took to get specifications written. Still afraid that we would get something wrong, or miss something, design sessions were lengthy and contentious. Everyone stayed upset. Programmers resented detailed specifications that restricted their creativity, yet became angry if something was left out. As author of the specifications, I resented being resented.
In addition to these procedural Black Swans, there were also unexpected stumbling blocks resulting from off-the-cuff technical decisions. I don’t recall now exactly what these decisions were, although I do know that they were made with the best of intentions. For example, one day, standing in the hallway casually talking with a senior developer, the system architect decided that things would be better done this way instead of that way. It seemed a minor thing at the time, but as the programmers got into the revision, it was discovered that the entire system had to be reviewed. A month or more was added to the schedule. In another case, the senior web developer decided the system would look better with a new design. He was right, but the result was another delay in the schedule.
Months and then years passed. However, in spite of all the Black Swans, work did proceed and a quality product did emerge. The window of opportunity for selling the system was closing, but in the Fall of 2001, a potential customer had emerged, a big bank that would become the positive Black Swan to offset the previous negative Black Swans. The day finally arrived when all our executives and senior staff were to get on a plane and fly to Chicago to close the deal. Success, although not certain, seemed possible.
That day was 9/11/2001 – the day a very large Black Swan excreted over the entire world. Our flight was cancelled; the deal ultimately feel through, and within a year almost everyone was gone, leaving behind what many of us regarded as the best system we never completed.