Inside this reading:
Analysing client requirements2
Data flow diagrams3
Confirming client requirements15
Documenting client requirements22
Analysing client requirements
Before you can start to analyse the information you have gathered you should think about what you are trying to achieve. The client has presented you with a business problem. In order to solve this problem you need to undertake the following steps: •identify what the current system does
•identify the new features the client needs in order to solve the problem •combine the outcomes of steps 1 and 2 to come up with the requirements which will solve the problem. The information that you have gathered should cover steps 1 and 2. It is important that you identify what information is part of each of those steps so that you can structure the requirements in a logical sequence. This will make it easy for the client to understand the process. You need to look at the information and ask yourself questions that will help you to: •clarify in your mind what the client requires
•structure the bits of information given to you by the client •organise the bits of information the client has given you •check with your client that you have done a sufficiently thorough analysis of the client's needs. Some questions you might ask yourself are:
'What happens if the information about products or services requested is not available either before or after installation?' Sometimes you need to ask what–if questions (hypothetical questions) in order to explore possibilities with the client. You'll also be able to bring out any reservations that you or the client may have. 'Have you specified and documented these information gaps? How will they affect the client?' This is a probing question that follows from the first question above. Probing questions go deep into the issue or problem. They aim to dig out insights and uncover underlying causes. 'From what the client was saying, some of the requirements of their human resources department coincide or are similar to the accounts department's needs. Now exactly what is the relationship here?' Often, you need to ask questions like this in order to clarify and structure information. Without a structure, the information would just be bits and pieces without any discernable patterns. With a good structure, you'll be able to see trends or themes, i.e. see how one bit of information fits in with others. Data flow diagrams
Design models can help you to organise the requirements in an easy–to–read, orderly way that can help you to recognise key features of the existing and planned systems. This modelling process is an important part of the analysis phase, since it will help to uncover areas of the system that you may not have considered, or questions that you do not have answers to. Process modelling
Process modelling uses a graphical representation of the processes in a business system. There are different process models but one of the most commonly used is a data flow diagram (DFD). Although there are different symbols used by different companies, we will be using the following set of symbols, and each one is explained below.
Figure 1: Data flow diagram symbols
A process is the task or action/s performed on data in order to: •store the data
•perform a calculation
•distribute the data to other components or systems.
At the requirements stage of a project we are only concerned with describing what business processes are performed, not how they are performed. This is often called a logical model of the system. The DFD we create at this stage therefore will not distinguish between manual or computerised processes. Data store
A data store is the location in which data is kept. This may be in a filing cabinet, a file on a computer hard disk or database program, such as Microsoft Access. In...