Palomares et al. (2014) state that it is difficult to use patterns without computational support to guide the software engineer. In particular, they also report participants' opinions on reuse based on software requirements patterns. One of the evaluated features involved the critical factors for the introduction of a requirements patterns catalog. Two main points were cited: the need for a well-defined method of use and a support tool.
In this project, after creating the patterns of functional requirements and the business rules, considering the observations of Palomares et al. (2014), the process of the approach and the computational support were also developed to guide the software engineers in the activity of requirements elicitation using the elaborated patterns. It is once again emphasized that non-functional requirements are not part of the scope of this paper.
In Section 5.1, the construction of computational support is discussed. In Section 5.2, the process of using the computational support with the requirements patterns for the elaboration of an RD is presented. In Section 5.3, the functions of the computational support are described. An example of application of computational support is presented in Section 5.4.
Computational Support Construction
The construction of the computational support used the iterative and incremental process model, allowing the improvement of the usability, of the functionalities as well as the inclusion of new ideas.
The Java language was chosen together with the Java SE (Standard Edition) platform (Java) with the MySQL Server Community database (MySQL), the JDBC (Java Database Connectivity) driver for MySQL library (MySQL et al. 2017) to allow connection to the database and the iText library (iText) for creating an RD in PDF format.
The computational support for the elaboration of an RD in the IS domain has three modules: i) the specification and management of the patterns, usually under the responsibility of a software engineer with more experience; ii) the instantiation of the patterns during the elicitation of requirements; and iii) the basic functions inherent to the maintenance of user (software engineer), client and project.
In Fig. 1 the conceptual model of computational support is presented using an UML class model. The elements of this model are presented in detail in the following topics:
-
A pattern (Pattern) may have related patterns (Related Pattern), which contribute to the complete elaboration of the RD. Each pattern may or may not have parameters (Parameter) corresponding to the variable part of the solution proposed by the pattern. If it exists, it must be associated with a type (Type of Parameter) which in turn provides suggestions of filling values for the parameters (Parameter Value Suggestion) to assist the software engineer while writing the variable part of the requirement. Example: The "Process Transaction" pattern has the "Execution Condition" pattern as related. When instantiating the "Process Transaction" pattern, the instantiation of the "Execution Condition" pattern is suggested in order to complement the elaborated requirement specification. Each pattern provides, as a solution, a template that can have parameters. In the case of "Process Transaction", the parameters are: <<transaction>>, <<entity> > and < <attributes>>. These parameters must be filled with values according to the needs of stakeholders. When elaborating the solution of this pattern, these parameters were associated to a type of parameter contained in the repository of the computational support so as to provide filling suggestions. The parameter "transaction", for example, is associated with a type called (transactionEntity) that provides suggestions for values to be filled in such as purchase, sale, rental, etc.
-
For the writing of requirements (Requirement), a project must be created (Project), which requires the selection of the client (Client), the user (User), and the subdomain (Subdomain). The client corresponds to the one who hired the project. The user is responsible for the specification of the RD. The subdomain guides the user towards the reuse of specified requirements in future projects. Example: The "Sales Order System" project of client "X", has "Y" as the responsible user (software engineer). This project belongs to the subdomain of "Sale of Products and Services". A project can be specified by more than one user, however, it must have a responsible user.
-
By means of the pattern (Pattern) a template, which has a text with fixed and variable parts, is provided for the specification of the requirement (Requirement). The variable part is called the parameter of the requirement (Requirement Parameter), which is used to receive the values that the user has supplied (Requirement Parameter Value). Example: The "Execution Condition" pattern provides the template " The < operation > should only be allowed if < condition > " to guide the software engineer in writing the requirement. After filling in the parameters of the pattern, the requirement is generated.
Process of Using the Computational Support for the Patterns Instantiation
To use the computational support for the instantiation of the patterns in order to elaborate IS requirements documents, the following steps must be followed:
-
1.
Selection of the Pattern: according to the client needs, the software engineer selects the appropriate pattern for this type of problem from the tree structure organized by the type of pattern that is currently represented by functional requirements and business rules Fig. 2. The information about the selected pattern is displayed in the "Basic Information" tab. If the pattern meets the requested requirement, the software engineer proceeds to the next step.
-
2.
Specification of the variable parts: the software engineer informs the client of the variabilities available for the use of this pattern to obtain the desired solution. The client can choose the options that will satisfy the needs of his system from the set of suggestions registered for the pattern. However, the client may inform what is desired and this can be incorporated as variabilities later on.
-
3.
Additional specifications: the software engineer identifies with the client the existence of some business rule and/or some complementary functional requirement in relation to the elaborated requirement. In both cases, a pattern can be used to complement the specification. Thus, we turn to steps 1 and 2 for the specification of the complementary requirements. The software engineer may also propose some complementary requirements through the suggestions of related patterns provided by the computational support.
If none of the patterns available in the computational support meet the client’s need, there is also the possibility of writing a requirement without the use of a pattern. To do this, it is necessary to use the [New] button of the "Elaboration" tab that will leave the Template field (item b. Fig. 2) blank to write the requirement.
In Fig. 3, the process of using the computational support for the patterns instantiation is presented.
Implemented Functions
With the module of specification and management of patterns (Fig. 4), it is possible to do maintenance on the patterns. For the specification of a pattern, it is necessary to fill in the elements: name, domain, purpose, problem, consequence, type and solution. In the definition of the solution, for each parameter of the template there is: a) a type, which is associated to a set of fill-in suggestions that can be used in the pattern instantiation. This set of fill-in suggestions was obtained from the requirements documents used for the elaboration of the patterns; b) a description that guides the correct completion of the parameter; c) the multiplicity that guides the amount of allowed values for the parameter.
To specify a pattern, the "Basic Information" and "Related Patterns" tabs are used. The patterns related to the pattern in question are described by means of the tab with the respective name.
The pattern instantiation module (Fig. 2) has four tabs. These are presented in detail in the following topics:
-
Basic information: presents the applicability and solution information of the pattern.
-
Elaboration: used for the specification of a requirement by means of the chosen pattern. The letters placed in Fig. 2 are intended to guide the reader, so they are the same as those used below. In this tab there is: a) a field to describe the requirement; b) the solution template; c) a list with parameters; d) a list of suggestions organized into categories of suggestions (per parameter); e) when you select the category of suggestions, a list of values is displayed. In the example in Fig. 2, the "Include Information" pattern is being instantiated for writing a requirement that describes the need of store product information.
-
Requirements: presents all project requirements; allows selection of the requirement for editing or deleting; allows the generation of an RD in PDF format; allows the establishment of relationship between the requirements; and provides suggestions of patterns related to the instantiated requirement.
-
Reuse: presents the requirements already instantiated in other projects, which were elaborated by the selected pattern. These requirements can be reused in the current project instead of being specified by using a pattern. The requirements generated in concluded projects are stored in a local repository that allows the reuse of requirements in future projects, with the possibility of changing those requirements if necessary.
Exemplifying the Writing of an RD by means of Instantiating Patterns
To exemplify the use of computational support, the specification of a Sales Order system will be used. The System Overview is displayed in Additional file 5.
The elaboration of the RD through the computational support begins with the registration of the project. For this you need to provide: a name for the project, its overview (it will be part of the RD), the selection of the responsible client and software engineer (previously registered), the project start date, the status (initially it must be "open" to indicate that the project is in progress) and the subdomain selection, to guide the software engineer in future reuse of requirements. In Fig. 5, the project registration interface populated with the Sales Order System data is shown.
After registering the project, through the pattern instantiation module, it is necessary to select the pattern according to the needs declared by the stakeholders. The information of the selected pattern is displayed in the "Basic Information" tab as can be seen in Fig. 6.
According to the system overview, it is indispensable to store clients in the database. Therefore, the “Include Information” pattern must be instantiated using the [Instantiate] button.
In Fig. 7, the "Elaboration" tab used to write a requirement for client inclusion is shown. To do so, one must: a) define a description for the requirement, to facilitate its location; b) fill in the parameters with the information provided by the stakeholders; c) select the parameter and choose one of two options: manually write the corresponding data which is done by clicking the [New] button (c1), or select the data from the suggestions provided by the computational support repository (c2). In this example, the < attributes > parameter is populated with values that match the attributes of the client. Selecting this parameter provides some categories of suggestions, such as sales, product, person, etc. When one of these suggestions is selected, others are presented for filling the parameter. After these selections, the [+] button must be pressed so that the selected values are assigned to the parameter; d) with the selection of the [View] button the substitution of the parameter in the template occurs with the data assigned to the parameter. This step is not required and replacement will occur when the [Save] button is pressed to wrap up the writing of the requirement; e) finally, press the [Save] button to finish writing the requirement.
In the example, it is assumed that a sales order must be processed, i.e., the registration of the sales order with all relevant information must be carried out. To meet this functionality the "Process Transaction" pattern should be used. Its instantiation occurs in the same way as the "Include Information" pattern, described above.
After saving the requirement, the computational support may suggest related patterns to complement the specification of the requirement. This is done using the [Related] button which displays a number that corresponds to the number of patterns related to the one instantiated. In Fig. 8, there are five patterns related to the pattern "Process Transaction". In this case, the suggested patterns are business rules commonly required when specifying a transaction, which establish for example: a) conditions or restrictions for the execution of an operation; b) the description of a mathematical calculation required by an operation and the condition for performing the calculation; c) a description of the information required in a given operation; and d) the limits on the execution of an operation. These patterns can guide the software engineer to complete the requirement specification. The instantiation of these patterns also occurs in the "Elaboration" tab.
To meet, for example, the business rule that allows you to place orders on time only for clients that have available credit limits, the pattern “Process Transaction” has the related pattern “Execution Condition” that must be used for this purpose. Finally, to meet the requirement to issue a report, the “Management Query” pattern must be instantiated.
In the Pattern Instantiation module, the "Requirements" tab (Fig. 9) presents the following items: a) all project requirements. When selecting a requirement by means of a click, requirements related to it are also presented, if they exist. In the example, the “Process Transaction of Sales Order” requirement has a dependency relationship with the “Execution Condition of the Order” requirement; b) allow the editing, visualization or exclusion of the selected requirement, as well as provide suggestions of patterns related to the selected requirement, as previously presented; c) allow the establishment of relationship between the requirements. The relationship between the requirements elaborated by the related patterns occurs automatically, but if the establishment of relationships between other requirements is necessary, this can be done manually. To exemplify the manual relationship between requirements, a dependency relationship was established for the requirement "Process Transaction of Sales Order" with the requirement "Include Information of Client", this relationship can be observed in the RD shown in Fig. 10; d) allow the generation of the document with all the instantiated requirements, in PDF format, as shown in Fig. 10.
The resulting RD after the use of computational support is shown in Fig. 10. Functional requirements are identified by the abbreviation "FR" and the business rules by the abbreviation "BR". The "Depends on" column shows the dependency between the requirements. In the example in question, the FR2 requirement depends on the FR1 requirement.
The "Reuse" tab presents the requirements of the repository that were instantiated in other projects, referring to the selected pattern. In the example that is shown in Fig. 11, as the “Include Information” pattern is selected, the suggestions for requirements that have been instantiated with this pattern in "reservation of goods and services" and "restaurant" projects are being presented. These requirements can be fully reused in the current project or have the possibility of changes. There are two possibilities for reuse: simply reuse the requirement by selecting the [Reuse] button or reuse with dependent requirements (related) by selecting the [Reuse with Dependents] button. Before reusing a requirement, the software engineer can view its specification by selecting the [View] button.
This work differs from the others presented in Section 2, since: a) it allows the writing of an RD with functional requirements and business rules for specific systems in the IS domain. For example, the pattern that specifies a new registration of an entity can be used for the elaboration of a hotel system, a pharmacy system or any other, and it will have the complete specification of that requirement in the RD; b) with the use of computational support the RD is elaborated in PDF format; c) the software engineer can reuse requirements specifications built on previous systems modifying some attributes or not. For example, a specification for the reservation in a hotel, can be retrieved from the repository and reused in another hotel system. There is the possibility of reusing this function in any other system, for example, a reservation system of books, cars, products, etc.; d) new requirements patterns can be elaborated using the presentation structure.