While working on a large automotive project to build infotainment systems in Germany during 2000, I conducted an academic exercise in observation. I wanted to see just how difficult it would be to capture the real requirements for a hypothetical incar email dictation system.
I fitted a video camera to the dashboard of my car and asked three colleagues to take turns to drive around a prespecified route in and around Hildesheim, near Hannover, including traffic lights, hills and turns. The objective was simple: dictate an email to an imaginary dictation system while driving the car. How difficult could that be?
I filmed all three attempts and transcribed the videos; what I got was the following:
[Engine starts running] Hi...[engage clutch] [change gear] errr...I would like to send [one second pause] an email [change gear][look in rear view mirror]...errr...I would like to send an email [two second pause] to Mary to tell her...[brake as approach turnoff][down a gear]. This is an email for Mary [up a gear][accelerate] just to tell her [change gear]...errr...that I will be late home tonight [down a gear for upcoming ascent] [one second pause]....errr..... so please don’t wait up [brake][down a gear], as I have a meeting running late so please don’t wait for me [down a gear][decelerate][turn left]...
From the transcripts, it became clear that the system would have to be very smart to make sense of the above.....garbage...!
The transcripts contained:
1. Pauses: do these mark the end of a phrase or sentence?
2. Repetition: does the user mean to repeat?
3. Words which are not really words, such as 'errrr', 'ummm' and 'ahhh'.
It was obvious that the driver was much more concerned with driving the car than dictating the email (quite normal considering his or her life depended on it). When I showed the video to my project manager, we both decided that email dictation systems posed a real challenge since the requirements were much more difficult than we had imagined.
So, if we apply this to a typical project where you are looking to improve process efficiency, it would be wise to never take for granted what our business stakeholders tell us. It will always be safer to carry out pure observation (just as above) to ensure we have the right data regarding how long a process takes, for example, (and therefore the 'real requirements') before starting out on implementation.
Anyone who has had the experience of delivering a presentation while being filmed probably knows that this can be an excruciating ordeal—after all, the camera never lies. You can see for yourself all your faults: speaking too fast, beginning every sentence with 'umm', putting your hands in your pockets, and so on. If we can learn this much about ourselves from watching a video, just think what we can learn about the 'real' behavior of our stakeholders (as opposed to their perceived behavior).
UK Mortage Application Process
In 2005, I worked on a project to create an online system for the mortgage application process of a UK bank. Some of our colleagues were located with the client and held multihour workshops to understand their requirements. The UK mortgage application process can be complex and we were perplexed by some of the business rules. The fragment of UML below recreates a typical scenario from that sector. The business rule is stated below it.
Business Rule: A mortgage loan of a given borrower can only be secured
by securities that are owned by the given borrower.
From the UML fragment, we see that a mortgage loan is associated to a property (which it views as its security) and to a borrower (which the mortgage loan views as the customer of the bank). The property views the borrower as the owner. There are different types of mortgage loans: namely, interest only and repayment.
The business rule above may need reading a few times to fully understand it. We realized that this statement alone may not be correctly interpreted by our development team. We decided to break it down further:
Context MortgageLoan
inv onlyOwnedSecurities:
security.owner>forAll(owner | owner = customer)
So we decided to convert many of the business rules and requirements into a declarative language that is fully contained within UML: the Object Constraint Language (OCL).
Now, my background happens to be in formal languages, so I was keen to put that knowledge to good use to break down the English language statements into something more easily convertible into a development language. The resulting OCL formalized the English language requirements and business rules to avoid ambiguity. In fact, I found that this process often unearthed problems early on, well before they reached development. Many times, we had to go back to the business to clarify specific aspects (and sometimes even they were not sure).
The Software Engineering Institute claims that '6080% of the cost of software development is in rework'. This is an indication that business analysts are not spending enough time refining the requirements and business rules before starting development.
Conclusion
It is wise to use whatever techniques we can to discover the 'real' requirements and business rules before embarking on development. We all seem to know that it is cheaper to fix problems earlier rather than later in an IT project. So why do so many of our projects exhibit the same mistakes?
Author: Manoj Phatak is the founder and director of product development at Domoticware S.L.U. (Spain) and Senior Business Analysis instructor with ESI International. Through ESI International, Manoj trains Fortune 500 clients across Europe, the Middle East and Latin America in product requirements modeling, UMLbased CASE tools and stakeholder management, with the aim of reducing project development costs and driving customercentric innovation. Manoj has developed softwareintensive technologies for the semiconductor, telecommunications, automotive, e government and financial sectors since 1990. He is a Chartered Engineer at the UK Engineering Council, a member of the International Institute of Business Analysis (IIBA) and Chartered IT Practitioner at the BCS. Manoj holds degrees in Electronics Engineering from Southampton University and in Software Engineering from Oxford University. Visit http://www.esi-intl.co.uk/