FIELD OF THE DISCLOSURE

The present disclosure relates to the field of product development. More particularly, the present disclosure provides a system and method for analysing user requirements for a product to determine requirement volatility.

BACKGROUND

Product development covers a complete process of bringing a new product to market. During product development, service providers or software developers often finalize initial requirements and then proceed with further requirements during subsequent phases. Requirement management is a continuous process of documenting, analyzing, tracing, prioritizing and agreeing on requirements, which have capability to affect project outcome.

During product development, many disputes arise between service providers and service receivers because of project delay. Sometimes, project delay becomes inevitable due to requirement change or additional requirements that are required to be added and a dispute may arise when a service provider fails to provide evidences for the project delay. Generating evidences becomes difficult as high effort is required for the service provider to manually verify, count and record changes when he/she receives subsequent baseline documents, which may also lead to inaccuracy in count. Further, the service provider and/or receiver is normally notified based on percentage of requirement change against total number of baselined requirements instead of focusing on requirements tagged by the service receiver.

Efforts have been made in the past to overcome the foresaid limitations associated with the pertinent art. For instance, United States Patent Number US 6,715,130 B1 provides a system for quantitative evaluation of customer requirements for a desired product such as a software application. Cited reference discloses automated analysis of a requirement document to identify the requirements, assigning a hierarchy level to each requirement and detecting keywords with respect to each requirement. However, minimization of disputes by providing alerts is not taught or even suggested.

There is therefore a need in the art for an efficient system and method that significantly minimizes disputes by providing appropriate alerts related to re- scheduling/re-planning of projects.

SUMMARY

The present disclosure proposes a system and method for analysing user requirements for a product to determine requirement volatility. The determined requirement volatility can be used to generate alerts for re-scheduling/re-planning.

An aspect of the present disclosure relates to a system including an enforcement engine that is operatively coupled with a computing device. The enforcement engine determines requirement volatility by analysing one or more user requirements for a product. The enforcement engine includes a document matching and data manager, a baselined document matching and categorizer, a categorizer and matching component and a volatility impact factor analyser.

The document matching and data manager reads, extracts and restructures one or more tagged requirements from any or a combination of a requirement document and a change request document and then stores the tagged requirements in a structured repository. The baselined document matching and categorizer retrieves a set of baselined documents using any or a combination of the requirement document and the change request document. Further, the baselined document matching and categorizer categorizes each of the set of baselined documents based on an associated time-stamp to determine initial number of requirements from a first based lined document.

The categorizer and matching component associates each of the tagged requirements with a volatility category based on matching of a current baselined document and a previous baselined document to compute total number of requirements and determines one or more attributes of each of the one or more tagged requirement using a knowledge data. The volatility impact factor analyzer analyzes at least one of a requirement volatility (RV), a requirement volatility and impact function (V) and requirement volatility and impact factor (RVIF) based on any or a combination of a development lifecycle phase, time period for work performed for the development phase cycle phase and number of each volatility type associated with the one or more tagged requirements to generate an alert when at least one of the RV, V and RVIF is greater than a pre-defined threshold.

According to an embodiment, the document matching and data manager receives the one or more tagged requirements from a user computing device that enables tagging of each of the one or more user requirements from any or a combination of the requirement document and the change request document and associates each tagged requirement with a running tagged identifier obtained using last running identifier stored in a data repository.

According to an embodiment, the tagging comprises defining a tag type selected from any or a combination of Business Requirement (BR), System Requirement (SR), Functional Requirement (FR), Non-Functional Requirement (NF) or Use Case (UC) for associating the running identifier based on the tag type.

According to an embodiment, when the one or more tagged requirements are obtained from the requirement document, the document matching and data manager validates the one or more tagged requirements by matching each of the one or more user requirements with existing requirement data in the data repository to avoid duplication of the one or more tagged requirements.

According to an embodiment, when the one or more tagged requirements are obtained from the change request document, the document matching and data manager verifies the one or more tagged requirements by matching each of the one or more user requirements with existing requirement data in the data repository and associates a difficulty level into matched data.

According to an embodiment, the volatility category is selected from any of added requirement, deleted requirement or modified requirement. According to an embodiment, the one or more attributes include a difficulty level and a weightage of difficulty level associated with each requirement.

According to an embodiment, the volatility impact factor analyzer determines the development lifecycle phase of the product based on time stamp of the current baselined document and first baselined document.

According to an embodiment, the volatility impact factor analyzer determines the development lifecycle phase using a project schedule.

Another aspect of the present disclosure relates to a method for determining requirement volatility by analysing one or more user requirements for a product. The method comprises the steps of: configuring an enforcement engine that is operatively coupled with a computing device, wherein the enforcement engine performs the steps of: reading, extracting and restructuring, one or more tagged requirements from any or a combination of a requirement document and a change request document and storing said one or more tagged requirements in a structured repository.

A set of baselined documents is retrieved by the enforcement engine using any or a combination of the requirement document and the change request document, and then categorized based on an associated time-stamp to determine initial number of requirements from a first based lined document. Each tagged requirement is associated with a volatility category by the enforcement engine based on matching of a current baselined document and a previous baselined document to compute total number of requirements. One or more attributes of each of the one or more tagged requirement is determined by the enforcement engine using knowledge data.

At least one of a requirement volatility (RV), a requirement volatility and impact function (V) and requirement volatility and impact factor (RVIF) is analyzed by the enforcement engine based on any or a combination of a development lifecycle phase, time period for work performed for the development phase cycle phase and number of each volatility type associated with the one or more tagged requirements to generate an alert when at least one of the RV, V and RVIF is greater than a pre defined threshold. Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

FIG. 1 A illustrates an exemplary network architecture in which or with which proposed system can be implemented in accordance with an embodiment of the present disclosure.

FIG. 1 B illustrates a work flow of the proposed system in accordance with an embodiment of the present disclosure.

FIGs. 2A-B illustrate exemplary implementations of document tagging component in accordance with an embodiment of the present disclosure. FIGs. 3A-B illustrate exemplary implementations of document matching and data manager in accordance with an embodiment of the present disclosure.

FIG. 4 illustrates an example of a client interface in accordance with an embodiment of the present disclosure.

FIG. 5 illustrates exemplary implementations of baselined document matching and categorizer in accordance with an embodiment of the present disclosure.

FIGs. 6A-D illustrate exemplary implementations of categorizer and matching component in accordance with an embodiment of the present disclosure. FIGs. 7A-F illustrate exemplary implementations of volatility impact factor analyzer in accordance with an embodiment of the present disclosure.

FIG. 8 is a flow diagram representing process for determining requirement volatility in accordance with an embodiment of the present disclosure. FIG. 9 illustrates an exemplary computer system in which or with which embodiments of the present invention can be utilized in accordance with embodiments of the present invention.

DETAILED DESCRIPTION In accordance with the present disclosure, there is provided a system and a method for analysing user requirements for a product to determine requirement volatility, which will now be described with reference to the embodiment shown in the accompanying drawings. The embodiment does not limit the scope and ambit of the disclosure. The description relates purely to the exemplary embodiment and its suggested applications.

The embodiment herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiment in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiment herein may be practiced and to further enable those of skill in the art to practice the embodiment herein. Accordingly, the description should not be construed as limiting the scope of the embodiment herein.

The description hereinafter, of the specific embodiment will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify or adapt or perform both for various applications such specific embodiment without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation.

Various terms as used herein are defined below. To the extent a term used in a claim is not defined below, it should be given the broadest definition persons in the pertinent art have given that term as reflected in printed publications and issued patents at the time of filing.

Definitions:

Storage Medium: Any computing hardware that is used for storing, porting and extracting data files and objects. It can hold and store information both temporarily and permanently, and can be internal or external to a computer, server or any similar computing device.

Baseline: A baseline is value or condition against which all requirements are compared. Thus, a baseline is a point of reference, which serves as a basis for defining incremental changes during development cycle of a product. The present disclosure provides a system that includes an enforcement engine. The enforcement engine can include a document matching and data manager, a baselined document matching and categorizer, a categorizer and matching component, and a volatility impact factor analyzer. The document matching and data manager reads, extracts and restructures one or more tagged requirements from any or a combination of a requirement document and a change request document and then stores said one or more tagged requirements in a structured repository.

The baselined document matching and categorizer retrieves a set of baselined documents using any or a combination of the requirement document and the change request document and then categorizes each of the set of baselined documents based on an associated time-stamp to determine initial number of requirements from a first based lined document.

The categorizer and matching component associates each of the one or more tagged requirement with a volatility category based on matching of a current baselined document and a previous baselined document to compute total number of requirements and then determines one or more attributes of each of the one or more tagged requirement using a knowledge data.

Further, the volatility impact factor analyzer analyzes at least one of a requirement volatility (RV), a requirement volatility and impact function (V) and requirement volatility and impact factor (RVIF) based on any or a combination of a development lifecycle phase, time period for work performed for the development phase cycle phase and number of each volatility type associated with the one or more tagged requirements to generate an alert when at least one of the RV, V and RVIF is greater than a pre-defined threshold.

Referring to accompanying FIGs. 1 A-B, FIG. 1 A illustrates an exemplary architecture (100) in which or with which proposed system can be implemented in accordance with an embodiment of the present disclosure.

As illustrated, in an architecture (100) that represents, proposed system can include an enforcement engine (102) that can be implemented in a computing device. The enforcement engine (102) can determine requirement volatility and can alert a user computing device (124) for re-scheduling. The computing device (124) can be any device using any or a combination of hardware components and software components such as a computing device, a security device, a network device, a web-server, a mobile phone, a desktop computer, a personal computer, a laptop, a tablet PC, a portable computer, a personal digital assistant and the like.

As illustrated, a system, which may comprise the enforcement engine (102), can include one or more processor(s) (104). The processor(s) (104) can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that manipulate data based on operational instructions. Among other capabilities, the processor(s) (104) are configured to fetch and execute computer-readable instructions stored in a memory (106) of the system. The memory (106) can store one or more computer-readable instructions or routines, which may be fetched and executed to create or share the data units over a network service. The memory (106) can include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like. In an example embodiment, the memory (106) may be a local memory or may be located remotely, such as a server, a file server, a data server, and the cloud.

The system can also include one or more interface(s) (108). The interface(s) (108) may include a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, and the like. The interface(s) (108) may facilitate communication of the system with various devices coupled to the system. The interface(s) (108) may also provide a communication pathway for one or more components of the system. Examples of such components include, but are not limited to, processing engine(s) (110), knowledge data (122) and data repository (168).

The processing engine(s) (1 10) can be implemented as a combination of hardware and software or firmware programming (for example, programmable instructions) to implement one or more functionalities of the engine(s) (1 10). In the examples described herein, such combinations of hardware and software or firmware programming may be implemented in several different ways. For example, the programming for the engine(s) may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the engine(s) (110) may include a processing resource (for example, one or more processors), to execute such instructions. In the examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the engine(s) (1 10). In such examples, the system can include the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing engine(s) (110) may be implemented by electronic circuitry. The data repository (168) can include data that is either stored or generated as a result of functionalities implemented by any of the components of the processing engine(s) (1 10).

In an example, the processing engine(s) (1 10) can include a document matching and data manager (1 12), a baselined document matching and categorizer (1 14), a categorizer and matching component (116), a volatility impact factor analyzer (118) and other engine(s) (120). Other engine(s) (120) can implement functionalities that supplement applications or functions performed by system or processing engine(s) (1 10). Those skilled in the art would appreciate that various components of the enforcement engine (102) can be implemented in a distributed computing environment, e.g., document matching and data manager (1 12) and data repository (168) can be a part of the user computing device (124).

FIG. 1 B illustrates an overall working of the proposed system in accordance with an embodiment of the present disclosure.

According to an embodiment, the document matching and data manager (1 12) reads, extracts and restructures tagged requirements from a requirement document or a change request document. Further, the document matching and data manager (112) stores the tagged requirements in a structured repository. The document matching and data manager (1 12) receives the tagged requirements from the user computing device (124) that enables tagging of each of one or more user requirements from any or a combination of the requirement document and the change request document and associates each tagged requirement with a running identifier or tagged identifier obtained using last running identifier stored in the data repository (168).

Referring to an example as illustrated in FIG. 2A-B, a document tagging component (152) of the user computing device (124) can provide an interface to allow a user to tag selected sentence or requirement in a document (162-1 - 162-N), which can include but is not limited to the requirement document or the change request document. The document tagging component (152) then generates a running identifier, e.g. numeric or alpha-numeric identifier, to automatically tag each requirement with a running identifier that can be retrieved using last running identifier stored in data repository (168). Further, after tagging, the last running identifier can be saved in the data repository (168) based on the tagged identifier. The requirement document can be associated with document type (DT) (210), document name (DN) (212), document identifier (ID) (220), document version (VS) (214), document date and time (VD) (216), document author (AN) (218) and requirement tagged identifier (UC) (222). Similarly, impact analysis document or change request document can be associated with the document type (DT) (210), requirement document identifier (ID) (220), requirement document version (VS) (214) and requirement tagged identifier (UC) (214).

According to an example, tagging can include defining a tag type for each requirement and associating each requirement with a running number that indicates tag identifier. Examples of requirement tag type can include, but are not limited to, Business Requirement (BR), System Requirement (SR), Functional Requirement (FR), Non-Functional Requirement (NF) and Use Case (UC). Examples of requirement tag Identifier can be running identifier such as 001 , 002, 003, and so on. In one example, the tag identifier can be generated based on associated tag type such as UC001 , UC002, UC003 and so on. Tagging can also include defining document type (DT) (210), document name (DN) (212), document identifier (ID) (220), document version (VS) (214), document date and time (VD) (216) and document author (AN) (218).

Referring to FIG. 3A-B, the document matching and data manager (1 12) can automatically read, extract, restructure the tagged requirements or sentences in documents (162-1 - 162-N, shown in FIG. 1 B) and transform it into spreadsheet (164-1 - 164-N, shown in FIG. 1 B). From the spreadsheet (164-1 - 164-N, shown in FIG. 1 B) as structured data, the document matching and data manager (1 12) can extract, validate, and insert the data into data repository (168). The document matching and data manager (1 12) can validate by matching the extracted data from requirement document with existing requirement data in the data repository (168) to avoid duplication of requirements such that the data inserted into data repository (168) relates to a unique requirement. In an example, the validation can be performed by matching the tagged requirements from the requirement document that include document ID (220) and document version (216) with existing requirement data in data repository (168).

Further, when document is an impact analysis or a change request document, the document matching and data manager (1 12) verifies by matching the extracted data from the impact analysis document or change request with existing requirement data in data repository (168) to insert a difficulty level defined in the document into the matched data. In an example, verification can be performed by matching the tagged requirements from impact analysis document or change request document requirement document id (220), requirement document version (214) and requirement document id (220) with existing requirement data in data repository (168).

Referring to FIG. 4, according to an example, a client interface (400) that can be web-based interface configured with the enforcement engine (102) or client computing device (124) can allow a user to create a project plan, assign a document identifier into the created project and choose a formula for triggering reschedule project plan. A project can be registered with various parameters, for example, project identifier, project name, project start date, project end date, etc. The parameters and the document identifier can be stored in the data repository (168). The interface (400) can allow a user to select one out of three techniques, i.e., a requirement volatility (RV), a requirement volatility and impact function (V) and requirement volatility and impact factor (RVIF) to trigger a reschedule plan.

According to an embodiment, the baselined document matching and categorizer (114) can retrieve at least one baselined document using any or a combination of the requirement document and the change request document to determine initial number of requirements and categorize the at least one baselined document based on an associated time-stamp.

Referring to FIG. 5, according to an example, the baselined document matching and categorizer (1 14) can extract time-stamps, say month and year, of project date (including project start date and project end date) and date and time of the requirement document. The requirement document date must be in between the project start date and project end date. Further, the baselined document matching and categorizer (1 14) can match both the dates and categorize the baseline document. For example, first matching of the month and year can be categorized as a first baseline document and the subsequent match can be categorized as subsequent baseline document.

Further, the baselined document matching and categorizer (1 14) can count the tagged requirements based on requirement tag type and requirement tag identifier from first baselined document. The total tagged requirements can be set as initial number of requirements. According to an embodiment, the categorizer and matching component (1 16) can determine one or more attributes of each tagged requirement using the knowledge data (122) and can associate each tagged requirement with a category to compute total number of requirements.

According to an example as illustrated in FIGs. 6A-B, firstly, the categorizer and matching component (1 16) can match current baselined version (i.e. the updated version) with previous version (i.e. one version before) and categorize volatility type of each requirement, e.g. added, modified or deleted requirement. Secondly, the categorizer and matching component (116) can get the initial number of requirements and can count added and deleted requirement. Thirdly, the categorizer and matching component (116) can calculate total number of requirements. The total number of requirements can be calculated by:

Total Number of Requirement (T) = Initial Number of Requirement + Number of Added Requirement - Number of Deleted Requirement

Referring to an example as illustrated in FIG. 6C, the categorizer and matching component (116) can compare a subsequent baseline document with a first baseline document to compute total number of components. Further, referring to an example as illustrated in FIG. 6D, the categorizer and matching component (1 16) can further determine one or more attributes of each tagged requirement using the knowledge data (122), for example, the categorizer and matching component (1 16) can retrieve difficulty level (low, medium, high) of each requirement using knowledge data (122) and weightage for each requirement.

According to an example, the categorizer and matching component (1 16) can determine each requirement as added, deleted or modified as follows:

- the requirement can be an added requirement if tag type and tag identifier does not exist in one version before but exist in current version;

- the requirement can be a modified requirement if the tag type and tag identifier exist in both version but data is different; and - the requirement can be a deleted requirement if the tag type and tag Identifier exists in one version before but does not exist in current version.

According to an example, the weightage can be based on number of impacted pages in a document or number of impacted lines of a code. According to an embodiment, the volatility impact factor analyzer (1 18) can analyze at least one of RV, V and RVIF based on any or a combination of a development lifecycle phase, time period for work performed for the development phase cycle phase and number of each volatility type associated with the one or more tagged requirements to alert the user computing device when at least one of the RV, V and RVIF is greater than a pre-defined threshold.

Referring to FIGs. 7 A-B, the volatility impact factor analyzer (118) can determine development life cycle phase based on time-stamp of the current baselined document and first baselined document. The development life cycle phase can be any of requirement phase, design phase, development phase, test phase or maintenance phase. As illustrated in FIG. 7C, the volatility impact factor analyzer (118) can retrieve number of phases past current baseline document using knowledge data (122). Further, as illustrated in FIG. 7D, the volatility impact factor analyzer (1 18) can analyze total days of previous phase completion and total days of current phase completion. Furthermore, as illustrated in FIG. 7E, the volatility impact factor analyzer (1 18) can determine RV, V or RVIF to generate an alert when any of RV, V or RVIF is greater than a pre-defined threshold. The threshold can be indicative of number or percentage of changes in a requirement.

According to an example RV, V and RVIF can be calculated as:

RV = (T + a+ m+ d) / T . . . (1 )

V = ( (a + m + d ) / T ) ^* 10 ^(P/2) ... (2)

Where, a = added requirement count ^* DL ^* VT d = deleted requirement count ^* DL ^* VT m = modified requirement count ^* DL ^* VT

DL = weightage of Difficulty Level of the requirement change (added, deleted, modified)

VT = weightage of Volatility Type of the requirement change T = Total requirement count p = number of phases past baseline

RVIF = ((A+D+M)/T) ^* 10 ^p/2 ...(3)

A = added requirement count ^* IC ^* VT

D = deleted requirement count ^* IC ^* VT M = modified requirement count ^* IC ^* VT

IC = (Percentage of Total Day of Previous Phase Completed) + (Percentage of Total Day of Current Phase Completed)

VT = weightage of Volatility Type of the requirement change T = Total requirement count p = number of phases past baseline

Those skilled in the art would appreciate that in the existing techniques; difficulty level is manually defined by user and documented in change request document. However, according to the present disclosure, difficulty Level (DL) can be changed to Impact Changes (IC) such as: IC = (Percentage of Total Day of Previous Phase Completed) + (Percentage of Total Day of Current Phase Completed)

Where:

Percentage of Total Day of Previous Phase Completed = ((End Date of Phase - Start Date of Phase) / (Total Day Of Project Completion)) x 100% Percentage of Total Day of Current Phase Completed = ((Date of Requirement Change Detected - Start Date of Current Phase) / (Total Day of Current Phase Completion)) x 100%

Total Day of Project Completion = End Date Test Phase - Start Date of Requirement Phase

Total Date of Current Phase Completion = End Date of Current Phase - Start Date of Current Phase.

As illustrated in FIG. 7F, the volatility impact factor analyzer (118) can alert the user or the project manager when RV, V or RVIF is greater than the pre-defined threshold (also represented at 166, shown in FIG. 1 B). For example, the pre-defined threshold can be set to 1.2, which may indicate 20% changes in requirement. Thus, in context of the present example, if RV, V or RF is greater than or equal to 1.2, an alert can be generated. In an embodiment, the alert can indicate an early message to a project manager (also represented at 168, shown in FIG. 1 B) to take an action on the project schedule and can provide information regarding project heath to the user. In another embodiment, the alert can indicate higher management when it is determined that requirements from same device has been changed multiple times as this may indicate that the person handling the device may not possess desirable skills or knowledge.

FIG. 8 is a flow diagram (800) representing process method for determining requirement volatility in accordance with an embodiment of the present disclosure.

According to an embodiment, at block (802), one or more tagged requirements from any or a combination of a requirement document and a change request document are read, extracted and restructured. Further, the one or more tagged requirements are stored in a structured repository. At block (804), a set of baselined documents are retrieved using any or a combination of the requirement document and the change request document. Further, each of the set of baselined documents are categorized based on an associated time-stamp to determine initial number of requirements from a first baselined document. At block (806), each of the one or more tagged requirement are associated with a volatility category based on matching of a current baselined document and a previous baselined document to compute total number of requirements. Further, one or more attributes of each of the one or more tagged requirement are determined using knowledge data. At block (808), at least one of RV, V and RVIF are analyzed based on any or a combination of a development lifecycle phase, time period for work performed for the development phase cycle phase and number of each volatility type associated with the one or more tagged requirements to generate an alert when at least one of the RV, V and RVIF is greater than a pre-defined threshold.

Those skilled in the art would appreciate that according to various embodiments of present disclosure can be accepted by both service provider and service receiver at beginning of the project to avoid disputes during a change request. Further, quality management is performed effortlessly when baseline documents are auto extracted and RV, V & RVIF are automatically calculated and analysed. The embodiments herein facilitate generation of project monitoring report immediately after the document baseline is extracted and accurate count of RV, V and RVIF is determined without human intervention. Thus, requirement volatility report can be generated with high integrity to produce accurate alert triggers for rescheduling. Embodiments herein are capable of alerting project manager to escalate to service receivers’ higher management when the number of times a requirement changed is high as to consider rescheduling. It would further be appreciated that the present disclosure advantageously provides automatic linkage from unstructured data to structure data repository governed by best practices in the market and an innovative RVIF that provides automatic monitoring and tracking for better decision making.

FIG. 9 illustrates an exemplary computer system (900) in which or with which embodiments of the present invention can be utilized in accordance with embodiments of the present invention.

As shown in FIG. 9, computer system (900) which may represent the proposed system or enforcement engine (102) can include an external storage device (910), a bus (920), a main memory (930), a read only memory (940), a mass storage device (950), communication port (960), and a processor (970). A person skilled in the art will appreciate that computer system may include more than one processor and communication ports. Examples of processor (970) include, but are not limited to, an Intel® Itanium® or Itanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), Motorola® lines of processors, FortiSOC™ system on a chip processors or other future processors. Processor (970) may include various modules associated with embodiments of the present invention. Communication port (960) can be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. Communication port (960) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which computer system connects.

Memory (930) can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read only memory (940) can be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or BIOS instructions for processor (970). Mass storage (950) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), e.g. those available from Seagate (e.g., the Seagate Barracuda 7200 family) or Hitachi (e.g., the Hitachi Deskstar 7K1000), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks (e.g., SATA arrays), available from various vendors including Dot Hill Systems Corp., LaCie, Nexsan Technologies, Inc. and Enhance Technology, Inc.

Bus (920) communicatively couples’ processor(s) (970) with the other memory, storage and communication blocks. Bus (920) can be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects processor (970) to software system.

Optionally, operator and administrative interfaces, e.g. a display, keyboard, and a cursor control device, may also be coupled to bus (920) to support direct operator interaction with computer system. Other operator and administrative interfaces can be provided through network connections connected through communication port (960). External storage device (910) can be any kind of external hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc - Re-Writable (CD-RW), Digital Video Disk - Read Only Memory (DVD-ROM). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise.

The terms "comprises," "comprising,"“including,” and“having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.

The use of the expression“at least” or“at least one” suggests the use of one or more elements, as the use may be in one of the embodiments to achieve one or more of the desired objects or results.

The process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously, in parallel, or concurrently.

Embodiments of the present invention may be provided as a computer program product, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, fixed (hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs, PROMs, random access memories (RAMs), programmable read-only memories (PROMs), erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory, magnetic or optical cards, or other type of media/machine-readable medium suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware).

Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product.

While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.