How we often, naively, design software wrong…

So we are working for a theoretical customer; who at the start of the project has outlined the following requirements.

We issue all our employees with one parking permit and would like to be able to monitor who uses our company carpark. This is so we can monitor the number of employees driving to work, and how this affects our carbon neutral status.

Great! I will design a simple database application. So I set about designing the database, where I have two simple entities. I want to record information about; a permit and an event. Let’s assume that each person will receive one permit, this permit will then be used in multiple vehicles. Each time a permit is detected by our car park hardware, an event is created to record the entry or exit.

So, has what we created fulfilled the requirements? Yes. We can monitor who is using the car park, we can see who has entered and exited, and even calculate the number of cars present during a particular time period. We can see which permit is being used the most, and other interesting facts about a permit and it’s related events.

However, the customer, has not given us the clearest of requirements and has told us that they actually want to be able to report on Car Make, Car Model, Engine Size and Fuel Type. These will form part of a management report that is looking at how often employees drive to work, and the potential emissions from their vehicle by combining the employee’s address details and the eco credentials of the vehicle.

So there are two lessons here:

1. Ensure you gather requirements in the most detailed manner, and if you are unsure always ask detailed, constructive and open ended questions. Try not to make assumptions.
2. When gathering software requirements, always ask ‘Why?’. Why do you need that information? Why do you need that particular field? A lot of the time the customer will reply ‘We want to be able to report on it’ or ‘We need it as part of a set of statistics that we send to XYZ’.

This leads nicely into the area of report driven design. Report driven design focuses on what the customer is trying to report on, in our example if the customer had told us that they wanted to record more detailed vehicle information to calculate emissions information these fields could have been included in the early development, testing and release stages. We should have asked the question ‘What affects the carbon neutral status, when it comes to employee car parking?’. In the above example we have made the assumption that all we need to store is the permit and event details to calculate the reports we assumed the customer wanted.