SRS on Customer Relationship Management

Software Requirements Specification for

Software Requirements Specification forCustomer Relationship Management

05-Sep-2014Ashok Yadav

Software Requirements Specification

for the InterGrid Architecture

ShreeLaxmi InfoTech Marcos Dias de Assuncao

Grid Computing and Distributed Systems (GRIDS) Laboratory

The University of Melbourne, Australia [email protected]

August 6, 2007

CONTENTS

Revision History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2Document Conventions and Common Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3Intended Audience and Reading Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4Product Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1Product Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42.2Product Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3User Classes and Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4Operation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.5Design and Implementation Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3System Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1Registration of Resource Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 73.2Client Application Requires Resources . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3DVE Manager Requests Slots from IGG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4Handling InterGrid Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5Initiation of Virtual Machines and Service Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 External Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164.1Communication Interfaces and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Revision History

NameDateReason For ChangesVersion

Marcos04-08-2007N/A0.1INTRODUCTION

Purpose

This document presents an overall description of the InterGrid architecture and its main software requirements. The InterGrid aims at enabling Grids to interconnect with one another through InterGrid Gateways (IGGs) that mediate access to the Grid resources. This way, included are the specifications of the Resource Manager Agent employed by the provider sites, the Distributed Virtual Environment (DVE) Manager used by clients to instantiate a DVE and the InterGrid Gateway that riper-sent a Grid, or organization, member of the InterGrid. Some of the system aspects presented here is based on a system model already implemented in GridSim. This is the version 0.1 of the requirements specification.

The purpose of customer relationship management (CRM) cannot be dwindled down to just one answer, because there are several reasons why a business would want to implement a CRM system. That said, perhaps the most obvious purpose of customer relationship management is to help a business keep customers. Along with that, it helps the business understand what it needs to do to get more customers. Another main purpose of customer relationship management is to reduce costs by managing costly complaints and finding out what services are useless for customers. This also can help a company figure out if its product is working and, ultimately, increases profit.

When it comes to using a CRM system, the prime reason is to log and manage customer relationships. These systems allow administrators to list new customers and include services that each customer should receive, as well as opportunities to make the customer spend more money. This also ensures that employees are doing all they can to make the customer happy within the policies of the company. By managing the relationship, the company is able to keep the customer loyal to the companys brand.

By checking to see what services work and which are not receiving much customer response, the company also is able to apply the information to potential customers. If the company sees one service is actually turning off potential customers and they remove that service to focus on another, this can convert more people into customers. Converting new customers and keeping old customers loyal helps the company receive more capital.

Reducing costs is another purpose of customer relationship management. Customers often will complain about something or show dissatisfaction for some product or service. This is normal in business but, if there is a growing trend against a product or service, a CRM system will help the business recognize this quickly. By cutting off these costs, the company can keep from spending money in the wrong places and funnel that money into more effective areas.

When companies try out a new product or service, they often send out marketing surveys, which tend to have a low participation rate. With a well-made CRM system, the company will be able to receive instant information from customers about whether the companys new venture is successful. This reduces the cost of having to send out marketing surveys and also helps the business receive the most accurate information to use in making decisions about the future of the company.

Document Conventions and Common Terms

Throughout the document, some acronyms and conventions are used. The list of common terms and their acronyms is presented as follows:

Resource Management Agent (RMA): Responsible for managing the re-sources at the level of an individual resource provider.

Distributed Virtual Environment (DVE): It is an execution environment or a network of virtual machines that can span more than one resource provider. This can be viewed as a virtual Grid.

DVE Manager: Component of the architecture responsible for initiating a DVE by instantiating the virtual machines at the resource providers and set-ting up the services required by applications.

InterGrid Gateway (IGG): An IGG is assigned with limited provisioning rights over shares of resources provided by resource providers within an individual Grid. An IGG can exchange shares with other IGGs or acquire shares from other IGGs based on the peering agreements established between them.

Slot: corresponds to a resource (physical or virtual) with a given capacity.

Intended Audience and Reading Suggestions

This document is intended for software developers, documentation writers and for general discussions on the implementation decisions regarding the InterGrid architecture.

Product Scope

The InterGrid, as a final product, is expected to enable the creation and manage-meant of execution environments here also termed DVEs composed of resources from multiple resource providers. The IGGs enable the allocation and exchange of resources across Grids. The main idea is to blend virtualization technology, distributed execution environments, and gateway based resource allocation, thus enabling the instantiation of DVEs that can provide a look and feel of a dedicated infrastructure to applications such as scientific workflows.

References

For more information regarding the overall InterGrid architecture we refer to [1]. The work in [2] describes the resource provisioning at a resource provider site. The assertions issued by resource providers and a simple mechanism used between the IGGs is presented in [3].

OVERALL DESCRIPTION

Product Perspective

The InterGrid should leverage existing Grid and virtualization technology. How-ever, it has to evolve to enable the exchange of resources among Virtual Organizations (VOs) or Grids for the creation of execution environments. Figure 1 presents an abstract view of the InterGrid architecture, its main components and summarizes their interactions.

A resource provider provides shares of resources to a Grid by registering the available resources as slot assertions at the IGG; this registration is performed by its RMA. A client application can require resources by requesting them from a DVE Manager; the client also provides additional information about the configuration to be performed once the resources are obtained along with required services. The IGG mediates or exchange resource shares with other IGGs based on the needs of the applications in an individual Grid and the peering policies. Once the resources are obtained, the DVE Manager initializes them and deploys the required services.

The InterGrid expects a minimum set of features from the RMA. The resources provided by to the InterGrid can be physical or virtual resources (i.e. virtual ma-chines). Therefore, it is expected that the RMA is able to collect information from the resource provider and based on the provisioning decisions of the later, issue assertions stating how many and when the resources will be available to the Grid. Also, when a DVE Manager presents permission to the RMA, the latter must be able to allocate the resources and initialize them.

This can correspond to fetching the image required to initialize a virtual machine and carrying out initial network configuration. Although we assume that this is the context in which the InterGrid will operate, nothing impedes one from using resource managers such as Aneka to reserve, allocate nodes and deploy the required services. However, this can limit the expected features of the InterGrid as discussed later in this document.

Product Features

The major features of the InterGrid are organized according to its main components. The features of the RMAs are as follows:

Collect information from the resource management system at the provider site. Publish availability of resources to the gateways as slot assertions based on the providers provisioning decisions. Handle resource use permissions given by the IGG to DVE Managers. Initialize resources and perform initial host and network configuration.

The main features of InterGrid Gateways are described as below:Receive assertions and update the slot inventory. Select and assign resources to DVEs based on the Grid-level provisioning policies. Negotiate upon and acquire resources from other IGGs. Provide resources to other IGGs based on the IGGs provisioning policies.

DVE Managers present the following features: Handle requests from a client application. Acquire resources from the InterGrid. Contact the RMAs at the resource provider sites. Deploy services on the resources allocated. Manage resources of a DVE and trigger allocation of additional resources or release allocated resources. Destroy a DVE.

User Classes and Characteristics

The users of the InterGrid can be classified in different ways. First, the users (i.e. client applications) can be classified according to the application life span. Applications can be long-lived and short-lived. Second, the applications can be classified with respect to the resources required. Some applications can explicitly require a cluster of nodes that must be provided by an individual resource provider; others can require resources or clusters from multiple providers; whereas other applications can require resources from multiple Grids. Other applications can require clusters of resources regardless their location (i.e. they do not explicitly specify to which Grid or resource provider the resources belong). Finally, the applications can be classified according to their requirements; the requirements can be hard or soft.

Operation Environment

The IGG should provide Web Services interfaces and be implemented in Java. The RMA should expose its features as Web Services interfaces and should utilize free virtualization technologies such as Xen and QEMU. The security infrastructure could rely on X.509 certificates by leveraging Grid Security Infrastructure (GSI). Messages exchanged by the components of the architecture should follow Grid standards provided by Open Grid Forum when applicable.

Design and Implementation Constraints

The RMA could rely on Aneka. However, the use of Aneka can limit the features of the RMA because the former does not support virtualization, performance isolation among other features.SYSTEM FEATURES

This section contains the main features of the proposed system. This is a preliminary list of features, which should be further improved.

Registration of Resource Assertions

This feature corresponds to the registration of resource assertions by the RMA in the IGG. Figure 2 presents the use case for this feature.

Stakeholders and Interests:RMA: Wants to inform the IGG gateway about the slots (i.e. resources) available at the resource provider. IGG: Wants to update the repository with the information provided by the RMA.

Assumptions:The scenario considers that a trustful relationship between the RMA and IGG has already been established. The format for the slot assertions has been defined. The communication protocol used between RMA and IGG has been defined. RMA is aware of the resource providers provisioning decisions.

Pre-Conditions: RMA has obtained information on resource available from the resource management system utilized by the resource provider. This information includes the number of slots available, their characteristics and the period of time over which they will be available.

Use Case Initiation: The registration process can start when (a) there are re-sources available to be used by the Grid and there are no outstanding assertions (i.e. RMA has not issued any assertion for the slots available beforehand); (b) a previously issued slot assertion is about to expire.

Use Case Dialog:

RMA, based on information obtained from the resource manager, issues a slot assertion and sends it to the IGG. If the (start time + duration) of the assertion is smaller than (current time + minimum time to initialize resources), IGG rejects the assertion. Else, IGG updates the slot repository with the information provided by RMA. IGG checks if the assertion is issued to renew another assertion previously sent by the RMA. If the assertion is a renewal, then IGG updates the allocations of resources to DVEs. IGG generates a registration ID and returns it to RMA.

Alternatively:Instead of publishing complete information about the slots available, RMA can provide an estimative of slots available.

Use Case Termination:The slot assertion is successfully registered. The registration may timeout. The assertion corresponds to a set of slots already published by the RMA. Post-Conditions: RMA saves the ID of the registration.

Cancel: Changes to the slot repository or to the RMAs status have to be rolled back.

Client Application Requires Resources

A user wants to allocate a set of nodes at one (or more) resource provider(s) on which she wants to deploy an application (Figure 3).