Ever play the game Jenga? That’s the one where players try to remove one wooden block at a time from a tower constructed of 54 blocks, placing each block they remove higher on the tower, without making the whole thing collapse. The principal of the game is simple: as long as the foundation is solid, you’ll be successful.
The Proof-of-Concept of a test project is kind of like the foundation of a Jenga tower: it’s an essential building block to testing success!
The goal of the Proof-of-Concept is to produce documentation that precisely details the project requirements that are used to create the concept design. Think of this documentation as a kind of contract between your company and the client: it has to be understandable to both sides and precise enough to be used effectively.
The Proof-of-Concept consists of two stages, both equally important: the Requirements Specifications and the Preliminary Design. The requirements are determined in the first stage, and then used to develop the necessary designs in the second.
Start with Requirements
In the Requirements Specification stage, the focus is on obtaining, solidifying, and documenting system-level requirements in order to set achievable budgetary goals and plan a successful schedule that meets the client’s automation and test project needs.
There are three key components to the Requirements Specification stage: gathering the requirements, specifying the requirements, and analysing them. This sometimes involves building and testing simple prototypes or producing brief feasibility studies in order to evaluate requirement trade-offs.
This information is then used to produce a System Requirements Specification document. Subsequently, all requirements are analyzed, cross-requirement trade-offs are considered, gaps and overlaps between requirements are identified, and then, based on all of this, requirements are reduced to precise characteristics that the eventual system must meet.
Follow Through with the Concept Design
While this first stage provides a thorough requirement analysis, the goal of the second stage, the Preliminary Design, is to provide a set of documents that outline the conceptual design. Specifically, there are certain key documents that are produced in this stage: software flow diagrams, a software block diagram that identifies major software system building blocks, a hardware block diagram that identifies major hardware components, both custom and off-the-shelf, and a Bill of Material draft that describes major equipment.
Additionally, two other documents may be submitted at this point: an Acceptance Test Plan and a Traceability Matrix.
Documentation is a Plus
End-user documentation can be provided for each test system that is part of the requirement specifications.
While the manuals provide users with essential references to the test systems, they can also be very useful to your team because they act as a thorough reference to the essential functions that the product needs to satisfy.
Averna's experience has proven that developing user manuals at the beginning of a project rather than at the end often leads to greater success, because it creates a “begin with the end in mind” approach that helps reduce risks and minimizes overruns during development.
Finally, involving users in all stages of development is crucial, because it not only helps the process by, for instance, identifying missing use cases that the test stations should cover, but ultimately means that users end up loving the Proof-of-Concept because it usually results in successful projects. And nothing beats that, except maybe winning at Jenga!
