7 Requirements you should never overlook-Part 2

In the first article of this series we said that identifying all the requirements for any system is almost impossible, however there are certain requirements that almost every system needs. In the previous article, we listed 7 Requirements you should never overlook, which included system shutdowns, permissions, error messaging, alarms upon failure, logging of errors, and handling and planning for overloads. Today, we list 7 more requirements you should never forget about or overlook.

Remember that as with any requirement, implementing too late increases development costs. Use this list as a starting point and supplement it with your own experiences. This will help you write more comprehensive requirements.

1: System integration/connections

Develop a traceability matrix that shows which test cases or test areas are affected. Are there sufficient requirements specified for these relationships?

2: Things the system must or must not do

There are things which any system must not be allowed to do. These fundamentals vary according to the system’s use, but a basic example would be that a banking system should never deduct money from an account without also ensuring it reaches the receiving account.

Have you identified all the situations of this kind? Are there any exceptions to normal handling rules? Make it a habit of asking yourself “Will this be valid in every case?”.

Many business rules have exceptions that are implied and easy to forget. Decision tables offer excellent techniques for identifying rules and exceptions.

3: It should be easy to implement changes

After you launch any new system, you’ll probably find a multitude of minor defects that you want to correct. Make sure the architecture supports simple changes so that you don’t have to recompile the entire system to make simple fixes such as changing the text of system messages. Recompiling a system often requires extensive regression testing, so you should avoid having to do it just to accommodate minor adjustments.

4: Requirements for documentation

Many systems are expected to be up and running for years. Determine what documentation will be required for future teams to maintain and operate the system cost-effectively. Determine early on what kind of documentation the system owner expects.

5: Identify implied and expected requirements

Implied requirements are easy to overlook, specifically because they are not expressed by definition. To find them, you have to read between the lines, imagine yourself in the user’s shoes, and generally think outside the box.

An example of common requirement that usually gets overlooked is printing – users expect that printing functions will be available and that the printouts will look a certain way.

Expected requirements are the ones that the client expects but thinks are so obvious that one doesn’t need to specify them. For example, customers don’t usually tell you that they need and existing functionality to continue to operate or to only be changed if they request it.

6: Reports

Are there any reporting requirements or other ways to extract data from the system? How often will reporting happen, who will carry it out and what metrics will they need to extract? Is there any delay in reporting data being populated?

The answers to the above make a huge difference to an overworked account manager extracting tens of reports every Monday morning.

7: Legal requirements

These requirements should never, ever be forgotten. Failing to adhere to this will result not only in lots of extra work, but in some cases, legal liability. Do your research diligently and get a professional opinion when in doubt. A couple of examples of legal requirements are a Consumer Credit Act or the laws regarding the handling and storage of personal data. These vary from country to country so make sure you are informed!

What’s next?

Kickstart your requirement gathering by reading our articles about the various facets of requirements;