Getting Visibility over the Blockchain

Functional Requirements Specification

Getting Visibility over the Blockchain

Functional Requirements Specifications?

It is important to remember that a Functional Requirement Specification (FRS) is not a Technical specification. From the ‘applied blockchain’ perspective, we talk often about developing a Functional Requirements Specification. We are in fact specifying what the blockchain network is required to do … and not what technology is required to make this happen.

Distinguishing between what a system does and how it does it provides a separation of ‘functional’ and ‘non-functional’ aspects, and a framework for developing a ‘high level’ Functional Requirements Specification that will inform developers of the behavioural expectations of the system.

Daniel Drescher describes a really neat and simple way of getting visibility over the functional requirements. He proposes that a system can be partitioned in two ways:

  1. Application vs Implementation
  2. Functional vs Non-functional aspects

In this article I wanted to provide some further clarification around ‘Functional vs Non-functional’. This becomes particularly important when preparing an FRS. The developer needs to understand not only ‘what’ the system needs to do (function) but ‘how‘ it is going to do it (non-functional). This will inform the developer of the expected behaviour of the function. Let me give you an example:

Functional aspect: Sending emails
Non -Functional aspect: Messages are sent fast

Let’s look at a typical functional aspect of a blockchain now:

Functional aspect: Clarifying Ownership
Non-functional aspect: Highly available, reliable, pseudoanonymous

Clearly in both instances you could apply this definition:
Functional aspects focus on what is done, while non-functional aspects focus on how things are done.

It is fair to say that most users are concerned with the functional aspects of the application layer of a system, while non-functional aspects of a system, in particular those of the implementation layer, are less visible to users.

Let’s talk about some typical non-functional aspects that describe the quality or expected behaviours of the blockchain:

  • Highly available – no down time
  • Censorship proof – no one dictates the content of a block
  • Reliable – can be trusted to clarify and transfer ownership correctly
  • Open – Is open to everyone without excluding certain users
  • Pseudoanonymous – identifies ownership without revealing identity
  • Secure – is secure on both transaction and whole system levels
  • Resilient – Withstands a wide range of attacks
  • Keeping integrity – free of logical errors

Consider these non-functional aspects. I hope this helps with your approach to developing a Functional Requirements Specification.


No Comments

Sorry, the comment form is closed at this time.