Iterative divide-and-conquer will eventually leave the designer with pages defining single, possibly indivisible, pieces of functionality. It doesn’t matter if the subject is a user interface, business functionality or anything else – the approach is similar.
I will often use a bullet point list to outline the functionality provided. Once I am happy that I have covered all aspects, I use a uSDLC command to split the list into separate sections. The list becomes the title pointing to an instrumentation addendum.
Add only a small amount of text to each section. Just say enough to explain the functionality, just as if you were discussing it with the project visionary or business analyst. Most of the description, detail and restrictions are in the instrumentation section – information that is readable to both the business representatives and the computer.
An example may make it clearer. The first page we are likely to tackle on a web-based system would be for authorisation and authentication. On that page, the first section is likely to describe each type of user the system will cater for. On a large system, this would be a page in its own right.
For development to go ahead we need a set of users – for both manual and automatic testing. The groups are the same as for production use. A user in the test group can do special actions, but cannot, by design, change production data.
create group 'administrator' create group 'operator' create group 'test' create user admin, groups: 'test', 'administrator', 'operator' create user oper, groups: 'test', 'operator' create user test, groups: 'test', 'administrator', 'operator'
As you can see above, the prose is to help the reader understand what we are trying to do. The instrumentation is human readable. It not only clearly defines the system, but understood by anyone with domain knowledge. A business owner may look at it and note that we need an operations manager.
Once the interested parties give iterative feedback, have them sign – in blood preferably. The instrumentation will drive the newly created system. It should describe functionality, restrictions and edge cases where they are known. Whatever it says, the system will do – feedback is king. When the customer comes back later and complains that the system doesn’t do Y, it is easy to prove whether Y was ever accounted for – and if it was it works or the instrumentation will fail.
The next article will extend the above example, while the one after that will discuss how to turn instrumentation into something your application will understand.