Many applications that are developed do not completely full the requirements of their stakeholders. This can be a result of inadequate requirements elicitation and poorly de ned requirements. Many solutions, including model-driven inspired ones, have been proposed to improve the elicitation of the requirements, though many of them are not yet widely used in practice as they require training of both the employees and the stakeholders. In this paper we propose the use of exible modelling for eliciting and capturing the requirements of applications to facilitate the production of correct products that deliver on the contract de ned between clients and developers. We argue that the use of exible modelling can lower the entry barrier for use in the industry. The proposed method, called FlexRE, is applied to a scenario to demonstrate its capabilities and ways it can be extended.
Tendered contracts [
Many techniques have been developed to tackle this problem, including those that are model-driven inspired. The Agile methodologies, were proposed to increase the active participation of the client in the software development process, thus in the requirements elicitation phase. The above research surveys suggest that the problem still exists.
The proposed solutions so far urge the composition of either a very structured artefact which should conform to a rigorously-de ned metamodel or a totally unstructured composition of requirements using text. The former are di cult to be used by non-technical stakeholders, as they force them to follow the semantics that are bound to a xed metamodel. Thus there is low clients' contribution to the requirements speci cation document and high entry barrier of the methodologies in real world. In contrast, the latter o er no or limited structure, thus one cannot bene t from the use of model management techniques.
This paper presents a novel approach in expressing tendered contracts that
promotes the active involvement of the clients in the composition of the
document having as primary goal to lower the entry barrier and reduce the cost of
using Model-Driven Engineering (MDE) in the requirements elicitation phase.
This approach, o ers a varying range of structure, positioning itself between the
unstructured and rigidly structured requirements methodologies. It is based on
the GraphML [
Clients are usually domain experts; they generally can understand the
terminology and the processes that take place in the domain. By contrast, business
analysts, modellers and developers are technology experts and know how systems
are built. The lack of knowledge of the domain by technology experts and the
lack of knowledge of the technology by domain experts is termed as the
symmetry of ignorance. [
In WebML [
A second problem of approaches that are based on rigorous and pre-de ned metamodels is the fact that they restrict users of expressing requirements that the author of the metamodel did not think about. Thus, the scope of the projects that they can model is reduced (e.g. support for data-driven web applications only) or clients are restricted to use speci c concepts that do not represent their envisioned applications. This boils down to the following anecdotal quote: \I've been in situations where I found that the modeling tool was simply too structured to let me describe everything I needed to describe."3
model-driven-development-yet
A survey conducted among 12 Business Analysts working with IBM [
In this paper we argue for an approach that can increase the domain experts' contribution to the speci cation of the requirements. This approach is based on the use of a simple drawing tool and thus it requires less training given that one can build on familiar idioms and mechanisms reducing the cost of adaptation in the real world. It o ers a varying range of structure, positioning itself between the unstructured and rigidly structured requirement methodologies promoting the use of Agile principles and processes. 3
The rst family of approaches includes those which use natural language as the
means of expressing requirements. One approach is the use of spreadsheets or
text documents for expressing the requirements. Controlled Natural Language
(CNL) techniques aim to tackle the ambiguity of such statements written in
natural language. In the same direction, Kaindl et al. [
Two other approaches are the Business Process Modelling Language (BPMN)4
and the Uni ed Modelling Language (UML)5. They allow business analysts to
describe work ows of an application. The Web Requirements Engineering
(WebRE) [
The Program Design Language (PDL) [
The closest to our approach is the one proposed in [
Our approach is based on the technical concepts of an approach called
Muddles, proposed in [
The Muddles approach [
Each GraphML Edge is also extended by the Type, Properties and Default elds. In addition, elds to hold the descriptors of the \Source", \Target", the \Role in source", the \Role in target" and their multiplicities are de ned. For example, an edge that represents linking between two nodes, has an outgoing relation named \linksTo" and an incoming relation called \linkedBy" with a multiplicity of 1. The \sourcePage" and \targetPage" de ne the keywords for the source and the taget page of the link, respectively. These keywords can be used by a model management suite to have access to the source or target element.
After the diagrams are annotated they are automatically transformed to an intermediate model which is instance of the Muddle metamodel. A discussion on the steps of the transformation are beyond the scope of this paper. The Epsilon
Image TDyaptae Link Properties String URL = \.." Properties String src=\..." Source source Role in sourcePage linksTo1 CDoefnatuelntts cnhaimlderen Target target Role in targetPage linkedBy1 (a) The Node Properties
(b) The Edge Properties
platform [
In this case study, the client is interested in having a web application that will be used to present their Hotel company. It includes static and dynamic pages to present the rooms, the restaurant and help customers check for the rooms availability. A comprehensive set of the requirements are summarised in Table 1.
The Manager, who is the client in this scenario, starts drawing using the yEd editor, concepts that they are familiar with like check-in dates, check-out dates, etc. (step 1). He does not need to follow any speci c rules and can use any shape or image from the palette of the drawing tool that represents their understanding of the required functionality. Business analysts can in parallel annotate the drawings with types that can be useful for the requirement methodologies they follow, using the elds presented in Fig. 1 (step 2). As an example, assume 6 http://www.yworks.com/en/products_yed_about.html \A page to present the rooms of the Hotel" \A home page that will have a short introduction of the hotel, the rooms and the sta ." FR3 Manager, Customer Services \A contact us page." FR4 Manager, Reservations Team \A page that will present all the available rooms for a speci c range of dates." FR5 Reservations Team
\A page for presenting the restaurant." that, for the \FR5" requirement, the client ends up with the drawing shown in Fig. 3(a). The business analyst starts annotating these concepts. In the interest of a more clear presentation, the business analyst annotations for each element are shown in square brackets. In reality, the types are given using the Properties window of each element (Fig. 1). In this example, all the distinct HTML elements that the client uses are annotated as subclasses of the \HTML Element" class that this company uses as to identify them in the development process. This is done by using the \>" symbol which is used to denote the extension relationship. For instance, the Type property of the drawing that the client referred to as an image is set to \Image > HTML Element". These names given to the types are conventions, used to let the elements be accessed by a model management suite. It could be anything that ts the model-driven processes used in each company. (a) The FR5 requirement drawing
(b) The FR4 requirement drawing
Non-functional requirements, business behaviour and work ows that can't be described using drawings can be typed in natural language. The business analysts can then either translate this into a drawing based on their experience or can simply attach bits of these requirements written in natural language to parts of the drawing that it is related to. For example, assume that the client needs to express the following requirement: \When the button is clicked, all the available rooms between the check-in and check-out dates should be shown in the results list.". This is part of the FR4 requirement shown in Fig. 3(b). The work ow that cannot be drawn is expressed using plain text inside the hexagons (see Fig. 3(b)) and can then be linked with the button that the client talks about, the check-in/out input elds and the results list that the client refers to.
The client continues drawing his understanding of the desired web application. As soon as the client has nished developers can then prepare model management programs or re-use those they have written in the past (step 3). These programs can be executed against the annotated drawings (step 4) using the technical facilities of the Muddles approach, to produce di erent artefacts that are interested in like pieces of code, test cases, textual contracts, and many others (step 5). Such examples are presented in the Section 5.
The same process could, in principle, be supported with a more traditional editor based on a xed metamodel (e.g., derived using EMF/GMF). An advantage of using a exible model is that it doesn't restrict clients in expressing concepts that the developers hadn't considered about when creating the metamodel. In other words, it allows clients to directly formulate the language of discourse without being restricted by a prede ned set of constructs produced by non-experts. In addition, the drawing editor is a tool that even non-technical stakeholder arguably are able to use with no extensive training.
A rst disadvantage of using exible modelling is that it is error-prone. For instance, typos in the de nition of the type of an element will create a new type. Secondly, there is a possibility of leaving untyped nodes which will left out from the model management processes. The above risks can be tackled by using validation rules. For instance, one could write a re-usable post-processor that calculates distance/similarity metrics for the Types. If the value for two Types is above a speci c threshold it alerts the modellers for possible errors. Work in this direction is being carried out. 5
As discussed in the previous section, the annotated drawing can be consumed by
programs expressed in model management languages of the Epsilon platform [
It would be of interest to check if important rules/constraints of the domain are being met. For example, in the web domain, all the \Link" edges must have exactly one source and one target element. Conformance to such rules can be achieved by applying model validation to the drawing. In our scenario we use the Epsilon Validation Language (EVL), to validate that the above constraint (see Listing 1.1). The \source" and \target" keywords used in the code are the names the modellers provided in the Source and Target elements of the \Link" properties (see Fig. 1). Similarly, the keyword \linksTo" is the identi er of the \Role in source" property (see Fig. 1). The EVL statements, can be run against the drawings, are written once and can be re-used for all the projects. context constrLaiinnkt fSourceAndTargetExist f gmchueeascrsdkagsei::z e(:s es>el="fl Lf.1i.isn)lTiknykpesedTOgoefs(. Lsosinuhkrocu)elPd aghea v.ea l le x.saicztel y==one1) saonudrce( sneol dfe. liannkdsTaot . tleaargsettPoangee . a l l .
t a r g e t node" g g
Listing 1.1. Example of EVL rule for validating the Link edges. 5.2
The Next Release Problem (NRP) is a multi-objective optimisation problem.
The best set of requirements that should be implemented into the next
software release, staying within the budget, is calculated. Burton et al. [
In this section we demonstrate the automatic transformation of the stored
requirements into code that can be consumed by the CATMOS capability
acquisition suite in [
Based on the scenario presented above, the developers just need to add and annotate two new types on the drawing. The rst one is of type \Cost" (see Fig. 3) and de nes the estimated cost to implement each component. The second is a \Dependency" edge and shows the dependency between two or more requirements. The drawing is now ready to be consumed by a model-to-text transformation expressed in the Epsilon Generation Language (EGL) and automatically generate the code needed to run the CATMOS tool. The EGL script is written once and can be then re-used.
2400 1 22020000 5 1800 1600 irceP111 240860000000000 3 0 4 2 400 200 0 0 0.1 0.2 0.3 0.4 Sa)s0fa.5c )on 0.6 0.7 0.8 0.9 1 (a) The optimal solutions (b) The solution #2
Fig. 4. The results of the CATMOS suite
The results of running the CATMOS are shown in Fig. 4. Fig. 4(a) shows all the possible optimal solutions for di erent budgets. The horizontal axis presents the total satisfaction that each solution o ers, while the vertical represents, the cost of implementing each solution. Based on the budget, clients can pick the most appropriate solution knowing that this set of requirements is the optimal for the amount of money they want to spent. An example is given in Fig. 4(b). In this solution, the client can have the FR2 (Home Page), FR3 (Contact Us) and FR5 (Restaurant Presentation) requirements developed, which is the optimal set of requirements for a budget of 1100 units of money. Code and test cases can be generated from the drawings. In this scenario, we use EGL to generate code for the structural and navigational parts of the described application. Code that implements the behavioural requirements (work ows) is not generated, yet. Plans for this process are presented in Section 6. In addition to that, we generate Selenium-Webdriver7 test cases directly from the speci cation for the structural and navigational aspect of the application. The test cases can be used as primary artefacts for a Test-Driven Development approach where the developers create the structure and navigation from scratch. 6
We presented a method that can be used to elicit and store requirements of applications. The method allows non-technical stakeholders to `draw' the requirements with no previous training o ering a low entry barrier for industrial use. It o ers a exible structure level to the requirements document (from completely un-structured to highly structured) without restricting the types of requirements that can be expressed. Finally, it can be used as a starting point for a number of MDE methodologies like code and test cases generation suites. It is highlighted though, that this approach could be bene cial in domains where the graphical representation of requirements adds value. In contrast, in domains where textual representations are more appropriate, the drawing overhead of the approach should be taken into account.
In the future, we aim to connect using M2M transformations, the requirements drawn using FlexRE with other MDE suites like WebRatio, which can perform full code generation.
This work was carried out in cooperation with Digital Lightspeed Solutions Ltd, and was supported by the EPSRC through the LSCITS initiative and part supported by the EU, through the MONDO FP7 STREP project (#611125). 7 http://docs.seleniumhq.org/projects/webdriver/