Requirements gathering phase

Requirements gathering, as it relates to Tivoli Decision Support, is a systematic process of identifying a customer's reporting requirements in order for us to deliver a well-thought-out implementation of Tivoli’s decision-making software. With the aid of detailed questionnaires, the consultant services organization works with the customer to identify complete and accurate requirements for their reporting solution. This activity also helps the customer establish the proper expectations of the breadth and scope of the TDS solution.

In order to deliver a definitive TDS requirements document, we will tailor this requirements gathering phase to provide only the information necessary to define the scope, architecture, and estimated hours that will be required to implement the customer’s TDS solution. The objective of this segment is, therefore, to gather requirements that enable the following:

• A system architect to analyze the information and successfully create a System Architecture and Design document

• The consultant, business operations, project management, sales team, and the deployment team to work together, led by business operations, to develop a technical proposal

• A deployment project team to create a detailed project plan

Table 1 shows the input and output items, which highlight the components of the requirements-gathering phase:

Table 1. Requirements gathering phase items

Figure 9 outlines the process flow of the requirements-gathering phase:

Figure 9. Requirements gathering process flow

We will now take a look at the questionnaires shown in Figure 9.

3.2.1.1 Questionnaires

Questionnaires serve as the main tool for gathering a detailed description and logical picture of the customer’s environment. It is a tool that portrays the customer’s environment and high-level goals for reporting on his or her IT environment.

Gathering the customer-specific TDS requirements is the focal point of this exercise and will be investigated shortly. First, however, we must take a look at the systems management requirements of the customer in the form of the Customer Requirements Questionnaire.

Requirements gathering phase Input Initial customer requirements questionnaire Output Tivoli decision support requirements questionnaires

Requirements Gathering Flow

3.2.1.2 Initial customer requirements questionnaire

The information gathered in this report serves as the single input element of the implementation solution. Our aim is to process this information and produce other questionnaires and reports that will serve as inputs to the subsequent phases of the implementation cycle.

In this questionnaire, many business-specific questions are answered. The most important and valuable pieces of information gathered would be the customer reporting goals and issues. For example, the answers to the following types of questions will be available to us:

• What are the immediate Tivoli-specific goals of the customer?

• What are the long-term Tivoli-specific goals of the customer?

• What are the customer's general immediate goals with TDS?

• What are the customer's general long-term goals with TDS?

From this information, the TDS consultant will be able to identify the reporting solution components that are significant to the customer’s business. He or she can now focus on the implementation of the product functions of Tivoli Decision Support and gather all the necessary TDS requirements.

3.2.1.3 Tivoli Decision Support requirements questionnaire Having manipulated the information received above, we are now ready to draw up a questionnaire to extract the TDS product-specific information. The TDS provider will set up an interview with the customer requesting the relevant business leaders as well as the IT technical leader to be present.

This interview is broken up into four steps, which are shown in the list below.

The purpose, requirements, and process of each step will be clearly

distinguished; furthermore, a set of suggested questions for the questionnaire will be proposed.

1. Decision-making/reporting requirements overview:

• Purpose

It is during this step that Tivoli personnel acquire their initial information on the customer’s reporting requirements. It is assumed that the customer has an amateur solution in place and intends to migrate to Tivoli Decision Support. The customer will be questioned on his or her current reporting activities, and a document detailing his or her

requirements will be drawn up.

• Required information

Details of what the customer expects from the Tivoli Decision Support solution, current process, procedure, service levels, reports, and any

product(s) associated with accomplishing their current reporting task (if any) are required information.

• Process

Document all customer expectations and reporting goals. Gather all existing reporting policies and procedures implemented by the customer. Review the customer's existing reporting policies and procedures to determine how data is collected and manipulated and what Tivoli Decision Support specifics need to be presented in order to migrate to this new reporting strategy.

• Suggested questions:

• What are the customer’s immediate report requirements?

• What report requirements are forecast as future needs?

• What is your current reporting strategy, and what are the shortfalls?

• Are you able to publish content to the Web?

• How often do you run your data mining and database interrogation procedures?

• Are any Tivoli products used to gather data for the current reporting solution?

2. Existing Tivoli systems management products installed:

• Purpose

Tivoli Decision Support is dependent on various Tivoli products to perform its reporting task. It is assumed that the customer has either an existing Tivoli Systems Management solution implemented, or it is in the process of implementation in their environment.

• Required information

Tivoli Servers, Tivoli Products (including patch levels), installed Plus modules, TMR architecture, and Operating System platforms are required.

• Process

It is in the analysis phase that we will investigate how these existing policies and procedures can be migrated to Tivoli Decision Support

Note

Gather all existing architecture and deployment documents (if available). Identify process flows, and systems management

procedures that the business is running with. Identify if Tivoli Decision Support dependent Tivoli products are installed for example,

Distributed Monitoring, Enterprise Console, Netview, Service Desk etc.

• Suggested questions:

• Which systems management disciplines does your Tivoli solution integrate with? Describe the details of that integration including the flow of data and desktop configurations.

• Are there current architecture and deployment summary documents that describe the Tivoli deployment?

• If using a Master-Spoke TMR, where are the Spoke TMR Servers located? (For example, central data center, different geographic locations, one per branch office).

3. Determine hardware and operating system information

For this step, we basically need to get an idea of the existing hardware that is deployed at the customer site. We will use this information in the Systems Analysis to decide if it is possible to share the roles of some of these machines with Tivoli Decision Support.

• Purpose

The purpose is to gather a hardware and operating system inventory of all dedicated Systems Management machines as well as machines that need to be monitored.

• Required information

System-specific information is required.

• Process

Review the Tivoli Decision Support hardware requirements with the customer. Processor, memory, monitor, and hard disk space of the existing hardware are some of the main issues that need to be covered.

4. Determine network-specific information

• Purpose

The purpose is to gather the following information to describe the network communication mechanisms used between the various components that may be used for the TDS deployment.

• Required information

The customer should provide a network topology diagram. If the following information is not on the diagram, annotate the diagram or provide details:

• Line speed of each network connection.

• Actual network bandwidth. If it varies by time of day, define the typical averages.

• Each firewall between nodes.

• Each firewall's configuration, monitoring, and policies.

• Socks configuration description.

• Protocols used within the current environment.

• Frame Relay (Committed Information Rate (CIR) and Burst Rate).

• Suggested questions:

• Are all systems reachable via TCP/IP?

• Describe the host and IP address naming conventions and scheme used to identify networking and computer system equipment.

• Is the TCP/IP routing structure static or dynamic?

• If DNS is used, provide a copy of the DNS map configuration. (Note that the integrity of these maps must be verified.) Describe how reverse lookups are performed.

• If DHCP or WINS is in use, identify the server and describe how these utilities are configured.