What is...

Content

• Definition

• Discussion

• Worked example introduction

• Example accuracy non-functional requirements

• References &Further reading

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 accuracy 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 accuracy non-functional requirement is any requirement that is not a functional, data or process requirement concerned with defining the precision which the solution will record or produce data.

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 specifying how unambiguous and correct the data will be that is recorded in the solution and produced by solution.

One general point about accuracy requirements that in principle applies to all requirements anyway: quite often the accuracy requirement will be stated as "The solution needs to be 100% accurate". There are issues with this requirement in that

• Being 100% accurate may involve lots of checking and double checking (to ensure that the data is correct) which may bring it in to conflict with other requirements concerned with the allowed time a given process should take . 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 accuracy. It is up to the project Business Analyst to mediate the resolution to conflicting requirements (for example in this case gaining agreement that the accuracy will endeavour to be 100% but that this cannot be guaranteed in the case of (say) recording a customer’s data of birth: the checking that would required to ensure it is 100% accurate 100% of the time for all customers would be complicated, costly and time consuming.).

• If no compromise can be mediated, then the cost implications of 100% accuracy need to be estimated and applied to the cost-benefit case for the project. This could in extreme circumstances destroy the benefits case. The sponsors of the solution then have to choose what to do. Perhaps in the case of an order taking solution they may instruct the project to degrade the accuracy from 100% to a cost effective level. Perhaps in the case of air traffic control system they may say that the extra cost simply has to be accepted.

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 revised costs. The alternative is that the Business Analyst raises this common issue if and when it arises with those that generated it and explains the likely consequences and options. The resolution of the issue still lies with those paying for the solution.

Ok, so some solutions do genuinely and with good reason want 100% accuracy (as in the air traffic control example) but even these will have cost and process time limitations restricting the robustness of the solution (air traffic control is not much use if it takes 12 hours to confirm the position of a plane): in reality 100% accuracy can never be guaranteed as there is always an outside chance that some data is recorded wrongly or calculated incorrectly or produced wrongly. Another (perhaps more mundane) example: GPS accuracy - if the application we are building is for a delivery company and the solution will make use of GPS navigation, specify the accuracy desired will have an impact on the cost as higher accuracy implies higher cost of the GPS service and GPS receivers. 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 perhaps by as much as tenfold.

The ramifications of this may manifest themselves in places you wouldn’t necessarily expect: and here are some further examples:

• If there are requirements for performing tasks at specific intervals (ex: send a status update every hour) or send a notification to a customer at X hour - how accurate does the system need to be aka perform the task within 10 milliseconds of the event or timer, 30 seconds, 5 minutes, 1 hour, etc. The accuracy needed will depend of the type of even, business need, as well as the cost to implement. Higher accuracy costs more just like higher availability costs more. They key is to identify with the business what they can live with (acceptable) and figure out if that (or better) can be done within the given budget.

• Voting system - what accuracy requirements exist for the voting system/process being put in place: how many votes are acceptable to be wrong (as % or per 1000)? For a paper based system with fill-in-the bubbles the accuracy of the scanner would be less than implementing touch screen voting machine.

• Currency - for systems which deal with money - how accurate does the system need to be when performing computations with currency such as rounding (to how many digits), round up or down, etc.

• Voice Recognition - if the application involves voice recognition such as dialing a phone number vs. dictating class notes the accuracy needs could be different. For a phone number dialing the non-functional accuracy requirement would be very high accuracy as when in the car the objective is to connect in the first try without having to retry. But when using it for taking notes in class then accuracy may not be as important as the user is also there in class and (if there are spelling errors) the use may still figure out the context.
   

The bottom line is that there is no alternative but for the business analyst to analyse and think through the accuracy non-functional requirements – there are no rules other than they must be captured. It doesn’t matter what the accuracy non-functional requirement is, just that it is defined and captured. So say that the business analyst determines that the context of the accuracy non-functional requirements may vary (for the same solution) depending on other variables – for example with a voice recognition system the accuracy non-functional requirements may vary with background noise. In that case they may be higher when the user is in a quiet place and lower when in a noisy place. Fine. Define, record and communicate that to the designers, developers and testers.

A final thought – don’t re-invent the wheel: some organisations will have in standards that cover solution accuracy. Find these and 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. Accuracy requirements will – from a user perspective – be accuracy of functional capabilities that are implemented via processes and accuracy of data that is stored and produced. Given this, we should use the table to focus on documenting accuracy non functional requirements as they relate to processes AND data – i.e. “Both”.

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 documentation of accuracy non-functional 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.

References & further reading

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

2. 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)

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

4. 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.

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

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

2018-05-02 Requirements.com All about Requirements 2020-09-20 SuperUser Account What are Accuracy Requirements?