Abstract: Activities regarding requirements engineering as a traditional discipline within well-defined software engineering processes often work well for projects with dedicated aims and defined outcomes. However, in the scope of explorative projects, i.e., research and development, aims are not always set precisely and achievements cannot be measured against pre-defined validation criteria. Thus, initially gathered requirements may continuously change over time, depending on the knowledge gained during the project and decisions made over time. In case that the project lasts several months up to years and members are spatially distributed and need to work asynchronously, keeping track of requirements, their updates as well as extensions, becomes an even harder task. Additionally, found solutions must be connected to initial needs, requirements or ideas. This article introduces the concept of applying design patterns for documenting evolving project knowledge, starting from the formulation of problems and requirements. The notion of design patterns is radically changed such that they are not created after a long period of research and validation in order to purely provide knowledge on proven solutions; furthermore, their parts are created according to the current project’s activities, starting from early problem descriptions, user needs and real requirements. In terms of patterns, these kinds of formulations correspond to the problem that a pattern addresses. Over time, when new knowledge is gained and the problem can be better described and first solutions appear, the still missing pattern sections are updated and reworked. A defined process helps to ensure the completeness of the pattern and the validity of its contents. All project members are encouraged to contribute to a pattern’s development regarding its contents, appropriateness, formulation quality, and its validity. For realizing this concept, this article describes the derived collaborative formulation process, indicated user roles and summarizes first results from its implementation as a web-based platform in a real joint research project setting.

1 INTRODUCTION

The knowledge and requirements management efforts described in this article, primarily focus on joint research projects that often have a highly distributed character in which different institutions, small-medium-sized and large enterprises collaborate. Each partner influences the project with individual expert knowledge and individually approved engineering methods. The duration of the different research projects lies between three and four years, depending on their type. Networks of Excellence (NoE) and Integrated Projects (IP) usually have a four-years runtime whereas Collaborative Projects (CP) run for three years. The European Commission favors cooperation, knowledge exchange and taking the advantage of synergy effects between different expert groups within research consortia.

Since every partner brings in his specific competences and working processes, project management must be very flexible but still follow a budget plan and schedule. Within a joint research project, the number of participants quickly spans up to 20 partners each introducing 2 to 4 project associates. Thus, the amount of consortium members that need to be managed and coordinated quickly reaches 50 to 100 people. In order to coordinate the efforts between the different stakeholders of the projects, different work packages (WP) are specified that focus on dedicated project tasks. Figure 1 shows a conceptual overview of a possible work package distribution. Tasks are often separated between overall project management and coordination, domain analysis, architectural work packages and technical work packages dealing with implementation and validation. Additionally, activities regarding demonstration, exploitation and dissemination of project achievements are defined. Mutual influences may exist as shown in the case of WP: Req. - Engineering and WP: Domain Analysis. WP: Management is shown as embracing structure as it is interconnected with all available work packages.

Figure 1. An example for a possible work package distribution within a joint research project.

When starting a new project, accepted management guidelines like the ”Project Management Body of Knowledge”, suggest to first define the project’s scope and create a management plan by taking into account the project’s requirements and possible risks [1]. The subsequent processes regarding implementation and change request management should ideally be handled iteratively, reacting to external influences like time or personnel restrictions. It should also integrate new requests from lessons learnt during the different engineering phases. For spatially distributed work packages, the high degree of the participants’ independence makes it hard to enforce strict rules and practices. The project consortium continuously needs to negotiate throughout the project runtime. Especially in the scope of joint research projects, high efforts need to be put on management, coordination and communication. In large projects, the problem of communicating and synchronizing new findings - be it requirements or results - emerges. The approach presented in this article introduces evolving design patterns as a possible solution for knowledge and requirements management that are formulated and evaluated by all project members.

2 IMPOSING AND MANAGING EVOLVING REQUIREMENTS

Requirements analysis is the central element of knowledge generation at project start. Different kinds of requirements need to be revealed with different techniques as described in the following. Domain analysis and existing knowledge from the project stakeholders further influence the elicitation of functional and non-functional requirements. Demands from domain-centered engineering have to be merged with functional requirements from the project scope. These can, e.g., be external influences concerning technical, legal or personal restrictions as well as demands on performance, setup time and reliability. According to Kano et al. there are mandatory requirements that absolutely need to be met by the application so that users accept it [2] at all. Additional attractive requirements and features the product offers support the advantage of the product in contrast to other existing approaches and can make it more successful. In between, there are specified requirements that the customer explicitly demands for the product and that can be specified, measured and technically formulated.

Figure 2. The Kano diagram separating different types of requirements and their importance regarding customer satisfaction. Adapted to [2].

Figure 2 illustrates the correlation between the different kinds of requirements, as further explained in the following. Mandatory requirements are often not directly expressed since they describe habits the users are no longer actively aware of [3]. Observatory methods help to discover this tacit knowledge. Domain representatives are watched while performing their work.

Another source for functional and non-functional requirements are involved project partners themselves that bring in their experience from former projects. Certainly, they are specialized with regard to their research field that can be focused on technology but also on the domain. Knowledge that is available right from the project’s start is very valuable for the project’s engineering and design work. It needs to be considered right from the beginning as basis for future findings.

According to Maiden and Gizikis, creativity techniques have proven as successful in order to learn about attractive requirements [4]. Very common methods are brain- storming and the 6-3-5-method in which six participants each create three ideas that are circulated and refined five times [5]. De Bono introduces the six-hats-method that allows for a perspective change, according to the hat the participants are currently wearing [6]. The spectrum covers analytical, emotional, critic, optimistic, creative and structuring attitudes.

Participatory design approaches combine observations with ethnographic methods that try to involve engineers into specific domain-related tasks as described by Suchman and Hughes et al. [7], [8]. These methods are support domain engineers to learn about tacit knowledge [9]. Kensing and Blomberg [10] discuss the integration of a participatory design approach that involves the user at a very early stage in the design process. In addition to Nielsen’s concept of iteratively designing prototypes (cf. [11]), the user is not only asked for evaluating the design outcome but also to actively take part in the requirements engineering process and specification of the system’s behavior.

During iterative design, prototyping methods allow for fast constructions of application concepts in terms of hard- and software that can be presented to users in order to quickly receive feedback on the current design, interaction or application approach. Prototyping methods can range from paper prototypes [12], to cognitive walkthroughs [13] and Wizard-of-Oz techniques [14] up to horizontal or vertical prototypes that either analyze the general concept or deeply focus on central aspects of the functionality.

The findings from the prototyping sessions are fed back to design methods and the requirements management tasks. Especially in a research project, requirements need to be formulated and adapted several times since they are not complete at the beginning of the project [15]. Changes and new results must be documented since they represent valuable engineering knowledge. Further experience with iterative an changing requirements within a research projects and an approach of handling them with a configurable issue tracker are illustrated in [16]. Here, the authors show that engineers need to perform elicitation, modeling, negotiation and agreement, specification, verification /validation and manage the evolution of requirements.

In summary, it can be stated that requirements result from a number of sources and can be imposed explicitly or hidden since they are discovered during system development. Parts of these already exist but are unconscious such that it is hard to reveal them right from the start and keep them up-to-date during the entire engineering process.

3 COLLABORATIVE FORMULATION OF EVOLVING PATTERNS

In order to convey generalizable information to the whole project consortium, the presented approach makes use of design patterns for documenting project knowledge. The pattern concept is well known and capable of capturing working solutions to recurring problems that a community of experts has developed over time. Patterns originate from the architectural domain where Christopher Alexander presents them as readily formulated pieces of solutions for general design problems [17]. Gamma et al. transferred the idea to software design [18]. Other areas such as user interface design [19], human-computer interaction [20] or website design [21] and [22] made use the pattern concept to share their knowledge. Several other non-technical domains adopted the concept and therewith formulate patterns for a variety of topics. Manns and Rising present patterns for the introduction of organizational process changes [23]. Coplien and Harrison give organizational advice through patterns [24] and Bergin et al. present patterns dealing with teaching aspects [25].

The solution proposed by a design pattern should be generic enough such that it can be used for different solutions. Falkenthal et al. further distinguish between the abstract pattern solution recommendation and instances of the concepts that they call solution implementations [26]. In their view on pattern collections, both parts are used to communicate abstract knowledge but also to provide working solutions that can directly be replicated and combined within real problem contexts.

Authors usually make use of natural language in order to avoid specific vocabulary and keeping the formulations understandable for non-experts. Recent research takes into account semi-formal and formal approaches in order to automate the structuring, retrieval and selection processes for patterns [27-31].

Within this article, patterns are not only considered as a way to capture and represent design knowledge but also as means of communication and documentation within and beyond the current project knowledge and the dynamic requirements engineering process. This way, they are used to capture domain, process as well as technical knowledge during all phases of the project lifecycle from many perspectives. Similar to Erickson [32], patterns are regarded as a lingua franca between stakeholders. One important aim of the approach is the parallel documentation of findings and updating the collection of requirements while performing research and development. In order to integrate as many findings as early as possible in the pattern collection, the presented approach lowers the threshold for contributing to the library. This allows contributors to provide early formulations that may range from considerations and incomplete pattern ideas up to acknowledged and proven solutions according to the original pattern concept. The patterns are created in parallel to the engineering process.

Some guidelines for extracting patterns from made of experience are given by Meszaros and Doble [33]. Their ”Pattern Language for Writing Patterns” is also available online (http://hillside.net/index.php/a-pattern-language-for-pattern-writing). In summary, they state that patterns should be:

• Readable such that quick parsing of the contents is possible
• Tailored to the target audience, i.e., in the context of this work, the project domain and work package tasks
• Understandable by the audience
• Structured such that the meaning of the different parts of a pattern is clear
• Self-explanatory by providing meaningful names and examples as well as using a common notation that is understood by every member of the audience

The presented approach takes into account that early formulations for discovered problems or user needs evolve over time and reflect the current engineering progress. Therefore, a pattern first represents an open problem that is refined and updated over time until both – problem and solution(s) are found. Clarifications and additional explanations are provided by the feedback from the project members that rate on the factors readability, understandability of the solution and relevance to the project scope. The entire derivation of the process, its rules and role model together with the abstract formulation of the different criteria for a pattern’s maturity state is described in [34].

The derived pattern maturation process is schematically depicted in Figure 3. Each newly submitted pattern undergoes a first semi - automated quality check process meaning that the system first ensures that all required pattern fields are actually filled. The submission is then forwarded to a group of pattern reviewers who decide whether the pattern can be published in the library or if certain formulations need to be changed again by the author. This quality check avoids flooding of the pattern library with inappropriate content. After a submission has passed the quality check, it is published in the library and is therewith open for the community-based discussion within the community.

Figure 3. The collaborative formulation process for evolving patterns.

After its publication within the pattern library, every registered user of the system can provide feedback to the pattern, its formulation and support or refute the pattern statement by providing more evidence in favor of the pattern or against it. Evidence can originate from references from literature or realizations in products or applied processes that support or refute the pattern’s validity.

Figure 3 shows different maturity states a pattern undergoes during the described process. From an initial pattern idea that is submitted as an ‘’open problem’’, i.e. a requirement, it develops from a pattern ‘’under consideration’’ to the more mature states ‘’pattern candidate’’ and ‘’approved pattern’’. These states reflect the usage and support of the pattern and tie the initially stated problem to the proposed solution.

In order to pass the state from an open problem to a pattern “under consideration”, an eventually not yet validated solution must be added to the pattern. The approach assumes that proposed solutions are implemented within the project and validated. The results of the validation are fed back as evidence to the pattern. In addition, assuring the pattern formulation quality is the aim of the threshold to the next maturity state. In order to pass, the project stakeholders review the pattern formulation and provide feedback and rating with regard to different aspects. These can be its readability, understandability and its appropriateness for the current project. The needed amount of reviews, considered aspects and needed rating scores can freely be defined. After the formulation quality threshold is passed, the formulation is becomes a “pattern candidate” that needs to be evaluated. Based on validation or research related to the stated problem, evidence that support or refute the pattern is collected. Again, the needed amount of pieces of evidence as well as their individual weights can freely be defined.

After this last threshold is passed, the problem formulation and solution finding process ends. The pattern now encapsulates the history from an initial problem to a proven solution. In case that the pattern library is used as knowledge repository for several current or future projects, the currentness of a pattern needs to be checked periodically. Eventually, the maturity state needs to be revalidated and formulations within the patterns need to be updated.

Besides the found and proven solutions, surprisingly failing solution attempts are also part of the library and denoted as anti-patterns as described in [35]. They also represent important knowledge that must be considered in future, similar problems such that repeating errors can be avoided and therefore save development time. Additionally, possible solutions should be documented to open the design space such that new ideas can be generated while taking up inspiration from existing ones.

The presented approach implicitly supports situations in which suggested and even proven solutions co-exist. Since the patterns intend to collect and communicate knowledge and possible ways to solve problems, contradicting solutions are kept. In engineering, there are usually several ways of dealing with challenges. The pattern structure and its contents encourage the description and discussion of the issues they treat. Therefore, the pattern library reflects collected experience. When searching for solutions, the reader, who can follow the line of argumentation that is inherently given in the pattern’s prose formulation, makes the choice.

4 EVALUATION WITHIN A REAL PROJECT SETTING

The summarized approach was implemented as an extension of a content management system. As test bed, the joint research project BRIDGE (http://www.bridgeproject.eu) with 60 participants was used. In total, a representative set consisting of 25% of the project members took part in a distributed pattern collection workshop that spanned 4 weeks. For the workshop, different assignments aimed at triggering different actions such as reviewing submitted patterns, contributing new ones and assigning evidence. However, there were no strict deadlines demanded such that the assignments served as orientation points for task support. The study setup helped to stick to the asynchronous, independent and spatially distributed working habits in a joint research project structure. All detailed results of the application and survey are discussed in [34]. Shows how the patterns addressing different aspects of the domain were structured in a hierarchy; Very abstract rules and processes are shown at the top, more concrete concepts and realizations follow later in the graph. The pattern visualization is surrounded by different widgets that are intended to show latest activities within the library and make suggestions on what user action could be performed next.

Figure 4. Screenshot of the BRIDGE Pattern Library Platform.

After the usage period, the pattern library contained 43 patterns in different maturity states. User feedback provided as ratings, comments and the assignment of evidence shows that the EPL concept was implemented in a way that could be used to contribute to the knowledge repository and improve the formulation quality as well as the validity of the different patterns. The fact that most patterns are currently in the states under consideration and pattern candidate reflects the ongoing project and engineering work; instead of formulating pattern collections in retrospective, proto-patterns and ideas are actively refined at the time of knowledge generation. Looking at the average length of the pattern formulations and the usage of the summary fields, the results are promising.

Besides the derived patterns in the project domain, qualitative and quantitative feedback from the users was collected with the help of elaborate questionnaires. Aspects covered regarded the understandability of the whole approach and estimations of applicability in the daily work processes. Furthermore, questions regarding the process and its rules were asked. In total, it can be stated that the implementation of the pattern library conveyed the idea of evolving patterns. The process and defined set of rules were understood. The distinction between users providing feedback and ratings, respectively, in contrast to users that contribute patterns or maintain the pattern library was understood. Interaction and visualization issues were raised concerning the visualization of the individual process steps. In order to show that others are actively working on the pattern library, different widgets were designed showing where changes were made, what contents were new or what patterns could be reviewed or rated next. The overall feedback from the questionnaires showed the importance of activity visualization for distributed teams in order to keep up the motivation to contribute to the library. The majority of the participants also stated that the approach has a low learning curve and not much time needed to be invested to work with the pattern library. The general appeal of the platform was given and suggestions for improvements were made and should be taken into account for future refinements.

The experimental pursue of the approach ends with the current state of the BRIDGE Pattern Library (http://pattern-library.sec-bridge.eu/pattern-library). Still, the project is running and the library will further accompany it. The results of the survey and the current state of patterns provide confidence in further usage of the platform within the project or adaptations to other settings. User behavior and working phases on the pattern library so far suggest using the pattern library as a project-wide tool. This way, project members can perceive that their contributions are actively maintained, reviewed and consumed.

5 SUMMARY AND FUTURE WORK

This article discusses the challenges for imposing requirements and keeping track of their development over time in the scope of large-scale, spatially distributed exploratory projects. Characteristic to this kind of projects is that dedicated and measurable aims are not completely present at the beginning of the project. Thus, from initial demands or problem statements, requirements evolve over time. In combination with increasing knowledge that is gathered throughout the whole project runtime, gathered requirements may change. According to new findings or intermediate results, existing needs may be discarded and new ones may be formulated. Since the whole project knowledge and its requirements is in permanent flow, a new approach is introduced that combines the iterative and exploratory character of research projects and combines it with the notion of design patterns.

Traditionally, patterns are used to document well-proven solutions such that others can reuse them in order to quickly derive a working solution. Due to their structure that separates the problem context, the problem itself and its solution, the presented approach adds collaborative elements. This allows every stakeholder in the project to take influence on the knowledge encapsulated within a pattern. Similar to the dynamics of knowledge gathered during the project’s runtime, the pattern contents are filled over time. This way, patterns allow all project members to document problems, user needs, edge constraints or traditional requirements within the problem section of a pattern. In classical software engineering, solutions addressing the requirements are inherent within the implementation or documentation. Within the presented process, solutions are tied to the problem statements and equally evolve over time. Additionally, the mechanism allows for evaluating the found solution such that its reliability for reuse is indicated. In case that several solutions are found to a problem, they are all tied to the problem. The approach was implemented within an online pattern library that was used within the FP7 project BRIDGE where it was used for documenting the evolving project knowledge. In total, 43 patterns were formulated so far.

Considerations were taken regarding users’ experience and reputation. Thus, comments and ratings could be weighted stronger. In the prototype presented in Section 4, such mechanisms were left out in order to gather first results with the assumption that all users have the same experience and their feedback has the same weight. Still, concerns remain whether such a competitive feedback mechanism would hinder the knowledge exchange since new members may hold back their ideas since they must fear that stronger feedback that is based on a higher reputation will cancel out their contribution.

Future work will further refine the process and the tool such that larger amounts of patterns can be handled in a better way. Additionally, the focus within projects will be strengthened on formulating requirements and problems as patterns as early as possible. Since the evolving pattern library serves as knowledge foundation for research groups, the approach may be transferred to enterprise environments. Although projects may have a shorter lifetime, the formulated pattern then serve as enterprise knowledge repository spanning clusters of similar projects. This way, enterprise-wide knowledge management is supported. Project teams may use the pattern library for exchanging gathered knowledge, learning from each other and fostering proven solutions.

Further iterations of the prototype (cf. Section 4) need to further address the challenge of users’ long-term motivation. The first concept showed other users’ activities in order to make clear that the currently working user is not the only one who contributes. Since the users of the library may be spatially distributed and live in different time zones, only few users may be visible online at the same time. The prototype also implemented suggestions on what to do next in case users do not intend to contribute a pattern formulation. The mechanism suggested patterns to be rated or commented. Hints on patterns that would benefit from further evidence are intended to raise the user’s interest in further exploring the pattern library.

Acknowledgements

The research leading to these results has received funding from the EU 7th Framework Programme (FP7/2007- 2013) under GA no.261817, the BRIDGE project (www.bridgeproject.eu) within the Security Programme SEC- 2010.4.2-1: Interoperability of data, systems, tools and equipment.

REFERENCES

[1] P. M. Institute, A Guide To The Project Management Body Of Knowledge (PMBOK Guides), 4th ed. Newtown Square, Pennsylvania, USA: Project Management Institute, 2008.

[2] N. Kano, S. Tsuji, N. Seraku, and F. Takahashi, “Attractive Quality and Must-Be Quality,” J. Japanese Soc. Qual. Control, vol. 14, no. 2, pp. 39–44, 1984.

[3] J. A. Goguen and C. Linde, “Techniques for Requirements Elicitation,” Requir. Eng., pp. 152–164, 1993.

[4] N. Maiden and A. Gizikis, “Where Do Requirements Come From?,” IEEE Softw., vol. 18, pp. 10–12, 2001.

[5] B. Rohrbach, “Kreativ nach Regeln - Methode 635,” Absatzwirtschaft, vol. 12, no. 19, p. 73/76, 1969.

[6] E. De Bono, De Bono’s Thinking Course, 1st new. Harlow, GB: BBC Active, 2006.

[7] L. Suchman, Human-Machine Reconfigurations: Plans and Situated Actions (Learning in Doing: Social, Cognitive, and Computational Perspectives), 2nd ed. New York, New York, USA: Cambridge University Press, 2007.

[8] J. A. Hughes, D. Randall, and D. Shapiro, “From Ethnographic Record to System Design: Some Experiences from the Field,” Comput. Support. Coop. Work, vol. 1, pp. 123–141, 1992.

[9] I. Sommerville, T. Rodden, P. Sawyer, R. Bentley, and M. Twidale, “Integrating ethnography into the requirements engineering process,” in Proceedings of IEEE International Symposium on Requirements Engineering, 1993, pp. 165–173.

[10] F. Kensing and J. Blomberg, “Participatory Design: Issues and Concerns,” Comput. Support. Coop. Work, vol. 7, no. 3, pp. 167–185, 1998.

[11] J. Nielsen, “Iterative User-Interface Design,” Computer (Long. Beach. Calif)., vol. 26, no. 11, pp. 32–41, 1993.

[12] C. Snyder, Paper prototyping. Morgan Kaufmann, 2003.

[13] C. Lewis, P. G. Polson, C. Wharton, and J. Rieman, “Testing a Walkthrough Methodology for Theory-Based Design of Walk-Up-and-Use Interfaces,” in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 1990, pp. 235–242.

[14] N. Dahlbäck, A. Jönsson, and L. Ahrenberg, “Wizard of Oz Studies: Why and How,” in Proceedings of the 1st International Conference on Intelligent User Interfaces, 1993, pp. 193–200.

[15] A. Dix, J. Finlay, G. Abowd, and R. Beale, Human-Computer Interaction, 2nd ed. Upper Saddle River, NJ, USA: Prentice Hall Inc., 1998.

[16] C. R. Prause, M. Scholten, A. Zimmermann, R. Reiners, and M. Eisenhauer, “Managing the Iterative Requirements Process in a Multi-National Project using an Issue Tracker,” in 3rd International Conference on Global Software Engineering. IEEE, 2008, pp. 151–159.

[17] C. Alexander, A Pattern Language: Towns, Buildings, Construction. New York, NY, USA: Oxford University Press, 1977.

[18] E. Gamma, R. Helm, R. E. Johnson, and J. Vlissides, Design Patterns. Elements of Reusable Object-Oriented Software. Amsterdam: Addison-Wesley Longman, 1994, p. 416.

[19] J. Tidwell, Designing Interfaces, 2nd ed. Sebastopol, CA, USA: O’Reilly Media, 2011.

[20] J. Borchers, A Pattern Approach to Interaction Design, 1st ed. West Sussex, England: John Wiley & Sons, 2001.

[21] I. Graham, A Pattern Language for Web Usability. London, UK: Addison-Wesley, 2003, p. 304.

[22] D. K. van Duyne, J. A. Landay, and J. Hong, The Design of Sites: Patterns for Creating Winning Websites, 2nd ed. Prentice Hall, 2007.

[23] M. L. Manns and L. Rising, Fearless Change: Patterns for Introducing New Ideas: Introducing Patterns into Organizations. Boston, MA, USA: Addison-Wesley, 2005.

[24] J. O. Coplien and N. B. Harrison, Organizational Patterns of Agile Software Development. Hamilton, NY, USA: Pearson Prentice Hall, 2005.

[25] J. Bergin, J. Eckstein, M. Völter, M. Sipos, E. Wallingford, K. Marquardt, J. Chandler, H. Sharp, and M. L. Manns, Pedagogical Patterns: Advice For Educators. CreateSpace Independent Publishing Platform, 2012.

[26] M. Falkenthal, J. Barzen, U. Breitenbücher, C. Fehling, and F. Leymann, “From Pattern Languages to Solution Implementations,” in PATTERNS 2014, The Sixth International Conferences on Pervasive Patterns and Applications, 2014, pp. 12–21.

[27] A. Cornils and G. Hedin, “Tool Support for Design Patterns Based on Reference Attribute Grammars,” in Proceedings of WAGA’00, 2000.

[28] S. Montero, P. Díaz, and I. Aedo, “A Semantic Representation for Domain-Specific Patterns,” in International Symposium on Metainformatics, Springer-Verlag, 2005, pp. 129–140.

[29] L. Pavlič, M. Heričko, V. Podgorelec, and I. Rozman, “Improving Design Pattern Adoption with an Ontology-Based Repository,” Practice, vol. 33, pp. 189–197, 2009.

[30] J. M. Smith and D. Stotts, “Elemental Design Patterns: A Link Between Architecture and Object Semantics Elemental Design Patterns,” in Proceedings of the 27th Annual NASA Goddard Software Engineering Workshop (SEW-27’02), 2002, pp. 183–199.

[31] A. H. Eden, A. Yehudai, and J. Gil, “Precise Specification and Automatic Application of Design Patterns,” in 12th IEEE International Conference on Automated Software Engineering (ASE’97) (formerly: KBSE), 1997.

[32] T. Erickson, “Lingua Francas for Design: Sacred Places and Pattern Languages,” in Proceedings of the 3rd Conference on Designing Interactive Systems: Processes, Practices, Methods, and Techniques, 2000, pp. 357–368.

[33] G. Meszaros and J. Doble, “A Pattern Language for Pattern Writing,” in Pattern Languages of Program Design 3, R. C. Martin, D. Riehle, and F. Buschmann, Eds. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1997, pp. 529–574.

[34] R. Reiners, An Evolving Pattern Library for Collaborative Project Documentation. Aachen: Shaker, Aachen, 2014.

[35] R. Reiners, I. Astrova, and A. Zimmermann, “Introducing new Pattern Language Concepts and an Extended Pattern Structure for Ubiquitous Computing Application Design Support,” in PATTERNS 2011, Third International Conferences on Pervasive Patterns and Applications, 2011, pp. 61–66.

Dr. René Reiners obtained his diploma in computer-science and doctoral degree of natural sciences from RWTH Aachen University, Germany. For 1.5 years he gained experience in industrial software development at a German IT sub-company of the REWE enterprise. From 2007 - 2013, he worked as a research associate at Fraunhofer FIT. Now he is responsible for project management and coordinating research efforts in the field of user-centered system and application design, human-computer-interaction and knowledge management with design patterns.