7 Requirements you should never overlook

This article originally appeared on Konsultbolag1

Identifying all the requirements for any system is close to impossible, however, there are certain requirements that almost every system needs. All too often, even given their importance, these requirements are overlooked.

As with any requirement, implementing too late increases development costs.
To help with this, here is a list of 7 Requirements you should never overlook.

Use this list as a starting point and supplement it with your own experiences. This will help you write more comprehensive and complete requirements.

1: System shut down

A system needs to be turned off for both emergency and planned downtime. Ideally, the process should provide the system administrator with a simple way to minimize errors that would arise if shutdown were a manual process. What information will the system display to users when it is going to be taken down or already is down?

2: Permissions

Who should be allowed to see or change what data? What happens when a user tries to use the features that he does not have access to? Can you see features you’re not authorised to use, or are they hidden? Who should administer permissions and how will they do it? All of these are questions you need to ask.

3: Error messages

Specify where messages are displayed. Do they use a message box or do they notify users in the program’s status bar? Error messages are very rarely specified in the requirements, but when developers inherit the task of formulating error messages, the results can be bad, since developers are often better at writing code than explaining things in plain English.

How can you counteract this? Specify a requirement that allows you to export all the messages in the system, for example to an Excel file. This will make it easier to adopt the same tone of voice in all the messaging, as well as make localization of the system easier if you ever decide to translate it into other languages.

Without this requirement in place, it’s usually very difficult to extract all the system messages into one place, let alone review and vet them.

4: Alarms when failures occur

When errors occur, the system should log the error and send an e-mail to operational staff, the system administrator or an equivalent. The great advantage of making the system send an alarm is that errors become more obvious and conspicuous, so the administrator is more likely to take action.

5: Logging errors

It’s much easier to troubleshoot the system if it records the details of each error to some type of log. This is especially true in the production environment, where it’s not possible to use development tools for troubleshooting.

You can log errors to a text file or to the Event Log in Windows. Other operating systems have different names for the Event Log, but the idea is available on all OSes.

When an error occurs, the system should log information about the program that crashed (including the line of code it was executing), the program error code (exception), and the input that led to the crash.

Often it’s worthwhile to log more than just the error itself. For example, you might log all calls to all functions, since the error might have occurred because the calls were made in the wrong order.

6: Handling overloads

What happens if the system gets overloaded? Do you automatically roll back transactions in case of overloads? Does the system show an error message? Should the system shut down automatically?

Think of the consequences and perceived risks of any of these choices and choose well, before overloads start happening.

7: Managing high volumes

High usage volumes is something you need to think of and plan beforehand. Ask yourself the question: “Will there be times when the system has to deal with a large number of users doing more things than usual?”

For example, the user volume of a retail sales system may be higher at certain times of the day, week, or year, while consumer banking systems are busier near payday. These types of spikes in usage can cause performance problems. Think of and plan these things beforehand!