QualityAssuredModel-Driven RequirementsEngineering and Software Development

Transcription

1 The Computer Journal Advance Access published July 14, 2015 c The British Computer Society All rights reserved. For Permissions, please journals.permissions@oup.com doi: /comjnl/bxv051 QualityAssuredModel-Driven RequirementsEngineering and Software Development László Lengyel 1, Tamás Mészáros 1,MárkAsztalos 1, Péter Boros 2, Attila Máté 2, Gábor Madács 2, Péter Hudák 1, Kristóf Kovács 1, András Tresch 2 and Hassan Charaf 1 1 Budapest University of Technology and Economics, Budapest, Hungary 2 Quattrosoft Ltd, London, UK Corresponding author: lengyel@aut.bme.hu Software development requires adequate methods for requirements engineering, design, development, testing and maintenance. The more complex the system is, the more sophisticated methods should be applied. A significant part of software projects is short on appropriate requirements engineering, communication, development and testing method, furthermore, verification and validation processes; i.e., not the right method is applied, and the project turns into ad hoc design and development decisions. This paper introduces our quality assured model-driven requirements engineering and software development method. The method is based on the modeling of the software requirements in a way that these models can be used to automatically generate several artifacts during the engineering process. This method is continuously developed during the last 12 years driven by our software projects. In the last two years, we have developed new tool support and also reworked the method. In this paper, as an experience report, we introduce the method: a framework to specify software requirements with four domain-specific languages and automated solutions to process the models. We focus on the requirements engineering method of the whole development cycle. We also report the lessons learned and share our best practices on the field of model-driven requirements engineering and software development. Keywords: software modeling, requirements-engineering, requirements modeling, model-driven methods, communication platform Received 11 April 2014; revised 15 May 2015 Handling editor: Mariangiola Dezani-Ciancaglini 1. INTRODUCTION AND MOTIVATION Developing software artifacts in enterprise environments should be based on mature methods. Software products drive almost all parts of our life. However, software development methods and the methods supporting the whole process still can be made more adequate. Appropriate approaches are required to support unambiguous requirement definition, capturing and defining user processes, making possible effective development that results in quality products, and verifying/validating the requirements. Adequate requirement engineering and analysis [1, 2] can define the obvious project scope and result in the agreement between the customer and the developer team during the project and also in the end when deliverables should be adjudged and accepted. The unambiguous requirement specification, being formal enough, can drive the whole software project, including the development, testing, documentation generation and maintenance as well. Furthermore, it is still important to be able to accept the continuous changes and run an iterative agile process cost effectively [3]. There are several issues in the system development that motivates software architects and developers to work out and use different methods. Notable motivating issues are the problem

2 2 L. Lengyel et al. of informal requirements specifications and the consequences of the ad hoc project scope. These issues can result in misunderstandings and losing the control over the project. We have assembled a few points that further drive our activities and motivate us to develop and apply more advanced and adequate techniques in the development process: (i) Inadequate requirements analysis method: the relevant customer processes are not or under analyzed. As a consequence, they are not addressed properly by the provided solutions. (ii) Ambiguous scope definition: a textual description of the requirements can easily mean different things for the customer and the solution providers. Without languages that are formal enough and understandable both for the customer, i.e. domain experts, and the software experts, the scope of the project and the real requirements can easily become unclear. (iii) Only software functions are defined but domain processes are not analyzed: this issue assumes that the software drives the business and not the business requirements define the software functions Overview of our methods From the beginning, which goes back to the previous decade, our vision was to develop software systems with a methodology that targets and supports the followings: (i) Techniques supporting effective requirements engineering that ends with formal user stories which can be validated by the customer. This means that the customer understands the specification, because it uses the domain concepts and defines their business processes. (ii) Domain-specific languages that are applied to define use cases, user stories (the business processes that are required to be supported), domain dictionary and the high level requirements. The languages facilitate cross-references between the model elements, i.e. referring domain concepts and requirements from use case models and activity models (user stories). (iii) A method to build the semantic model based on the business processes defined by the user stories. (iv) A technique to generate as much of the source code as possible from the requirements specification. The generated code is based on supporting libraries that are continuously developed by senior developers. The generated code covers those parts of the implementation that are very similar in each projects, e.g. data management (database-related functionalities, concurrency management), communication between the client and the server. Of course, there is custom logic, which is difficult to express on the model level, therefore, the related code is not generated. (v) Each requirement is connected to the model elements that define the software development activity even if it is generated or implemented manually. This makes possible to follow the modifications and apply the required changes during the whole lifecycle of the system. (vi) A technique to automatically generate relevant test scenarios for the manually written modules based on the formal user stories was introduced above. The meaning of the relevant test scenario will be discussed later in the paper. (vii) A technique to automatically generate formal but user readable documentation, i.e., the documentation is also driven by the identified user stories, automatically generated and validated by the customer. The documentation includes the detailed specification that is easy to read and validate by the end users. Based on the documentation, the representatives of the customer can decide if the specification meets their business requirements. (viii) A method to ensure the continuously up-to-date state of the semantic model (requirements specification) all along the lifecycle of the given solution. This paper introduces a domain-specific modeling and model processing-based method for supporting effective software development. The method covers the whole development process, including requirements engineering, development, testing and documentation as well. In this paper, the focus is on the requirements engineering method and tools. Figure 1 introduces the main concept of the suggested requirements engineering and development method. The requirements engineering and analysis result in the Requirement specification, which is a collection of models that are both human readable and formal. This means that these models can be easily understood by domain specialists (customers) and also formal FIGURE 1. Overview of the requirements engineering and development method.

3 Quality Assured Model-Driven Requirements 3 enough to serve the software artifact generation. The specification includes use cases, activity and further models collecting the user requirements. These models define the high-level requirements, the domain vocabulary, the use cases and the detailed user stories. The stories are step-by-step scenarios defining the exact algorithm (workflow) of the business processes that should be covered with the solution. Based on the requirements specification we generate the software artifacts, the relevant test scenarios and documentation as well. The source code is manually extended by custom logic after generating the frame and the general components: data access layer, communication, first version of the user interface and the integration of the prepared library components, i.e. logging, security, others. The testing performed on the executables is based on the automatically generated test scenarios. The verification and validation, performed on the generated and manually extended software products, is also based on the requirements specification. These all mean that the well-defined requirements specification drives the whole process. This is one of the most important points of the entire method, i.e. the requirements specification is in the focus: the customer and the developer team agree on the scope of the project with the help of the requirements specification models. Next, this specification drives the whole process: we always go back to the specification and derive each of the required artifacts based on it. The method provides an iterative process: the continuously gained experience and the feedback improve the requirements specification and therefore influence the next iteration as well: newly generated and altered software artifacts, test scenarios and the refreshed documentation. We apply the method to develop three layered software systems: database, business logic and web-based or desktop user interface. During the last 12 years several projects required and supported to develop class libraries that make the artifact generation effective and robust as well. This means that the generated artifacts are the SQL scripts of database creation, data access layer to perform the database related create, read, update and delete methods, the frame of the application both on the server side and the client side. Furthermore, well-parameterized lists of function calls as the derived process workflows and business logic are also generated. These function calls are targeting class library methods that are developed by senior developers and are well tested. These libraries are the result of several year development and more than a dozen of different projects. The goal is to reuse them because of their stability. We apply different Java techniques to perform all these. The generated source code is extended manually and also utilizes different class libraries, therefore, the requirements models driven testing is careful. The whole method is applicable for different fields, for example, for embedded system development, but based on the previous notes, it requires to perform several projects on the field and manually build the supporting class libraries, furthermore, work out and maintain the appropriate model processors that generate the artifacts utilizing these libraries Impact of the applied methods In the following, we present our vision about how our modelbased development methods developed in the last decade are able to improve certain aspects of the software engineering process. Our overall goal with the method is to increase the quality of the produced artifacts, the effectiveness of the requirements engineering, the unambiguity of the project scope and development, and the customer satisfaction. The scope of the method is as follows: (i) To identify which characteristics of the system to be developed determine if the suggested method can be applied for it. By system characteristics we mean the size of the system under development, the architecture (e.g. web client, server, DB layer), the technology (e.g. Java) and the development method (e.g. waterfall, agile, other). We examined numerous software development technologies and methods to be able to provide as generic method as possible. (ii) To identify the target audience. The key is in the length of the lifecycle. The longer the software system is maintained, the more changes must be applied during the lifecycle. By having a well-understandable software model, the changes can be introduced at a significantly lower cost. We believe that this affect can produce shorter return of investment (ROI) period if the method and the tooling are harmonized. Our experiences show that our methodology aims bigger systems that require careful modeling, exact processes and workflows, furthermore detailed documentation and deep testing. Such target audience can be banking applications, civil service, public administration, insurance companies, medicine factories etc. (iii) A method supporting to define software specifications on the level of abstraction high enough for the domain experts and the further engineering process. The method and the tools should produce the documentation and the basement of the following development activities. Therefore, it provides a commonly used communication platform between the participants of a software development project. (iv) The method and the provided supporting tools should be effective enough to make it easier to follow the process than to sabotage it. In general, the overall goals of software projects are well-known, and every software expert understands their needs and agrees with them. But they still follow the ad hoc approach, usually saying that we do not have enough time to be systematic. We believe that an effective method and the appropriate tool support can break this habit.

4 4 L. Lengyel et al Structure of the paper We have strengthened the motivation of our work by discussing the challenges from the field of requirements engineering and software development. We have also provided a high-level overview of the methodology we have developed. The rest of this paper is organized as follows: (i) Background is summarized in Section 2. We discuss the techniques we applied to achieve our goals, i.e. introduce the domain-specific modeling and model processing with their benefits. (ii) Section 3 introduces our model-based requirements engineering method and provides our experiencebased thoughts. We present a modeling framework with four domain-specific languages. These languages make it possible to specify models of various software requirements. Besides the conceptual overview of the models, the implemented tool support is also discussed. (iii) Section 4 shows how the models can be used during the development process and how our methodology improves the engineering process. We overview the techniques that starting from the requirement models automatically generate source code, relevant test scenarios and documentation. The model processing is not in the focus of this paper, therefore, we only summarize it from a bird s eye view. We mainly concentrate on the requirements engineering part of the method. (iv) Section 5 summarizes the lessons we learned during we worked out the method: we discuss the strengths and the consequences of the method, furthermore, we provide a detailed list about the techniques and best practices we have applied successfully. (v) Finally, conclusions are elaborated in Section BACKGROUND This section provides motivating examples and highlights the need for effective methods in the field of software development. The two key points in application development are evergreen: make the development effective and provide high quality artifacts. Model-driven approaches address both of these issues Model-based development Nowadays, modeling is a key concept, which facilitates the system definition and supports better communication on the appropriate abstraction level. Furthermore, system models are the first-class artifacts in model-based development. Modeling and model-based development gather several fields, such as UML [4], domain-specific modeling, multi-paradigm modeling [5], generative programming [6] or model processing [7 9]. The growing size and complexity of software systems made software modeling technologies essential in application development. This is an observable trend to move from universal modeling languages towards domain-specific solutions. Domain-specific languages (DSLs) [10, 11] are strictly limited to a domain, but this limitation makes it also possible to be much more efficient than a universal language could be. Using domain-specific artifacts and enforcing the domain rules automatically makes DSLs useful not only for software developers, but also for domain experts. Based on precise, formal models, the automatic generation of complete application layers or even the entire application came to reality [11]. The most popular model processing methods are model traversing processors, template-based processors and high-level model-to-model transformations [8, 12]. Traversing processors provide a mechanism to visit the internal representation of the model [13]. Traversing processors are often used for code and document generation and they are usually supported by a script or template language. Template-based model processing is very effective if the goal is to generate textual output, for example, configuration file, XML file or source code. Model-to-model transformations often represent the processing of input models and the generation of output models in a high abstraction level, for example by using the modeling languages of the models themselves [14]. High-level modelto-model transformations are usually based on mathematical graph rewriting that can be applied if the model is represented as a graph that has a solid formal specification, which makes the verification and the validation of the transformation and the output much easier. Model-based software development (MBSD) is an increasingly applied method in producing software artifacts. MBSD is driven by model processing that is attempted to bridge the semantic gaps between high-level models and low-level languages [7]. The benefits of the model processing-based methods are the more flexible, efficient and configurable development solutions, the increased efficiency of the development and the high quality of the software products Requirements engineering Requirements engineering [1] is the process of formulating, documenting and maintaining software requirements. Requirements engineering has a significant role in successful software engineering processes. Requirements analysis in software engineering encompasses those tasks that go into determining the needs or conditions to meet for a new or altered software product or artifact, taking into account the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software and system requirements. The IEEE Standard Glossary of Software Engineering Technology [15] defines a software requirement in the

5 Quality Assured Model-Driven Requirements 5 following way: (i) A condition or capability needed by a user to solve a problem or achieve an objective. (ii) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document. (iii) A documented representation of a condition or capability as in 1 or 2. In the field of requirements engineering, there are several widely used concepts and approaches, which thoughts and values are worth to be considered and adapt some practice from them. These concepts and approaches are as follows: business requirements, requirements analysis, requirements management, requirement prioritization, requirements traceability and user stories. Business requirements are what must be delivered to provide value. Software, information systems, further software and non-software products and processes are the ways how to meet or satisfy the whats of the business requirements. The topic of business requirements usually arises in the context of developing software systems. Requirements analysis in the field of software engineering includes all those tasks that help to identify the end user needs and the conditions that should be addressed by the developed product. Requirements analysis should take into account the surrounding conditions and the requirements of the various stakeholders [1]. Requirements analysis is a critical phase in software development and has a significant effect on the success of the whole project. The requirements should be clearly documented, measurable, testable, traceable, transparently related to certain business needs, and defined to a level of detail sufficient for system design. Requirements management is a continuous process throughout a software development project. Requirements management addresses several activities: documentation, analysis, tracing, prioritizing and agreeing on requirements. Furthermore, requirements management controls change requests and handles the communication between the relevant stakeholders. In software product management, requirement prioritization is used for determining which requirements of a software product should be included in a certain software package (release). Several methods for assessing a prioritization of software requirements exist; usually these methods prefer the most important and high risk requirements. Requirements traceability documents the life of the user requirements and provides bi-directional traceability between various associated requirements. These methods enable users to find the origin of each requirement and track every change that was made to this requirement [16]. In software development, a user story is few sentences that captures what a user does or needs to do as part of his job function. User stories are usually written in the everyday or business language of the end user. User stories capture the basis for defining the functions a software system must provide, and to facilitate requirements management. User stories capture the who, what and why aspects of a requirement. Functional user stories are formed by business users. To express non-functional requirements (e.g. security, performance, quality, others) user stories are extended by developers as well. User stories are an effective way of handling customer requirements without creating formalized requirement descriptions and without managing and administrating them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing business requirements [17]. Our method, introduced in this paper, notably benefits from the user stories by defining and applying them in a formal way. Besides the user stories, requirements analysis, requirements engineering and requirements management also contribute a significant part to the presented quality assured software development method. Furthermore, there are approaches that also influenced our method, these are story-driven modeling and domain-driven design. Story-driven modeling [18], a high-level graphical method, employs so called story boards to analyze the dynamics of object structures as sequences of graphical snap shots for sample scenarios. The major benefit of the approach is that story boards allow to develop and illustrate design and ideas of a systems object structure and central mechanisms in a quite simple visual notation. On the other hand, story boards have welldefined syntax and semantics that gives way to semi-automatic derivation of subsequent specifications like, e.g. the static class hierarchy and dynamic operations on object structures. Story-driven modeling supports analysis, design and implementation of software components. Story-driven modeling is not intended to replace existing modeling techniques like UML but to complement them. Story-driven modeling has proven to work well for the cooperation with non-it experts. Both story-driven modeling and our approach, presented in the paper, address these goals, i.e. to provide a ubiquitous language (one or more DSLs) that is understandable for both the domain experts and requirement analyzers, enough formal to define precisely the user requirements, capable to define the dynamics of object structures as sequences and can be automatically analyzed and processed. The difference is that our approach is driven by not only the need to analyze and formally define requirements that is understandable for the domain experts as well, but this is a tool to be able to effectively support the development by artifact generation, the testing by test scenario generation and also the maintenance phase of the software lifecycle. Domain-driven design [19] as a software development approach supports complex requirements by connecting the implementation to an evolving model. Domain-driven design places the project s primary focus on the core domain and domain logic, bases complex designs on a model of the

6 6 L. Lengyel et al. domain and initiates a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems. Domain-driven design does not specifically require the use of a DSL, though it could be used to help define a DSL and support methods like domain-specific multimodeling. The emphasis is put on to understand and build the domain model. This is common with our approach, i.e. to understand and define the domain related processes and derive the system behavior from it. Both of the approaches define that a system based on the domain model and rules is easier to understand, use and extend Domain-specific languages Domain-specific languages are an effective way to narrow the communication gap between the customer and the developer team. DSLs can form that common language which is understandable for the customer and has useful meaning for development purposes. To raise the level of abstraction in model-driven development, both the modeling language and the model processors (generators) need to be domainspecific. With a domain-specific language, the problem is solved only once by modeling the solution using familiar domain concepts. The goal is to define the end user requirements with the help of domain-specific languages. These models are the final artifacts in the development process that are understandable for the customer, therefore, these artifacts are the last step where the customer can validate his requirements. Also, these models are the first step where developers understand the operation of the system in a formal way. As a consequence, these models should drive the whole development process, i.e. we should derive all the functionalities, the documentation and also the test scenarios from these models. This requires that our DSLs provide constructs and enough details for all these issues to be defined, while remain understandable for domain experts. Our DLSs, the Use Case DSL, theactivity DSL, therequirements DSL and the Concept DSL, are extensions of different UML models: their roots are the different UML diagrams, but we have modified their abstract syntax (metamodel), concrete syntax, and we have added custom semantics to them. Handling them in this way, these DSLs drive our model-based system development process. 3. DOMAIN-SPECIFIC LANGUAGES FOR REQUIREMENTS ENGINEERING We have developed four DSLs, which provide an extensive toolset to facilitate the description and collection of the requirements in an efficient way: (i) Use Case DSL: to describe the actors and the use cases of software systems. (ii) Activity DSL: to describe the workflows use cases related to specific user and test case scenarios. (iii) Requirements DSL: a dictionary of the requirements to make it possible to reference them from other models. (iv) Concept DSL: a glossary of domain related concepts that can be referenced from other model elements. The tool support of the method is implemented in the Eclipse Framework [20] as an Eclipse plugin and further model processing components. We discuss the metamodels of the domain-specific languages, introduce the plugin, which is based on the eclipse graphical modeling framework (GMF) within the frame of eclipse graphical modeling project (GMP) [21]. Furthermore, we share some details about the realized editor using the eclipse extended editing framework (EEF) [22]. We have chosen the Eclipse Framework as the implementation platform, because Quattrosoft Ltd. uses it as its default implementation environment. Their software projects are mainly implemented on Java platform. Alternative implementation environments could be for example generic modeling environment (GME) [23], DSLTools [24] or an optional custom tool. This means that the methods and the domain-specific languages provided by the presented methodology are tool independent, i.e. the results and the methods can be applied in different environments as well. The domain-specific languages not only support the quality assured model-driven requirements engineering method, but also serve as a basis for generating software artifacts. First, we introduce the common elements of the four modeling languages, and then present the concept of each language separately. Finally, tool support for efficient management of the models is detailed. The processing of the models, i.e. the methods that generate code, documentation and test scenarios are addressed in Section Common elements of the DSLs The four DSLs have a common tree view editor interface, a table view and a more intuitive graphical view for visual editing. These DSLs are an improved and expanded version of the ubiquitous UML use case and activity models [4]. We have modified the original UML languages, because we wanted them to fit our needs to specify the requirements, these modifications are based on our experiences distilled from several industrial case studies. Our improvements make the formulation of user stories a simplified process. We used eclipse modeling framework (EMF) to describe the metamodels. The four DSLs are realized as one monolith metamodel because of the requirement to be able to mix the model elements from the different domains into one instance model as well. All languages are based on a common metamodel fragment that is depicted in Fig. 2. Each element of the metamodel derives from AbstractType that facilitates the unified handling of all model

7 Quality Assured Model-Driven Requirements 7 FIGURE 2. Metamodel of the common language elements. FIGURE 3. The use case metamodel. elements: each model element has a name, areal name (toprovide a more meaningful name), a unique id, a description, and a sortorder that specifies priority during documentation generation for a specific element. The description field contains a rich text description (in XML format) that may contain cross references to other model elements as well. This weak reference (stored in the XML document) is also expressed with modeled references (referencingentities/referencedentities edges) to be able to discover dependencies without parsing all the XML descriptions as well. The descriptions may embed images as well, this dependency is expressed by the Attached- Image element (that points to a file-system element) and the images relationship. According to the metamodel, all model elements can be organized into Packages that may also correspond to real Java packages during code generation The use case and the activity DSLs The Use Case DSL is a model of how users connect to and interact with the system to handle problems. The DSL describes the goals of the users, the interactions between the users and the system, and the required behavior of the system to satisfy these goals. The two main elements of the language are the UseCase and the Actor (Fig. 3). Note that all the elements in this metamodel inherit from the AbstractType element, so they all have a name,adescription, can be referenced etc. UseCases also have the usual precondition, postcondition, purpose and scenario attributes to precisely define the use case. The attributes also contain rich text content in XML format, may contain references to images or cross references to other model elements. UseCases may include and extend each other corresponding to UML. By Actors, we distinguish User and System actors (ActorType) to be able to differentiate between the different actors interacting with the system. Models can be edited in the usual EMF tree view-based model editor, however, we can assign diagrams to any of the packages as a root elemenet, and visualize a model fragment in a graphical way as well. We may place elements contained by another package than that of the diagram root onto the digram, however, in this case the element is placed as a shortcut (that is indicated by an arrow on the top of the element). By deleting a shortcut, the element itself is not deleted from the model. Also a shortcut is created when a model element is placed on the same diagram for a second or third time, e.g. to increase transparency. The complete DSL diagram editor application consists of the Project Explorer view, an Outline view (or Navigator window), a drawing area (diagram) and the palettes, which provide the toolset for placing elements on the drawing area (Fig. 4). Elements can be inserted by clicking on an appropriate element on the diagram palette and dropping it to the drawing view. The navigator window is used as an instant summary of our model as a tree view. We can add, modify and delete new elements here and diagrams as well. The Activity DSL is used to display a sequence of activities. It is useful both to formalize user stories and also to define test scenarios for validation. The metamodel of the language is provided in Fig. 5. The user story or test workflow starts at a Start node, finishes at an End node and each step (activity)

8 8 L. Lengyel et al. FIGURE 4. Asampleusecasediagram. FIGURE 5. The activity (user story) metamodel. describes the test case to perform or the expected behavior in textual, human readable format (description field). Activities are connected with Transition edges that simbolize a conditional (guard attribute) transition between two activities. In addition to simple activities, we distinguish two special kinds of activities as well: Assert and Output. Assert describes the main purpose of the test scenario, i.e. the condition that must be satisfied in order to say that the test has been successfull. The Output node denotes an activity where the testing user must produce some kind of output (a screenshot or a print), and attach it to the test log. These two special kinds of activities are used to ephasize their roles on the user interface for the user and they are also taken into account later, for example, during the automated test generation. All these techniques, based on the actity model, support the identification of relevant test cases. Activity and use case models represent the business processes and the system level use cases. These models serve as a communication platform at an appropriate level of abstraction. These artifacts can be transformed to human readable and understandable documentations. Therefore, these artifacts are typical products of the requirements handling and definition project phases. Based on the customer feadbacks, we found that using our DSLs, the model and the generated documenntation are compact and

9 Quality Assured Model-Driven Requirements 9 FIGURE 6. A sample activity diagram. unambiguous. The formal definition of the DSLs makes possibe to use their keywords as instructions during the analysis of the activity graph. Activities may be hierarchical as well: an activity can be specified in more details in another activity diagram. The end nodes of the contained activity model can be mapped to the leaving transitions of the container activity node (originatingend reference), thus, we can specify which transition to follow for each end state of the contained scenario. To be able to organize activities by actors within a model, we have introduced a special element called Swimbox. Swimboxes are similar to swimlanes (like in UML Sequence diagrams) with the difference that they can be freely aligned on the screen thus we can achieve optimal layout. Each swimbox can be connected to one specific user and a system actor. For an activity, we can also exactly define those use cases realized by the activity (realizedusecases edge), and for each use case, we can assign a complete activity model, if the use case can be performed by a complex workflow. An example activity model is depicted in Fig The requirements and concept dictionary DSLs The Requirements DSL and the Concept Dictionary DSL make it possible to summarize all the related concepts and requirements of an actual software product. The metamodels are provided in Fig. 7. The implementation provides these dictionaries in a table format. The different dictionaries can be embedded into our model hierarchy. After creating the dictionaries in the tree view of the model editor, we can edit them both in the table view and in the tree view. The table view processes the actually opened model and organizes the related information to display the dictionaries in a practical format in table cells. The Concept dictionary is a glossary of domain related concepts. We can refer to these concepts from other model FIGURE 7. The requirements and the concept dictionary metamodels. elements, such as activities or actors, and we can look up those model elements, in which these concepts are affected. An example concept dictionary is presented in Fig. 8, where the concepts are provided both in a tree control and in a table format: name of the concept and the related description. User requirements are collected in the requirements tables. The links between the requirement items and model elements help us to follow which model parts realize a certain requirement, and vice versa, which requirements are affected by a model element. The layout of the requirements dictionary matches that of the concept dictionary EEF-based rich editing features The EEF [22] is a presentation framework for the EMF. EEF makes possible to create rich user interfaces instead of the default grid-like property editor panels to edit EMF models. The realized EEF-based rich editor is a great help during the modeling. The capabilities of the realized EEF editor are discussed in this section. In addition to being able to edit the usual model element properties, we can edit the textual model properties with the help of a rich text editor. Using this control, we can apply

10 10 L. Lengyel et al. FIGURE 8. A sample concept dictionary specification. FIGURE 9. The EEF editor of an actor object. different font styles (bold, italic) in the text; we can apply bulleted lists, and mark text fragments as source code with special formatting. References that refer to model elements (e.g. an actor or activity) can be inserted into a text as cross references. Besides, the images provided by the file system (the eclipse workspace is the root directory) can also be inserted as references. Figure 9 depicts the EEF editor interface for an Actor element. The bottom part of the figure shows the custom rich text editor. The formatted text is converted and stored in XML format that mostly uses the well-known HTML tags. The XML format of the text is available and editable in the SourceView of the editor (Fig. 10). Pressing the More...button, a larger dialog window pops up and makes possible the more comfortable editing of the text. A separate dialog has been developed to serve the reference management (Fig. 11). The window represents the model elements in the hierarchy they are stored in the model. By selecting a model element the solution puts a reference into the source view of the text (e.g. <a href = /My Folder/qsmodel.qsmodel #_h8xcydfgeeoazyngizuwow mode = name />, where the code after the hashmark character denotes the unique id of the referenced model element), and shows the value of the Name attribute of the referred model element in the rich text. The name is shown as blue underlined expression, and by moving the mouse over the name of the referred element, a tooltip shows the path related to the model element (Fig. 12). In a similar way, we can refer to images as shown in Fig. 13. By selecting an image the solution puts a

11 Quality Assured Model-Driven Requirements 11 FIGURE 10. The SourceView of the editor. resolved during the generation of the documentation, while it also maintains a formal model in the background that facilitates finding dependencies between various requirements and their implications. FIGURE 11. The reference chooser dialog window. FIGURE 12. Tooltip of a referred element. reference into the source view of the text (e.g. <img align = center caption = MyCaptionText src = \MyFolder\ pana004_resized2.jpg />), and shows an image placeholder. The tooltip of the placeholder shows the path of the referred image file. With the help of the realized editor interface, we are able to describe use case descriptions, activity operations, etc. in a WYSIWYG format, and we can insert image references and cross references to elements. The presented solution provides a comfortable way to manage cross references that can be 3.5. Further domains of the environment Through a software development process, all the gathered information pieces should be organized in a carefully designed repository structure. Usually, the information is represented by plain text documents and stored in separated repositories maintained by the different project partners. This method results in extra administration cost during the software development process. Unfortunately, this type of administration should be performed by highly qualified experts, because all information has its semantic meaning. Misunderstanding the meaning of information can lead to communication problems and further issues. Therefore, applying the appropriate DSLs and providing a consistent working environment for the experts, we can significantly reduce the unnecessary administration and allow experts focusing on their main objectives. We have defined several further DSLs for the rest of the software development process. All DSLs are about to capture the appropriate level of abstraction and help the communication between domain experts and software engineers. These DSLs support the task management, definition of business entities, user interfaces, etc. We have mentioned them to provide a general overview, but the details of these DSLs are out of the scope of this paper because here we concentrate on the requirements engineering part and its tool support of the whole development cycle. Project tasks are automatically derived from the domainspecific models and provide an easy way to follow the connections between the requirements and the daily activities. The well-formed domain models support automatic code generation. This is important that in this case the code generation is not equivalent with the visual programming technology. Domain models capture a higher level of abstraction than source code. Models support the designer to make high-level decisions. Code generators extend the models with platform-specific and implementation related details. Business entities of the software systems are defined within a separate DSL. The instance models of this DSL refer to

12 12 L. Lengyel et al. FIGURE 13. The image browser dialog window and a sample inserted image placeholder with a tooltip. relational database models. We also defined a DSL for capturing the graphical user interface requirements. During the definition of our DSLs, we aimed that the different DSLs can refer to each other. As a result, different domain models can refer to each other, and they utilize the objects and constructs of each other. 4. GENERATING SOFTWARE ARTIFACTS Previous section has discussed the requirements engineering part and introduced the supporting environment of our method. As we have already mentioned in the introduction section, the model processing is not in the focus of this paper, therefore, we only provide a summary about it, i.e., in this section, we shortly introduce the model processors that based on the requirement model set generate different artifacts: source code, tasks, documentation and relevant test scenarios Source code and task generation The requirement models serve as a plan for all the activities done by different roles of the software development process. They act like a design layout for a building. We found that ideally the great majority of the development-related tasks should be generated from the models. The more tasks are generated from the models, the less inconsistency can be observed between the model and the reality. Therefore, the first step is to solve the automatic and tool supported relationship between the model elements and the tasks. The next step is to identify which tasks are well-defined and can be expressed as decision points in domain models. For these cases, we can address the generation of the given software artifacts. We believe that this approach is quite important and should be followed; otherwise, a ;l art pour l art; effort could be taken: generating something that is not relevant or making all the decisions already in the model space. We apply source code generation to process the following domain models: (i) From business object models, we generate the object persistency layer of the system. (ii) From the abstract user interface models, we generate the appropriate client source code. (iii) Furthermore, other artifacts are automatically produced like language resources and messages based on the terminology of domain models. It is important to handle this issue in an automatic way, because the same labels, domain expressions and messages should be generated in the documentation, in the source code and on the user interface as well Generating relevant test scenarios Based on the business processes and the use case scenarios, the test cases are produced by traversing the process graph and identifying its different paths. The processing generates the so-called relevant test scenarios. A relevant test scenarios represent a subset of the complete test scenario set. The solution makes possible to define test data sets that are harmonized with the decision points and the process graph. By exhaustively traversing the whole process graph, we can generate all the test scenarios. However, in case of knowing certain decisions (parameters or variable values) we should test only those branches of the whole process graph that can occur. This makes the testing process more effective, because the known parameters and variable values cut the problem space. For example, consider the following: there is a decision point, where we can choose between the red and green paths. Assume that we select the green one (e.g. based on an input parameter). Later, if the same decision arises, we should follow the same path again. Therefore, there is no need to generate test scenarios covering the red path. In this way we can reduce the number of test cases and ignore the unnecessary ones. The method, based on the use case scenarios generates a template for possible input parameters. This is an Excel table. The user fills out this table and based on it and the use case scenarios the solution generates the relevant test scenarios.

13 Quality Assured Model-Driven Requirements Generating documentation In our approach, domain models drive the whole development process. However, end user artifacts are mainly documents, which are the readable layouts of the given domain models. The business process models are a communication platform between the development team and the project stakeholders. Therefore, the documentation generated based on these models should be well-formed, and furthermore, easy to read and understand for the domain experts. To fulfill this requirement, the business process model and every further DSL sections have their own documentation layout. The generator uses a template-based technology by writing the document directly through a Java API. The generator can produce documents of several hundred pages within a few seconds, i.e. the document generation solution is effective. Note, that it is not a goal to generate verbose and too long documents. The length of the documents depends on the sections related documentation layout, the size of the processed domain models, and the document format settings (e.g. font size, margins and further paragraph settings). Model element descriptions are formatted as rich text sections; furthermore, they handle inserted images as well. Therefore, the generated document artifacts do not require any post-processing like manual formatting or extending. 5. LESSONS LEARNED The result of this systematic approach leads to a close relationship between the original requirements, the source code, the documentation and the test cases used in the transition phase of the project. Based on our experience, the method significantly reduces the project risks. Based on this method, in the last twelve years, all our projects were delivered successfully. A further benefit was that the change management was also supported with a strong method. This is not trivial to calculate the direct and indirect benefits of the whole method, but calculating with the 15% of the project cost is a good estimation. We highlight, that this ratio is an estimation by our senior architects and technical project leaders. This benefit is related to the development phase of the software artifact s lifecycle and it is calculated based on the last 12 years. The typical development phase of these projects is between 6 and 24 months. Furthermore, there is also benefit provided by the method that is realized during the maintenance of the software. The benefit is the result of the modularized, well tested and clean code. We are about to extend the method with certain well-defined points in order to be able to measure the benefits related to the whole development and maintenance phases more precisely. As a general rule, both parties (the customer and the solution provider) are interested in defining the system requirements as precisely as possible. Our projects proved that extra efforts (e.g. a careful design) performed at the preliminary phase save more efforts in the transition phase and significantly reduce the risks. This was our main goal during developing and applying this method. The next two subsections discusses the strengths and weaknesses of the approach, furthermore, provide a comprehensive list of best practices we suggest to apply for model-driven requirements engineering and model-driven development Advantages and disadvantages of the method The strengths of the method: (i) Requirements models drive the whole development process: requirements analysis and requirements engineering, artifact generation (development related tasks, source code, test scenarios, and documentation), testing, verification/validation issues, maintenance and feedback management. This results a model-centered and strictly model-driven approach with advantages of clear requirements management and direct connections and consequences during the development process. (ii) Provides the frame of adequate analysis, unambiguous scope definition and involvement of the domain experts (customers) into the development. (iii) Defines a clear connection between the requirements and the software components (system functionalities). (iv) Puts the domain processes (workflows) into the focus of the requirements analysis and the development. (v) Ensures the continuously up-to-date state of the requirements models all along the lifecycle of the given solution. (vi) The method and its supporting tools are effective enough to make both the domain experts and developers life easy when they are working with them. (vii) The method can be freely extended with optional number of DSLs and domain-specific model processors. The key concept is that models should drive the artifact generation, the testing process and also the maintenance. The weaknesses of the approach: (i) The generated source code is based on companyspecific class libraries. Some of these libraries are developed for different application domains (e.g. financial sector, governmental sector, pharmaceutical field, other) but the great majority of these libraries cover enterprise software related issues, i.e. support the communication between the clients and the server, the data access and database management practices. These libraries are company-specific artifacts, therefore, the generators should be redeveloped by each company in order to target their own library capabilities. (ii) The maintenance of the metamodels, the modeling tool and model processors brings the evolution into

14 14 L. Lengyel et al. the process, but also require a reasonable amount of development effort. Based on the collected experience and requirements stated by the development process, targeted platforms or the natural need to extend the methods to address further aspects of the software systems, i.e. add new domain-specific languages to the modeling part, our team regularly improves and/or extends the DSL metamodels. Furthermore, the underlying company-specific class libraries are also evolving with different components distilled from our projects. These two changing factors require to maintain both the modeling environment and also the model processors reading the models and generating the artifacts. We perform these modifications on a yearly basis. (iii) Technology changes also have an effect on the modeling tool and model processors. Technology change means the evolution of the host modeling environment, i.e. the appearance of new versions or extensions of the base environment. An example for the technology evolution is the attendance of the Sirius technology, which is a novel way to define our own graphical modeling tools in Eclipse. It leverages the Eclipse modeling technologies, including EMF for the model management and GMF for the graphical representation. We found that Sirius technology can make the design phase more productive with improved graphical representations to better elaborate and analyze a system and improve the communication with other team members, partners or customers. Therefore, we decided to adapt this technology. As a consequence this requires reasonable maintenance in our DSL plugins. This also has a side effect for the model processors that need to be revised. (iv) The provided method is presented as an experimental report, and not as a tutorial or a receipt to follow. The reason is that each developer company or team has its own rules and processes. The introduced method is not about to redefine the working method, but it suggests those thoughts, methods and assets that are worth to follow in order to make the software development process more effective and increase the quality of the resulted artifacts. Section 5.2 provides general best practices that are also applicable by different companies and teams. (v) The paper does not provide the exact details of the method. The reason is that we think about this paper as an experimental report. In the industry, there are dozens of company-specific decisions and solutions. We think that it is more useful to provide an overview and only some details about the method, especially related to artifact generation, because developer teams are interested in the general concept and not the implementation details. They have their own implementation preferences and they usually do not use out-of-box solutions, but implement the methods on their own way. There are situations when the legal entities or other regulations force a certain level of validation. We had several projects in the field of pharmaceutical, financial and governmental sectors. These projects required theoretically proven and verified approaches to confirm the correctness of the validation process for the auditor organization. As an example, we mention a project from the pharmaceutical filed, where factory level processes, implemented in the newly introduced ERP system, was validated by the presented method and with some supporting tools Best practices for model-driven requirements engineering and model-driven development We have learned several practices from different design and development approaches and during the years and based on our projects we have combined them with our experience. In this section, we provide a distilled list with our short explanations. Requirements modeling helps us understand, discuss, and communicate our customers needs by drawing diagrams about their activities and the part their system should play in helping them achieve their goals. A requirements model is a set of these diagrams, each of which focuses on a different aspect of the customers needs. We use the requirements model to help in the following way: (i) Describe the users and stakeholders needs with much less ambiguity than we can in natural language. i.e. reduce gaps and inconsistencies in the requirements. (ii) Define a consistent, ubiquitous glossary of terms that can be used by users, developers, and testers. (iii) Plan the order in which features will be developed. (iv) Reduce the work needed to respond to requirements changes. (v) Use the models as a basis for system tests, making a clear relationship between the tests and the requirements. When the requirements change, this relationship helps us update the tests correctly. This makes sure that the system meets the new requirements. (vi) Separate the system s external behavior from its internal design. Lessons learned and best practices that are worth to take home: (i) Continuously keep the design up to date. A requirements model provides great benefit if we use it to focus discussions with the users or their representatives, and revisit it at the beginning of each iteration.

15 Quality Assured Model-Driven Requirements 15 Revisiting the design is a part of an agile-like method, i.e. at the beginning of each iteration we go through the design, think it over and do the necessary modifications to address the actualities. This is similar to the backlog analysis and adjustment of the user story priorities. (ii) Clearly understand users needs. Creating a model usually results in a significant reduction in inconsistencies and ambiguities in the users requirements. Different stakeholders frequently have different understandings of the business world in which the system works. Therefore our first task is to resolve these differences between our users. i.e. the starting point of any design is a clear understanding of the users needs. (iii) Develop iteratively. Ideally, we know all requirements in advance, however, usually this is not the case. As a consequence we often should apply an iterative method. (iv) Use components. Breaking down a system model is the appropriate way of design and development. This promotes ability to test individual components before they are integrated into a larger system. (v) Model visually. Use diagrams to represent all major components, users and their interaction. We found that many questions about the business domain arise naturally while we were creating a model. By putting these questions to our users, we can significantly reduce the need for changes at a later stage in the project. (vi) Dedicate time to review the design to minimize conceptual (semantic) errors. Verify quality. The design team should ensure that major conceptual elements of the design have been addressed. The design should be unambiguous and consistent. Always make testing a major part of the project at any point of time. Testing becomes heavier as the project progresses but should be a constant factor in any software product creation. (vii) Apply continuous integration. Prepare the method to control the changes. Several projects are created by different teams, sometimes with different background and in various locations, even different platforms may be used. As a result it is essential to make sure that changes made to a system are synchronized and verified constantly. (viii) Consider alternative approaches. We should consider alternative approaches, evaluating each based on the requirements of the problem, the resources available to accomplish the project. (ix) The design should be traceable to the analysis model. A single element of the design model often reflects to multiple requirements. Therefore, it is necessary to have a way for tracking how requirements have been satisfied by the design model. (x) The design should not reinvent the wheel. Development time is short and resources are always limited (we can utilize them for different purposes as well). Systems should be constructed using a set of design patterns. Design time should be invested in working out truly new ideas and integrating those patterns that already exist. Patterns support the understandability and maintainability of the system. (xi) The design should follow the domain as it exists in the real world. The structure of the software design ideally mimics the structure of the problem domain. That is, we minimize the semantical distance between the software and the targeted domain. This supports both the development and the maintenance. (xii) The design should be uniform. Format, rules and style should be precisely de?ned for the design team before the design work begins. As a result the design should appear as it would be developed by one person. Best practices related to model-driven development [25]: (i) Model the requirements, not the solution. Use or adapt the UML or design DSL(s) that describe the users requirements. We should avoid designing the notation according to the different aspects of the implementation. (ii) UML or DSL? (i) Try to apply UML. (ii) Consider creating your modeling notation by using stereotypes to extend UML. (iii) Define a DSL if there is no UML diagram that fits the purpose. Important: avoid breaking the rules and semantics of the UML. (iii) Model the variant aspects. Analyze the implementation and identify the aspects that can vary, either between one deployment and another, or over time as requirements change. These aspects should be modeled and then derived from requirements and design models. (iv) Separate concerns. If the variable aspects can be divided into independent areas, use separate model types for each area. For example, use cases, processes, business entities, user interfaces, further aspects should be modeled separately. (v) Generate or interpret? If the requirements for a particular deployment rarely change, generate source code from the model, build it and execute it. If the requirements might frequently change, or might co-exist in more than one variant in the same deployment, develop the application in a way that it can read and interpret the model or the configuration file derived from the models.

16 16 L. Lengyel et al. 6. CONCLUSION In this paper, using an experimental report form, we have introduced our requirements engineering and software development method. We have provided a strong motivation that has driven our research and development activities related to the method. Next, we have introduced the architecture and the details of the method. Furthermore, we have discussed our domain-specific modeling languages that support the effective requirements engineering. In addition, we have reviewed the model processors generating the human readable end-user documentation and the relevant test scenarios. Finally, we have provided quite a comprehensive list of lessons learned and best practices related to model-driven requirements engineering and model-driven development. We started to use the presented method or certain parts of it in our software projects more than ten years ago. Of course, the method and its tool support are being continuously developed and adapted to the actual conditions of different projects. The introduced method has various benefits for the industrial partners. By applying quality assured methods in requirements engineering, user story definition, and requiring customer validation of the business requirements, significantly pushes forward the unambiguous project scope definition, the appropriate quality assurance, and the customer satisfaction. We believe that this method can improve the quality of the software artifacts, increase the development productivity, and decrease the required resources and the time-to-market period. The methods and the introduced domain-specific languages are tool independent, i.e. the results and the methods can be applied in different environments as well. Of course, we continuously use the method, refine it and develop it tool support. This activity is driven based on our current software projects and novel experiences. FUNDING This work was partially supported by the Hungarian Government, managed by the National Development Agency, and financed by the Research and Technology Innovation Fund (grant no.: GOP ). REFERENCES [1] Sommerville, I. and Kotonya, G. (1998) Requirements Engineering: Processes and Techniques. John Wiley, Inc. New York, NY, USA. [2] Pohl, K. (2010) Requirements Engineering: Fundamentals, Principles, and Techniques. Springer. [3] Manifesto for Agile Software Development (2001) agilemanifesto.org/ (accessed May 15, 2015). [4] OMG UML specification, Version 2.3 (2010) OMG document formal/ , (accessed May 15, 2015). [5] de Lara, J., Vangheluwe, H. and Alfonseca, M. (2004) Metamodelling and graph grammars for multi-paradigm modelling in AToM3. J. Softw. Syst. Model., 3, [6] Czarnecki, K. and Eisenecker, U.W. (2000) Generative Programming: Methods, Tools, and Applications. Addison-Wesley. [7] Amrani, M., Dingel, J., Lambers, L., Lúcio, L., Salay, R., Selim, G., Syriani, E. and Wimmer, M. (2012) Towards a Model Transformation Intent Catalog. Proc. 1st Workshop on the Analysis of Model Transformations, pp. 3 8, ACM, New York, NY, USA. [8] Mens, T. and van Gorp, P. (2006) A Taxonomy of Model Transformation. Proc. Int. Workshop on Graph and Model Transformation, pp Electronic Notes in Theoretical Computer Science, 152. [9] Sendall, S. and Kozaczynski, W. (2003) Model transformation: the heart and soul of model-driven software development. IEEE Softw., 20, [10] Fowler, M. (2010) Domain-Specific Languages. Addison- Wesley Professional. [11] Kelly, S. and Tolvanen, J.P. (2008) Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society. [12] Czarnecki, K. and Helsen, S. (2006) Feature-based survey of model transformation approaches. IBM Syst. J., 45, [13] Vajk, T., Kereskényi, R., Levendovszky, T. and Lédeczi, Á. (2009) Raising the Abstraction of Domain-Specific Model Translator Development. Proc. 16th Annual IEEE Int. Conf. and Workshop on the Engineering of Computer Based Systems. San Francisco, USA, pp [14] Ehrig, H., Ehrig, K., Prange, U. and Taenzer, G. (2006) Fundamentals of Algebraic Graph Transformation. In Monographs in Theoretical Computer Science. Springer. [15] IEEE Computer Society (1990) IEEE Standard Glossary of Software Engineering Terminology. IEEE Standard. ieee.org/findstds/standard/ html (accessed May 15, 2015). [16] Gotel, O. and Finkelstein, A. (1994) An Analysis of the Requirements Traceability Problem. Proc. 1st Int. Conf. Requirements Engineering, pp [17] Davies, R. (2011) Non-Functional Requirements: Do User Stories Really Help? archive.php?id=113 (accessed May 15, 2015). [18] Norbisrath, U., Jubeh, R. and Zündorf, A. (2013) Story Driven Modeling. CreateSpace Independent Publishing Platform. [19] Evans, E. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. [20] Eclipse Framework (2014) (accessed May 15, 2015). [21] Eclipse Graphical Modeling Project (2014) org/modeling/gmp/ (accessed May 15, 2015). [22] Eclipse Extended Editing Framework (2014) org/modeling/emft/?project=eef (accessed May 15, 2015). [23] GME: Generic Modeling Environment (2008) vanderbilt.edu/projects/gme/ (accessed May 15, 2015). [24] Domain-Specific Language Tools (2013) com/en-us/library/bb aspx (accessed May 15, 2015). [25] Jacobson, S. (2002) The Rational Objectory Process A UMLbased Software Engineering Process. Rational Software Scandinavia AB.