Requirements

I have been working with requirements for more than 20 years. To be honest, it was several years before I understood the true purpose of requirements. The enlightenment came about when I was tasked with documenting a presentation to my colleagues that described the characteristics of a ‘good’ requirement. The characteristics that the team came up with included:

• Complete – A functional requirement should describe all observable inputs, all observable outputs, when it can occur, who (actor that) is allowed to initiate the requirement and the maximum time that the requirement is allowed to complete.

• Consistent – The requirement should not be in conflict with any other requirements for the project. For example, if one requirement states that all user inputs will be processed within 5 seconds of entry and another requirements states that system shall respond to a particular user input within 10 seconds, there is a conflict in the requirements.

• Correct – Are the requirements specifying a solution that the business wants implemented?

• Design independent – If there is another way of specifying the requirement which will result in a different solution to the problem, then it probably contains design information and should be abstracted out to allow for all possible design decisions. For example, stating that when the main window is closed that the system will logout the user etc, is too detailed. Supposing we decide not to build a windowed application? A better way to abstract the requirement would be to say that when the user exits the application that they will be logged out, etc.

• Feasible – Is it possible to implement the requirement within the specified time and budget? (And, we might want to ask if there is there a positive return on investment (ROI) for implementing this requirement?)

• No negative requirements – Stating the system ‘shall not’ do something is either untestable or irrelevant. The requirements state what the system will do; anything else is out of scope. For example, instead of stating that something shall not be ‘red’, state the colors that it may take. Irrelevant example; stating that the system ‘shall not’ allow a user to view user information, is already covered by a requirement that an administrator shall be able to view user information. The fact that it has been stated that administrators may view this information, excludes all other actors, unless explicitly stated. A rule of thumb is that the system does nothing unless it is stated as a function of the requirements.

• Relevant – Is the requirement in scope for the current effort.

• Testable – Is it possible to define specific ranges of inputs and outputs for the requirement such that when the implementation of the requirement is executed all inputs cause the system to produce the specified outputs, otherwise the implementation of the requirement fails?

• Unambiguous – The requirement should not contain any words that are open to interpretation. This includes all adjectives and adverbs, unless they are clearly defined in a project glossary. For example, the system shall allow ‘many’ users to change their profile. Unless the word ‘many’ is explicitly defined this requirement has little meaning; and it can be satisfied by allowing exactly 2 users to change their profile and no more.

Functional Requirements

In addition to the above, functional requirements include the following characteristics:

• Precondition (optional) – when can the functional requirement execute? The precondition specifies what state the system must be in before the requirement may be initiated. Not all functional requirements are able to execute at any time. If using a use case approach to writing functional requirements, the use case precondition states what use case(s) must have completed prior to this use case being able to initiate, and each step in the use case has an implied precondition, which is the previous step in the use case. (Sometimes the precondition may be implied by the wording of the requirement, in which case it does not have to be explicitely stated.)
  

• Time to complete – if a functional requirement does not have an associated maximum time to complete, then if the implementation of the requirement does nothing it will never fail testing. If it never fails testing and never does anything it will never get deployed into production. Again, using a use case approach, the whole use case may be given a time to complete, or you may specify time to complete for individual steps. If a group of steps are assigned a time to complete, and that time expires during testing, then every step in that grouping is considered to have failed the test.

Non-Functional Requirements

Non-functional requirements additionally include the following characteristics:

• Reference to a functional requirement – non-functional requirements place constraints upon functional requirements. Functional requirements may include the meaning of the non-functional requirement in their specification. The reason non-functional requirements are specified separately is because they often impact many functional requirements. We do not want to duplicate the requirement. Therefore it is called out as a separate requirement and references the functional requirements that it impacts.

Definition of a Functional Requirement

From Wikipedia: ‘In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs (see also software).’

When not employing use cases, I use a template for specifying requirements of the following format: 'When' in a certain state* 'and' 'upon’ some externally visible event occurring (the trigger), ‘the system shall’ do something externally visible, ‘within’ a certain time frame.

['When' in a certain state is optional, and if omitted means that the requirement is valid in under all circumstances, i.e. it has no precondition.]

For example, 'When' the ATM is free, 'and upon’ a customer inserting a valid debit card into the ATM slot, ‘the system shall’ request that the customer input their PIN through the ATM user interface, ‘within’ 5 seconds.

(The 5 seconds of course applies to the system and not to the customer entering their PIN.)

Here are some examples of requirements that do not satisfy the template. See if you can figure why before reading my answers.

1. When requesting a customer PIN, and upon a customer entering their PIN through the ATM UI, the system shall verify that the PIN is correct for the card, within 5 seconds.

2. Upon verification of the customers PIN, the system shall inform their customer that they may select an action from the ATM UI, within 5 seconds.

3. Upon dispensing cash to a customer, the system shall send a message to the Banking System requesting that the customer’s account balance be deducted by the amount dispensed.

4. When a customer card is inserted, and upon the Banking system receiving a deduction message, the system shall give the customer their card back, within 5 seconds.

5. Upon a customer entering the 'Display Balance' command, the system shall request the customer balance from the Banking system, within 5 seconds.

In my opinion these requirements contain the following errors:

1. ‘Verify the PIN’ is not an externally visible action. If the PIN is valid, the selection screen will be displayed. If the PIN is invalid, an error message will be displayed. The first case was already covered by the original requirement when it included the word ‘valid’. We need to add another (separate) requirement to cover the invalid situation.

2. The trigger is not externally visible. We cannot observe the system verifying the customer PIN. In fact the act of ‘verifying’ the PIN is a design decision. Our designers might equally decide that the PIN is verified by the Banking System. In fact, in reality, it probably is.

3. No time frame specified. The banking system is going to lose a lot of money if the ATM sends out deduction requests once a year.

4. The trigger is not an event that the ATM system can recognize. The Banking System has to somehow inform the ATM system that it received the message. It is upon reception of this event that the requirement initiates.

5. No precondition. The customer must first have entered a valid PIN, otherwise the system cannot be sure whose balance to request.

In my next post I intend to identify some best practices for working with requirements..