To define the scope we need to understand what the parts of the user base look like,
and what each part requires. For example lets say ABC Inc. (a supplier of something)
needs to collect data or orders from web customers who fill in a form.
- What will the users expect from the system?
Often the actual capture person (or a web customer in the example)
has the simplest requirements for example:
- A nice looking form to capture their response.
- A report or summary page showing what was captured before confirmation.
- A well formated email to the customer, basically a letter for their own records.
- What will other parties expect from the system? In our example ABC Inc. themselves will have much more complex needs:
- Perhaps a Respondent analysis screen, that breaks up the respondents by category.
This of course immediately implies that the category should have been a pulldown or a list so
that the data is consistent (or alternatively that proper data validation was done).
Although ABC Inc. has a clear list of the present categories,
they think they might add to it in the future. This means we should store the categories as
data in the database, which in turn brings us to the requirement for a category maintenance form.
Notice how quickly we found some need for additional features. If we want to restrict the
ability to add a new category to certain individuals, we suddenly need some form of security,
and the requirements just grew by another big step.
So we start by listing what everybody expects/requires from the system.
This is a list of possible people to interview in our example,
every company is going to be a little different.
- Project Sponsor (more about this person later)
- High Level End Users. For example ABC Inc has a strategic planning manager
who requires information about the change in customer spending patterns.
- Middle Level End Users. For example ABC Inc has a production department head
who requires some reports to assist in the preparation of weekly production schedules.
- Workers, in our example they may need to view the customers input combined with
the in-house stock numbers.
- Depending on the nature of the system, it may be important to discuss the system with
the auditors. Some bigger companies will have both internal and external auditors.
Getting useful feedback from auditors can be difficult as they seem to prefer to be
told what is planned and then find flaws rather than actively offer suggestions early on.
Also remember that auditors may well charge for their input, at a rate that requires
careful budget consideration. Despite these difficulties, speak to the auditors anyway,
they sometimes have the power to veto a project if they feel excluded.
- Speak to the internal IT department too. This can occasionally be tricky.
If you are an external provider, the internal IT department may want to push you aside
in favor of developing the system themselves. Remember that it is the clients call,
and the client is the one who gets to break the news to IT, and this should be made clear
before the project commences. The IT department will however have some
standards/practices that will need to be adhered to and this may impact the system design.
- You might even speak to some of the customers of ABC. Especially if there are
some big corporate customers. Would they like anything from the system?
Perhaps previous systems lacked in some way, and could be improved upon.
Its a common mistake to concentrate on one group of users more than on others.
If we gave insufficient attention to our Production Department Head (above) we
might miss that (s)he needs to set the order in which the customers are helped.
Spend some extra time with the less sophisticated users.
This is especially important for IT projects. Some extra thought about usability
at an early stage (and for that matter throughout the development stages) can
make a big difference in how easy it is for less skilled people to use the system.
These are the users who are likely to do the unexpected. If the unexpected causes a
system crash, or just bad data (which is arguably a worse scenario), you may end up
adding on extra checks late in the project.
All companies have business procedures and practices.
These procedures and practices will form part of the requirements for the new system.
Procedures and practices are often tiresome to the employee but are very much required
for the on-going smooth running of the company. To ease the burden on employees
(and to reduce the risk to the business), many practices can be enforced by IT systems
(you cant do x until someone else does y).
- Be careful when replacing an old system
with a new system. There are probably outdated practices embedded in the old system.
This deadwood can be safely removed.
- If the old system was ever any good, there will be many currently valid practices
embedded in the old system which definitely need to be included in the new system.
- Watch carefully for practices embedded in the old system that were only
required to support the old system and not to support the business.
Sometimes the users will have a hard time believing that these practices will fall away.
- Also watch carefully for important practices embedded in the old system that the
users have long forgotten.
- Be especially careful if there is no IT support for the old system
as no-one will be able to spot these forgotten practices.
This is when a good Business Analyst must step in and fill the gaps.
- Some users of an old system will have become very attached to the old way of doing things.
Careful and thorough re-training is going to be especially important for these users.
Costing & Resourcing Planning