Introduction
My next article is going to comprise of a series of four. I plan to investigate and annotate a project design and development cycle. By means of an example I am going to construct a small wish list application in the run-up to christmas.
I am setting myself a tentative completion deadline of 4 weeks (though as with any project at this stage this is a guide line only, and a firmer date will be put in place upon completion of the project design stage).
I should point out that this does not represent any official way of doing things, instead it represents what I think works effectively and efficiently in a real world development environment, and by means of this scenario I hope to explain my rationale behind this.
Throughout my Masters in Computing Science there was a great deal of focus of software development, beginning at requirements analysis, working through to the development procedures used (Extreme programming Vs MDA etc) and project development lifecycles. Whilst I found most of this to be incredibly useful, exposure to real world projects, deadlines and clients has shown me that not all of it is realistically practical or even required.
Project Planning
The purpose of this first article is to cover the project planning stage. This stage can be referred to through a number of terms, and is often broken down itself into component parts. Principally I see the goal of the project planing phase to produce a definitive specification list that your application should satisfy. This process is absolutely critical and fundamental to the concept of project design (which comes next). As anyone who works with users in the web design business knows getting content from a client is comparable to the blood and a stone analogy, getting a client to sign off on a specification can be equally as challenging.
In order to establish exactly what the client requires you will probably have to go through a number of exercises, all dependent on the type of application that is being planned. The concept of gathering and identifying potential functionality is often referred to as 'Requirements Analysis'. In an ideal world we could argue that as developers we should sit back and the client should bring to us the exact specification of what it is they want us to build, and maybe this is true, however this is also not realistic. When compared to other engineering disciplines many analogies can (and should) be drawn.
Engineering is as Engineering does
When a client approaches a construction firm wanting them to build them a house they do not go in with a verbal description of what it is they want, instead they must commission architects to come up with exact specifications (in this example drawings) which the construction firm can subsequently use to produce a definitive schedule, pricing structure and construction plan.
The same is true for the construction of any piece of software, we first must know WHAT to build, before we CAN build. This being the case it falls down to us as developers to ensure that we are working off of complete enough specifications and if the client has not produced such a specification it falls down to us to guide them through the process of producing one. This guidance can take a number of forms, in reality however the first goal is normally that of education. It must be made clear to the client just how important this stage is, why it is required and why it is that you will be spending so much time on ensuring that it is completed properly and effectively, the key points to convey in my opinion are;
- A specification will allow accurate time scheduling
- A specification will enable greatly increased pricing accuracy prior to any development work
- The specification will rule out any functional confusion and will mean that they client is reassured of the exact functionality they will receive
- Ultimately the quality of the product will be increased through the minimisation of potential bugs (through early identification) and thorough project design
- By identifying the precise functionality the product must provide your client will be able to accurately track the status of the project through its development
Project planning goals
The primary goal of the project planning phase should be to produce an accurate specification document that we as developers can take, accurately identify what the client wants in terms of functionality, and be able to use as the basis from which to construct a technical specification and project plan.
When attempting to construct this 'requirements specification' functionality is divided into two distinct types:
- Be able to display all users who have made a purchase in the last week is an example of a functional requirement
- Page render times should never rise above 500 milliseconds would be a non-functional requirement
Functional requirements should specify particular behaviours of a system, whereas non-functional requirements impose constraints on the design or implementation of the system [wikipedia - http://en.wikipedia.org/wiki/Functional_requirements]
The client should then sign off this requirements specification at the beginning of the project and it would be made clear that this set of requirements will subsequently form the basis of the technical specification and ultimately final deliverable project. It should be made clear that subsequent functionality would be scheduled for post release and separate quotes, specifications and project plans drawn up as such.
In reality there will often (if not always!) be an instance where a client wishes to add functionality at a later stage during the project build, this should be managed on a case by case basis and its potential implications on the project plan measured.
The functional specification
In essence the document simply needs to contain a list of the functional and non-functional requirements for the system. These can be ordered or grouped if necessary. Each requirement should be identifiable by name or reference, and have plain text descriptions and rationale associated. Use cases can also be used to demonstrate requirements which may be part of a complicated work flow etc. In a real world example however use cases often prove more work as a form of communication between the developer and the client, and can provide invaluable when attempting to accurately identify specific features and workflows so that they may be correctly documented.
Functional requirement
| Ref: | X001 | Title: | User storage |
|---|---|---|---|
| Description | |||
| A user should be able to store a collection of items within their wish list | |||
Non-functional requirement
| Ref: | Y001 | Title: | Operational platform |
|---|---|---|---|
| Description | |||
| The application should run on top of the standard Apache, MySQL and PHP setup which is currently available | |||
By creating a template for this document a comprehensive list of the application requirements could be rapidly put together, grouping often helps to identify specific sub-sets of the application and such organisation can help to identify missing functionality.
This process is an inherently iterative one, there may be a number of revisions to the document and additions to the functionality but it is important to try and outline a full set so that the project design phase be as accurate as possible.
Once the requirements specification has been completed then the project can enter its design phase and a detailed project plan can be produced to guide the production
Resources
- processimpact
- View the site - Various resources and articles on requirements engineering, of particular note is "When Telepathy Won't Do: Requirements Engineering Key Practices".
- Wikipedia - Requirements analysis
- View the site - Wikipedia description of requirements analysis.