The Requirement, The Whole Requirement and Nothing But the Requirement

An Exercise in Observation

Whilst working on a large automotive project to build an infotainment system in Germany during 1999-2000, I conducted an academic exercise in observation. I wanted to see how difficult it would be to capture the ‘real requirements’ for a hypothetical In­Car Email Dictation System.

So, I fitted a video camera to the dashboard of my car and asked 3 colleagues to drive round a pre­-specified route. Their objective was to ­dictate an email to an imaginary dictation system whilst driving the car. I filmed all 3 attempts and transcripted the videos:-­

[Engine starts running]
Hi…[engage clutch][change gear] errr…I would like to send
[1 sec pause] an email [change gear][look in rear view mirror]…errr…
I would like to send an email [2 sec pause] to Mary to tell her…[brake as approach turn­off]
[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] [1 sec 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:

Pauses: do these mark the end of a phrase or sentence? Repetition: does the user mean to repeat? 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 / her life depended on it).

When I showed the video to my project manager, we both decided that email dictation systems posed a challenge since the requirements were much more difficult than we had imagined.

Now, if we apply this to a project where you are looking to improve process efficiency, it would be wise to not 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.

Business Analysts must take care to observe the ‘real’ requirements. What stakeholders say may not be the same as what they do.

Another Example: UK Mortgage Application Process

Business Rule:­ A mortgage loan of a given borrower can only be secured by securities that are owned by the given borrower.

From the above UML fragment, we see that a MortgageLoan is associated to a Property (which it views as it’s Security) and to a Borrower (which the MortgageLoan views as the Customer of the bank). The Property views the Borrower as the Owner. There are different types of MortgageLoan: namely, InterestOnly and Repayment.

The business rule above may need reading a few times to fully understand it. We realised in fact that this statement alone may not be correctly interpreted by our development team, so we decided to break it down further using OCL, the Object Constraint Language:-

The OCL statement says basically what the business rule above says, but in a less ambiguous way, which is less open to misinterpretation by the development engineers. In fact, we 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).

context MortgageLoan 
inv onlyOwnedSecurities: 
security.owner­>forAll(owner | owner = customer)

Conclusion

It is wise to use whatever techniques we can to discover the ‘real’ requirements and business rules before embarking on development. Videoed observation is a key technique that allows us to see what is really happening in a business process. After all, the camera never lies.