Worried that your finished product won’t accurately reflect your requirements? Our visual prototype and written functional spec will ensure that it does.
When we build software, we leave nothing to chance. We don’t assume; we ask, understand and articulate into an exact plan. The tangibility of this plan is the prototype (the visualisation of the plan) and the functional spec (the written blueprint). Both ensure that you’re getting exactly what you expected and agreed to.
The reason many software development projects fail is due to poor planning. Without it, you run the risk of delays, errors and costs.
For developers, the excitement comes from getting stuck into writing code and seeing a project taking shape. As a result, meticulous planning is often overlooked with developers cutting corners and making assumptions.
Understandably, customers want their software up and running as soon as possible, so often focus on the core functions rather than considering rare scenarios. It’s not until the software begins to be used that these scenarios manifest themselves and the gaps are revealed. The cost of retrospectively fixing these gaps in terms of system stability, cost and time can be severe.
To solve these problems and to avoid functionality gaps, additional cost and disappointment, for each development project we work on we create:
A functioning model – prototype – of the new application. Even the most creative among us can struggle to visualise what software will look like and how it will function from a piece of paper. With the prototype, you won’t have to. Everything is covered and nothing left to assumption.
Optionally, and depending on whether we engage under the Agile or Fixed Price model, an articulate and concise functional specification. This is a blueprint for your application; it sets out in writing exactly what you’ll be getting once the development is complete.
The first step we take is to prototype your new software. This starts with a visit from our Technical Architects to work through requirements in minute detail, during which we make it our responsibility to:
extract all the necessary information we need from you to avoid gaps in functionality
contribute our own thoughts and concepts based on experience to maximise your return on investment
Then, using cutting edge visual tools we’ll create a functioning model (prototype) of your new system so you can see it working. This includes workflow diagrams to accurately map out the user journey, background processes, and interactive user interfaces to demonstrate how each screen will look and function.
Because of its visual nature, the prototype helps avoid assumption and ensure all parties are in agreement about what is being developed.
Once this is complete, we’ll optionally write your functional specification which can later be used as the basis for a user guide to complement the knowledge of stakeholders involved in the project. This is an essential step for Fixed Price commercial engagements, and optional under the Agile model.
You wouldn’t expect a building to be constructed without accurate plans, detailing every material, measurement and position. The same is true with the software we develop.
The functional specification is the blueprint for your application. It identifies each area of your application and explains what it will contain and how each aspect will work. It includes diagrams to better explain functions, processes and workflows, as well as graphical designs of the user interface.
We appreciate that our customers are not always technical, so we prepare our specifications using ‘English’ rather than technical jargon so our customers can relate to what we’re planning.
Once written, it is vital that you understand the functional specification, so you can confirm your agreement with the plan as the build of your software is based on it.
The prototype and functional specification document work together to describe the end product in fine detail. They improve our Quality Assurance process, enabling us to use this high level of detail to ensure everything works as it should.