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.
No comments:
Post a Comment