Example of Agile Requirements Capturing

In software development it is often not until the users have something in their hands, have been shown or given something, some kind of tangible outcome, software, screen with links to a dummy content, etc, before they only begin to realise what they actually need. The requirements are painstakingly being elicited from them and gradually narrowed down to a form that would be satisfactory for their purposes. It might be rather a long process and end users need to be fully involved right from the start of the project.


In the example below, the client (large welfare organisation) wanted to develop a system for managing casework information about their clients first, but with each step in the development process they realised that they actually needed a functionality that would encompass their other departments.

So the database was developed with this in mind: that it will most likely have to be used for other purposes as well. Some requirements were 'hard logic' (for instance, some of the output had to be used for reporting to government agencies and so the information had to be 'compatible'.
Most other requirements however were 'soft'. The end users didn't have much clue in what would be on the screen when they actually see the clients and how they can view, record, sort, and maintain them. They also weren't very clear on what kind of information should be included. Some users worked with only partial information about their clients while others worked with other information. This had to be put into a cohesive whole. User stories were very helpful in showing what information the users actually work with and that was included in the main database.

Casework has so become the core of the system with the main information about clients concentrated in the main table with a foreign key linking it to other, let's say subsidiary tables containing other information such as case notes, treatments in clinic, educational courses clients were enrolled in,
Additionally there were other unrelated or separate tables of information to be created when users later discovered that Intake - their room booking system was to be part of the system as well. There were about hundred and fifty rooms where clients were checking in and out. Similarly they later wanted their daily 'communications book' - one used by the reception staff to record incidents or any important information for following shifts as this was a 24/7 workplace.

There were multiple users to use the system and they would be constantly changing with many staff leaving and new staff coming on board. All recorded piece of information was to have its 'owner' or creator and most of it, once recorded was to be kept in its original form.

Simplicity was another 'big' requirement with special emphasis put on lightweight functionality instead of any impressive graphic. The project was carried out with one of the Extreme Programming most fundamental values in mind: simplest solutions were developed first and additional functionality was being added to it later.

As for the design of the product, the users were not sure and did not have any specific requirements. In the end the company's logo was taken into account and users agreed the screens would be stylised to go hand in had with that. This was one of the easier ones.

One of the most challenging aspects of developing this system was how to bring about 10 years of previously recorded information into the one system especially because it was not many different formats and needed to be 'reconciled' into some agreeable form. The form had to be elicited from the users gradually.

Interviewing users and close observation of what they do and what processes they follow in their daily work with clients was the key to proper understanding of the requirements. It was not possible to get stories from all the users and so they were categorised by department and rank.
Once user requirements took a more tangible form, system requirements were drafted. With the initial scope of the system known everything pointed in a direction of a lightweight solution such as PHP/MySQL.

The project went on with weekly iterations. Something was brought to the table each week and discussed further with user representatives from each department.