Reading: Gather and record client requirements data
Gather and record client requirements data
Inside this reading:
Who do you need to talk to? 2
What information are you looking for? 2
Gathering the information 4
Storing and retrieving the information 9
Summary 12
Who do you need to talk to?
To gather the information that you need about a system, you first need to identify who has this information and who the ’stakeholders’ in the system are.
A ’stakeholder’ is a person or organisation that has a legitimate interest in a project or entity. Stakeholders may include:
· Clients (to ensure the project fits the brief)
· End users (to ensure their needs are met)
· Finance managers (to keep an eye on cost)
· IT staff (to ensure fit with existing systems)
· Management (to monitor project outcomes)
Once you have a list of the stakeholders it will be possible to create a plan of how to go about obtaining the information you need. Putting the plan into action will involve carrying out the gathering process, and ensuring that you have covered all the areas identified. When the information has been collected it must be recorded and stored in such a way that it can be easily accessed and understood by the project team and stakeholders.
What information are you looking for?
Your final requirements specification will need to cover the following areas:
· functional requirements – what will the system do (and for whom)?
· non-functional requirements – what constraints are there?
· interfaces to the system – are there other systems it needs to talk to?
· priorities – what are the most important things?
Functional requirements
Functional requirements describe what the problem is without getting into how a solution would work.
Examples of functional requirements are:
· The system will produce a monthly sales summary report.
· The system will notify the inventory manager immediately when the stock level of an item drops below 110% of its minimum holding level.
Non-functional requirements
Non-functional requirements are constraints on the system and are often neglected until the system has been implemented, which can be too late to cater for them.
In an IT environment non-functional requirements can relate to:
· the performance (speed) of the computer system
· up-time (i.e. how reliable is the system?)
· the physical environment and interfaces with other systems
· other human factors (how user friendly is it?)
· the documentation and training that will be required to use the system
· system resources (hardware and software)
· what security issues need to be considered
· how to measure the quality of the system being produced.
Examples of non-functional requirements are:
· The system will return from all product searches in less that five seconds.
· All users will have to log on for access to the system, and log on again after ten minutes of inactivity.
· The system will have to be online 24x7 (24 hours a day, 7 days a week) with a greater than 95% up-time.
Users of the system will probably not think of these things but it is important for you as the analyst who is gathering the requirements to make sure that they are covered.
Interfaces to the system
In the earlier stages of a project you may create a context diagram to illustrate how data will be processed by a system in terms of inputs and outputs. During the information gathering stage you will flesh-out this diagram with more detailed information about the other systems that your proposed system will interact with.
You could use a form with the following headings to gather information about these interfaces:
Name of system / Description of the interaction / Frequency of interaction / Technical issues / Nominated liaison personTable: Headings for information gathering
Priorities
Make sure that you incorporate priority ratings in your information gathering phase. This may be a simple numbered priority where 1 is ‘essential’ and 3 is ‘nice to have if possible’.
This is not as easy as it sounds, as business users may classify everything as either ’crucial’ or ’not necessary’, depending on their perspective. Remember also your judgement may play a key role in determining priorities, particularly if you are working with clients who know very little about the systems to be introduced. For example, you may see from the client’s requirements that they will definitely need to upgrade their server, but the client might consider this an unnecessary cost.
It might be useful to ask your stakeholders which order they would have the functions delivered in, if they were to be delivered one at a time.
Gathering the information
Now that you have identified the stakeholders of the system and the information that you want to collect, you will need to plan how you will gather that information from them.
You should identify each stakeholder from whom you are going to collect information, the information you require, the method you are going to use, and when and where the collection process will take place. A table could be used to record these details, as follows:
Stakeholder / InformationRequired / Collection Method / Collection Date/Time / Collection Location / Comments
Ben Davies, Head of Teaching department / Departmental statistics reporting details / Interview / 20th June, 2.30pm / Head Teacher’s office
Mary Blake, teacher / Grading details for data entry / questionnaire / Response by 25th June / Sent via email, 18th June
Adam Dimos, teacher / Grading details for data entry / questionnaire / Response by 25th June / Sent via email, 18th June
Carl Mendoza, teacher / Grading details for data entry / questionnaire / Response by 25th June / Sent via email, 18th June
Dan Jones, enrolment officer / Enrolment procedures / observation / 21st June, 10.00 am / Enrolment office
Table: Example of a table listing information gathering details by stakeholder
Create the plan
Now put these activities into a plan. This will give you an estimated finish date for the information gathering stage. By doing this you can ensure that this fits in with the sponsor’s expectations about the length of the overall project. By planning ahead, you have time to change your approach if the time-frame is not acceptable.
A project planning tool such as Microsoft Project can be used if you have multiple tasks to manage.
Some important things to consider are:
· put tasks in the plan for resolving conflicts that may arise
· check with the stakeholders that they are available for activities that involve them. If the users have a busy period planned right in the middle of the time you plan to interview them, then your plan is probably not realistic.
An example of a plan is shown below.
Figure. An information gathering plan with Gantt chart
Research—Gantt charts
How familiar are you with Gantt charts? A Gantt chart is a popular type of bar chart, that aims to show the timing of tasks or activities as they occur over time. Find out more by looking up ’Gantt chart’ on Wikipedia: en.wikipedia.org
Trial the process
In some situations the effort involved in gathering information will be substantial. You may be creating a questionnaire and distributing it to hundreds of individuals. If you get it wrong then you may not have the time or money to have another go.
Check your technique out on a selection of users that represent the population from which you need to gather information. Repeat this process until you are satisfied that you will achieve your objectives as shown below.
Figure: Trial your technique before gathering information
Reflect
You are working on a project to create a web site providing information on child safety products. You have created a questionnaire to find out what sort of information would be useful and would now like to trial it on a small group of stakeholders. What sort of people would be your main stakeholders? Where might you find a suitable sample for your trial?
Your main stakeholders would be parents of young children. You might consider carrying out your trial at a child care centre or kindergarten, since these are places that large numbers of young parents visit.
Stages in information gathering
As you progress through the process of gathering information, the emphasis will change.
Initial gathering
When you begin to gather requirements, you are not likely to understand the requirements yourself. This first stage will involve you collecting information from different users and getting it clear in your head.
It is a good idea to start at the top of the organisation and work your way down. As you move down the organisational structure the information you are collecting will become more detailed. For example, the director of finance will tell you about the future direction that the finance department is heading but it will be the accounts clerk that gives you details of what data is entered into the daily accounts receivable process.
In this stage, questionnaires and one-to-one interviews are a good way to collect information.
Adding detail
As you are adding detail there will inevitably be things that you realize you don’t have enough information about. Questionnaires, via email, could quickly provide answers to specific questions. If you find that there are some major issues or areas that involve several departments, then a JAD (Joint Application Development) session might be the quickest way to obtain that detail. JAD is a formal structured technique used to gather information in a group.
Research—JAD sessions
Find out more about JAD (Joint Application Development) on the web. Use your preferred search engine (such as Google: www.google.com.au) to search for information on ’ Joint Application Development’. Think about how you might use this technique in gathering client requirements.
Resolve conflicts
When the requirements are beginning to mature – say 80% complete, there are likely to be conflicts. Your plan should allow for these and include some techniques and time to resolve them. JAD sessions may also be of value here if you are able to bring together the key stakeholders in an environment where the conflicting issues can be sorted out as quickly as possible.
Understand the obstacles
Some problems you may face when gathering requirements are:
· you will need to navigate through an organisation to find the people who really understand the problem
· contradictory statements may be made by different people
· different people use the same term to mean different things
· many organisations have reams of written documentation that you will need to sift through
· restricting people to talking only about the problem that the proposed system is solving can be difficult if they have lots of frustrations about other systems-related issues.
The barriers to users cooperating with you are generally a combination of:
· a fear of change
· past systems failures
· not understanding the computer jargon used
· poor listening skills.
While there are no easy solutions to these issues, understanding where the users are coming from is the first and most important step in gaining their trust and cooperation. Some tips are:
· consider the user’s backgrounds – technical abilities and business expertise as well as their confidence about keeping their jobs
· where there is a need, ensure that there is professional support for users who are likely to struggle with change
· make the system requirements easy to understand from a user perspective at each stage of your gathering process. Keep users up-to-date on what is happening in the project
· structure all your documents simply
· keep your activities consistent and recognizable (transparent)
· make sure the process is flexible so that users can contribute changes as required.
· make sure that when the time arrives to make a commitment that it is not sprung on them – they expect it in advance and it seems fair.
Reflect
You are interviewing an elderly clerk about her requirements for a new computerised inventory system. She is reluctant to provide you with definite answers and seems quite stressed. Eventually she admits that she is concerned that she will not be able to operate the new system effectively – she hasn’t used computers before and feels that at her age she will be too slow to pick it up. What sort of support might you consider in this situation?
Feedback
You could explain that the system will be new to all of the staff and so everyone will need to learn how to use it. Reassure her that there will be training provided and documentation which she will have with her when she is using the system. Mention the fact that since she has been using the current system for so long she is uniquely positioned to provide you with the information to ensure that the new system will operate as simply as possible. Make sure that you follow up on this when identifying training requirements.
Keeping track of changes
As you go through the process of gathering requirements you will find that changes will inevitably occur. It is important to keep track of and document these changes. To do this make sure that each document that is produced has a version table at the front which lists:
· the version number of the document
· who made the changes
· a short description of what the changes were
Storing and retrieving the information
Recording the information
Now that you have gathered the information you must make sure that you record the details.
Reflect
How many times have you listened to a speaker and told yourself that you would remember the details of the talk, only to find that by the next week you had forgotten a significant amount?
The only way to make sure that you remember all of the important points of an information gathering exercise is to write them down.
The best option is to record them at the time that they are being gathered, but if this is not possible then you should make time to do it as soon after the event as you can, preferably the same day.