What are Availability Requirements?

What is...A Oct 18, 2018 6 mins 37543 Views 0 Comments 2 Likes

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.

Content

Definition

In Association with:

This page was created in association with Smart-BA, provider of business analysis mentoring and distance learning programs.
Discussion
Worked Example Introduction
Example Availability Requirements
References & Further reading

Definition

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

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

Specific examples and alternative styles of documenting availability non-functional requirements are readily available from an internet search using terms: +availability +"non functional requirement"
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.
The "four nines (99.99%)" and the "five nines (99.999%)" see: http://en.wikipedia.org/wiki/High_availability
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
Most books deal with Functional AND Non-Functional Requirements such as “Writing Better Requirements” by Ian Alexander and Richard Stevens (Paperback - 17 Jul 2002)
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)