Reading: Identify alternative solutions

Identify alternative solutions

Inside this reading:

Determining future requirements 2

Identifying possible solutions 4

Documenting alternative solutions 12

Summary 13

Determining future requirements

When identifying the client’s requirements it is important to identify not only the current requirements of the business but also what their business requirements will be in the future. Since a great deal of time and money will be spent in providing a solution to the current business problem it is essential that the solution chosen meets the requirements of the business for several years to come.

Imagine the situation where you are shopping for a new printer for your computer. The sales assistant asks you what you use a printer for. You think about it for a moment and then reply that you use it for printing assignments and letters, and occasionally for printing party invitations. Based on this information the salesperson recommends a basic printer that will allow you to do all of those things. You are very happy and since it is a reasonably priced printer, you buy it and take it home. Next month you buy the digital camera that you have wanted all year and start taking wonderful pictures that you can download on to your computer. You want to print some of the pictures to give to friends but when you try to print them the quality is really bad.

If, when buying your printer, you had considered that in the future you would like to use it to print photographs then the salesperson would have recommended a better quality printer that would have produced high quality photographs.

The aim of gathering information on future requirements is to identify the direction the organisation will be following in the future.

Analyse corporate plans

A useful source of information for determining future requirements are corporate plans such as the:

·  vision statements

·  strategic plans

·  business IT strategies.

A vision statement is the highest level of future planning. It states where the organisation wants to be at a future point in time.

An organisational vision could be:

’To take full advantage of the competitive marketplace using high-speed long-distance communications systems.’

Strategic plans break the vision statement down into several long term objectives. They represent outcomes the organisation hopes to achieve in the future. Whereas the vision statement is very general, strategies specify what the organisation is going to do, the conditions they intend to operate under and the proposed outcome.

In the above example a strategy would be:

’Upgrade existing communication links with branch office to allow access to online corporate information.’

Business IT strategies are a further refinement of corporate strategies. They are stated in more technical terminology. In the above example one strategy could be:

’Installation of Internet access and training of all users in all branch offices.’

Reflect

Have a look at the environmental vision statement for the Gold Coast Airport. What possible future requirements can you think of based on the aim of having ’integrated transport links’? (go to: www.goldcoastairport.com.au, select 'Corporate' then 'Environment')

Anticipated Growth

As well as investigating future directions for a business it is also necessary to consider the potential growth of the business in terms of:

·  volumes of transactions to be processed

·  increased workloads on staff and equipment

Information from the client

The types of information described above can be obtained by asking the client questions such as these:

  1. Do business areas expect any changes to their existing workload?
  2. These could be changes in procedures within the business that increase or decrease workload, extending facilities to more users or extra locations etc.
  3. Do business areas intend to implement new computer applications or enhance existing applications over the next year? If so, what impact will this have on workload?
  4. Does the business expect it will increase the number of staff over the next year? If so, what impact is that expected to have on workloads?

Information from other stakeholders

It may be useful at this point to speak to the IT department to determine if there are applications that are being developed for this business area. If so their expected impact on workloads must be taken into account.

Hardware requirements

If you are investigating the future IT requirements for a client, you should also look at the hardware available to meet their future requirements.

What equipment will be required to meet the business unit’s future workload? You can estimate the future hardware requirements by looking at:

·  each hardware item and determining its useful life (the number of years the hardware item can be expected to work)

·  how much new hardware will be required to meet future workloads

Network requirements

If relevant you should consider changes that need to be made to an IT network to meet future requirements. You will need to consider:

·  Future network requirements or capacity—the amount of information that the network or servers can process while the network and servers perform to an acceptable level.

Hardware and networking requirements should be included in your requirements document and considered when identifying and evaluating alternative solutions.

Identifying possible solutions

A client will nearly always have an idea of what they require before you conduct a feasibility study and report. The client should be given a number of alternatives to choose from if they are to then make an informed decision.

Identifying possible solutions to meet requirements often means thinking laterally or reviewing work done by others to solve similar dilemmas.

Review functional requirements

Take another detailed look at all of the functional requirements for the system. Recall that functional requirements describe the problem but are independent of how the solution would work. They define processes rather than the technical elements.

The functional requirements are often documented with reference to the inputs, outputs and processes that are required. This is sometimes referred to as the logical model of the system.

Data flow diagrams can be a useful tool for documenting the logical model of the system.

Data Flow Diagrams (DFD)

Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

The symbols used in a data flow diagram are as follows:

Symbol / Explanation
/ A process transforms incoming data flow into outgoing data flow.
/ Data stores are repositories of data in the system.
/ Data flows are pipelines through which packets of information flow. Label the arrows with the name of the data that moves through it.
/ External entities are objects outside the system, with which the system communicates. External entities are sources and destinations of the system’s inputs and outputs.

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'. This shows the major processes of the complete system and contains all of the external entities and data flows from the context diagram.

If necessary, each process on the Diagram 0 can be broken down, or exploded to a lower level in order to show more detail

A new data flow diagram is created for the process—this is called leveling.

Take a look at the following example:

Context diagram example for a Cross Country Athletics system

This is an example of a context diagram for a Cross Country Athletics system. The system is represented as one process.

To look inside this system it is necessary to break it down into its individual processes, as shown below.

Diagram 0 for the Cross Country Athletics system

This is called a 'Diagram 0'. The Diagram 0 shows all of the data flows from the context diagram but also includes where that data is stored.

Each process has information flowing into it or out of it, and sometimes both. Each object on the diagram is labelled to describe what it is or what it does.

From this diagram it can be seen that there are four main processes:

·  Enter event details

·  Enter athlete details

·  Print event program

·  Print event results

Data flow diagrams are used to produce a logical model of the system. They show what is being done but not how, where, or when.

A table is sometimes used to show each of the processes and its associated inputs and outputs, as follows:

Process / Inputs / Outputs
Enter event details / Event details / Event in sorted order
Enter athlete details / Athlete details / Athlete in sorted order
Print event program / Event details
Athlete details / Event program
Print event results / Athlete name
Event name / Event results

Now that the processes and their inputs and outputs have been determined it should be possible to start the process of developing alternative solutions.

Developing alternative solutions

Solutions are developed by research into the problem. The problem is the central theme of all solution development at this point. Many feasibility studies fail because the developers, by the over-familiarity of working on a solution, lose sight of the real problem.

There are three basic types of solutions you can come up with:

  1. Automated
  2. Procedural
  3. Automated + Procedural

Automated solutions are computerised. Procedural solutions involve identifying new or modified manual processes that will solve the problem. In most cases the solution you select will be a combination of computerisation and manual procedures, but don’t assume that there must be some computerisation involved.

How many solutions should I devise?

It is a general rule that you recommend at least three solutions to management. There will probably be:

·  one solution that stands out as the best

·  a second solution that includes all the ’nice to haves’

·  a third solution that is less expensive but acceptable.

Development Methods

When identifying solutions that involve new software, you must also consider how that new software will be developed. The options are:

·  In-house development

·  Purchase a software package

·  Customise a software package

·  Outsource the development

In-house Development

This means that the system will be developed by the IT department of the business specifically for this situation.

·  The main advantage of this method is that the system can be designed to meet all of the user’s requirements – meaning less change to business procedures and policies and meeting any constraints imposed by existing systems or technology.

·  The disadvantages are that it will take longer and usually be more expensive than the alternatives. Many small businesses do not have their own IT staff and so this will not be an option.

Purchase a software package

This is usually the cheapest automated option, takes less time to implement and has fewer errors, as it is already likely to be operating in other companies. Fewer staff will be needed to implement this option and any upgrades to the system will be provided by the vendor. There are software packages available for a huge variety of business functions, incorporating the most common features of the businesses that operate in the industry.

If this option is to be considered then there will need to be a significant amount of research to ensure that the best options are selected. You should also identify any companies that are already using the packages that are being considered, in order to obtain an unbiased evaluation.

Customise a software package

If an existing package cannot be found to satisfy all the business requirements a possible solution is to purchase a customised package. There are three options for customisation:

·  Negotiate with the vendor for enhancements to an existing package

·  Purchase the package and modify it in-house

·  In some cases the package may have been designed as a central core with extra components that can be individually customised.

If a package is to be purchased it is important to evaluate those that are available against the functional requirements of the system. An evaluation matrix may be used for this purpose, listing the key functions required by the system and identifying which packages provide that function.

The following is an example of an evaluation matrix for a financial package:

Function / Package A / Package B / Package C / Package D
General Ledger / Yes / Yes / Yes / Yes
Accounts Payable / Yes / Yes / Yes / Yes
Accounts Receivable / Yes / Yes / Yes / Yes
Ordering / No / Yes / Yes / No
Payroll / No / No / Yes / Yes

In the example above, Package C would be the recommended choice as it meets all of the functional requirements, assuming that all other important criteria and constraints are also met.

A document is usually prepared to send to vendors of software packages that might be suitable, identifying the requirements that must be met. The document is called a Request For Proposal (RFP). RFPs for simple information systems may be only one page, however for large systems it might consist of dozens of pages.

Reflection activity

Try searching on the web for examples of RFP templates. You might also try the activity on RFP templates in the Practice section of this learning pack.

Outsource the development

This involves hiring an outside company to develop the new system. This solution is becoming more popular as businesses try to minimise the overheads associated with having a large staff of specialised IT personnel. The outsourcing may be for the complete project or specific stages of the project. There are many software companies that perform outsourcing work and in turn these companies often hire specialised staff on a contract basis for specific projects.

Some of the possible benefits and disadvantages of working with contractors or outside companies are outlined in the table below:

Benefits / Disadvantages
Broad view of industry standards and experience in a range of organisations / May not be familiar with organisational goals - less commitment to organisational aims
Set price solutions with clear billing records - separate from regular organisational spending / May have preferred working methods at odds with organisational standards
Range of solutions on offer with experience in customisation / All additional time will be billed (full-time employees will often put in extra effort to complete a project)
Flexibility of employment arrangements - fixed term contracts / Competition with jobs for other organisations may cause scheduling problems

Take a look at the Practice section of this learning pack for a practical exercise on outsourcing.