Helium System Development Lifecyle

High level summary, with elaboration for Requirements Gathering

HELIUM – REQUIREMENT GATHERING PROCESS 1

 NAME TITLE SIGNATURE DATE
Daniel
Author COO 11/12/18
Ames

Reviewer

Authoriser

READ BY

NAME TITLE SIGNATURE DATE

HELIUM – REQUIREMENT GATHERING PROCESS 2

Background

The Helium project has always had the intention to partner with businesses that depend on robust
supply chain and logistics management. Whilst a range of companies have expressed interest in
working with Helium to build a Blockchain platform for them to use, a requirements gathering
exercise is required to analyse and identify what functions and utility the service must provide.

This document is intended to provide offer two purposes. Firstly, a high level overview of the
processes that are happening behind the scenes and secondly an update of progress so far.

This document will provide a high level overview of each software development phase, but only go
into detail for the current phase, requirements gathering. A version of this document will be
published for community reading as each phase is begun in order to provide a detailed
understanding of what that phase will involve.

The Software Development Lifecyle

The Helium project will be using a light and agile software development lifecycle. We are not
building a system that makes changes to an existing business or life critical application. We will have
an opportunity to design, build and test thoroughly without significant risk of impacting the project
or our partners in a negative way. For this reason.

The following phases will be followed by the Helium Project.

1. Preliminary analysis.
2. Requirements Gathering & Analysis
3. System Design
4. Development
5. Integration and Testing
6. Acceptance & Technical Launch

Preliminary Analysis

This stage is complete. The preliminary analysis involved identifying whether there is demand for
the vision that we hoped to deliver and whether there is a realistic opportunity for us to build a
system that offers interested businesses sufficient advantages to adopt Helium.

HELIUM – REQUIREMENT GATHERING PROCESS 3

Requirements Gathering

Requirements play many roles in the project; they encapsulate the client’s needs, create a contract
between developers and the client as well as provide a basis for system and acceptance testing. If a
software development project does not understand what is important to it’s partners, then there is
little hope of a usable product being the end result.

As Watts S. Humphrey, the father of software engineering quality management said in 1989, “The
best software practices are useless if they are focused on implementing the wrong functions”.

With apologies for quoting directly from Wikipedia (I am unable to express this information in a
better way); in 1992, Christel and Kang identified problems that indicate the challenges for
requirements elicitation:

'Problems of scope'. The boundary of the system is ill-defined or the customers/users specify
unnecessary technical details that may confuse, rather than clarify, overall system objectives.

Problems of understanding. The customers/users are not completely sure of what is needed, have a
poor understanding of the capabilities and limitations of their computing environment, don’t have a
full understanding of the problem domain, have trouble communicating needs to the system
engineer, omit information that is believed to be “obvious,” specify requirements that conflict with
the needs of other customers/users, or specify requirements that are ambiguous or untestable.

Problems of volatility. The requirements change over time. The rate of change is sometimes
referred to as the level of requirement volatility

To counteract these problems, the process and process documentation must include:

Visualization. Using tools that promote better understanding of the desired end-product such as
visualization and simulation.

Consistent language. Using simple, consistent definitions for requirements described in natural
language and use the business terminology that is prevalent in the enterprise.

Guidelines. Following organizational guidelines that describe the collection techniques and the types
of requirements to be collected. These guidelines are then used consistently across projects.

Consistent use of templates. Producing a consistent set of models and templates to document the
requirements.

Documenting dependencies. Documenting dependencies and interrelationships among

requirements.

Analysis of changes. Performing root cause analysis of changes to requirements and making
corrective actions.

HELIUM – REQUIREMENT GATHERING PROCESS 4

In order for Helium to engage with its partners and identify their requirements whilst sidestepping
the above problems, the following steps will be undertaken.

1) Partner interviews
2) Create a robust requirements change process.
3) Create a Product Requirements Document
4) Create a detailed functional requirements document.

Partner interviews

In order to get to know our prospective partners, a structured but also relatively informal dialogue is
required in order to understand what the businesses do, how they currently do it, what their
attitude towards Blockchain is and how they see the Helium platform improving the way they do
business in the future. This process is underway, using a standardised interview/questionnaire
document that is being used to ensure that the same questions are being asked of each potential
partner.

Create a robust requirements change process.

If a partner makes a change to a requirement, it is essential to understand whether that change has
an impact on dependencies or whether there will a cost or time impact if the change is incorporated.
The process and documentation for this process has been created.

Create a Product Requirements Document

Once a relationship has been established with the potential partner, the conversation can move
towards high level discussion of the functions that the system need to provide. An expected output
of this will be a list of actual functions that need to be incorporated and an understanding of how
those functions will serve their businesses. The document templates and process around this step
have been created and are ready to go.

Creation of Functional Requirements Document

Once the PRD is complete, the product requirements will be translated into a functional
requirements document which goes into the low level of how users and business will interact with
the Helium platform, what form the data flows will take, and outline performance requirements,
acceptance criteria and other key metrics. The document templates and process to conduct this step
have been created and are ready to go.

System Design

At this stage, the FRD is translated with further assistance from the partner into a thorough, detailed
and explicit document that outlines the desired features and operations such as including interface
layouts, business rules, process diagrams, pseudocode, and other documentation. The system design
document will be used to plan resources required and timescales for actual delivery of the Helium

HELIUM – REQUIREMENT GATHERING PROCESS 5

Platform. This step will also allow us to create an accurate delivery plan, based on real resource
requirements and cost estimates.

Development

This is the phase where the developers write the code to bring the system requirements into
existence. The process and documentation around this phase has not been created yet but will likely
be based on simplified industry standards for ease. The decision on which process to use will likely
be made when coders have been appointed as software engineers tend to have a preferred
methodology to follow.

Integration & Testing

This phase will see the Helium platform being tested on a live blockchain in testnet. The process and
documentation for this phase has already been created and is ready to use. It is likely that there will
be three phases of testing a closed testnet, a community testnet and then a further community
testnet once bugs have been fixed from the first two test phases.

Acceptance & Technical Launch

The final level of testing will be when the partner organisations get to simulate real life usage for
their business. If the system passes, then the Helium platform will be integrated into the mainnet
chain. If the system does not pass, the system will be passed back to the development team to fix
and then put through testing again.

HELIUM – REQUIREMENT GATHERING PROCESS 6