Analyse data and document client requirements

Inside this reading:

Analysing client requirements 2

Data flow diagrams 3

Data dictionaries 10

CASE tools 14

Confirming client requirements 15

Documenting client requirements 22

Summary 26

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.

[pic]

Figure 1: Data flow diagram symbols

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.

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 process modelling, the diagram simply shows that at specific stages in the process the data must be stored somewhere, and that the data must then remain in the data storage or be transferred to somewhere else.

External Entity

An External Entity, sometimes called a sink or source, is external to the system we are modelling and can be classified as a source or sink depending on which way the data is flowing.

A source is where the data comes from and a sink is where the data goes to. Once it has been processed, data or information leaves the system, and is dealt with outside the scope of the system. External entities can only be the starting point or endpoint of a data flow.

Data Flow

To illustrate the use of data flows, let us consider a very simple tea–making process that you would use to make a cup of tea.

|Resources and ingredients: |teapot, tea cup, tea, water |
|Where to get the resources and ingredients: |cupboard, china cupboard, pantry, tap |
|Steps: |boil the water, put tea in teapot, pour boiling water |
| |over the tea leaves, pour the tea into the cup. |

You can see how the information in the table can be represented in an easy–to–understand diagram in Figure 2. The table does not record the relationship between the data, processes and data stores.

[pic]

Figure 2 Process to make a cup of tea

Process of translating information into a DFD?

In the DFD in Figure 3 below, we can see that each process has been placed in an oval process symbol.

Then the processes were linked together to indicate the relationships between them. We can see that it doesn’t matter whether we boil the water or put the tea into the teapot first, but we must boil the water before making the tea.

[pic]

Figure 3 Relationships between the processes

Once we have figured out the correct sequence of events or processes, we then must determine what data or information passes between each of the processes. (see Figure 4).

[pic]

Figure 4 Data or information which passes between each of the processes

The next step is to identify the data that each process needs. For example, in order to boil water, you need to have some water to start with (see Figure 5).

[pic]

Figure 5 Identifying data that each process needs

The data that each process uses is called a data flow and the direction of the arrowhead identifies whether the data is flowing into or out of the process.

The only difficult part in creating this DFD is in knowing where to start and where to end.

Sources

What event created the need for the whole activity in the first place? Perhaps your mother asked you to make her a cup of tea.

Is the start of your system a source?

Examples of sources that you might come across in a computing context include:

• another organisation which sends data to or which requests data from the system you are investigating

• a person who is supported by your system, such as a client or customer

• another computer system which needs information from your system, or from which you need information, for example a finance system or a client–recording system.

If your mother had started the process, she would have been represented as a source in this diagram.

Most processes will be started by a source. In the previous tea–making example, it was a request from an unknown origin that started the process, which is why no source has been defined.

Anyone can ask for a cup of black tea without sugar, and the DFD would be the same. If you were in the business of making cups of tea, then the DFD would probably start with a source called Customer.

Sinks

Where does the outcome or output of your system go? In the above case, the cup of tea went to your mother. Whether she drank the tea or not, accidentally knocked it over or gave it to someone else is outside the system and is therefore represented as a sink.

Examples of sinks that you might come across in a computing context include:

• another organisation which requires data from the system you are investigating

• a person who is supported by your system, such as a client or customer

• another computer system which needs information from your system.

A real tea–making process is probably much more complex than this one, particularly if you were asked to make a drink requiring more steps than making black tea without sugar.

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.

If necessary it is possible to examine each of the processes on the Diagram 0 in more detail, that is, break the process down into sub–processes. This can be repeated until all of the elements of the process have been documented. Remember we are doing this so that we can ensure that we have understood the user requirements.

The activity of breaking a process down into sub–processes is called levelling.

A context diagram example

Look at a simple system for booking appointments. The context diagram for this system is shown in Figure 6.

[pic]

Figure 6 Context diagram for appointments system

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).

Figure 7 shows the diagram for the processes for making an appointment.

[pic]

Figure 7 Context diagram for appointments system

Guidelines for creating DFDs

There are a few guidelines to consider when creating a Data Flow Diagram (DFD):

A process represents an activity and must be labelled with a VERB and NOUN , e.g. check availability

• A data flow represents data and must only use a NOUN for its label, e.g. appointment

• All Data Stores must be named, e.g. diary

• Flow should be top to bottom, left to right

• Data cannot flow directly from one data store to another or from a data store to an external entity – there must be a process in between

• Every data store must have data flowing into it and out of it

To provide the necessary detail of the requirements you will now expand the descriptions of the data stores and processes. This can be done by using a data dictionary as the recording tool.

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.

A data store usually consists of records that represent entities that the system deals with, e.g. customers, parts.

Each record contains a number of fields, or data elements, each holding a particular piece of information.

The record for a customer, for example, would have fields for the person’s name, address, phone number etc.

The data dictionary will list every data element in every file used by the system. For each element, it specifies:

• the name, which should be unique across the system.

• a description of the data

• the type of data that it contains (for example, text, number, date, currency amount).

• rules about the range of values that the data can take ( for example, the element containing the hours worked in a day must have a value between 0 and 24)

Here is an example of the data dictionary entries for a Patient Records system.

Data dictionary – Data element description

System: Patient Records Name: PatientDOB

Type and length: Short Date Output format: dd/mm/yyyy

Default value: none Acceptable values: not greater than current date

Security: not applicable

Responsible user: Patient Records manager

Description: Patient’s date of birth.

|Data Dictionary – Data Store description |
|System: Patient Records Name: Patients |
|Description: Contains the patient details |
|Volume and frequency: 5000 total records ; 5 to 10 additions per month |
|Element Name |Description |Type |Comments |
|PatientId |Patient identity code |Number |Increased by 1 for each new |
| | | |patient |
|PatientName |First and last name |Text | |
|PatientDOB |Date of birth |Date |Must be less than current date |
|PatientSex |Sex of patient |Text |Single letter, must be M or F |

|Data Dictionary – Data Flow description |
|System: Patient Records Name: BillingAddress |
|Description: The billing address of the patient |
|Origin: Patient |
|Element Name: |
|PatientAddressLine1 |
|PatientAddressLine2 |
|PatientSuburb |
|PatientState |
|PatientPostcode |

Data Dictionary – Process description

System: Patient Records Name: Create Bill

Description: Determine the amount owing by the patient and produce a bill.

1. Access the Services record to obtain details of the services performed.

2. Calculate the total amount for services performed.

3. Access the Patients record to obtain the patient’s details and billing address

4. Create a bill containing the service details and amount owing.

Input data flows: BillingAddress, ServiceDetails, PatientDetails

Output data flows: PatientBill, AmountOwing

The data dictionary can be recorded:

• on paper

• in a table in a word processing document

• in a spreadsheet table

• using the analyser feature of a database

• using a specific documenting tool such as a CASE tool.

When you are selecting the recording method to be used keep in mind that it will have to be updated and so should be in a format that will be easy to maintain.

Recording processes

What processes do, and how they do it, also needs to be recorded. The DFD shows the process as an activity but to actually carry out that activity will usually require a series of steps to be undertaken in a specific sequence. In the tea–making example, there was a process that was labelled ‘Boil water’. To carry out the ‘boil water’ activity there are several steps that you would have to perform, including:

• Get the kettle

• Take the kettle to the tap.

• Turn on the tap.

• Fill the kettle to the correct level.

• Turn the tap off.

• Plug the kettle into the power socket.

• Turn the switch on

• Wait for the water to boil.

• Turn the power off.

As you can see, each of the steps above must be done in the correct sequence or the water cannot be boiled.

You will need to record these steps and the sequence that they must be performed in to make sure that you understand exactly what the new system will need to do.

There are a number of ways of describing a process, one of the most popular is Structured English.

Structured English

Structured English is a modified form of English that allows you to describe processes and procedures. Structured English consists of nouns (the names of data elements and variable quantities) and verbs (such as read, write, print, move, etc).

Structured English is used to describe a set of steps in a shorthand way that is fairly simple to understand once you are familiar with the conventions. If you are familiar with programming languages or scripting languages, then structured English will be very easy for you to read.

In its simplest form, we can represent a sequence of actions by using structured English similar to the following:

BOIL water

PUT tea in teapot

POUR boiling water into teapot

POUR tea into cup

We simply start at the top of the instruction list and work our way down to the bottom.

The words in uppercase italics are verbs that tell us what action to take. The nouns following the verb tell us what to apply the action to. Consider the following example of structured English:

IF teapot is NOT empty

THEN POUR tea

ELSE APOLOGISE

What do you think that this structured English statement does? This statement is a conditional statement. This means that we have a specified condition teapot is not empty. The conditional statement tells us what to do if the condition is met, or what to do if the condition is not met.

A description of the ‘Boil water’ process in the above example might look as follows:

GET kettle

IF kettle is empty

THEN TAKE kettle to tap

TURN tap on

FILL kettle

TURN tap off

ELSE

PLUG in kettle

TURN power on

END IF

WHILE water is not boiled DO nothing

ELSE IF water boiled

THEN

TURN power off

END DO

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 |

All features of the CASE tool should reference the dictionary to check for consistency. In integrated dictionaries, changes in one part of the CASE tool are automatically updated in the dictionary. For example, a change to a data flow in a DFD would be automatically updated in the data dictionary.

CASE tools provide a powerful documentation feature that can be used through all phases of the development. The management of text and diagrams in a large system is difficult. The requirements may change through the phases of the development and it is important that the documentation be kept up to date, complete and consistent.

The integrated dictionaries will automate this update process so that it is not forgotten! At a lower level a CASE tool provides a facility to manage text and diagrams in an organized manner.

There are different types of CASE tools that provide features for different parts of a system development. The CASE tools we are looking at in this topic will be used to automate the process of defining and recording requirements. These tools are called ‘Upper’ or ‘Front–end’ CASE tools.

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.

Requirements will generally fall somewhere between needs and expectations. Normally requirements fall into four categories. See Figure 1.

[pic]

Figure 8: Categories of requirements

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.

Conformity with functional requirements is the degree to which a system performs its intended function. You must clarify which business functions are mandatory and which are optional.

System Outputs are the screens and reports the system generates. It is important to clearly define what these will look like for a system. Can the client easily interpret these outputs? Can they get all of the reports they need in a suitable format?

Performance addresses how well a product or service performs the client’s intended use. In order to design an IT system with high quality performance, project stakeholders must consider many issues, including the following:

• What volumes of data/transactions should the system be capable of handling?

• How many simultaneous users should the system be designed to handle?

• What is the projected growth rate in the number of users?

• What type of equipment must the system run on?

• How fast must the response time be for different aspects of the system under different circumstances?

Reliability is the ability of a product or service to perform as expected under normal conditions without unacceptable failures.

Client’s must define what their reliability expectations are:

• Should reliability tests be based on 50 people accessing the system at once and running simple queries?

• Is the client willing to have the system unavailable several hours a week for system maintenance?

• How fast a response do clients expect for help desk support?

Maintainability – will the product be easy to maintain? Have documentation requirements been included?

Security determines how access to the system should be controlled. Have security issues been included?

Usability addresses how easy it should be to operate the system.

Efficiency specifies how efficient the system should be in terms of resources used.

Interoperability determines the level of interface with other systems that is necessary.

Portability is the ease with which the system can be moved to another environment, i.e. another hardware platform or operating system.

Where there are gaps in the information you will need to go back to the client to confirm the details. Quality requirements must be agreed upon and documented.

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.

SWOT analysis

In other words, in order to go forward you must know where you are. This process of determining where an organisation is currently positioned is referred to as SWOT analysis (Strengths, Weaknesses, Opportunities and Threats).

SWOT analysis examines the current business in terms of its internal and external aspects.

The internal examination divides significant factors into strengths and weaknesses while examination of the external environment looks at the opportunities and threats.

A thorough SWOT analysis enables a clear picture to be formed of:

• where the business is currently

• what it is good at

• what its failings are

• where the opportunities lie in the market and

• what are the looming business environment problems.

• From this position, planning for the future can be undertaken.

Here is a good example of this type of analysis

A clothing design and manufacturing business decided that its strength lay in its design, marketing and manufacturing capabilities. Management recognised that its weakness was incompatibilities between the IT systems in its Design, Marketing and Manufacturing departments.

Clothing designs developed on the Design department’s database had to be manually entered into the Marketing department’s system in order for them to produce the seasonal catalogue. However, requests on production could not be easily converted into a format from either of these systems into the Manufacturing department’s system.

In line with the recognised opportunity for sales with the up coming summer season new technology needed to be implemented in order to streamline these processes. If not, it would mean that the product would get to the market place late and consequently sales would be lost to the company’s competitors.

Such new technology would not be seen as a short–term investment but rather as a long–term solution to meet the organisation’s strategic goals. This then would be a strategic requirement.

Adhering to organisational guidelines

In your requirements analysis, you will need to use the methods and techniques that have been adopted by the organisation as you develop the user requirements. There may even be a computer application or CASE tool (Computer Assisted Software Engineering) that is used for developing requirements.

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).

Information you and your client need to agree on

You provide the clients with information that will help them make an informed decision.

You and your client agree on certain decisions (eg the specifications of the job and the scope of the job).

Documenting client requirements

What you need to do now is to document the requirements that you have identified, in order to provide your client with the details to make an informed decision about what the next step should be.

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 specialists

Where 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

• 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

Background

This section should contain details about the background of the project and a recap of the developmental effort to date.

It describes:

• problems with the current system

• the anticipated benefits and objectives of developing a new system

• the scope of the project

• the results of the preliminary investigation phase

Functional Requirements

This will be the logical design of the new system, i.e. what it will do. The functional requirements may be described using:

• data flow diagrams

• data dictionary entries

• process descriptions

• screen and report layouts

• The functional requirements should be prioritised as previously described.

Non –Functional Requirements

These are the constraints under which the system must operate and should include:

• operating constraints

• external constraints

• hardware and systems software constraints

• control requirements

• security requirements

Operating constraints include:

• volumes, sizes, and frequencies

• timing considerations

• reporting deadlines

• on–line response times

• processing schedules

External constraints include:

• Statutory restrictions

• Requirements by regulatory and governmental agencies – examples are data retention requirements and privacy considerations

External Interfaces

The systems with which the proposed system must interact. This section should describe in detail what form the interfaces will take, for example, if a particular output from the proposed system will be required to be used as input to an existing system. In this case it will be important to include a sample of the required input to the existing system.

Appendices

Frequently, the requirements document has a separate appendix with copies of important documents from previous phases of the project, e.g., the systems request and preliminary investigation report

Information sources and references should also be included and provide a sample of questionnaires, sample forms, lists of interviews with end users and software package vendors.

There are many examples of requirements documents on the web, including sites that provide document templates. Use a search engine with the keywords “user requirements document template” to investigate some of these.

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.

Sometimes a client will let you know exactly what they want. If their request or problem is a simple one, you may not need to analyse what they've said to ascertain exactly what they want. There are times, though, when you would not know precisely what the client's requirements are. This may be due to the fact that the client does not have the technical information to fully understand what they really need or what the possibilities are.

Suppose your grandmother has asked for your help to buy a new car. You have spent some time talking to her to find out what she wants. Before you start actually looking at cars you decide that you need to analyse the information your grandmother has given you to make sure that you know exactly what her requirements are. Create one “what–if” question that you might ask her to clarify what she wants.

You might have asked: “If the situation arises where an automatic is not available in the model you would like, are you prepared to consider a manual car instead?”. This is a ‘what–if’ question which will explore possibilities that may not have previously been considered.

Some examples of constraints that may impact on the requirements of an IT solution include:

Can you think of any more examples?

There are many, including:

You have discovered a package that meets all of the user requirements and more. The problem is that it will not work on the standard server configuration that the IT department has adopted. You could run it on another server with a second operating system and integrate it in the system that way. What would you need to consider when making your recommendation?

You should consider:

You've analysed your client's requirements. You must then:

It's important that you gather the correct information from a client so that you can accurately determine their requirements. It's just as important that:

You would not want a client to say at a later date that they were not satisfied with the service you provided. You also would not want to pre–empt any later misunderstandings. Finally, you would want to make sure that your organisation is not taken to court!

Many IT projects fail because the system as delivered does not meet user requirements. Users may have difficulty in explaining what they want and in some cases may not even know what they want.

In this topic, you learnt the skills that will help you accurately analyse client requirements. You learnt skills such as how to document, in a systematic manner, information provided by clients in order to produce a report containing the requirements for the new system.