In preparation for my next Open University module, I have invested in getting an early copy of the set book so that I can start working through it at a nice relaxed pace. The book itself – Mastering the Requirements Process (Robertson and Robertson) – is a renowned text that deals with the specification of requirements, primarily for use in the development of software systems.
The authors have provided the case study of a road de-icing system, which involves weather prediction and the scheduling of road de-icing trucks, to demonstrate their proposed process at each of the following stages:
- Setting the scope of the project;
- Investigating the nature of the problem;
- Devising the optimal solution;
- Defining the system requirements.
A fundamental belief that reoccurs throughout is that focus should primarily be on the real-world problem, stripping away any technology or implementation specific details. One of the many quotes illustrating this appears on page 225:
[Functional requirements] should be, as far as possible, expressed independently from any technology that will be used to implement them.
At work I have recently moved from developing lower level software implementations to designing and describing higher level system requirements, so have a real appreciation for how challenging this shift in focus can be. However, even with my relative inexperience in this area, I was quite surprised to see the following examples of functional requirements presented over on page 227:
The product shall accept a scheduling date.
The product shall warn if the scheduling date is neither today nor the next day.
A personal philosophy that I picked up during my undergraduate study was that software should, as far as possible, prevent the user from entering invalid data. I mean, how frustrating do you find it when a piece of software tells you that you have entered something wrong, when it could have prevented you from doing so in the first place?
For this reason, any decently designed user interface for the road de-icing system would, until very recently, probably have provided a date picker dialog box with the date range limited to today and tomorrow.
As user interfaces have become increasingly rich in recent years, and touchscreens more prevalent, a modern implementation of the system may actually look more similar to the Bing Weather application. This shows the weather for the next seven days in a single scrolling view, with the user swiping left and right to get the full forecast.
In either case, there is no need for the user to enter a date and certainly no need for a warning message to be displayed. As such, if I were asked to review a specification containing the two examples of requirements shown above, I would definitely have to question whether or not they are placing a constraint on the designers.
Although not professed as being a perfect solution, perhaps the starting point for a more implementation agnostic requirement would be:
The product shall provide a road de-icing schedule for the current day and the following day.
I believe that my observation here inadvertently adds weight to Robertson and Robertson’s core argument that requirements should be free of technological details, and I would not say that it tarnishes their outstanding work in any way.
From a personal perspective however, I do feel a slight sense of relief that even the subject matter experts have had difficulty in creating a functional requirement that does not raise questions.
DW.