I’m going to use the live example of building EQE’s website to highlight the ‘challenges’ in delivering software to a customer and to spark off thoughts and discussions in the area of creating quality software.
EQE’s previous web site was created by using some of the basic templates from our ISP. While it provided a presence on the web very quickly and provided a reference point for customers, it always felt lethargic and old. So the decision was made to create a fresh new web site and a new logo. Colin acted as the customer on this task and my role was to deliver a tangible product.
Two things were apparent right away. One was that we didn’t have the capability to create a logo in house. The other was that we felt that by engaging a web development company we would be paying someone to ask us to to spend time writing the web narrative. Given that we have the technical capability in house, we decided to ‘look after’ this ourselves.
For the logo, a designer was called in and a design was established. The 3 arrows on the logo was to identify the ideals of EQE -
- people are the key to any organisation,
- processes, (when utilised correctly), can be a massive benefit to an organisation and
- the accumulation and sharing of knowledge allows an organisation to grow and be more effective.
For the website, it was decided to create this in-house for a number of reasons:
- the real work is in the narrative and that EQE’s time will have to be allocated it regardless of the technical creation,
- the technical side was easily within our remit,
- to optimise our 1 day “web test” offering,
- to ensure that we get what we wanted and
- to provide a topic for our first blog.
From a management side, it was decided that an incremental approach would be utilised to build the site. The rationale for this was two fold: to ensure content is released as soon as possible for the benefit of EQE and the realisation that the web-site will always be a “live” project and never be finished. We used time-boxes to identify and track our immediate requirements per incremental release.
The first white board session was to examine the basic requirement – “build a fresh website”. The outcome of this initial white-board session was: to develop a web site that was professional looking, easy to maintain, W3C compliant, relevant to our target audience, adhere to EQE’s web standards, establish the level and scope of testing involved, identify the risks, establish the non functional requirements, identify the configuration management approach, score a high percentage in EQE’s 1 day web test (greater than 80%), implement search engine optimisation, develop a secure test environment, allow for audience feedback, allow for blogging and so on……
So, (like most software projects), we quickly went from an easily understood and simple customer request of building a fresh website to several high level and diverse requirements in a very short space of time…… and the customers of software projects question why the development of software takes so long???
The increase in requirements listed above is an example of the need for contiuous communication. All of these requirements, plus more, came from white board sessions between just 2 people in the same company, (who understand and adopt appropriate techniques for requirements elicitation and management). Furthermore, even before the start of the first white board session, the question about the use of language in requirements is raised – the use of subjective terminology and the typical problems associated with ambiguous requirements. Simply – first question is – define ‘fresh’….?
