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 Diagram and 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 management overview

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.