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:

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.

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?'

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 this set of symbols, and each one is explained below.

Process

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.

Context diagram

Data flow diagrams comprise a hierarchical set of diagrams . The top level is called a Context Diagramand provides an overview of the whole system. It shows how external entities interact with the system and the information flowing between them. Data stores are not used on a Context diagram as the internal structure of the system is not shown at the top level.

The next level down is called a Diagram 0 (also referred to as top–level DFD).

This shows the major processes of the complete system and contains all of the external entities and data flows from the context diagram. It also shows all of the data flows between the processes in the system and the data stores where the data is held.

A context diagram example

Look at a simple system for booking

appointments.

The system can be broken

down into the following

processes:

Obtain appointment time.

Check availability.

Book appointment if available.

Suggest alternatives if not available.

Obtain alternative time (repeat from 1).

DFD diagram for the processes for making

an appointment.

Activity: Create a Diagram 0 for the

following system.

In a payroll system the time cards are submitted by the employees, pay cheques are issued to the employees, and information on the employee is given to the Tax Department. Further investigation reveals the following major functions:

Hours worked are verified against the time card file.

Salary deductions are calculated using the tax table file.

Pay cheques are prepared and sent to the employee.

A tax report is prepared and sent to the tax department.

Network diagrams A network diagram is a schematic depicting the nodes

and connections amongst nodes in a computer network or, more generally, any telecommunications network.

Readily identifiable icons are used to depict common network appliances e.g. Router, and the style of lines between them indicate the type of connection.

Clouds are used to represent networks external to the one pictured for the purposes of depicting connections between internal and external devices, without indicating the specifics of the outside network.

Depending on whether the diagram is intended for formal or informal use, certain details may be lacking and must be determined from context. For example, the sample diagram does not indicate the physical type of connection between the PCs and the switch, but since a modern LAN is depicted, ethernet port may be assumed. If the same style of line was used in a WAN (wide area network) diagram, however, it may indicate a different physical connection.

Data dictionaries

A data dictionary is a centralised system for defining and storing information about the data and the processes that transform the data in some way.

Each data flow and data store will be defined based on the data elements that it contains. The processes will be defined based on what they do to the data flowing into them and what data flows they create.

CASE tools

CASE (Computer Aided Software

Engineering) tools are software packages

that help to automate software

development. This may cover all phases of

the development life cycle.

CASE tools can be used to create data

flow diagrams and the data dictionary.

Most CASE products have the

following components:

Diagramming

tool

Diagrams can be easily drawn and

arranged using standard symbols,

such as DFDs

Design Analyser Assists in data analysis, checks for

consistency and completeness

Application

generator

Automatically generates an application

from design by code generation

and/or database definitions

Central

repository

Contains all definitions of functions,

processes, data and rules, in other

words, a data dictionary

Confirming client requirements

In the initial phase of a project a preliminary analysis of the information that you have put together occurs. Once this is done, you need to take a more in–depth examination of the information you have gathered to confirm with clients that the:

client needs you have identified are correct and complete

client expectations are in line with what is achievable.

Client needs are requirements that the client must have to run their business. They are the minimum requirements.

Client expectations, on the other hand, are the difference between what the client wants (and usually thinks they are getting) and what the client needs.

Depending on the methods you used to collect

your information, you will have numerous

documents, interview feedback, questionnaires,

emails, observation notes, product information,

data and other supporting system information.

You need to analyse this information in

depth to verify that the information:

falls within the scope of the project

covers functional, quality, constraints and

added–value requirements.

Is the information within the project

scope?

The project brief is a statement of the scope of the project. During the data–gathering phase you will collect whatever information the client provides and then cross–check it to determine if it fits within the project scope.

You will invariably end up with information that falls outside the project scope as defined in the project brief, and in this situation you may need to negotiate with the stakeholders to reach an agreement on what the project will deliver to the client and what will not deliver.

What is agreed to be delivered to the client is what is within scope and what is not being delivered is outside of scope. This may mean that the scope will need to be revised to cater for the negotiated agreement.

Does the information cover

functional requirements?

Once again, you need to cross–check the information you have gathered to ensure it covers the functional requirements completely. Functional requirements deal with business processes and data. You can use the following techniques to assist you in determining whether the functional requirements have been covered:

data flow diagrams that show how the data moves through a computer system

data models that show the structure of the data, for example the fields in a database

process descriptions

prototypes – a small working sample of the larger computer system or web page.

You will need to go back to the client to confirm the details where there are gaps in the information.

Does the information cover quality

requirements? You also need to cross–check the information

you have gathered to ensure it covers the quality requirements. Quality requirements are things like:

conformity with functional requirements

system outputs

performance

reliability

maintainability

security

usability

efficiency

interoperability

portability.

Does the information cover

constraints? You also need to cross–check the information you have gathered to

ensure it covers the constraints. Constraints are physical things or issues that act as a hindrance to the completion of the project. They are things like:

costs – is the budget sufficient?

deadlines – can we meet the deadlines?

technology – is the technology appropriate or do we need to investigate new alternatives?

platforms – will the product run over numerous platforms?

staff – do we have enough staff?

organisational policy – will compliance with organisational policy slow the project down?

Legal/statutory impact – will compliance with legal requirements impact on the project?

You will need to go back to the client or the IT department to confirm the details where there are gaps in this information.

Where statutory issues are involved, statutes that govern some aspects of the business requirements might need to be considered.

Statutory bodies expect you to seek out and recognise any laws that the system must comply with.

It is a legal requirement of statutory bodies that any changes to legislation must be published and publicly accessible

It is also important to be aware of the industry standards that might have to be taken into account.

Most industries have co-ordinating bodies such as industry associations which can be very helpful in guiding you in making decisions in relation to change.

Does the information cover added–

value requirements? You also need to cross–check the information you have

gathered to ensure it covers the added–value requirements.

Added–value requirements define why the client is undertaking the project. They are the elements of the project that add value to the final system as defined by the customer. They are things like:

financial benefits

increased productivity

improved customer satisfaction

any other improvements the client considers value–adding.

You must agree on the added–value requirements with your clients. Some compromise and conflict resolution may be required as clients may have different ideas on what constitutes value in the final system.

Does the information cover

strategic requirements?

Strategic direction is something that is set by upper management. It refers to the strategy the business will undertake to steer it through its planned future course. In order to formulate a strategic direction, upper management needs to take into consideration the current circumstance of the organisation.

Confirm the client happy with your

analysis You have analysed the client's needs. Now you need to

write a report based on your understanding of the client's requirements. However, did you get an accurate picture of these requirements?

You or your colleagues need to go back to the client and check that they are indeed satisfied with your analysis.

Examples of the types of questions to ask are listed below.

Does my report accurately:

reflect your explanation of how your job operates?

describe what the tasks and deliverables of your job are?

relate these tasks and deliverables to the key business outcomes of your organisation?

portray how you interact with other people and tasks in your organisation?

Information you need to provide to

your client

Tell the client whether you (or your organisation)

would be able to meet their requirements.

Let them know of other options or possibilities of

which they had not been aware.

Provide the client with any information that will

help them understand what they're getting into

before you go ahead with the job (or project).

Document functional requirements

To do this you should now:

organise the functional requirements into an order of priority, for example:

Absolutely vital

Very desirable

Could be useful but not important

identify current volumes of data and anticipated growth. – will the proposed system handle the growth?

identify those functional requirements that are complex, have a high dependency on other functions or have a particularly high frequency of use – these may need special attention to make sure that you get them right.

Document non functional

requirements

These will include the quality, strategic

and added–value requirements, and the

constraints, as discussed in the previous

section.

Document any transition issues Transition issues are those that are not business requirements but

must be included in order for the new system to be successfully implemented.

Training

When any new system is implemented, clients will usually require some form of training to bring their competence levels up to the required standard. You need to document any training the clients may require, including documentation to be provided.

Organisational structure

In some cases the implementation of a new system will result in changes to the organisational structure. Where this occurs you will need to:

identify where the structure has changed

have the organisational chart updated accordingly.

Existing systems

If the new system is going to impact on existing systems, you need to:

identify the affected systems

determine the degree of impact of the new system

document the impact on all existing systems.

Report to senior management and

technical specialistsWhere a new system is going to impact on the

organisational structure, existing systems or user competence, you must formally report these requirements to:

senior management

technical specialists.

Management will be particularly interested in the impact on the organisational structure and staff but not particularly interested in the technical aspects. Keep the technical elements to a minimum and use business–like terminology.

Technical specialists will be particularly interested in detailed technical requirements but not so interested in the impact on the organisational structure and staff. Ensure the technical elements are detailed using terminology appropriate to technical specialists.

The requirements document

The requirements document is the official statement of what is required of systems developers. It is not a design document. It should say WHAT the system should do rather than HOW it should do it.

It is a formal report which details all that has been learned and concluded about the system and is the starting point for Systems Design. It will also be the basis for a managerial decision on whether to continue with the project. It acts as a contract of deliverables to the end users and as such all key stakeholders will sign off this document.

Since the requirements document contains the details of what the client has asked for it will also serve as a reference document for testing the system in the future.

Your organisation may have a standard layout for

this type of document, but it will usually include:

an introduction

a management summary (executive summary)

a sign–off sheet

a version control table

a glossary – define all the technical terms that may cause confusion

background to the project

functional requirements, with attached priorities

non–functional requirements

external interfaces

Management Summary

This should be a concise summary of the main points of the document. Management will be interested in:

the facts needed in order to make a decision; note that supporting details for these facts are found elsewhere in document

the objectives of the system

an outline of the developmental efforts to date.

The management summary is normally two to three pages in length and usually the last section of the document to be written, as it provides an overview of everything in the document.

It is sometimes called an executive summary, or managementoverview

Summary Some client requests and requirements are quite

straightforward. Others, however, can be quite complicated and will need a lot of thinking through on your part as well as your client's.

You may have heard of technology purchased by an organisation that ends up being hardly used. Or equipment purchased (eg by isolated communities) that breaks down and then is left to rust because parts are not easy to get and the experts are all in the city. You may have heard of systems that are set up that fail to meet the organisation's needs or soon get outdated.

In these cases, the client may not have had a clear idea of exactly what was required and may have asked for something they thought they needed. Or the 'expert' or supplier may not have accurately determined or analysed the client's needs.