Claims:1. A system for identifying project requirements in a computing environment, the system comprising:
a memory configured to store predetermined set of rules and pre-defined schema;
a processor coupled with the memory to receive the predetermined set of rules and further configured to generate system processing commands;
an input module coupled with the processor and configured to receive a plurality of functional requirements from a client/ customer for a project;
an identifier module coupled with the processor and configured to identify architecturally significant functional requirements from the plurality of functional requirements based on keywords and phrases learnt during a training phases;
a classifier module coupled with the processor and configured to classify the architecturally significant functional requirements into specific architecturally significant functional requirement classes having a plurality of architectural impact on the project;
a meta schema generator module coupled with the processor and the memory to receive the pre-defined schema and, configured to generate a schema related to architecturally significant functional requirements, based on the classification of the architecturally significant functional requirements and the pre-defined schema;
a question recommender module coupled with the processor, configured to provide probing questions selected from a bank of probing questions for the architecturally significant functional requirements based on the generated meta schema related to the architecturally significant functional requirements; and
a solution recommender module coupled with the processor, configured to recommend architectural solutions selected from a bank of solutions corresponding to the answers provided for specific probing question based on the generated meta schema.
2. The system as claimed in claim 1, wherein pre-defined schema comprises the bank of probing questions and the bank of architectural solutions corresponding to the probing questions, further corresponding to architecturally significant functional requirement classes.
3. A method for identifying project requirements in a computing environment, the method comprising:
storing predetermined set of rules and pre-defined schema;
receiving the predetermined set of rules and generating system processing commands;
receiving a plurality of functional requirements from a client/ customer for a project;
identifying architecturally significant functional requirements from the plurality of functional requirements based on keywords and phrases learnt during a training phases;
classifying the architecturally significant functional requirements into specific architecturally significant functional requirement classes having a plurality of architectural impact on the project;
generating a meta schema related to architecturally significant functional requirements based on the classification of the architecturally significant functional requirements and the pre-defined schema;
providing probing questions selected from a bank of probing questions for the architecturally significant functional requirements; and
recommending architectural solutions selected from a bank of solutions corresponding to the answers provided for specific probing question based on the generated meta schema.
4. The method as claimed in claim 1, wherein pre-defined schema comprises the bank of probing questions, bank of possible answers and depending on the answers, the bank of architectural solutions corresponding to the probing questions, further corresponding to the architecturally significant functional requirement classes. , Description:TECHNICAL FIELD
The present invention relates to a system and method for identifying project requirements in a computing environment.
BACKGROUND
Traditionally, the development, deployment and subsequent customization cost of even moderately complex software is significantly high. One of the primary contributors to the high cost of the software development is associated with the lack of adequate documentation of the customer requirements. Further, the requirement document typically include functional and non-functional requirements (NFRs), respectively describing what the system needs to do and how it is to be achieved.
Since, the skills needed for identifying functional requirements are different than those needed for identifying architectural solutions, the requirement engineering exercise is often carried out by different teams in a project. For example, functional requirements are collected and documented by business analysts and domain experts. But the architectural solutions related to requirements are identified/ suggested by technology experts. As a result, the knowledge bank for functional requirements and architectural solutions are maintained separately.
However, this may not be as simple as it looks, for example, some functional requirements statements may carry an architectural impact. The kind of impact they may have on architecture is typically not explicitly stated in the functional requirement statement and may be difficult to identify from a given set of functional requirements. Furthermore, the business analysts, who are collecting functional requirements, may not have the requisite technical knowledge to infer and articulate the architectural impact from the functional requirements that they capture from customers. Because of their background limitation, they are not technically equipped to ask the right question to the customer to unearth the architectural impact.
Failure to identify and analyze architecturally significant functional requirements early in the life cycle of a project may result in costly rework at later stages of software development. For example, “ability to receive notification whenever transaction is made” is a functional requirement which carries an architectural impact. This functional requirement explicitly doesn’t states about the mode through which a notification is to be made i.e. email notification or real time notification with an ability to subscribe to topic of interest. If notification is to be made using email, a simple event-driven architecture would suffice. However, for real time notification with an ability to subscribe to topic of interest a different architecture (e.g. – publish-subscribe) is required. Thus, identifying the architecturally significant functional requirements from the pool of functional requirements is difficult.
Therefore, there is a need for a system that identifies the architecturally significant functional requirements and recommends the probing questions and architectural solutions to unearth architectural impact.
OBJECT
Some of the objects of the present disclosure aimed to ameliorate one or more problems of the prior art or to at least provide a useful alternative are listed herein below.
An object of the present disclosure is to provide a system which automatically identifies architectural significant functional requirements from functional requirements.
Another object of the present disclosure is to provide a system for identifying project requirements which provides a bank of probing questions to produce a more complete requirement specification.
Yet another object of the present disclosure is to provide a system for identifying project requirements which automatically recommends a selection of possible architectural solutions to the architectural impact.
SUMMARY
This summary is provided to introduce concepts related to a computer implemented system and a method for identifying project requirement, which is further described below in the detailed description. This summary is not intended to identify essential features of the disclosure nor is it intended for use in determining or limiting the scope of the disclosure.
In an embodiment, method(s) and system(s) to identify project requirements is disclosed. The method includes identifying architectural significant functional requirements from functional requirements based on keywords and phrases learnt during training phases. The method further includes, classifying the architecturally significant functional requirements into specific classes based on the architectural impact they may have on the project. Furthermore, the method includes generating a meta schema based on the classification of the architecturally significant functional requirements and a predefined schema. Thereafter, the method further includes providing a probing questions from the bank of probing questions for the architecturally significant functional requirements based on the generated meta schema, and is further configured to recommend the architectural solutions selected from a bank of solutions corresponding to the answers provided for specific probing question.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
The computer implemented system and method for identifying project requirements of the present disclosure will now be described with the help of the accompanying drawings, in which:
Figure 1 illustrates a network implementing a system for identifying project requirements, according to an implementation of the present disclosure.
Figure 2 illustrates a method for identifying project requirements, according to an implementation of the present disclosure.
It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION
The present disclosure relates to a system and a method for identifying project requirements.
A computer implemented system and method for identifying project requirements will now be described with reference to the embodiment shown in the accompanying drawing. The embodiment does not limit the scope and ambit of the disclosure. The description relates purely to the examples and preferred embodiments of the disclosed system and its suggested applications.
The embodiments herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiments in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
The description hereinafter of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.
According to an implementation, the present disclosure envisages a computer implemented system and method for identifying project requirements. The system stores predetermined set of rules and a pre-defined schema. Further, the system generates system processing commands based on the predetermined set of rules. The system identifies architecturally significant functional requirements from the functional requirements given by a client/ customer for a project based on keywords and phrases learnt during training phase. Further, the system classifies the architecturally significant functional requirements into specific architecturally significant functional requirement classes, wherein these classes determine the plurality of architectural impact they may have on the project. Further, the system generates a meta schema related to the architecturally significant functional requirements, based on the classification of the architecturally significant functional requirements and the pre-defined schema. The pre-defined schema is defined during the training phase, wherein the pre-defined schema may contain a bank of probing questions and a bank of answers to the probing questions and depending on the answers one or more architectural solutions, corresponding to the architecturally significant functional requirement classes. Subsequently, the system selectively identifies probing questions from the probing question bank for the architecturally significant functional requirements based on the generated meta schema related to the architecturally significant functional requirements. Thereafter, the system recommends and displays architectural solutions corresponding to the answers provided for the specific probing questions based on the generated meta schema.
Fig. 1 illustrates a network implementation of a system 102 for identifying project requirements. The system 102 can be implemented as a variety of communication devices, such as a laptop computer, a notebook, a workstation, a mainframe computer, a server and the like. The system 102 described herein, can also be implemented in any network environment comprising a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.
In one implementation, the system 102 is connected to one or more devices 104-1, 104-2…104-N, individually and commonly hereinafter referred to as device(s) 104, and a database 108, through a network 106. The devices 104 may be implemented as, but are not limited to, hand-held devices, laptops or other portable computers, tablet computers, mobile phones, personal digital assistants (PDAs), Smartphone, and the like. The devices 104 may be located within the vicinity of the system 102 or may be located at different geographic locations. Further, the devices 104 may themselves be located either within the vicinity of each other, or may be located at different geographic locations.
The network 106 may be a wireless or a wired network, or a combination thereof. The network 106 can be a collection of individual networks, interconnected with each other and functioning as a single large network (e.g., the internet or an intranet). The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate with each other.
In one implementation, the system 102 includes memory 130. The memory 130 may be coupled to the processor 110. The memory 130 can include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
Further, the memory 130 is configured to store predetermined set of rules and a pre-defined schema. The pre-defined schema is defined during the training phases, wherein the pre-defined schema may contains a bank of probing questions and a bank of architectural solutions to the probing questions, corresponding to the architecturally significant functional requirement classes. In an embodiment, the architecturally significant functional requirement classes are identified wherein each class specifies the kind of architectural impact they may have on the project. In an exemplary embodiment, wherein the class related to architecturally significant functional requirement is identified as “communication”, the system further provides probing questions to identify the architectural impact such as “What mode of alert is needed? Is it real time or email or SMS? ”. If the client/customer gives the answer as “ real time” then the system recommends “publish-subscribe” architectural solution.
In one implementation, the system 102 will also include processor(s) 110. The processor 110 is coupled with the memory 130 to receive the pre-determined set of rules and further configured to generate system processing commands. The processor 110 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is configured to fetch and execute computer-readable instructions stored in a memory.
The functions of the various elements shown in the figure, including any functional blocks labeled as “processor(s)”, may be provided through the use of dedicated hardware as well as hardware capable of executing embedded or coded software in association. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage. Other hardware, conventional and/or custom, may also be included.
Also, the system 102 includes interface(s) 120. The interfaces 120 may include a variety of software and hardware interfaces that allow the system 102 to interact with the entities of the network 106, or with each other. The interfaces 120 may facilitate multiple communications within a wide variety of networks and protocol types, including wire networks, for example, LAN, cable, etc., and wireless networks, for example, WLAN, cellular, satellite-based network, etc.
The system 102 further includes a data repository 160. Further, the data repository 160 may include global data 162, classification data 164, test data 166 and other data 168. The other data 168, amongst other things, may serve as a repository for storing data that is processed, received, or generated as a result of the execution of one or more modules in the modules 140. In an implementation, the global data 162 refers to all the data related to plurality of processes executed by the system 102. In an implementation, the classification data 164 refers to all the data required for the classification of the architecturally significant functional requirements. In an implementation, the test data 166 refers to all the data related to the testing phase, which may contain permutation and combination of data to test different modules by the system.
Further, the system 102 includes module(s) 140. In an implementation, the module(s) 140 includes an input module 142, an identifier module 144, a classifier module 146, a meta schema generator module 148, a question recommender module 150, a solution recommender module 152 and other module(s) 154. The other module(s) 154 may include an updation module to update the schema and programs or coded instructions that supplement applications or functions performed by the system 102.
According to the one implementation, the input module 142 is coupled with the processor 110 to receive system processing commands and is configured to receive a plurality of functional requirements from a client/ customer for a project. In an embodiment, the functional requirements given by the client/ customer contain the functional requirements which have implicit architectural impact and the functional requirements which don’t have architectural impact.
According to the present implementation, the identifier module 144 is coupled with the processor 110 and is configured to identify architecturally significant functional requirements from the plurality of functional requirements based on the keywords and phrases learnt during the training phases.
In one embodiment, the training phase includes pre-processing of test functional requirements for identifying the architecturally significant functional requirements. The pre-processing involves removing stop words that do not provide any relevant information on the statement’s lexical content (for example conjunctions and prepositions). The statements are then reduced into a set of keywords. The keywords are reduced to their stemmed forms using algorithms like Lovin’s stemming algorithm to reduce all words with the same roots to a common form. These stemmed words extracted from the test requirement statements are used for training the first identifier module 144.
According to the present implementation, the classifier module 146 is coupled with the processor 110 to receive system processing commands and is configured to classify the architecturally significant functional requirements into specific architecturally significant functional requirement classes based on the kind of architectural impact they may have on the project. In an exemplary embodiment, the classifier module 146 classifies the architecturally significant functional requirement such as “Delivering specific communications in other languages” in “Localization” architecturally significant functional requirement class. Similarly, another architecturally significant functional requirement “The system must record every modification to customer records for audit purposes.” will be classified in “Audit Trail” architecturally significant functional requirement class by the classifier module 146.
In an embodiment, the classes are identified by the system wherein each class specifies the kind of architectural impact they may have on the project. In an exemplary embodiment, there are different classes like: audit trail, batch processing, localization, communication, payment, print, report, search, third party interaction, workflow, online help and licensing, and so on.
In another embodiment, the classification of architecturally significant functional requirements is based on a set of keywords and phrases learnt during the training phase. The architecturally significant functional requirements are preprocessed to remove stop words which do not provide any relevant information on the lexical content of the statement. The architecturally significant functional requirements are further reduced to a set of keywords. The keywords are further reduced to their stemmed form using the algorithms such as Lovin’s stemming algorithm, to reduce all the words with the same roots to a common form, usually stripping each word of its derivational and inflectional suffixes. Further, these common form words are used to train the classifiers like Multinomial Naive Bayes Classifier, which is used for classification of architecturally significant functional requirements. Further, a confusion matrix is deployed to determine the accuracy of classification, which is further used by the classifier module to achieve better precision.
In one another embodiment, where architectural significant functional requirements doesn’t fall in any of the architecturally significant functional requirement classes, the classifier module 146 may generate a new class to accommodate the architectural significant functional requirements.
According to the present implementation, the meta schema generator module 148 is coupled with the processor 110 to receive the system processing commands and configured to generate a meta schema related to the architecturally significant functional requirements based on the classification of the architecturally significant functional requirements and the pre-defined schema.
According to the present implementation, the question recommender module 150 is coupled with the processor to receive system processing commands and is configured to provide probing questions selected from a bank for the architecturally significant functional requirements based on the generated meta schema related to the architecturally significant functional requirements. In an exemplary embodiment these probing questions are provided to an analyst so that, the analyst can ask these questions to the client for producing more complete requirement specifications and unearth the architectural impact of the architecturally significant functional requirements.
In another embodiment, the bank of probing questions are pre-stored in the system in various domains like banking, financial services and insurance, healthcare, retail, government, telecommunications, airline management and other domains.
According to the present implementation, the solution recommender module 152 is coupled with the processor 110 to receive system processing commands and is configured to recommend architectural solutions based on the answers received for the specific probing questions. The solution recommender module 152 recommends the architectural solutions based on the generated meta schema.
In an embodiment, the architectural solutions are created by the system architecture experts practicing in various domains.
Figure 2 illustrates a method 200 for identifying project requirements according to an embodiment of the present disclosure. The method 200 may be described in the general context of computer executable instructions. Generally, computer executable instructions include routines, programs, objects, components, data structures, procedures, and modules, functions, which perform particular functions or implement particular abstract data types. The method 200 can also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, computer executable instructions are located in both local and remote computer storage media, including memory storage devices.
The order in which the method 200 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 200, or an alternative method. Additionally, individual blocks may be deleted from the method 200 without departing from the spirit and scope of the method described herein. Furthermore, the method 200 can be implemented in any suitable hardware, software, firmware, or combination thereof.
Referring to method 200, at block 202, predetermined set of rules and pre-defined schema is stored. In an implementation, the predetermined set of rules and pre-defined schema is stored in the memory 130.
At block 204, predetermined set of rules are received and system processing commands are generated. In an implementation, the processor 110 is configured to receive the predetermined set of rules and generate system processing commands.
At block 206, a plurality of functional requirements from a client/customer for a project is received. In an implementation, the input module 142 receives the requirements from the client/ customer for a project.
At block 208, architecturally significant functional requirements are identified from the received functional requirements, based on keywords and phrases learnt during training phases. In an implementation the identifier module 144 identifies the architecturally significant functional requirements based on the keywords and phrases.
At block 210, the identified architecturally significant functional requirements are classified into specific architecturally significant functional requirements classes stating the different kind of architectural impact they may have on the project. In an implementation, the classification of the architecturally significant functional requirements is done by the classifier module 146.
At block 212, a meta schema related to architecturally significant functional requirements is generated based on the classification of the architecturally significant functional requirements and the pre-defined schema. In an implementation, the meta schema generator module 148 generates the meta schema based on the classification of the architecturally significant functional requirements and the pre-defined schema.
At block 214, specific probing questions are provided from the bank of probing questions for the architecturally significant functional requirements. In an implementation, a question recommender module 150 provides the probing questions selected from said bank.
At block 216, specific architectural solutions are recommended based on the answers to the probing questions, based on the generated meta schema. In an implementation, the architectural solutions to the specific probing questions are recommended by the solution recommender module 152.
TECHNICAL ADVANCEMENTS AND ECONOMIC SIGNIFICANCE
The technical advancements of the system envisaged by the present disclosure include the realization of:
a system and method for identifying project requirements which identifies the architectural significant functional requirements;
a system and method for identifying project requirements which recommends questions to produce a more complete requirement specification; and
a system and method for identifying project requirements which recommends possible architectural solutions to the architectural impact;
The systems and methods are not limited to the specific embodiments described herein. In addition, components of each system and each method can be practiced independently and separately from other components and methods described herein. Each component and method can be used in combination with other components and other methods.
Throughout the description and claims of this complete specification, the word “comprise” and variations of the word, such as “comprising” and “comprises,” means “including but not limited to,” and is not intended to exclude, for example, other additives, components, integers or steps. “Exemplary” means “an example of” and is not intended to convey an indication of a preferred or ideal embodiment. “Such as” is not used in a restrictive sense, but for explanatory purposes.
For a firmware and/or software implementation, the methodologies can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. Any machine readable medium tangibly embodying instructions can be used in implementing the methodologies described herein. For example, software codes and programs can be stored in a memory and executed by a processing unit.
In another firmware and/or software implementation, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium. Examples include computer-readable media encoded with a data structure and computer-readable media encoded with a computer program. The computer-readable media may take the form of an article of manufacturer. The computer-readable media includes physical computer storage media. A storage medium may be any available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer; disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blue-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.