WO2017081597A1

WO2017081597A1 - A system and method for use case analysis

Info

Publication number: WO2017081597A1
Application number: PCT/IB2016/056699
Authority: WO
Inventors: Marc Vollenweider
Original assignee: Evalueserve AG
Priority date: 2015-11-13
Filing date: 2016-11-08
Publication date: 2017-05-18

Abstract

A system and a method for creating a platform for use case analytics, knowledge management, and trading services. The system comprising; at least one device, wherein the at least one device is configured to present a user interface to a user to feed in at least one parameter for a use case scenario; a first server, communicably coupled to the at least one device through a network, wherein the first server is configured to create use case analytics knowledge management and trading services; and a second server, communicably coupled to the first server through the network, wherein the second server is configured to provide external data to the first server, wherein the second server is further configured to receive use case scenarios generated by the first server for storage wherein the stored use case scenarios can be traded across.

Description

A SYSTEM AND METHOD FOR USE CASE ANALYSIS

FIELD OF INVENTION

Various embodiments of the disclosure relate to a system and method for use case analysis. More specifically, various embodiments of the disclosure relate to creation of a single universal platform for use case analysis and knowledge management.

BACKGROUND OF INVENTION

Numerous developments and data analytics solutions in the field of information and knowledge processing have emerged during the last decade. Typically, for a given service model, various application examples, such as use cases, may be thoroughly analyzed to address a plurality of business questions for the service model. In other words, the use cases may facilitate identification, clarification, and organization of system requirements and functional requirements for the given service model. Further, the use cases may provide an insight of how the service model, implemented in a system may provide interfaces that may facilitate user interaction with the system. Based on at least one of various dimensions and new/upcoming trends associated with a particular business question, multiple use cases may be generated. Such dimensions may include: a business issue, a related industry, a related functional area, a specific geography, qualitative or quantitative data, internal or external data, offline or live data, and human or machine data. Examples of the new trends may include networked devices, sensor data, analytic computation power, information needs, and regulatory changes.

In certain scenarios, the use cases may be implemented in a hierarchical structure, with a higher level referral to a general use case and a lower level referral to some specific use cases. In such a hierarchical structure, the count of the specific use cases increases geometrically downwards with each level. Existing platforms may not be sufficiently scalable to manage proliferated analytic data and use case portfolios. Further, the existing platforms may be inconsistent for various specific use cases based on which the associated generality of corresponding point solutions may be lost. Due to such an inconsistency, the use cases may generate different point solutions that may not be interoperable, reusable and/or portable. Further, the existing platforms may be slow to set up, may require specialized resources, and may provide little insight on investment (IOI) for decision makers and key stakeholders. Furthermore, the existing platforms may not provide audit trails.

There is, therefore, a need for a consistent platform that may be flexible enough to effectively integrate humans and machines, collaborate internal and external resources, and provide qualitative and quantitative information addressing at least the above mentioned aspects. There is a further need of cross-company reuse via a market place for analytic use cases.

Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of described systems with some aspects of the present disclosure, as set forth in the remainder of the present application and with reference to the drawings. SUMMARY OF INVENTION

A system and a method for creating a platform for use case analytics, knowledge management, and trading services substantially as shown in, and/or described in connection with, at least one of the figures.

These and other features and advantages of the present disclosure may be appreciated from a review of the following detailed description of the present disclosure, along with the accompanying figures in which like reference numerals refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments will now be illustrated with accompanying drawings which are intended to illustrate certain embodiments in which the present invention may be practiced. It is to be understood that the present invention is not deemed to be limited to the exact configurations of the system shown by these figures and that the drawings are not intended to be taken restrictively to imply any limitation on the scope of the present invention. Any modifications, adaptations, equivalent changes in the drawings depicting the configuration of the system, by the persons skilled in the art employing the principles and features as embodied in the present invention are intended to be taken as within the scope of the present invention. In the accompanying figures:

FIG. 1 shows a configuration of the system of present disclosure.

FIG. 2A is a block diagram that illustrates an exemplary use case server.

FIG. 2B is a block diagram that illustrates a service architecture of an exemplary use case server. FIG. 3 shows a diagram to illustrate basic elements of a use case architecture.

FIG. 4 shows an interconnection of use cases in an exemplary use case architecture.

FIGs. 5A and 5B shows different operators that may be implemented in a use case architecture.

FIGs. 6A and 6B describe a life cycle management and portfolio management, respectively.

FIG. 7 shows a diagram that illustrates an exemplary market place for use case descriptors.

DETAILED DESCRIPTION OF INVENTION

The present invention can be best understood when description of various embodiments set forth herein is read with reference to accompanying figures. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is just for explanatory purposes as functional features and principles of the disclosed methods and systems may be deployed in variant embodiments incorporating modifications, adaptations and equivalent changes. For example, those skilled in the art will appreciate that, in light of the teachings presented, multiple alternative and suitable approaches can be recognized depending on the needs of a particular application, to implement the functionality or feature of any detail described herein.

At the outset, the various terms used in the ensuing description are defined as under:

Use Cases: Use cases may be defined as a collection of possible business scenarios with a set of possible sequences of interactions between systems and users in a particular business environment and related to a pre -determined goal. The use cases may include a group of elements, such as classes and interfaces, used together in a way that may have an effect larger than the sum of the separate elements combined. The use cases may include all system activities significant to a set of users. The usage of the use cases may sometimes be limited to a simple survey and sometimes may be a more detailed system with exhaustive test cases. Typically, Unified Modeling Language (UML) is used to model a system related to the use cases.

Use Case Framework (UCF): The UCF may comprise three layers, such as a use case architecture layer, a use case engine layer as the intermediate layer and a use case governance layer. The UCF may deal with qualitative and quantitative data, data from internal sources and external sources, live data and offline data. The UCF may provide transparency across the system and may facilitate recovery and analysis of audit trails of the use cases. The UCF may provide a common language for all use cases.

Use Case Architecture (UCA): The UCA may be an open source architecture which may support the other layers of the UCF. The UCA may be spread across company boundaries and may be implemented in a cloud platform or as a website to facilitate a trading service.

Use Case Engine (UCE): The UCEmay be a scalable tool or processing engine to design, implement and execute a plurality of use cases. The UCE may be implemented based on Evalueserve's proprietary mind+machine® model.

Use Case Libraries (UCL): The UCL may be a a set of pre-stored library files that may be utilized to implement a quick re-use and interoperability across boundaries of the system.The UCL may comprise proprietary intellectual property that may further facilitate open- architecture approach enabling open-standards.

Use Case Governance (UCG): The UCF may comprise a tool set for managing various use case portfolios, such as financial, economic and operational portfolios. The UCG may be a set of rules to manage specific and general use cases in an efficient manner. The use cases may be executed by the UCE based on the set of rules defined in the UCG.

According to disclosed embodiments, there is provided a system and a method for creating a platform for use case analytics, knowledge management, and trading service. From the system's perspective, the platform may effectively manage various reusable models for managing use cases to provide a single consistent platform for various use case analytics. From an end-user perspective, the platform may further provide scalable governance and a robust platform and toolset to efficiently manage use case portfolios.

The system may implement a meta level technology-agnostic language for use cases. The system may combine mind and machine, qualitative and quantitative data, internal and external resources, and offline and live data. The system may enable re -use and interoperability across boundaries, such as functionalities and libraries. The system may facilitate transparency and audit trails. The system may further facilitate improvement in implementation, adaption, and execution. The system may implement a full knowledge management and portfolio management. FIG. 1 shows a configuration of the system of present disclosure. With reference to FIG. 1, there is shown a network environment that comprises a use case (UC) server 102, a database server 104, an electronic device 106, and a communication network 108. The electronic device 106 may comprise a display screen that may render a user interface for a user 110, such as a client subscribed to use case analytics, knowledge management, and trading services provided by the UC server 102. The electronic device 106 may be communicably coupled with the UC server 102 and the database server 104, via the communication network 108. The UC server 102 may comprise suitable logic, circuitry, interfaces, and/or code that may be operable to create a platform for use case analytics knowledge management, and trading services. The UC server 102 may be configured to design, implement and execute the use cases. The UC server 102 may be implemented as a cloud server. The UC server 102 may be implemented based on one or more technologies known in the art.

The database server 104 may comprise suitable logic, circuitry, interfaces, and/or code that may be operable to provide external data to the UC server 102. The database server 104 may further receive use cases generated by the UC server 102 for reuse. The database server 104 may further store data structures and data models required for use case modeling. The database server 104 may have a fully distributed architecture and advanced file management algorithms that may allow support of repositories with large storage size. The database server 104 may implement a fast file access by spreading the files algorithmically and evenly throughout the system without a centralized metadata server. The database server 104 may be implemented based on one or more technologies known in the art.

The electronic device 106 may comprise suitable logic, circuitry, interfaces, and/or code that may be operable to be utilized by the user 110 to provide a request for one or more use case analytics, knowledge management, and trading services. The electronic device 106 may be further operable to render analysis result on the display screen. Examples of the electronic device 106 may include, but are not limited to, a laptop, a tablet computer, a smartphone, and/or a Personal Digital Assistant (PDA) device.

The communication network 108 may include a medium through which the electronic device 106 may communicate with one or more servers, such as the UC server 102. Examples of the communication network 108 may include, but are not limited to, the Internet, a cloud network, a Wireless Fidelity (Wi-Fi) network, a Wireless Local Area Network (WLAN), a Local Area Network (LAN), a telephone line (POTS), and/or a Metropolitan Area Network (MAN). Various devices in the network environment 100 may be operable to connect to the communication network 108, in accordance with various wired and wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, infrared (IR), IEEE 802.11, 802.16, cellular communication protocols, and/or Bluetooth (BT) communication protocols.

In operation, the user 110, such as a client, may provide a request via the electronic device 106 for creating a new use case. The request may be transmitted to the UC server 102, via the communication network 108. The request may comprise input parameters corresponding to various dimensions, preconfigured by the UC server 102. For example, the request may comprise a first input parameter "Preventive maintenance for... " for a first use case dimension "Business issue to be addressed", a second input parameter "Trucks" for a second use case dimension "Industry", a third input parameter "After Sales" for a third use case dimension "Functional Area", a fourth input parameter "UK" for a fourth use case dimension "Geography", and/or the like. The user 110 may further provide one or more user preferences for customizing the new use cases. In an embodiment, the electronic device 106 may provide a toolset to the user 110 to provide such input parameters. In an embodiment, the electronic device 106 may provide the toolset to the user 110 to generate and manage use case portfolios.

The UC server 102 may receive the request comprising the input parameters for the various use case dimensions, from the electronic device 106. The UC server 102 may store the input parameters for the various use case dimensions in the local storage devices. In an embodiment, the UC server 102 may receive external data related to the requested new use case from external resources, such as the database server 104, via a corresponding application programming interface (API). Examples of the external data may include, but are not limited to, live sensor data, periodic data, offline historic sensor data, and/or offline historic failure data.

The UC server 102 may capture all the essential elements, such as the input parameters and/or the external data, in accordance with a common meta-level language, known in the art. The common meta-level language may facilitate reusability of the new use case and ensure interoperability for other processes, such as workflow management, use case administration, knowledge management, and audit trails, across company boundaries. The UC server 102 may generate descriptors based on all the captured essential elements and associated dimensions. The descriptors may be referred to as "unique identifiers" for the requested use case. The UC server 102 may store the generated descriptors comprising the dimensions and input parameters in the local storage device.

The UC server 102 may implement various operators, such as a model execution operator or a human modelling operator, for structuring and modelling of the new use case based on the generated descriptors.In an embodiment, the UC server 102 may reuse one or more pre-stored use cases from a 'use case library'to perform structuring and modelling of the new use case. The operators in the UC server 102 may further perform cleansing, enhancement and execution for the required new use case. The operators may further perform knowledge extraction from the structured and modelled new use case. Such a new use case may be tested based on reviewed assumptions, via an API. The UC server 102 may store use-case specific code written in other languages, such as Teradata®, Aster®, and SPSS®. The UC server 102 may locally or remotely store the use-case specific code, project plans, and any other information relevant to the use case, and may further change history (such as, who did what, to which piece of software at what point)for the regulatory aspects, audit purposes, and speedy application, since every event is appropriately tracked.

The new use case may be further visualized, formatted and distributed by another user (not shown), such as an analyst, via a pre-specified API. Such an intervention by the analyst before roll-out of the new use case may be based on Evalueserve's proprietary mind+machine® approach and makes the use case flexible and scalable in accordance with the requirement of the user 110. Once tested, the UC server 102 may facilitate audit trails of the new use cases once rolled-out to the electronic device 106. The audit trail may include various processes like data logging, flow observation, flaggers, and use case trackers for subsequent reference. The UC server 102 may transmit the new use case to the electronic device 106, via the communication network 108. In accordance with another embodiment, the UC server 102 may generate a use case portfolio, based on a request received from the user 110 via the electronic device 106. Based on the request, the UC server 102 may perform resource allocation across the at least one of the many use case dimensions, discussed above in FIG. 1. The analyst may provide additional inputs and perform refinements, in accordance with the mind+machine® approach. Once the portfolio is created, knowledge management reviews may be performed to spot latest trends that can be provided to the electronic device 106, via the communication network 108. Not withstanding, the disclosure may not be so limited, and different new use cases and new use case portfolios may be generated by the UC server 102, without deviating from the scope of the disclosure.

The electronic device 106 may receive the new use case or the use case portfolio from the UC server 102 and display the received new use case and/or the use case portfolio in an appropriate format on the display screen.

FIG. 2A is a block diagram that illustrates an exemplary use case server. FIG. 2 is explained in conjunction with elements from FIG. 1. With reference to FIG. 2, there is shown the UC server 102. The UC server 102 may comprise a processor 202. The processor 202 may further comprise a use case engine (UCE) 202a and a use case governance (UCG) 202b module. The UC server 102 may further comprise a memory 204, a storage device 206, one or more input/output (I/O) devices, such as an I/O device 208, and a transceiver 210. The I/O device 208 may further include a display screen (not shown).

The processor 202 may comprise suitable logic, circuitry, interfaces, and/or code that may be configured to execute a set of instructions stored in the memory 204. Examples of the processor 202 may include an X86-based processor, a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a state machine, and/or other processors or circuits. The memory 204 may comprise suitable logic, circuitry, and/or interfaces that may be configured to store a machine code and/or a set of instructions with at least one code section executable by the processor 202. The memory 204 may store different types of data, such as actual production data and meta-data (such as code, models, project plans, and audit data).Examples of implementation of the memory 204 may include, but are not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Hard Disk Drive (HDD), Flash memory, and/or a Secure Digital (SD) card.

The I/O device 208 may comprise suitable logic, circuitry, interfaces, and/or code that may correspond to various input and output devices that may be operable to communicate with the processor 202. The input device may be operable to receive an input from the user 110. The output device may be operable to provide an output to the user 110. Examples of the input devices may include, but are not limited to, a touch screen, a microphone, a motion sensor, a light sensor, and/or a docking station. Examples of the output devices may include, but are not limited to, the display screen and/or a speaker.

The transceiver 210 may comprise suitable logic, circuitry, interfaces, and/or code that may be operable to communicate with one or more external devices, such as the UC server 102 and/or the database server 104. Such communication with the one or more external devices may occur by use of the communication network 108. The transceiver 210 may implement known technologies to support wireless communication of the UC server 102 with the communication network 108. The transceiver 210 may include, but is not limited to, an antenna, a radio frequency (RF) transceiver, one or more amplifiers, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, and/or a subscriber identity module (SIM) card.

The transceiver 210 may communicate via wireless communication with networks, such as the Internet, an Intranet and/or a wireless network, such as a dedicated short-range communication (DSRC) network, mobile ad-hoc network (MANET), vehicular ad-hoc network (VANET), intelligent vehicular ad-hoc network (InVANET), internet -based mobile ad-hoc network (IMANET), wireless sensor network (WSN), wireless mesh network (WMN), cellular telephone network, cloud network, wireless fidelity (Wi-Fi) network, and/or wireless local area network (WLAN). The wireless communication may use any of a plurality of communication standards, protocols and technologies, such as the global system for mobile communications (GSM), enhanced data GSM environment (EDGE), wideband code division multiple access (W-CDMA), code division multiple access (CDMA), long term evolution (LTE), time division multiple access (TDMA), Bluetooth (BT), Wireless Fidelity (Wi-Fi) (such as IEEE 802.11a, IEEE 802.11b, IEEE 802. l lg and/or IEEE 802.11η), voice over Internet Protocol (VoIP), Wi-MAX, a protocol for email, instant messaging, and/or Short Message Service (SMS).

In operation, the processor 202 may receive the request comprising the input parameters for the various use case dimensions from the electronic device 106, via the transceiver 210. The processor 202 may store the request in the storage device 206. The request may be received from the electronic device 106 by the transceiver 21 Oof the UC server 102, via the communication network 108. The request may comprise input parameters corresponding to various use case dimensions, preconfigured by the UCE 202a. For example, the request may comprise a first input parameter "Preventive maintenance for... " for a first use case dimension "Business issue to be addressed", a second input parameter "Trucks" for a second use case dimension "Industry", a third input parameter "After Sales" for a third use case dimension "Functional Area", a fourth input parameter "UK" for a fourth use case dimension "Geography", and/or the like. The processor 202 may further receive one or more user preferences from the electronic device 106 for customizing the new use cases. The processor 202 may receive the request comprising the input parameters for the various use case dimensions, and may store in the storage device 206. In an embodiment, the processor 202 may receive external data related to the requested new use case from external resources, such as the database server 104, via a corresponding application programming interface (API). Examples of the external data may include, but are not limited to, live sensor data, periodic data, offline historic sensor data, and/or offline historic failure data.

The processor 202 may communicate all the essential elements, such as the input parameters and/or the external data, to the UCE 202a. The UCE 202a may convert the language of the essential elements to a common meta-level language, known in the art. The common meta-level language may facilitate reusability of the new use case and ensures interoperability for other processes, such as workflow management, use case administration, knowledge management, and audit trails, across company boundaries. The UCG 202b may comprise a tool set for the user 110 to manage the various use case portfolios, such as financial, economic and operational portfolios. The UCG 202b may execute a set of rules to manage the specific and general use cases in an efficient manner. The use cases may be executed by the UCE 202a based on the set of rules retrieved from the UCA 206a. The set of rules may be determined by the UCG 202b. In an embodiment, the set of rules may be implemented by the UCE 202a for specific use cases, general use cases, and use cases from use case libraries that can combine the knowledge of all related use cases.The UCG 202b may may be controlled by a UCG committee that make decisions on data analytics of use case portfolios according to commercial and strategic criteria. The UCG committee further prioritizes amongst the myriads of potential use cases and prepares reports. The UCG committee may include business unit representatives (such as business unit chief data officers or marketing personnel), corporate chief information officers/ chief data officers, chief marketing officer, finance personnel, and controllers. For example, a division may develop a preventative maintenance suite of use cases. The UCG committee may decide to develope some of them that have a business case. The UCG committee may decide to exclude the ones that don't have a business case.

The UCE 202a may generate descriptors based on all the captured essential elements and associated dimensions. The descriptors may be referred to as unique identifiers for the requested use case. The UCE 202a may store the generated descriptors comprising the dimensions and input parameters in the UCA 206a of the storage device 206.

The UCA 206a may implement various operators, such as a model execution operator or a human modelling operator, for structuring and modelling of the new use case based on the generated descriptors. In an embodiment, the UCE 202a may reuse one or more pre- stored use cases from a use case library to perform structuring and modelling of the new use case. One or more operators in the UCA 206a may further perform cleansing, enhancement and execution for the required new use case. The operators may further perform knowledge extraction from the structured and modelled new use case. Such a new use case may be tested based on reviewed assumptions, via an API. The new use case may be further visualized, formatted and distributed by another user, such as an analyst, via a pre-specified API. For example, an auto manufacturer may want to distribute analytic results of preventative maintenance to a dealership network in a specific geographic area. In accordance with an embodiment of the disclosure, independent modules, such as distributors, may be pulled-in from the UCL and parametrized quickly, so that the independent modules are available off-the-shelf and do not require rewriting each time. Such an intervention by the analyst before roll-out of the new use case may be based on the mind+machine® approach and makes the use case flexible and scalable in accordance with the requirement of the user 110. Once tested, the UCA 206a may facilitate audit trails of the new use cases once rolled-out to the electronic device 106 by the UCE 202a. The audit trail may include various processes like data logging, flow observation, flaggers, details of IP rights and legal entity holding the rights and use case trackers for subsequent reference. The UCE 202a may transmit the new use case to the electronic device 106, via the communication network 108.

In accordance with another embodiment, the UCE 202a may generate a use case portfolio, based on a request received from the user 110 via the electronic device 106. Based on the request, the UCE 202a may perform resource allocation across the use case dimensions. The analyst may provide additional inputs and perform refinements, in accordance with the Evalueserve's proprietary mind+machine® approach. Once the portfolio is created, the knowledge management reviews may be performed to spot latest trends that may be provided to the electronic device 106, via the communication network 108. Notwithstanding, the disclosure may not be so limited, and new use cases and new use case portfolios may be generated by the UCE 202a, without deviating from the scope of the disclosure. The electronic device 106 may receive the new use case or the use case portfolio from the UCE 202a and display the received new use case and/or the use case portfolio on the display screen.

FIG. 2B is a block diagram that illustrates a service architecture of an exemplary use case server. FIG. 2B is explained in conjunction with elements from FIG. 1 and FIG 2A. In accordance with FIG. 2B, there is shown a service architecture 200 that may comprise various layers, such as a Use Case Architecture (UCA) 212, the Use Case Engine (UCE) 202a and a Use Case Governance (UCG) 214.

The UCA 206a may be an open source architecture which may support the other layers of use case framework. The UCA 206a may spread across company boundaries and may be implemented in a cloud platform or on a web server. The UCA 206a, at a service level, may include business problems, business questions, decision makers, and data. The UCA 206a, at a use case portfolio level, may include a plurality of use cases. The plurality of use cases may be retrieved from use case libraries and use case governance module. The UCA 206a, at a use case level, may include use case descriptors that may comprise a plurality of use case elements to describe various attributed of the use case. One use case may have at least one descriptor that may capture all essential elements of the use case and related use case dimensions. The use case dimensions may comprise one or more of: a service issue to be addressed, industry related to the use case, functional area related to the use case, geography of the use case, output usage of the use case, owner of the use case, recipients of the use case, input for the use case, outputs of the use case, and models associated with the use case.

The association of a descriptor with each of the use cases may lead to effective utilization, fast execution and reusability of use cases. For example, the service issue to be addressed may be "Preventive maintenance for... " The industry related to the use case may be "Trucks", functional area related to the use case may be "After sales", geography of the use case may be "UK",output usage of the use case may be "Decision on past replacement", owner of the use case may be "After sales support", recipients of theuse case may be "Truck Owners", input for theuse case may be "Formats, Timings... ", outputs of the use case may be "Formats, Timings... ", and the models associated with the use cases may comprise the UCE 202a and use case process. The UCA 206a may be executed by the UCE 202a and the processor 202. The reusability characteristic may be realized by the UCA 206a based on a uniform naming convention for use cases and associated descriptors.

The UCE 202a may be a scalable tool or processor to design, implement and execute the use cases. The UCE 202a may be implemented based on Evalueserve's proprietary mind+machine® model. The UCE 202a may evolve through three different phases. The evolution in first phase, "Phase l",may involve capturing the use cases from client (e.g. the user 110) in a language, such as meta-level language, of the UCA 206a. The UCE 202a may produce an output for one or more processes of the UCG 202b.The UCE 202a may handle workflow at UCA level 3, and part of level 2 and level l.The evolution in second phase, "Phase Π" may increase automation across UCA levelsO to 3. The UCE 202a and/or the UCA 206a may interface with the software packages, such as Astes® and Apama ®. The UCE 202a may further support all the basic elements of the UCA 206a, such as auditors 312, disseminators 308, and/or the operators 316.

The evolution in third phase, "Phase III", may enable the client (e.g. the user 110) to use the use case libraries based on the UCA 206a. Various interoperable UCE 202a packages may be available to create a more automated use case management framework with lesser human intervention. The UCA 206a and/or a variant thereof may be defined as an industry standard to be followed for use case analytics, knowledge management, and trading services.

The UCG 202b may comprise a tool set for clients to manage the various use case portfolios, such as financial, economic and operational portfolios. The UCG 202b may be a set of rules to manage the specific and general use cases in an efficient manner. The use cases may be executed by the UCE 202a based on the set of rules retrieved from the UCA 206a. The set of rules may be decided via the UCG 202b. The set of rules may be implemented by the UCE 202a for specific use cases, general use cases, and use cases from use case libraries that can combine the knowledge of all related use cases. The key areas of governance of the UCG 202b are economic, financial, marketing, customer-based, operational and technical areas. The UCG may capture data at a use case level, such as "Level 0".The UCA 206a may enable capturing key elements at use case level, such as "Level 0". The "Level 0" use cases may be aggregated, based on nested, recursive, fractal, and/or modular paradigm, at the portfolio level, such as "Level 1". Use case libraries may enable life cycle management and data aggregation of such use case portfolios. The UCG 202b may further set priorities on rules to assist a decision making body at company level, such as "Level 2". A cross-functional decision making body may enable market-based decision making based on the use case result. FIG. 3 showsa diagram to illustrate basic elements of a use case architecture. FIG. 3 is explained in conjunction with elements from FIG. 1, FIG. 2 A, and FIG 2B. With reference to FIG. 3, there is shown the UCA 206a. The UCA 206a may include basic elements, such as contributors 302, sources 304, the storage devices 306, disseminators 308, an analyst 310, auditors 312, an administrator 314, operators 316 and a set of application programming interfaces (APIs) 318. The basic elements may be centrally spaced or may be spatially distributed and may be connected through the communication network 108. The analyst 310 may be a human or another system that can provide input or instruction use cases to the analytic use case frame work.

The contributors 302 may be a human (a stakeholder), another system (actors), or other use cases that may interact with the UCA 206a. The contributors 302 may provide external inputs which may be a command for managing the use cases. The sources 304 may be a component that may receive external inputs from the contributors 302 and transmit the received external inputs to the set of APIs 318. The storage devices 306 of the UCA 206a may include a temporary storage area, a permanent tactical storage area and a permanent knowledge management area. The storage devices 306 of the UCA 206a may further store intellectual property (IP) rights that correspond to the use cases, which are the legal entities that own the IP for a module, a library, or a whole use case. The disseminators 308 may perform the task of visualizing, formatting, and distributing the analytic result to the corresponding analyst 310. The auditors312 may perform the task of logging of the data, observing the flow of use cases and tracking the execution of use cases. The data auditing performed by the auditors 312 may ease the life cycle management of use cases, and helps in decision making to set priorities.

The administrator 314 may comprise hardware or software modules to perform transportation, scheduling of workflows, administration of workflow and communication of data from/to the operators 316, the disseminators 308, and the contributors 302. The administrator 314 may fetch the data from/to the storage devices 306, the auditors 312 and the operators 316. The administrator 314 may comprise the set of APIs 318that may interact with the software modules of the operators 316, the disseminators 308 and the contributors 302 and for corresponding operations to be performed. The operators316 may structure the one or more use cases, cleanse the analytical raw data available on which the use cases are to be performed. The operators 316 may further perform modelling of the use cases. The operators 316 may further structure the use cases with data/knowledge extracted from unstructured data sources. The operators 316 may further perform cleansing, enhancement, execution and knowledge extraction of data based on rules stored in the UCG 202b. The operators 316, the disseminators 308, and the auditors 312 may be implemented as hardware or software modules.

FIG. 4 shows an interconnection of use cases 404 in an exemplary use case architecture. FIG. 4 is explained in conjunction with elements from FIG. 1 to FIG 3. With reference to FIG. 4, there is shown one of the various paradigms based on which the plurality of use cases in the UCA 206a may be structured. The various paradigms may be nested, recursive, fractal or modular in which the plurality of use cases are connected with each other. In accordance with an embodiment, new use cases may be created by connecting one or more of existing use cases. The plurality of use cases may be classified into different levels. A "Level 0" use case, such as use case 402a, 402b, or 402c,may be one of the existing plurality of use cases. A "Level 1" use case (not shown) may be an interconnection of one or more "Level 0" use cases. Similarly, a "Level 2" use case (not shown) may be an interconnection of one or more "Level 1" use cases. As shown in FIG 4, the three "Level 0" use cases, such as use cases 402a, 402b, and 402c, are interconnected with each other to create one "Level 1" use case for the analyst 310. Such interconnection and structuring of use cases may facilitate in reuse of use cases. For example, a new use case that may require a new actor activity relation may be created with the existing "Level 0" use cases that addresses multiple and different actor-activity relations. Thus "Level 0" use cases may act as building blocks in the UCA 206a which can be interconnected according to the need of user. The common meta-level language may be used for work flow, administration, knowledge management, audit trails. The meta-level language may further enable interoperability between the different use cases at different levels.

The meta-levels of the UCA 206a may be categorized into four levels, such as a protection level (Level 0), a modelling level (Level 1), a work flow level (Level 2) and a knowledge management level (Level 3).The production level (Level 0) is the bottom most level in the UCA 206a meta levels. The production level (Level 0) may handle the actual data flow and run time execution of the use cases.For example, an internet of things (IoT) application for preventive maintenance may run on live system, using software AG®.

The modelling level (Level 1) may work over the production level (Level 0) and may handle model identification before execution version is implemented. For example, the IoT application for preventive maintenance to be identified, such as on software Aster . The workflow level (Level 2) may monitor and handle the work flow of the use cases. The work flow model (Level 2) may identify the roles and jobs that need to be handled at modelling (Level 1) and production level (Level 0). The knowledge management level (Level 3) may analyze and improve models and process of handling the plurality of use cases, such as Rol of the IoT use case.

The UCA 206a may be associated with different meta-levels for distinguishing and distributing the responsibilities of delivering a service to the user 110. Because of the layered architecture, it is easy to write, understand, test and extend the operation. Addition of new services and management of the UCA 206a in a layered architecture is simplified. The layered architecture of the UCA 206a may render the complex process of creation of a new use case of level N+l, from existing level N use cases, much easier. FIGs. 5A and 5B show the different operators that may be implemented in a use case architecture. FIGs. 5A and 5B are explained in conjunction with elements from FIG. 1 to FIG 3. With reference to FIG 5 A, there is shown an example, such as "Mode Execution" operator, of the operators316. The "Model Execution" operator may be fed with data, and an internal operation may be performed on the data by one or more processors, such as the processor 202. The data may be fed as data feeds, such as "Feed #1" to "Feed #5",as input data stream to the "Model Execution" operator. The input data stream may be live sensor data with data points every 1 ms.

The "Model Execution" operator may perform any mathematical operation, known in the art. For example, the "Model Execution" operator may perform a first mathematical operation, such as subtraction of sum of "Feed #1 and "Feed #2" with sum of "Feed #3", "Feed #4", and "Feed #5" to generate "Output #1". The "Model Execution" operator may perform a multiplication of the result of the first mathematical operation with a numeral, such as "5", to generate "Output #2". The "Model Execution" operator may further perform a comparison of the result of the first mathematical operation with a numeral, such as "10". If the result of the comparison is greater than the numeral, "Output #3" is generated. The "Model Execution" operator may output a live stream, such as "Output #1", "Output #2", and "Output #3", of the processed data with data points every 1 ms. The "Model Execution" operator may further synchronize both the input and the output stream data.

With reference to FIG 5B, there is shown a "Human Modelling" operator, of the operators 316. The "Human Modelling" operator may be based on Evalueserve's proprietary mind+machine® approach of performing an intelligent operation, such as generating a model for a use case. The "Human Modelling" operator may be fed with data, and an internal operation may be performed on the data by one or more processors, such as the processor 202. The data may be fed as data feeds, such as "Feed #1" to "Feed #4", as input data stream to the "Human Modelling" operator. The input data stream may be offline historic sensor data or offline historic failure data. The "Human Modelling" operator may perform any intelligent operation, for example, the "Human Modelling" operator may find a model for preventive maintenance for a packaging machine. The "Model Execution" operator may output a live stream of processed data, such as "Output #1", that may correspond to a model.

FIGs. 6A and 6B describe the life cycle management and portfolio management of use cases. With reference to FIG. 6A, there is shown a sequence of steps involved in life cycle management at a use case level. The sequence starts from step 602. At step 602, a new use case may be proposed. The use case proposal may be based on market needs, business need, business case, and implementation plan, as per the requirements of the client. At step 604, the new use case may be designed based on the use case libraries, internal and external data. In an embodiment, the new use case may be at "Level 0". In another embodiment, the new use case may be at "Level 1" that may be designed based on aggregation of "Level 0" use cases. Such designed use cases may be tested thereafter to review the assumptions. At step 606, a use case may be rolled out after being refined based on testing of the designed use cases. The progress of the rolled-out use cases is monitored and audited by the auditors 312 to observe the flow, log and tracking of the use cases. At step 608, the life cycle of the use case may be extended based on the key point indicator (KPI) evaluation. At step 610, the use cases may be terminated based on the termination decision taken by the decision making body at company levels.

With reference to FIG. 6B, there is shown a sequence of steps involved in use case portfolio management at a use case portfolio level. The sequence starts from step 612. At step 612, the resources may be allocated across a business unit, a functional requirement, and a geography to generate a use case portfolio. At step 614, knowledge management reviews may be performed to spot trends in the generated use case portfolio.

FIG. 7 shows a diagram that illustrates an exemplary market place for use case descriptors. With reference to FIG. 7, there is shown a trading service, such as a use case market place 702, that may be implemented by use of a tool, such as Microsoft Azure^®, known in the art. There is further shown a plurality of companies 704A to 704D. Each of the plurality of companies 704A to 704D may build corresponding use cases, such as706A, 706B, 706C, and 706, respectively. The plurality of companies 704A to 704D may themselves build such use cases 706A to 706D on a platform provided by the communication network 108. The plurality of companies 704A to 704D may then own the corresponding pluralities of use case descriptors. For example, the company 704A may own a plurality of use case descriptors, such as Al, A2, A3,... , AN. Similarly, the company 704B may own a plurality of use case descriptors Bl, B2, B3,... , BN. Similarly, the company 704C may own a plurality of use case descriptors CI, C2, C3,... , CN. Similarly, the company 704D may own a plurality of use case descriptors Dl, D2, D3,... , DN. The plurality of companies 704A to 704D may also list the corresponding pluralities of use case descriptors for sale in the use casemarket place 702. Further, the IP rules for nested use cases may be defined. For example, the company 704A may develop a higher- level use case based on other 'smaller' use cases owned by someone else, such as the company 704B. A portfolio of each of the aforesaid use case descriptors, owned by a corresponding company, such as Evalueserve^®, may have a precise ownership in terms of the IP of the company.

In operation, the use case market place 702 may provide a cross-company platform to mutually exchange such use cases 706 A to 706D and various input parameters of corresponding plurality of companies 704A to 704D. Some companies may not want to exchange their use cases, as they consider such use cases to be their key asset. Some other companies, like Evalueserve , may develop a business model, that may include a licensing and/or revenue-sharing model, based on such cross-company platform. Such a business model may commercialise their use case descriptor portfolios, via the use case market place 702.

While the present disclosure has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present disclosure. In addition, many modifications and adaptations may be made to adapt the system and method of the present invention to a particular situation without departing from its scope. Therefore, it is intended that the present invention is not to be taken as limited to the particular embodiment disclosed herein, but embodiments incorporating such modifications, adaptations, equivalents are intended to fall within the scope of the present invention.

Claims

Claims:

1. A system comprising;

at least one device, wherein the at least one device is configured to present a user interface to a user to feed in at least one parameter for a use case scenario;

a first server, communicably coupled to the at least one device through a network, wherein the first server is configured to create use case analytics knowledge management and trading services; and

a second server, communicably coupled to the first server through the network, wherein the second server is configured to provide external data to the first server, wherein the second server is further configured to receive use case scenarios generated by the first server for storage wherein the stored use case scenarios can be traded across.

2. The system of claim 1, wherein the at least one device is any one of a laptop, a tablet computer, a smartphone, or a Personal Digital Assistant (PDA) device.

3. The system of claim 1, wherein, the at least one user device is further configured to display result of analysis.

4. The system of claim 1 , wherein the at least one user device includes a touch or a non-touch display.

5. The system of claim 1, wherein the first server is implemented over cloud platform.

6. The system of claim 1, wherein the first server is further configured to design, implement, and use the use case scenarios generated.

7. The system of claim 1, wherein the second server is implemented over cloud platform.

8. The system of claim 1, wherein the second server is configured to store use case scenarios generated by other servers.

9. The system of claim 1, wherein the second server stores data models and data structures for modelling use case scenarios.

10. The system of claim 1, wherein the second server implements a fast file access by spreading the files algorithmically and evenly.

11. The system of claim 1 , wherein the network is chosen from a group comprising Internet, a cloud network, a Wireless Fidelity (Wi-Fi) network, a Wireless Local Area Network (WLAN), a Local Area Network (LAN), a telephone line (POTS), and/or a Metropolitan Area Network (MAN).

12. The system of claim 1, wherein the at least one device is able to communicate to the network through a Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, infrared (IR), IEEE 802.11, 802.16, cellular communication protocols, and/or Bluetooth (BT) communication protocols.

13. A method comprising ;

receiving, by a server, a request by a user through an electronic device connected to the server through a network, wherein the request is for a new use case, wherein the request further comprises at least one input parameter gathered by the electronic device by user's input and at least one user preference;

gathering, by the server, external data stored in a data storage that stores input parameters for various use case dimensions, connected to the server through the network, wherein the external data is related to the request received by the server; capturing, by the server, the at least input parameter and the corresponding external data in a common meta level language;

generating, by the server, a unique identifier for the requested use case;

storing, by the server, the unique identifier in the data storage;

structuring and modeling, by the server, a new use case analytics based on the unique identifier;

storing, by the server, the new use case analytics in the data storage that stores a plurality of used case analytics of previous requests; and

sending, by the server, the use case analytics to the electronic device.

14. The method of claim 13, wherein the new use case analytics may be structured using anyone or a combination of the plurality of used case analytics stored in the data storage.

15. The method of claim 13, wherein the user inputs are received through a user interface on the electronic device.

16. The method of claim 13, wherein the electronic device is any one of a laptop, a tablet computer, a smartphone, or a Personal Digital Assistant (PDA) device.

17. The method of claim 13, wherein the electronic device includes a touch or a non- touch display.

18. The method of claim 13, wherein the stored new use case analytics can be traded off through the server.

19. The method of claim 13, wherein the method further includes formatting of the new use case analytics by an analyst before being sent to the electronic device.

20. The method of claim 13, wherein the method further includes adding additional inputs by the analyst.

21. The method of claim 13, wherein the external data is any one or a combination of live sensor data, periodic data, offline historic sensor data, or offline historic failure data.

22. The method of claim 13, wherein the method further includes capturing the input parameters and the external data in accordance with a common meta-level language to facilitate reusability of the new use case analytics.

23. The method of claim 13, wherein the data storage is a local data storage or remote data storage.

24. A non-transitory computer-readable storage medium for generating new use case analytics, when executed by a server, causes the server to;

receiving, by the server, a request by a user through an electronic device connected to the server through a network, wherein the request is for the new use case analytics, wherein the request further comprises at least one input parameter gathered by the electronic device by user's input and at least one user preference;

gathering, by the server, external data stored in a data storage that stores input parameters for various use case dimensions, connected to the server through the network, wherein the external data is related to the request received by the server;

capturing, by the server, the at least input parameter and the corresponding external data in a common meta level language;

generating, by the server, a unique identifier for the requested use case;

storing, by the server, the unique identifier in the data storage;

sending, by the server, the use case analytics to the electronic device.