Friday, May 26, 2017

Availability Requirements

Content

Definition

Note: for the definition of Non-Functional requirements in general see the article “Non-Functional Requirements”.

There is no one standard definition of an Availability Non-Functional Requirement. It will be defined for each project where it needs to be specified. This principle is true of all non-functional requirements.

For the purposes of this article an Availability Requirement is any requirement that is not a functional, data or process requirement concerned with defining the periods when the solution can be used.

Discussion

The ‘definition’ may be ambiguous. That is not material to the success of the project. What is material is that all requirements (including non-functional) are captured and progressed. This definition means what it needs to mean to the project that are defining the requirements. For the purposes of this article, it means times of day and days of year when the solution can be used and by definition when it will not be available for use.

One general point about availability requirements that in principle applies to all requirements anyway: quite often the availability requirement will be stated as “The solution needs to be available 100% of the time”. There are issues with this requirement in that

  • it may conflict with other requirements concerned with doing regular maintenance of the solution who require planned downtime (as opposed to unplanned downtime). These requirements also need to be discovered and – as with any requirements – checked that they are not in conflict with other requirements – in this case such as availability. It is up to the project Business Analyst to mediate the resolution to conflicting requirements (for example in this case gaining agreement that the availability requirements refer to times excluding planned maintenance).

  • the designers will point out that that while technically feasible 100% availability is a potentially expensive option as it means developing solutions to ensure that in the event of component(s) failure, the solution can compensate (for example a full “mirror” of the solution is always running in parallel in the background being updated by the operational solution. In the event of failure users are switched to the “mirror”. Does the mirror also need a mirror in case the first mirror also fails? If 100% availability is to be guaranteed then the logical answer is yes. Does that mirror also need a mirror? And so on.).

As a Business Analyst you could record the initial requirement, and in the first case wait for the conflicting requirements and in the second case wait for the designers to come up with revised costs. The alternative is that the Business Analyst raises this common issue if and when it arises with those that generated it.

Of course some solutions do genuinely and with good reason want 100% availability (air traffic control for example) but even these will have cost limitations restricting the robustness of the solution: in reality 100% availability can never be guaranteed as the designers of the Titanic discovered! In these cases it is common to use "four nines (99.99%)" or "five nines (99.999%)".

However, be aware that every “9” after the decimal point significantly increases whole solution costs. see: http://en.wikipedia.org/wiki/High_availability

A final thought – don’t re-invent the wheel: most organisations will have in existence Service Level Agreements (SLAs) that cover solution availability. Find these and test them on test them with the people who have the authority to specify the requirements for the solution being worked on. If they are acceptable, reference them in the requirements documents.

As previously noted, these principles (identify conflicting requirements, resolve known or common requirements issues as soon as possible and re-use of existing standards) applies to all requirements gathering.

Worked Example Introduction

The main article on Non-Functional Requirements discusses why the following table is a reasonable tool to use to assess at what level to document non-functional requirements.

Availability requirements will – from a user perspective – be availability of functional capabilities that are implemented via processes. Given this, we should use the table to focus on documenting availability non functional requirements as they relate to processes.

Type Level

Process

Data

Both

Whole solution

Terms of reference or Requirements Spec

Terms of reference or Requirements Spec

Terms of reference or Requirements Spec

All automated or all manual components

Terms of reference or Requirements Spec

Terms of reference or Requirements Spec

Terms of reference or Requirements Spec

Functional requirement

Requirements Spec or Requirements catalogue

N/a

N/a

Whole process

Process spec

Process spec

Process spec

Any level within a process hierarchy

Relevant level process spec

Relevant level process spec or Entity spec or Attribute spec

Relevant level process spec

An individual process step

Process step spec

Process step spec or Entity spec or Attribute Spec

Process step spec

All data

Process spec

Data model overview

Process spec Data model overview

An individual data entity

Process spec or Entity spec

Entity spec

Process spec or Entity spec

An individual attribute on an entity

Process spec or Attribute spec

Attribute spec

Process spec or Attribute spec

Suppose you have different names for your analysis deliverables or maybe different analysis deliverables? You should still apply the rules of documenting the non-functional requirements you need to at the highest level you can, regardless of the analysis deliverable they end up in.

Example Availability Requirements

This is just what it says: examples of how these non-functional requirements could be documented. The style and precise wording will be down to organisational and individual standards and preferences. What matters is that the requirement is documented and communicated to all who need to know about it in such a way they can understand and use it as they need to.

Level

Process

Example & notes

Whole solution

Terms of reference or Requirements Spec

Have a section entitled “Non-Functional Requirements” and list them as they apply to the whole solution:

  • The solution will be available for normal use from 08:00 to 19:00 hours Monday to Saturday.

  • The solution will be available for system maintenance purposes from 22:00 to 02:00 hours every day.

  • The solution will not be available for normal use or system maintenance purposes for all UK bank holidays, and the Christmas shut down period.

All automated or all manual components

Terms of reference or Requirements Spec

As per whole solution, except the heading of the section will read “Non-Functional Requirements for all Automated (or Manual) Components”.

Functional requirement

Requirements Spec or Requirements catalogue

Functional requirement: “Be able to record orders”.
Associated non-functional requirements:

  • This function is available from 08:00 to 19:00 hours Monday to Friday.

  • This function is available from 09:00 to 12:00 on Saturday.

  • This function will be available for system maintenance purposes from 22:00 to 02:00 hours every day.

  • This function will not be available for normal use or system maintenance purposes for all UK bank holidays, and the Christmas shut down period.

Note that non-functional requirements recorded at this level could be used to supplement those recorded at higher levels:

  • this function is available as per the whole solution except Saturdays when it is only available between 09:00 and 14:00.

This principle can be extended to the documentation of non-functional requirements at any level.

Whole process

Process spec

Add a “Non Functional Requirements” heading to whatever document is used to define or describe the process. Document them either explicitly or as exceptions or variations to the non-functional requirements documented at any higher level.

 

 

CASE (Computer Aided Software Engineering) and other analysis tools will often allow recording non-functional requirements explicitly in pre-defined or user defined sections.

Any level within a process hierarchy

Relevant level process spec

As per whole process.

An individual process step

Process step spec

It is unlikely that there will be non-functional availability requirements for data at any level.

In the event that there are, they could be recorded as a separate heading in whatever document is used to define or describe the data required by the solution as per whole process.

Again, note that CASE and other analysis tools will often allow recording non-functional requirements explicitly in pre-defined or user defined sections.

All data

Process spec

Add a “Non Functional Requirements” heading to whatever document is used to define or describe the process. Document them either explicitly or as exceptions or variations to the non-functional requirements documented at any higher level.

An individual data entity

Process spec or Entity spec

As per all data.

Document them either explicitly or as exceptions or variations to the non-functional requirements documented at any higher level

An individual attribute on an entity

Process spec or Attribute spec

As per individual data entry.

 

References & further reading

  1. Specific examples and alternative styles of documenting availability non-functional requirements are readily available from an internet search using terms: +availability +"non functional requirement"

  2. Business Analysis Body of Knowledge, Release 1.6 ©2006, International Institute of Business Analysis http://www.theiiba.org. There is a v2.0 of this document.

  3. The "four nines (99.99%)" and the "five nines (99.999%)" see: http://en.wikipedia.org/wiki/High_availability

  4. Here's a couple of references which might trigger additional thoughts and considerations:
    http://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/AvailabilityRequirements.html~Contents and http://articles.techrepublic.com.com/5100-10878_11-1060286.html

  5. Most books deal with Functional AND Non-Functional Requirements such as “Writing Better Requirements” by Ian Alexander and Richard Stevens (Paperback - 17 Jul 2002)

  6. There are some specialist books on non-functional requirements such as “Methodologies for Non-functional Requirements in Service-oriented Architecture” by Junichi Suzuki (Editor) (Hardcover 2009) or Non-functional Requirements in Software Engineering (International Series in Software Engineering) (Hardcover) by Lawrence Chung, Brian A. Nixon, Eric Yu , John Mylopoulos (1999)

 

More requirements topics:

Requirements Glossary - from A to Z


Copyright 2009-2014 by Modern Analyst Media LLC