It has been said that a journey of a thousand miles begins with a single step. However, unless you have a compass and a map, those first few steps are unlikely to get you nearer your destination. However, following the map without question may also fail to get you to your destination. There have been a number of cases where truck drivers have blocked traffic by ignoring clearly marked height and weight restrictions. The police have been generally unimpressed by the statement that the driver had to keep going because that was what Google Maps or Mapquest told him to do so.
When creating a software application, the requirements document can serve as a map showing your destination and how far you have to go. However, there can be problems.
- I have encountered people who ask what we have to do so that we can declare the requirement has been satisfied. My attitude is that you look for what has to be done to satisfy the requirement. (Some people really don’t see a difference.) They assume that they can convince the user that the requirement has been met, even though it hasn’t. If the statement comes from your manager, you may not have much of a choice, but don’t be surprised when the user isn’t happy. If you can’t meet a requirement, you have to deal with it. Determine the impact of not meeting the requirement and see what you can do to either meet the requirement or reduce the impact of not meeting the requirement. At the very least, don’t let it catch him by surprise. (Surprises are very unpopular.) The user may decide that the requirement can be eliminated or replaced with with something else.
- In addition to the requirements in the document, there are many implied requirements. These are the requirements that seem so obvious, they don’t need to be said. However, that being said, it is probably best that they are said, and you should consider adding them to the requirements list. An example might be having electrical power and an internet connection where the computers are to be located. Even if it isn’t your requirement, it is somebody’s requirement. (When I informed one user that I couldn’t install a computer system because there was no internet connection in their building, they informed me that I should stop by the stock room on the way over and pick one up. This is the equivalent to installing an electrical outlet without having it hooked up to power.)
When I look at an application, I think about the abilities of the software. Whether or not they are in the formal requirements document, you want to think about these things. I have listed a few of the items below, and you may find these items useful.
I’m not a perfectionist when it comes to user demands. I merely desire a close enough approximation so that the user can’t tell the difference. It’s actually easier than you think.
- Capability – There is something that the software is supposed to do. Does the software have the capability to do it?
- Usability – Is the user able to use the software to do his work? Does the software have built-in documentation, or does he need to have a manual ready when he uses it? (If the user needs to have a few manuals sitting next to him, that says something about the lack of usability.)
- Flexibility – Does the user have to change how he does work in order to use the software? Can different users operate the system in ways that are convenient for them?
- Likability – Does the user feel comfortable using the software? After a few hours, do you hear screams of despair from his cubicle accompanied by the sounds of breaking pottery? (I am speaking quite literally here.)
- Verifiability – After carrying out a task, is the user able to verify that he did it correctly? This will go a long way towards user satisfaction.
- Reliability – Will the system be available when the user wants it?
Things will go wrong from time to time. If the system can’t be fixed, expect problems.
- Understandability – Can the people who maintain the system understand how it works? Is it well documented, including the source code and the instructions for the software builds?
- Traceability – If something goes wrong, can the people maintaining the system identify the piece of code causing the problem?
- Audit-ability – Can the people who maintain the system verify that it is actually doing what it is supposed to be doing? If it isn’t doing the right thing, can they determine what it is actually doing? If there are operational problems, are the operators informed or must they wait for the sound of angry users?
- Restorability – If the system crashes, can it be restarted? Can it be verified that the restart doesn’t introduce errors?
- Survivability – If unexpected events occur, will the system keep running? What happens when there are network problems or an unexpected load on the system?
- Administrate-ability – Can the operator make administrative changes to the system or do they require changes to the code?
- Isolatability – Can changes be tested on a test platform before being placed in production? (Isolating the development, test, and production environments.)
Change is a constant
I have frequently heard that there will be no further changes to a system. However, there are always more changes.
- Modifiability – How hard is it to make changes to the system? For example, how hard is it to change the database used by the application? What is involved in making changes to the wording of menus? Can the system be moved to another platform?
- Scalability – If the workload increases by an order of magnitude, what is required to keep it running?
- Mobility – Can the software system be moved to another system, and how much effort is involved? I was involved in one set of applications that hard-coded the IP addresses in the software. When the network was reconfigured, the IP addresses had to be changed, and they had to change all of the code for the system.