This disclosure relates generally to monolith applications,
and more particularly to method and system for identifying common
requirements from applications.
Background
[002] In a large organization, multiple teams may develop several
monolith applications with similar functionalities based on team perspective
and needs. Alternately, monolith applications with similar functionalities may
have been procured from different vendors over different timelines. Many
functionalities in such applications may be similar or overlapping with one
or more functionalities in other applications. Due to differences in a
technology stack across systems, the functionalities may be duplicated to
accomplish a need.
[003] For example, in a traffic management system and a parking
management system, a module to capture image of a parked vehicle, fetch
details about the vehicle such as make of the car, vehicle number, or the
like, may be required by both systems. but when the two systems are
developed on different technology stacks, the same module may be
replicated. Therefore, this may lead to an increase in cost for resources such
as assets for deploying same functionality with different technology stacks,
man power for developing software with same functionality, etc. Further,
reusability of such functionalities may not be feasible on different technology
stacks.
[004] The conventional technqiues fail to obtain a common
monolith application from a plurality of applications, particularly when the
plurality of applications are based on different technology stacks. There is,
therefore, a need in the present state of art for techniques to identify
Docket No.: IIP-HCL-P0062
3
common requirements from applications of varying technology stakcs and
optimize the common requirements to generate a common monolith
application.
SUMMARY
[005] In one embodiment, a method for identifying common
requirements from applications is disclosed. In one example, the method
includes receiving a plurality of requirements from a plurality of applications.
Each of the plurality of requirements corresponds to a functionality in one of
the plurality of applications. For at least two of the plurality of requirements,
the method further includes determining a similarity index through each of a
set of analysis techniques. The set of analysis techniques includes a
process driven analysis technique, a data driven analysis technique, and a
consumer driven analysis technique. For at least two of the plurality of
requirements, the method further includes calculating a final similarity index
based on the similarity index determined through each of a set of analysis
techniques. The final similarity index is a weighted average of the similarity
index determined through each of a set of analysis techniques. The method
further includes generating a similarity matrix for the plurality of
requirements based on the final similarity index. Elements of the similarity
matrix are final similarity indices corresponding to the plurality of
requirements. The method further includes generating a hierarchical cluster
tree for the plurality of requirements based on the final similarity index
corresponding to each of the plurality of requirements.
[006] In one embodiment, a system for identifying common
requirements from applications is disclosed. In one example, the system
includes a processor and a computer-readable medium communicatively
coupled to the processor. The computer-readable medium may store
processor-executable instructions, which, on execution, may cause the
processor to receive a plurality of requirements from a plurality of
applications. Each of the plurality of requirements corresponds to a
Docket No.: IIP-HCL-P0062
4
functionality in one of the plurality of applications. For at least two of the
plurality of requirements, the processor-executable instructions, on
execution, may further cause the processor to determine a similarity index
through each of a set of analysis techniques. The set of analysis techniques
includes a process driven analysis technique, a data driven analysis
technique, and a consumer driven analysis technique. For at least two of
the plurality of requirements, the processor-executable instructions, on
execution, may further cause the processor to calculate a final similarity
index based on the similarity index determined through each of a set of
analysis techniques. The final similarity index is a weighted average of the
similarity index determined through each of a set of analysis techniques.
The processor-executable instructions, on execution, may further cause the
processor to generate a similarity matrix for the plurality of requirements
based on the final similarity index. Elements of the similarity matrix are final
similarity indices corresponding to the plurality of requirements. The
processor-executable instructions, on execution, may further cause the
processor to generate a hierarchical cluster tree for the plurality of
requirements based on the final similarity index corresponding to each of
the plurality of requirements.
[007] It is to be understood that both the foregoing general
description and the following detailed description are exemplary and
explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[008] The accompanying drawings, which are incorporated in and
constitute a part of this disclosure, illustrate exemplary embodiments and,
together with the description, serve to explain the disclosed principles.
[009] FIG. 1 is a block diagram of an exemplary system for
identifying common requirements from applications, in accordance with
some embodiments.
Docket No.: IIP-HCL-P0062
5
[010] FIG. 2 illustrates a functional block diagram of a
requirements identification device implemented by the exemplary system of
FIG. 1, in accordance with some embodiments.
[011] FIGS. 3A and 3B illustrate a flow diagram of an exemplary
process for identifying common requirements from applications, in
accordance with some embodiments.
[012] FIGS. 4A and 4B illustrate a flow diagram of a detailed
exemplary control logic for identifying common requirements from
applications, in accordance with some embodiments.
[013] FIG. 5 illustrates transformation of technology-specific
elements of requirements into technology-agnostic process elements
through call graph analysis, in accordance with some embodiments.
[014] FIG. 6 is an exemplary table describing calculation of a
similarity index between two requirements based on call graph-based
comparison, in accordance with some embodiments.
[015] FIG. 7 illustrates data-driven comparison between two
requirements, in accordance with some embodiments.
[016] FIG. 8 illustrates consumer-driven comparison between two
requirements, in accordance with some embodiments.
[017] FIG. 9 illustrates an exemplary similarity matrix for a plurality
of requirements, in accordance with some embodiments.
[018] FIG. 10 illustrates a hierarchical cluster tree for a plurality of
requirements, in accordance with some embodiments.
[019] FIG. 11 is an exemplary table describing maturity analysis
between two common requirements, in accordance with some
embodiments.
DETAILED DESCRIPTION
[020] Exemplary embodiments are described with reference to the
accompanying drawings. Wherever convenient, the same reference
numbers are used throughout the drawings to refer to the same or like parts.
Docket No.: IIP-HCL-P0062
6
While examples and features of disclosed principles are described herein,
modifications, adaptations, and other implementations are possible without
departing from the spirit and scope of the disclosed embodiments. It is
intended that the following detailed description be considered as exemplary
only, with the true scope and spirit being indicated by the following claims.
[021] Referring now to FIG. 1, an exemplary system 100 for
identifying common requirements from applications is illustrated, in
accordance with some embodiments of the present disclosure. The system
100 may implement a requirements identification device 102 (for example,
server, desktop, laptop, notebook, netbook, tablet, smartphone, mobile
phone, or any other computing device), in accordance with some
embodiments of the present disclosure. The requirements identification
device 102 may identify common requirements from applications (such as,
software applications, smartphone applications, web applications, etc.)
based on a similarity index obtained by comparing a plurality of
requirements of each of the applications. It should be noted that, in some
embodiments, the requirements identification device 102 may generate a
hierarchical cluster tree based on the similarity index to obtain the common
requirements of the applications.
[022] As will be described in greater detail in conjunction with
FIGS. 2 – 12, the requirements identification device may receive a plurality
of requirements from a plurality of applications. Each of the plurality of
requirements may correspond to a functionality in one of the plurality of
applications. For at least two of the plurality of requirements, the
requirements identification device may further determine a similarity index
through each of a set of analysis techniques. The set of analysis techniques
may include a process driven analysis technique, a data driven analysis
technique, and a consumer driven analysis technique. For at least two of
the plurality of requirements, the requirements identification device may
further calculate a final similarity index based on the similarity index
determined through each of a set of analysis techniques. The final similarity
Docket No.: IIP-HCL-P0062
7
index is a weighted average of the similarity index determined through each
of a set of analysis techniques. The requirements identification device may
further generate a similarity matrix for the plurality of requirements based
on the final similarity index. Elements of the similarity matrix are final
similarity indices corresponding to the plurality of requirements. The
requirements identification device may further generate a hierarchical
cluster tree for the plurality of requirements based on the final similarity
index corresponding to each of the plurality of requirements.
[023] In some embodiments, the requirements identification
device 102 may include one or more processors 104 and a computerreadable medium 106 (for example, a memory). The computer-readable
medium 106 may include a plurality of requirements corresponding to a
plurality of applications. Further, the computer-readable storage medium
106 may store instructions that, when executed by the one or more
processors 104, cause the one or more processors 104 to identify common
requirements from applications, in accordance with aspects of the present
disclosure. The computer-readable storage medium 106 may also store
various data (for example, the plurality of requirements, similarity indices
between at least two of the plurality of requirements, similarity matrix, cluster
tree, and the like) that may be captured, processed, and/or required by the
system 100.
[024] The system 100 may further include a display 108. The
system 100 may interact with a user via a user interface 110 accessible via
the display 108. The system 100 may also include one or more external
devices 112. In some embodiments, the requirements identification device
102 may interact with the one or more external devices 112 over a
communication network 114 for sending or receiving various data. The
external devices 112 may include, but may not be limited to, a remote
server, a digital device, or another computing system.
[025] Referring now to FIG. 2, a functional block diagram of a
requirements identification device 200 is illustrated, in accordance with
Docket No.: IIP-HCL-P0062
8
some embodiments. In an embodiment, the requirements identification
device 200 may include a comparison module 202, a cluster tree generation
module 204, a maturity analysis module 206, and a delta analysis module
208. In such an embodiment, the requirements identification device 200
may be analogous to the requirements identification device 102 of the
system 100.
[026] The requirements identification device 200 may receive an
input 210. By way of an example, the input 210 may be a plurality of
applications or source code associated with each of the plurality of
applications. In an embodiment, each of the plurality of applications may be
a monolith application. The comparison module 202 may receive the input
210 and identify a plurality of requirements for each of the plurality of
applications. Each of the plurality of requirements corresponds to a
functionality of an application. In an embodiment, the plurality of
requirements may be identified through a code analysis technique (such as,
static code analysis, dynamic code analysis, etc.). Further, the comparison
module 202 may compare the plurality of requirements in pairs through each
of a set of analysis techniques. In an exemplary scenario, two applications
may be received as the input 210. In such a scenario, each of the plurality
of requirements of a first application may be compared with each of the
plurality of requirements of a second application. In general, when n number
of applications are received by the comparison module 202, the plurality of
requirements corresponding to each of the n number of applications may be
compared with the plurality of requirements corresponding to remaining n-1
applications.
[027] A similarity index is determined between two requirements
through each of the set of analysis techniques. In some embodiments, the
set of analysis techniques includes a process driven analysis technique, a
data driven analysis technique, and a consumer driven analysis technique.
In such embodiments, three similarity indices are obtained. Further, a final
similarity index is calculated using each of the three similarity indices. It may
Docket No.: IIP-HCL-P0062
9
be noted that the final similarity index may be a weighted average of the
three similarity indices. The final similarity index may be calculated for every
two of the plurality of requirements corresponding to the plurality of
applications.
[028] The cluster tree generation module 204 receives the final
similarity indices corresponding to the plurality of requirements. Further, the
cluster tree generation module 204 generates a similarity matrix based on
the final similarity indices. Elements of the similarity matrix are final similarity
indices corresponding to the plurality of requirements. Further, the cluster
tree generation module 204 generates a hierarchical cluster tree for the
plurality of requirements based on the similarity matrix. Further, the cluster
tree generation module 204 identifies at least one cluster of requirements
from the plurality of requirements through the hierarchical cluster tree. It
may be noted that the at least one cluster of requirements includes a set of
requirements from the plurality of requirements. The final similarity indices
corresponding to every two of the set of requirements within the at least one
cluster are above a predefined threshold.
[029] The maturity analysis module 206 receives the at least one
cluster from the cluster tree generation module 204. Further, for each of the
least one cluster, the maturity analysis module 206 assigns a rank to each
of the set of requirements based on a set of performance parameters of
each of the set of requirements. By way of an example, the set of
performance parameters may include, but may not be limited to,
performance, code quality, error handling, defect localization in production
environment, technology weightage, and the like. Further, for each of the
least one cluster, the maturity analysis module 206 selects a top-ranked
requirement from the set of requirements.
[030] The delta analysis module 208 receives the top-ranked
requirement from the maturity analysis module 206. For each of the at least
one cluster, the delta analysis module 208 compares the top-ranked
requirement with remaining of the set of requirements. Further, for each of
Docket No.: IIP-HCL-P0062
10
the at least one cluster, the delta analysis module 208 identifies one or more
unique elements from the remaining of the at least two of the plurality of
requirements which are absent in the top-ranked requirement. Further, for
each of the at least one cluster, the delta analysis module 208 either creates
a new requirement based on each of the one or more unique elements, or
adds the one or more unique elements to the top-ranked requirement.
Further, the delta analysis module 208 generates a common application as
an output 212. The common application includes common requirements
identified from the plurality of applications.
[031] It should be noted that all such aforementioned modules 202
– 208 may be represented as a single module or a combination of different
modules. Further, as will be appreciated by those skilled in the art, each of
the modules 202 – 208 may reside, in whole or in parts, on one device or
multiple devices in communication with each other. In some embodiments,
each of the modules 202 – 208 may be implemented as dedicated hardware
circuit comprising custom application-specific integrated circuit (ASIC) or
gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or
other discrete components. Each of the modules 202 – 208 may also be
implemented in a programmable hardware device such as a field
programmable gate array (FPGA), programmable array logic,
programmable logic device, and so forth. Alternatively, each of the modules
202 – 208 may be implemented in software for execution by various types
of processors (e.g., processor 104). An identified module of executable
code may, for instance, include one or more physical or logical blocks of
computer instructions, which may, for instance, be organized as an object,
procedure, function, or other construct. Nevertheless, the executables of an
identified module or component need not be physically located together, but
may include disparate instructions stored in different locations which, when
joined logically together, include the module and achieve the stated purpose
of the module. Indeed, a module of executable code could be a single
instruction, or many instructions, and may even be distributed over several
Docket No.: IIP-HCL-P0062
11
different code segments, among different applications, and across several
memory devices.
[032] As will be appreciated by one skilled in the art, a variety of
processes may be employed for identifying common requirements from
applications. For example, the exemplary system 100 and the associated
requirements identification device 102 may identify common requirements
from applications by the processes discussed herein. In particular, as will
be appreciated by those of ordinary skill in the art, control logic and/or
automated routines for performing the techniques and steps described
herein may be implemented by the system 100 and the associated
requirements identification device 102 either by hardware, software, or
combinations of hardware and software. For example, suitable code may
be accessed and executed by the one or more processors on the system
100 to perform some or all of the techniques described herein. Similarly,
application specific integrated circuits (ASICs) configured to perform some
or all of the processes described herein may be included in the one or more
processors on the system 100.
[033] Referring now to FIGS. 3A and 3B, an exemplary process
300 for identifying common requirements from applications is depicted via
a flowchart, in accordance with some embodiments. The process 300 may
be implemented by the requirements identification device 102 of the system
100. The process 300 includes receiving a plurality of requirements from a
plurality of applications, at step 302. It should be noted that each of the
plurality of requirements corresponds to a functionality in one of the plurality
of applications. In some embodiments, the plurality of requirements is
identified from each of the plurality of applications through a code analysis
technique.
[034] Further, the process 300 includes, for at least two of the
plurality of requirements, determining a similarity index through each of a
set of analysis techniques, at step 304. In an embodiment, the set of
analysis techniques includes a process driven analysis technique, a data
Docket No.: IIP-HCL-P0062
12
driven analysis technique, and a consumer driven analysis technique. It may
be noted that elements of each of the at least two of the plurality of
requirements may be transformed into technology agnostic elements prior
to determining the similarity index through each of the set of analysis
techniques.
[035] Further, the process 300 includes, for at least two of the
plurality of requirements, calculating a final similarity index based on the
similarity index determined through each of a set of analysis techniques, at
step 306. In an embodiment, the final similarity index is a weighted average
of the similarity index determined through each of a set of analysis
techniques. Further, the process 300 includes generating a similarity matrix
for the plurality of requirements based on the final similarity index, at step
308. Elements of the similarity matrix are final similarity indices
corresponding to the plurality of requirements. By way of an example, the
comparison module 202 may receive the plurality of applications and
identify the plurality of requirements in each of the plurality of applications
through a code analysis technique. Further, the comparison module 202
may determine a similarity index for at least two of the plurality of
requirements through each of a process-driven comparison, a data-driven
comparison, and a consumer-driven comparison. A weighted average of
three similarity indices obtained through the set of analysis techniques may
be used to obtain a final similarity index. A similarity matrix may be obtained
including the final similarity indices corresponding to the plurality of
requirements.
[036] Further, the process 300 includes generating a hierarchical
cluster tree for the plurality of requirements based on the final similarity
index corresponding to each of the plurality of requirements, at step 310.
Further, the process 300 includes identifying at least one cluster of
requirements from the plurality of requirements through the hierarchical
cluster tree, at step 312. It may be noted that the at least one cluster of
requirements includes each of the at least two of the plurality of
Docket No.: IIP-HCL-P0062
13
requirements. It may also be noted that the final similarity index
corresponding to the at least two of the plurality of requirements within the
at least one cluster is above a predefined threshold. In continuation of the
example above, the cluster tree generation module 204 may receive the
similarity matrix from the comparison module 202 and generate a
hierarchical cluster tree based on the similarity matrix. Further, the plurality
of requirements may be divided into clusters using the hierarchical cluster
tree. It may be noted that for requirements within each cluster, the final
similarity index is above a predefined threshold.
[037] Further, the process 300 includes, for each of the at least
one cluster, assigning a rank to each of the at least two of the plurality of
requirements based on a set of performance parameters, at step 314.
Further, the process 300 includes for each of the at least one cluster,
selecting a top-ranked requirement from the at least two of the plurality of
requirements, at step 316. Further, the process 300 includes generating a
common application using the top-ranked requirement from each of the at
least one cluster, at step 318. In continuation of the example above, the
maturity analysis module 206 may receive the clusters from the cluster tree
generation module 204 and assign a rank to each of the requirements within
the cluster based on a set of performance parameters of each of the
requirements within the cluster. It may be noted that the requirements within
a cluster are considered as common requirements by the system 200.
Therefore, a top-ranked requirement from each of the clusters may be
selected to generate a common application (for example, a common
monolith application from a plurality of applications).
[038] Further, the process 300 includes, for each of the at least
one cluster, comparing the top-ranked requirement with remaining of the at
least two of the plurality of requirements, at step 320. Further, the process
300 includes, for each of the at least one cluster, identifying one or more
unique elements from the remaining of the at least two of the plurality of
requirements, at step 322. The one or more unique elements are absent in
Docket No.: IIP-HCL-P0062
14
the top-ranked requirement. Further, the process 300 includes, for each of
the at least one cluster, creating a new requirement, corresponding to each
of the one or more unique elements, in the common application, at step 324.
Further, the process 300 includes, for each of the at least one cluster,
adding the one or more unique elements to the top-ranked requirement in
the common application, at step 326. In continuation of the example above,
the delta analysis module 208 receives the top-ranked requirement selected
by the maturity analysis module 206. Further, the delta analysis module 206
performs a comparison between process elements of the top-ranked
requirement with process elements of remaining of the requirements within
the cluster. When unique process elements are found in the remining of the
requirements which may be essential for the common application, such
unique process elements are either added to the top-ranked requirement in
the common application or added as a new requirement to the common
application. It may be noted that an optimized set of requirements is
obtained in form of the common application.
[039] Referring now to FIGS. 4A and 4B, a detailed exemplary
control logic 400 for identifying common requirements from applications is
depicted via a flow chart, in accordance with some embodiments. In an
embodiment, the control logic 400 may be implemented through the
requirements identification device 102. By way of an example, the control
logic 400 includes a plurality of applications (for example, an application
402, an application 404, and an application 406). It may be noted that the
application 402, the application 404, and the application 406 are shown as
an exemplary scenario for the control logic 400 and that in some other
embodiments, the plurality of applications may include more than three
applications.
[040] Further, each of the plurality of applications includes a
plurality of requirements. By way of an example, the application 402
includes requirements 408a, 408b, 408c, and 408d, the application 404
includes requirements 410a, 410b, 410c, and 410d, and the application 406
Docket No.: IIP-HCL-P0062
15
includes requirements 412a, 412b, 412c, and 412d. The control logic 400
includes identifying the plurality of requirements from each of the plurality of
applications. Technology-specific static and dynamic code analysis may be
used to identify the plurality of requirements of an application. Further, the
control logic 400 includes comparing each of the plurality of requirements
with remaining of the plurality of requirements through a set of analysis
techniques. The set of analysis techniques includes process-driven
comparison 414, data-driven comparison 416, and consumer-driven
comparison 418. A similarity index may be determined between each of the
plurality of requirements with remaining of the plurality of requirements
through each of the set of analysis techniques. Three similarity indices may
be obtained upon performing process-driven comparison 414, data-driven
comparison 416, and consumer-driven comparison 418. The similarity index
between two requirements (for example, the requirement 412a and the
requirement 414a) indicates a level of commonality between the two
requirements. In an embodiment, the similarity index may range from 0 to
100. In such an embodiment, the similarity index of 0 may indicate no
similarity between the two requirements and the similarity index of 100 may
indicate complete similarity between the two requirements.
[041] The process driven comparison 414 may be performed for
two requirements to identify a process flow associated with a requirement
and to compare the process flow of the requirement with the process flow
of another requirement to determine a similarity level between the two
requirements. Further, the process driven comparison 414 may include a
call graph-based comparison 420, a dependency-based comparison 422,
or a combination thereof. The call graph-based comparison 420 is explained
in detail in conjunction with FIGS. 5 and 6.
[042] Referring now to FIG. 5, transformation of technologyspecific elements of requirements (for example, A1R1 and A2R1) into
technology-agnostic process elements through call graph analysis is
illustrated, in accordance with some embodiments. The comparison module
Docket No.: IIP-HCL-P0062
16
202 generates a technology-specific method flow for each of the plurality of
requirements. A technology-specific method flow 502 is obtained for the
requirement A1R1 and a technology-specific method flow 504 is obtained
for the requirement A2R1 through call graph data. By way of an example,
the technology-specific method flow 502 includes steps A1R1-M1, A1R1-
M2, A1R1-M3, and A1R1-M4 and the technology-specific method flow 504
includes steps A2R1-M1, A2R1-M2, A2R1-M3, and A2R1-M4. It may be
noted that the technology-specific method flow of a requirement is based on
a technology of an application to which the requirement belongs. Therefore,
the steps in the technology-specific method flows of different requirements
may be based on different technologies. However, to obtain a similarity
index between two requirements, the technology of each of the two
requirements should be same.
[043] The comparison module 202 may transform the steps of the
technology-specific method flow for each of the plurality of requirements into
technology-agnostic elements. Thus, the technology-specific method flow
for each of the plurality of requirements is transformed into a technologyagnostic process flow or a pseudocode. The technology-specific method
flow 502 is transformed into technology-agnostic process flow 506 and the
technology-specific method flow 504 is transformed into technologyagnostic process flow 508. Technology-agnostic elements of the
technology-agnostic process flow 506 include A1R1-PF1, A1R1-PF2,
A1R1-PF3, and A1R1-PF4. Technology-agnostic elements of the
technology-agnostic process flow 506 include A2R1-PF1, A2R1-PF2,
A2R1-PF3, and A2R1-PF4. It may be noted that the technology-agnostic
process flow obtained through a call graph may be in form of a sequence
diagram, a flowchart diagram, a pseudocode, or the like.
[044] Referring now to FIG. 6, an exemplary table 600 describing
calculation of a similarity index between two requirements (for example,
A1R1 and A2R1) based on call graph-based comparison is shown, in
accordance with some embodiments. The table 600 aligns the steps of the
Docket No.: IIP-HCL-P0062
17
technology-agnostic process flows of the requirements A1R1 and A2R1.
Further, a weightage 602 is assigned to each of the steps of the technologyagnostic process flows based on importance of each of the steps. For
example, the weightage 602 corresponding to the steps A1R1-PF1 and
A2R1-PF1 is 20%. Further, the steps may be compared to obtain a process
level similarity index 604. The process level similarity index 604
corresponding to the steps A1R1-PF1 and A2R1-PF1 is 80.
[045] Further, effective similarity index 606 at a process level is
calculated by multiplying the process level similarity index 604 and the
weightage 602. The effective similarity index 606 corresponding to the steps
A1R1-PF1 and A2R1-PF1 is 16. Similarly, the effective similarity index 606
may be obtained for each of the steps of the technology-agnostic process
flows of the requirements A1R1 and A2R1. A requirement level similarity
index 608 based on the call graph-based comparison is calculated as a sum
of the effective similarity index 606 corresponding to each of the steps of
the technology-agnostic process flows of the requirements A1R1 and A2R1.
The requirement level similarity index 608 of the requirements A1R1 and
A2R1 is 46.8.
[046] Referring back to FIG. 4A and 4B, the dependency based
comparison 422 performs a comparison between list of external
dependencies used for each of the plurality of requirements. An element of
a requirement may use an external dependency through libraries or thirdparty web services. Evaluation of number of library calls and type of library
calls may be used for identifying similarities between requirements. Further,
applications may use third-party web services over the internet and analysis
of common third-party web services across applications may be used to
identify the similarities between requirements. It may be noted that the
similarity index between two requirements with respect to process-driven
comparison 414 may be calculated by applying the similarity index
calculated based on the call graph based comparison 420 and the
dependency based comparison 422 using an appropriate weightage.
Docket No.: IIP-HCL-P0062
18
[047] Further, the data-driven comparison 416 may include input
parameters based comparison 424 and output parameters based
comparison 426. The data-driven comparison 416 may compare the
plurality of requirements based on data elements consumed and processed
by each of the plurality of requirements. It may be noted that internal
processing element may be similar to a black box. By way of an example,
data inflow to a requirement may be through method argument,
configurations, query result from a database, etc. It may also be noted that
data outflow for a requirement may be through return value of a function,
report generated in a file system, updating data in a database, etc. A
similarity index based on the data-driven comparison 416 may be
determined. This is further discussed in detail in conjunction with FIG. 7.
[048] Referring now to FIG. 7, data-driven comparison between
two requirements (for example, requirement 1 and requirement 2) is
illustrated, in accordance with some embodiments. It may be noted that
requirement 1 data 702 and requirement 2 data 704 may be technologyspecific and based on the technology of the application. In some exemplary
scenarios, data representation and formation in at least one requirement
may be provided in a non-standardized manner. In such scenarios, direct
data comparison may give erroneous results. Therefore, data converter 706
receives the requirement 1 data 702 and the requirement 2 data 704.
Further, the data converter 706 uses a data element mapper 708 to
transform data elements of each of the requirement 1 data 702 and the
requirement 2 data 704 into requirement 1 technology agnostic elements
710 and requirement 2 technology agnostic elements 712, respectively. In
some embodiments, the data element mapper 708 may include technology
specific data types. Further, the requirement 1 technology agnostic
elements 710 and the requirement 2 technology agnostic elements 712 may
be provided to a similarity index calculator 714 to determine a requirement
1 and requirement 2 similarity index 716.
Docket No.: IIP-HCL-P0062
19
[049] Referring back to FIGS. 4A and 4B, consumer-driven
comparison 418 is performed between the plurality of requirements. The
consumer-driven comparison 418 evaluates a requirement based on a
business problem resolved by the requirement from point of view of a
consumer. The consumer-driven comparison 418 may include a business
problem comparison 428 and a resolution comparison 430. It may be noted
that the process-driven comparison 414, the data-driven comparison 416,
and the consumer-driven comparison 418 may be performed sequentially
or in parallel. This is discussed in detail in conjunction with FIG. 8.
[050] Referring now to FIG. 8, consumer-driven comparison
between two requirements (for example, requirement 1 and requirement 2)
is illustrated, in accordance with some embodiments. The consumer-driven
comparison includes a business problem comparison 802 and a resolution
comparison 804. The business problem comparison 802 includes receiving
a requirement 1 business problem 806 and a requirement 2 business
problem 808. Further, a similarity index based on business problem 810 is
calculated based on the requirement 1 business problem 806 and the
requirement 2 business problem 808. The resolution comparison 804
includes receiving a requirement 1 resolution 812 and a requirement 2
resolution 814. Further, a similarity index based on resolution 816 is
calculated based on the requirement 1 resolution 812 and the requirement
2 resolution 814.
[051] Referring now to FIGS. 4A and 4B, the control logic 400
includes calculating a similarity index between two requirements through
each of the process-driven comparison 414, the data-driven comparison
416, and the consumer-driven comparison 418. A similarity matrix is
generated for the plurality of requirements through each of the processdriven comparison 414, the data-driven comparison 416, and the consumerdriven comparison 418. The process-driven comparison 414 generates a
requirement similarity matrix 432, the data-driven comparison 416
generates a requirement similarity matrix 434, and the consumer-driven
Docket No.: IIP-HCL-P0062
20
comparison 418 generates a requirement similarity matrix 436. Further, a
final similarity index is calculated between two requirements based on the
similarity matrix calculated through each of the process-driven comparison
414, the data-driven comparison 416, and the consumer-driven comparison
418. In some embodiments, the final similarity index for two requirements
may be a weighted average of the similarity indices for the two requirements
calculated through the process-driven comparison 414, the data-driven
comparison 416, and the consumer-driven comparison 418. A consolidated
similarity matrix 438 is constructed for the plurality of requirements using
each of the requirement similarity matrix 432, the requirement similarity
matrix 434, and the requirement similarity matrix 436. This is discussed in
detail in conjunction with FIG. 9.
[052] Referring now to FIG. 9, an exemplary similarity matrix 900
for a plurality of requirements (for example, A1R1, A1R2, A2R1, A2R2, and
A2R3) is depicted, in accordance with some embodiments. The similarity
matrix 900 may be analogous to the consolidated similarity matrix 438. Each
of elements of the similarity matrix 900 may be a final similarity index for two
requirements. For example, the final similarity index between A1R1 and
A1R2 is 0.45 and the final similarity index between A1R1 and A2R1 is 0.74.
In some embodiments, the final similarity index for two requirements may
be a weighted average of the similarity indices for the two requirements
calculated through the process-driven comparison 414, the data-driven
comparison 416, and the consumer-driven comparison 418.
[053] Referring now to FIGS. 4A and 4B, the control logic 400
further includes requirement clustering 440. The plurality of requirements is
grouped into a plurality of clusters through a hierarchical cluster tree. For
example, the plurality of clusters may include a cluster 442a, a cluster 442b,
and a cluster 442c. This has been discussed in detail in conjunction with
FIG. 10.
[054] Referring now to FIG. 10, a hierarchical cluster tree 1000 for
a plurality of requirements (for example, A1R2, A2R2, A1R1, and A2R1) is
Docket No.: IIP-HCL-P0062
21
illustrated, in accordance with some embodiments. The hierarchical cluster
tree 1000 is generated based on a similarity matrix (for example, the
similarity matrix 900) corresponding to the plurality of requirements. It may
be noted that two requirements may be grouped into a cluster when the final
similarity index between the two requirements is above a predefined
threshold similarity. Therefore, when the predefined threshold similarity is
75%, A1R1 and A2R1 are grouped into one cluster. The hierarchical cluster
tree may be summarized as: “(A1R1, A2R1), A2R2, A1R2”. The predefined
threshold similarity may be defined based on business requirements. The
requirements A1R1 and A2R1 are above the predefined threshold similarity.
Therefore, A1R1 and A2R1 are considered as common requirements. It
may be noted that one of A1R1 and A2R1 may be included in an optimal
set of requirements for the common application.
[055] Referring now to FIGS 4A and 4B, the control logic 400 may
further include maturity analysis 444. In an embodiment, the maturity
analysis 444 may be performed by the maturity analysis module 206. A
cluster obtained from the hierarchical cluster tree may include a set of
requirements. The maturity analysis 444 may determines an optimum
requirement from the set of requirements based on a set of performance
parameters. This is discussed in detail in conjunction with FIG. 11.
[056] Referring now to FIG. 11, an exemplary table 1100
describing maturity analysis between two common requirements (for
example, A1R1 and A2R1) is illustrated, in accordance with some
embodiments. The maturity analysis includes assigning a rank to each of a
set of requirements within a cluster. Further, a top-ranked requirement from
the set of requirements is selected in a list of final requirements in the
common application. The table 1100 allows evaluation of each of the set of
requirements within a cluster based on a set of performance parameters
such as performance 1102, code quality 1104, error handling 1106, usage
in production 1108, and technology weightage 1110. Further, a sum of each
of the set of performance parameters is calculated as total 1112. Further, a
Docket No.: IIP-HCL-P0062
22
rank 1114 is assigned to each of the set of requirements based on the total
1112. For example, when the total 1112 corresponding to A1R1 and A2R1
are 30 and 21, respectively, the ranks 1114 associated with A1R1 and A2R1
are 1 and 2, respectively. Therefore, A1R1 may be selected within the
optimal set of requirements in the common application.
[057] Referring now to FIGS. 4A and 4B, the control logic 400 may
further include delta analysis 446. Delta analysis 446 compares the topranked requirement from a set of requirements (for example, A1R1) with
remaining of the set of requirements (such as, A2R1) to identify missing
features in the top-ranked requirement which may be essential in the
common application. For example, when A1R1 is an accepted requirement
and A2R1 is a rejected requirement, the delta analysis 446 may be
performed between A1R1 and A2R1 to identify unique process elements of
A2R1. Process elements of each of the set of requirements may be obtained
through call graph comparison. For example, A1R1 may include the process
elements PE1, PE2, PE3, and PE5. Further, A2R1 may include the process
elements PE1, PE2, PE4, and PE6. Therefore, the delta analysis 446
between A1R1 and A2R1 may be represented as:
D(A1R1, A2R1) = PE4, PE6
(1)
[058] Therefore, PE4 and PE6 may be identified as unique
elements through the delta analysis 446. Further, based on the nature of
each of PE4 and PE6, the delta analysis module 208 may decide whether
to create a new requirement corresponding to PE4 and PE6 in the common
application or to add PE4 and PE6 to the top-ranked requirement in the
optimal set of requirements 448.
[059] As will be also appreciated, the above described techniques
may take the form of computer or controller implemented processes and
apparatuses for practicing those processes. The disclosure can also be
embodied in the form of computer program code containing instructions
embodied in tangible media, such as floppy diskettes, solid state drives, CD-
Docket No.: IIP-HCL-P0062
23
ROMs, hard drives, or any other computer-readable storage medium,
wherein, when the computer program code is loaded into and executed by
a computer or controller, the computer becomes an apparatus for practicing
the invention. The disclosure may also be embodied in the form of computer
program code or signal, for example, whether stored in a storage medium,
loaded into and/or executed by a computer or controller, or transmitted over
some transmission medium, such as over electrical wiring or cabling,
through fiber optics, or via electromagnetic radiation, wherein, when the
computer program code is loaded into and executed by a computer, the
computer becomes an apparatus for practicing the invention. When
implemented on a general-purpose microprocessor, the computer program
code segments configure the microprocessor to create specific logic
circuits.
[060] Thus, the disclosed method and system try to overcome the
technical problem of identifying common requirements from applications.
The method and system provide a significant reduction in application
portfolio optimization assessment. Further, the method and system provide
for cost and effort optimization in identifying commonalities and uniqueness
across heterogeneous monolith applications. Further, the method and
system accelerate time to market by generating intelligent insights and help
in making informed decisions on transformation roadmap.
[061] As will be appreciated by those skilled in the art, the
techniques described in the various embodiments discussed above are not
routine, or conventional, or well understood in the art. The techniques
discussed above provide for identifying common requirements from
applications. The techniques first receive a plurality of requirements from a
plurality of applications. Each of the plurality of requirements corresponds
to a functionality in one of the plurality of applications. For at least two of the
plurality of requirements, the techniques may then determine a similarity
index through each of a set of analysis techniques. The set of analysis
techniques includes a process driven analysis technique, a data driven
Docket No.: IIP-HCL-P0062
24
analysis technique, and a consumer driven analysis technique. For at least
two of the plurality of requirements, the techniques may then calculate a
final similarity index based on the similarity index determined through each
of a set of analysis techniques. The final similarity index is a weighted
average of the similarity index determined through each of a set of analysis
techniques. The techniques may then generate a similarity matrix for the
plurality of requirements based on the final similarity index. Elements of the
similarity matrix are final similarity indices corresponding to the plurality of
requirements. The techniques may then generate a hierarchical cluster tree
for the plurality of requirements based on the final similarity index
corresponding to each of the plurality of requirements.
[062] In light of the above mentioned advantages and the technical
advancements provided by the disclosed method and system, the claimed
steps as discussed above are not routine, conventional, or well understood
in the art, as the claimed steps enable the following solutions to the existing
problems in conventional technologies. Further, the claimed steps clearly
bring an improvement in the functioning of the device itself as the claimed
steps provide a technical solution to a technical problem.
[063] The specification has described method and system for
identifying common requirements from applications. The illustrated steps
are set out to explain the exemplary embodiments shown, and it should be
anticipated that ongoing technological development will change the manner
in which particular functions are performed. These examples are presented
herein for purposes of illustration, and not limitation. Further, the boundaries
of the functional building blocks have been arbitrarily defined herein for the
convenience of the description. Alternative boundaries can be defined so
long as the specified functions and relationships thereof are appropriately
performed. Alternatives (including equivalents, extensions, variations,
deviations, etc., of those described herein) will be apparent to persons
skilled in the relevant art(s) based on the teachings contained herein. Such
alternatives fall within the scope and spirit of the disclosed embodiments.
Docket No.: IIP-HCL-P0062
25
[064] Furthermore, one or more computer-readable storage media
may be utilized in implementing embodiments consistent with the present
disclosure. A computer-readable storage medium refers to any type of
physical memory on which information or data readable by a processor may
be stored. Thus, a computer-readable storage medium may store
instructions for execution by one or more processors, including instructions
for causing the processor(s) to perform steps or stages consistent with the
embodiments described herein. The term “computer-readable medium”
should be understood to include tangible items and exclude carrier waves
and transient signals, i.e., be non-transitory. Examples include random
access memory (RAM), read-only memory (ROM), volatile memory,
nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and
any other known physical storage media.
[065] It is intended that the disclosure and examples be
considered as exemplary only, with a true scope and spirit of disclosed
embodiments being indicated by the following claims.

CLAIMS
WHAT IS CLAIMED IS:
1. A method (300) for identifying common requirements from applications,
the method comprising:
receiving (302), by a requirements identification device (102), a
plurality of requirements from a plurality of applications, wherein each of
the plurality of requirements corresponds to a functionality in one of the
plurality of applications;
for at least two of the plurality of requirements,
determining (304), by the requirements identification device
(102), a similarity index through each of a set of analysis
techniques, wherein the set of analysis techniques comprises a
process driven analysis technique, a data driven analysis
technique, and a consumer driven analysis technique;
calculating (306), by the requirements identification device
(102), a final similarity index based on the similarity index
determined through each of a set of analysis techniques, wherein
the final similarity index is a weighted average of the similarity index
determined through each of a set of analysis techniques;
generating (308), by the requirements identification device (102), a
similarity matrix (900) for the plurality of requirements based on the final
similarity index, wherein elements of the similarity matrix (900) are final
similarity indices corresponding to the plurality of requirements; and
generating (310), by the requirements identification device (102), a
hierarchical cluster tree (1000) for the plurality of requirements based on
the final similarity index corresponding to each of the plurality of
requirements.
2. The method (300) of claim 1, further comprising:
Docket No.: IIP-HCL-P0062
27
identifying (312) at least one cluster of requirements from the
plurality of requirements through the hierarchical cluster tree (1000),
wherein the at least one cluster of requirements comprises each of the at
least two of the plurality of requirements, and wherein the final similarity
index corresponding to the at least two of the plurality of requirements
within the at least one cluster is above a predefined threshold;
for each of the at least one cluster,
assigning (314) a rank to each of the at least two of the
plurality of requirements based on a set of performance parameters;
selecting (316) a top-ranked requirement from the at least
two of the plurality of requirements; and
generating (318) a common application using the top-ranked
requirement from each of the at least one cluster.
3. The method (300) of claim 2, further comprising:
for each of the at least one cluster,
comparing (320) the top-ranked requirement with remaining
of the at least two of the plurality of requirements; and
identifying (322) one or more unique elements from the
remaining of the at least two of the plurality of requirements,
wherein the one or more unique elements are absent in the topranked requirement; and
one of,
creating (324) a new requirement, corresponding to
each of the one or more unique elements, in the common
application; or
adding (326) the one or more unique elements to the
top-ranked requirement in the common application.
Docket No.: IIP-HCL-P0062
28
4. The method (300) of claim 1, further comprising identifying the plurality
of requirements from each of the plurality of applications through a code
analysis technique.
5. The method (300) of claim 1, further comprising transforming elements
of each of the at least two of the plurality of requirements into technology
agnostic elements prior to determining the similarity index through each of
the set of analysis techniques.
6. A system (100) for identifying common requirements from applications,
the system (200) comprising:
a processor (104); and
a memory (106) communicatively coupled to the processor (104),
wherein the memory (106) stores processor instructions, which when
executed by the processor (104), cause the processor (104) to:
receive (302) a plurality of requirements from a plurality of
applications, wherein each of the plurality of requirements
corresponds to a functionality in one of the plurality of applications;
for at least two of the plurality of requirements,
determine (304) a similarity index through each of a
set of analysis techniques, wherein the set of analysis
techniques comprises a process driven analysis technique, a
data driven analysis technique, and a consumer driven
analysis technique;
calculate (306) a final similarity index based on the
similarity index determined through each of a set of analysis
techniques, wherein the final similarity index is a weighted
average of the similarity index determined through each of a
set of analysis techniques;
Docket No.: IIP-HCL-P0062
29
generate (308) a similarity matrix (900) for the plurality of
requirements based on the final similarity index, wherein elements
of the similarity matrix (900) are final similarity indices
corresponding to the plurality of requirements; and
generate (310) a hierarchical cluster tree (1000) for the
plurality of requirements based on the final similarity index
corresponding to each of the plurality of requirements.
7. The system (100) of claim 6, wherein the processor instructions, on
execution, further cause the processor (104) to:
identify (312) at least one cluster of requirements from the plurality
of requirements through the hierarchical cluster tree (1000), wherein the at
least one cluster of requirements comprises each of the at least two of the
plurality of requirements, and wherein the final similarity index
corresponding to the at least two of the plurality of requirements within the
at least one cluster is above a predefined threshold;
for each of the at least one cluster,
assign (314) a rank to each of the at least two of the plurality
of requirements based on a set of performance parameters;
select (316) a top-ranked requirement from the at least two
of the plurality of requirements; and
generate (318) a common application using the top-ranked
requirement from each of the at least one cluster.
8. The system (100) of claim 7, wherein the processor instructions, on
execution, further cause the processor (104) to:
for each of the at least one cluster,
compare (320) the top-ranked requirement with remaining of
the at least two of the plurality of requirements; and
identify (322) one or more unique elements from the
remaining of the at least two of the plurality of requirements,
Docket No.: IIP-HCL-P0062
30
wherein the one or more unique elements are absent in the topranked requirement;
one of,
create (324) a new requirement, corresponding to
each of the one or more unique elements, in the common
application; or
add (326) the one or more unique elements to the topranked requirement in the common application.
9. The system (100) of claim 6, wherein the processor instructions, on
execution, further cause the processor (104) to identify the plurality of
requirements from each of the plurality of applications through a code
analysis technique.
10. The system (100) of claim 6, wherein the processor instructions, on
execution, further cause the processor (104) to transform elements of
each of the at least two of the plurality of requirements into technology
agnostic elements prior to determining the similarity index through each of
the set of analysis techniques.