How RIBACPD.com was developed

Occasionally, it's nice to look back on a project once it has gone live. To see similar posts check out the "Behind the scenes" label for this blog.

Earlier this year the new RIBACPD.com site went live. Below is a bit of background to how we went from requirements through to the finished product. Those readers of this blog from the construction industry will probably see some big parallels between software development and construction.
(and as always with these things - the hard work was not done by me - well done Chris and Chris and John the main designer, developer and QA-er behind this project).

Fig 1 below shows the main requirements document. This forms part of the project plan after a business case has been agreed. Requirements are testable - you cannot have a requirement if you cannot verify it has been met. Each requirement is categorised as "Must be done", "Should be done", "Could be done" or "Won't be done". The volume of comments and track changes in the document below clearly show what an important process this is.

Fig 1 - A well commented fourteen page requirements document is where it all really starts 

Fig 2 below shows an example of a concept design sketch for the homepage. By designing on paper or a whiteboard it is possible to get broad agreement prior to investing time in more detailed designs. This blog is a promoter of "digital is best" 99% of the time. But sometimes it is best starting out with pen and paper.

Fig 2 - Example concept sketch design on paper for the home page

Fig 3 shows that the designs then need worked up to the stage where a software application can be developed from. This tends to be a mix of Fireworks and HTML mock-ups which get passed over the fence from design to development. By breaking the developments down into stages (homepage, search returns, manufacturer page, shortlist etc...) then developments can happen on certain stages before designs have started on others. This can be thought of as Staged Delivery software development methodology - somewhere between traditional waterfall and the more radical agile methods. This gives efficiency in workflow but also greater certainty in terms of delivering requirements.

Fig 3 - A detailed design document then gets down to the nitty gritty of how things work  on each page

And then Fig 4 shows the actual RIBACPD.com site as it was built...

Fig 4 - And then through some clever software development the final site pops out

Fig 5 and Fig 6 show this process again for the basket/shortlist area of the site...

Fig 5 - Another example of concept designs - this time for the "basket"

Fig 6 - And the finished product - note that the "basket" changed to "shortlist"

And finally throughout this process requirements, designs and software are put to our Advisory Panel, Beta Testers and other user groups for their feedback. The picture below shows QA Manager Clair Hillier and Head of Specification Ian Chapman hosting a break-out group from our Advisory Panel.

User feedback