Analysing the requirements

The first stage in the application lifecycle is where you need to accurately figure out the goals your application must achieve in order to be considered successful. As you can imagine, if this step is not completed correctly, or, worse, skipped altogether, the result might be a product that is wholly unsatisfactory for the end user.

The amount of analysis you should do naturally varies as to the size of the project under construction. For larger applications you will almost certainly need to take into account the views and requirements of users who have contrasting goals - some may want feature X, but others might hate feature X and ask for feature Y. Fortunately, it is usually outside of our remit as developers to decide what features should be in the final product - your best bet is to produce a system spec based upon what has been asked for, and ask the management staff at your client to make the final choice.

The most basic level of analysis involves creating what are known as use case diagrams, which are a small part of the Unified Modelling Language (UML). Each use case diagram is a simple sketch designed to convey one complete action from a user's point of view - for example, adding a user to an authentication system is one complete action, that would involve the user presumably clicking a link from a menu called "Add user", filling out various fields, a little data validation, and finally the new user being added to the system. The diagrams themselves are usually remarkably childlike in appearance, because the quality of your artwork is not what is important.

Use case diagrams can be as complicated or as simple as you want, and can also be used to model relatively specific tasks such as the one above, or more general tasks such as a use case diagram for Quake 3 that states "Start game, kill monsters, end game". You will likely find that the more specific you are able to be at the analysis stage, the less chance you have of ending up having to rely on assumptions at a later date - assumptions that might, of course, prove wrong.

Other important parts of your analysis should include a full examination of any existing system that is already in place, with particular emphasis on what staff members think of the system - what they like, what they dislike, etc. For larger projects you should conduct formal interviews in order to gain a complete understanding of the current implementation.

A crucial characteristic of the analysis stage is that it should include as little technical information as possible. At this stage your primary goal should be to understand what the ideal system should be, within reason. As you can imagine, most non-technical people will mentally switch off at the merest mention of a database schema!


Next chapter: Designing the solution >>

Previous chapter: The design process

Jump to:


Home: Table of Contents

Copyright ©2015 Paul Hudson. Follow me: @twostraws.