Systems Analysis - Information Requirements and Fact-Finding

A company may decide to go ahead with a project after considering the Feasibility Study. They will agree a date for the next stage in the project life cycle to begin. This is known as the 'Systems Analysis' stage. During this stage, the Systems Analyst will investigate the problem in much more detail than was done for the Feasibility Study.

A Systems Analyst must find out exactly what information the company needs to use in any proposed solution. They must also clearly identify why a company needs to keep each piece of data. Data stored but not used is a waste of resources!

  • Unused data has to be stored somewhere, taking up valuable storage space.
  • Unused data has to be entered into the system, which is a waste of input resources if it is never used.
  • Unused data can slow down data operations such as file retrieval.

Not only is it important to identify what data is not needed, it is important to identify what is needed and in what form the data is needed. For example, if a Systems Analyst is designing a mail order system and they don't identify that the company also sends out emails, they will not design email use into any new system. The company will not be happy when they realise that they cannot email customers anymore! If the company likes to also keep a record of how many times a customer buys a product, they will not be happy if they cannot do this anymore with the new system. The Systems Analyst could have identified both of these scenarios by simple fact-finding methods during the systems analysis stage. There are six fact-finding methods that could be used. These are:

  • One-to-one interviews.
  • Group interviews.
  • Collecting documents.
  • Observations.
  • Questionnaires.
  • Letters, emails and phone.

One-to-one interviews

A well-planned interview will involve: •Preparing questions. •Making an appointment. •Giving the person you are interviewing the questions in advance. •Carrying out the interview, ideally recording it if possible. •Writing up the interview for the appendix of the Systems Analyst's report. •Clarifying with the interviewee any points that the interviewer is not sure about, then updating the write-up. •Summarising the interview's findings for the body of the Systems Analyst's report. •Thanking the interviewee.

Interviews should ideally be held with the managers first, to get an overview of a system, followed by interviews with the users of a system, to find out the day-to-day operational problems. During interviews, the Systems Analyst can start getting a feel for what people want from any new system, what problems they want solving, what reports they want generating and so on. Interviews can be quite time-consuming to organise, especially if you need to do more than a few. They are very important to do, however, because details of the way things are currently done and the way people would like to do things can quickly be ascertained. They are also very useful because you can ask new questions based on answers you receive in the interview and you can explain questions if the interviewee doesn't understand them..

Group interviews

We have already said that doing lots of one-to-one interviews can be time-consuming. A compromise would be to hold a group interview. This could be done with the employees from a department, for example. They could all be called together and operations, problems and methods could be discussed. The Systems Analyst needs to understand that for many workers, introducing a new computerised system equates to redundancies and they will need to show skill in finding out what they need to know without upsetting anyone! While group interviews can save time, there is a danger that one or two people will dominate these events and that some people's views will be drowned out.

Collecting documents

An excellent way of finding out about the data used in any existing system and the way a company currently does things is to collect examples of documents that are used. These will show the names of data items, give examples of the items themselves and will prompt the Systems Analyst to ask employees questions about the data. For example:

  • Where did the data originate?
  • How is the data constructed?
  • Are there any synonyms used for any data items - different names for the same piece of data? For example, most people would call a car a 'car' but some might use the words 'auto or 'automobile'. You would, however, only want to set up one field for car, not three! Are there any instances where different names are used to describe the same piece of data in the system being investigated?
  • What is the range of allowable values?
  • What actually happens to the data on a document?
  • Who uses the data?
  • When is the data removed from a system and who does it?


Sometimes, what people say they do is different to what actually happens in practice. Sometimes, people simply don't mention things in an interview because they either forget or it seems too trivial to mention. A Systems Analyst can sometimes find out information by spending time watching people go about their job. People can be very aware of the presence of someone that they know is watching what they are doing and behave differently, although with skill and time, this problem can be overcome.


Questionnaires can be used to collect very focused answers to questions from a large number of people relatively quickly and without using up a lot of manpower (compared to interviews, for example). However,

  • Writing good questions in a questionnaire is very difficult indeed.
  • Most people do not return them.

An improvement, if resources are available, is to have someone 'interview' people using a questionnaire. The person interviewing asks the questions on the questionnaire and records the answers. If the person doesn't understand a question, it can be explained to them. More questionnaires will be completed this way.

Letters, email and phone

Phone calls can be useful because you can actually speak to the person you need to without having to spend time travelling to see them. Email is immediate compared to letters but whilst everyone can be sent a letter, not everyone has an email address. Even if someone has an email address, they may not use it and you may not realise they don't! Letters are more time-consuming to prepare and write compared to email, which tend to be written in a quick, matter-of-fact way. Both emails and letters give you answers in writing compared to phone calls, where you are relying on your ability to take good notes and understand what someone is telling you. Emails and the phone, and to a lesser degree letters, are especially useful to quickly clarify points made during an interview.

The Systems Analyst, then, needs to find out about current methods used and to find out all about the data used when investigating a problem in an existing system. If they are setting up an entirely new system, they still need to form a 'picture' of how any proposed business will do the jobs that need doing and will still need to fact-find.

Business | Systems

QR Code
QR Code information_requirements_and_fact_finding (generated for current page)