People struggle with how to specify software. Many Owner/Managers are visually inclined and only see the “big picture”. To help our clients with specifying software requirements we draw screens. This way we can quickly tell if we are on the right track to delivering software they need. As most people we talk to are not programmers this is a very quick way of creating dialog.
Archive for the Blog Category
To the user the Interface is the software, how it works, looks and feels is what they are looking for. Unfortunately this is only 20% of the software, the other 80% is the rules behind the Interface. How to calculate x? What happens when? We use the interface to create rules and stories.
Rules are statements which are either true or false ie the email field should contain a valid email. They are usually easy to write and some times implied for example we all know that the Phone Number field should only take digits.
Stories are a little more complicated, this is when the user interface requires more than just rules. For example on story may be that when the validation rules fail the user is presented with the screen again with the errors highlighted in red.
The concept of stories comes from the agile manifesto, short sharp descriptions of a small piece of functionality. I believe it should be 1 dot point, no more than 3 sentences. If you cannot specify the functionality in 3 ideas then it’s too complicated and is more than one story. Keep it McKinsey way.
Pictures give you the 80% the customer is looking for, rules and stories give you the 80% you need to deliver something that does something and works. It’s the old 80/20 rule again.