Towards Recyclable System Requirements
Ian Alexander
Friedemann Kiedaisch
University of Ulm
(formerly: DaimlerChrysler AG
Research and Technology)
friedemann.kiedaisch@informatik.uni-ulm.de
9th Annual IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS 2002), Lund University, Sweden, April 8-10, 2002
Abstract
With the increasing importance and complexity of software systems in cars, car manufacturers are faced with new challenges: Very large specification documents with a fast growing portion concerning software must be handled by engineers without dedicated backgrounds in computer science.The development must be accompanied by completely new processes. All this is under the pressure to reduce time-to-market and development costs. In this paper we focus on the early phase of software development and describe a planned approach to obtain high quality and well structured requirement specifications by revisiting development artifacts of former similar systems. We present experiences in following this approach with concrete methods, namely introducing Use Cases in this case. Benefits and difficulties with this method will be discussed and future research directions are pointed out.
1. Introduction
Many system development activities do not start on a green field but enhance existing systems. This is especially true for embedded systems which replace and extend functionality that was formerly built in hardware. Typically, these software systems are built in increments, enhancing the functionality from increment to increment. Accordingly, the set of requirements increases, too. Often, however, it is not possible to reuse the implementation of predecessor systems or to extend them, because the new system has to be embedded into a new environment, or it has to use a new technology, or the supplierwho has to realize the system has changed.
In any case, one cannot economically justify repeating the whole RE process for such systems, beginning from generating ideas, via negotiation with various stakeholders until reaching the technical specification. And even if it is repeated, it is doubtful whether the same standard of quality as with the predecessor system will be reached, because the engineers may be careless, unconsciously thinking that they already know all these things. Instead, one should reuse available artifacts and intermediate results of the predecessor development cycle, e.g. specification documents but also high-level information structures, such as goals, conceptual models, and decision trees.
The result will reach a higher degree of quality, as the engineers are rethinking and improving the artifacts. It may take some time before you will recognize a significant saving of time or effort in the requirements phase of the development cycle, because the engineers have to get used to a new process, new documenting standards or new tools in general. But there will be a substantial gain in quality as the specification matures, i.e. expensive rework and correction in later phases of the development cycle are reduced.
In general, DaimlerChrysler’s development departments do not build such systems themselves, but order them from suppliers. This means the specification document is the real and only result of requirements activities. It is the basis of the contract with the supplier. The next intermediate results of development the DC engineers will see, are samples of the finished system. For that, we have a really substantial need to achieve high quality within these documents!
In fact, some kind of "reuse" is already done in practice but in an unsystematic, low-level manner. Normally, the engineers partially copy the old wording of requirements but do not think about dependencies between them and those that were not copied. The engineers do not or cannot verify whether the decisions that caused the existing wording are still true. They have no idea how to enhance the old specification or to integrate new features without introducing new inconsistencies and errors.
This means that there are big specification documents, increasing over time, accumulating a lot of details that are often overspecified. With every revision inconsistencies may be introduced. In addition, these documents are typically written on a very technical level and do not provide an adequate introduction or overview to the system, that may help readers to get familiar with the system. Often even the people in charge get lost in detail.
2. Reasons for believing that Use Cases might offer a solution
There might be many feasible approaches to solving the problem of recycling requirements. We felt that Use Cases were an especially promising approach.
Firstly, they tell a clear and simple story – what germans call the ‘Roter Faden’, the essential ‘red thread’ to guide you through the forest – in the form of scenarios. Secondly, they present clear goals. Thirdly, they create a functional overview of the purpose and behaviour of a system. Fourthly, they demand and enable systematic search for exceptions, critical in specifying highly reliable systems. Fifthly, since Use Cases often form the basis of test cases, recycling at Use Case level may make test planning more efficient.
Finally, their relatively high level offers the hope that they may remain rather stable over time, while more detailed specifications may well have to change as technologies and subsystems evolve – for example the encoding of messages on a car’s communications bus can change quite rapidly, whereas goals like locking the car and adjusting the seats seem unlikely to go away.
3. An experiment with Use Cases
DaimlerChrysler engineers prepare detailed specifications in sufficient detail to form the basis of contracts with subsystem suppliers. An artificial example of such a specification, carefully constructed to resemble a real subsystem document without giving away commercially-sensitive information about new models of car, is the Door Control Unit or Türsteuergerät (TSG) specification [15].
We chose Alistair Cockburn’s template [8] for Use Cases. This broadly resembles the templates of [22] as well as of the Rational Unified Process [20]: it provides for a Goal, Primary Scenario, Alternative Paths, Extensions, Triggers, Preconditions, Stakeholders and their Interests in the system, as well as Minimal and Success Guarantees (i.e. Postconditions). We made just two changes that seemed to us necessary for an application to systems engineering. We replaced ‘Extensions’ with Exceptions, to describe the handling of events that interrupt progress towards the goal of a Use Case: such events are generally experienced as exceptions in system operation. We also added a section of (local) Constraints within each Use Case, to cover any non-functional requirements that applied specifically to one Use Case. Global Constraints we cover as usual in a separate chapter. The resulting template was entered into the Scenario Plus toolkit for use with the DOORS requirements tool [29, 13]. Other sections (such as Threats) could readily be incorporated simply by editing the template.
The Use Case goals were identified from the TSG specification functions. The primary scenarios were written by examining the functional descriptions and assessing what was at user level and what constituted design detail: the TSG specification essentially combined information from several levels of detail, right down to the assignment of hexadecimal codes to messages. It was generally clear what should go into the Use Cases, though some issues such as diagnosis required more careful consideration.
4. Findings
The TSG Use Cases were quite simple to write. A few small mysteries were posed by domain-specific terms, and one or two more by technical German words (like Schnittstelle, interface) that were not in ordinary dictionaries. This simplicity stemmed from the fact that the TSG specification was clear and well-written, with a good overview and a sensible breakdown of the functions which at chapter level could essentially be reused directly as the goals (titles) of the Use Cases. It was also not too large and complex. Real specifications are expected to require more effort to understand, to write, and to validate: where they are unclear, it will be necessary to conduct interviews and workshops to reverse-engineer the Use Cases that they represent. Of course, if future requirements are written as Use Cases then reverse engineering will not be needed. Once constructed in DOORS / Scenario Plus, the Use Cases are easy to navigate. The Use Case toolkit draws a summary diagram (shown below) automatically, using information about the Actors, Use Cases, and relationships between them. The diagram itself can be used to navigate directly to Actor or Use Case definitions; links representing ‘includes’ and ‘has exception’ relationships between Use Cases can also be followed by pointing and clicking with the DOORS user interface.
Figure 1: Navigable Use Case Summary Diagram Prepared by Scenario Plus.
The user interface permits rapid selection (by filtering) of items of interest, such as all the exceptions, or all the primary scenarios, or undefined steps. Relationships between items, such as the ‘acts in’ relationship between actors and Use Cases, can be explored directly by point-and-click navigation as well as by displaying traceability-type columns to show who acts in each Use Case and which scenario steps include other Use Cases.
Initially we found ourselves lacking an easy way to read the Use Case model outside the DOORS environment. Neither the standard Word export nor the HTML export produced the kind of document that we felt we needed. It turned out to be a matter of only two days’ work to construct a hypertext export tool which built a simple but elegant hypertext of the entire model, essentially just by walking the Use Case document tree.
A table of contents frame is constructed from the top 2 or 3 levels of the DOORS heading structure in a narrow frame on the left. Detail is shown only for the current chapter; other chapters are collapsed.
The lower-level subtree structures are displayed as pages with headings, subheadings, text and embedded diagrams in the main frame on the right. Links are displayed along with their types (e.g. ‘acts in’, ‘includes’) as hyperlinks immediately after the text of their source objects. (It would be simple to provide reverse links if desired – DOORS links may be followed in either direction). Everyone in the project was happy with the result.
Figure 2: Example for the hypertext version of the Use Case description
DaimlerChrysler engineers are accustomed to working with paper specifications, because it is the most common interface between them and the suppliers. The use of dedicated requirements management tools with shared contend between DC and suppliers is just in its infancy. The result of printing out a Use Case model – a linear document – is visibly less easy to understand and explore than either a requirements database or a hypertext. The task of identifying and creating appropriate paper representations of aspects of a Use Case model of interest to different stakeholders appears to us an interesting research agenda. DOORS makes it a simple matter to design and implement any desired view, so the question is what combination of output views or aspects would be helpful to each kind of consumer of Use Cases. Of course, if the end result of adopting a Use Case-driven systems engineering approach is that engineers habitually browse Use Case models in DOORS or hypertext when seeking to recycle requirements, then there will be no problem to solve within the company, though the issue may remain interesting outside it.
5. Towards recycling
The described experiment with Use Cases was one step in a more widespread research activity [16, 17, 18]. The goal of this long term work is to enable recycling of requirements. We do not like the expression "reuse" in this case, because it is occupied by approaches known e.g. from software reuse [14, 21], that are dealing with component libraries that contain highly formalized components. This implies a high effort in making components reusable and the need of sophisticated retrieval mechanisms to find candidates for reuse. We hope this formal effort is unnecessary for our domain, where we are dealing with a manageable number of artifacts, even though they may be voluminous. Instead, we want to gain every possible benefit of the results of former development activities, by using their results as they are. This is what we want to express by "recycling" instead of "reuse".
There have been research activities on requirements reuse before, e.g. [9-11]. [23] distinguishes three approaches:
Analogy or Similarity between specifications (e.g. [12, 24-27, 30]) will be helpful for reusing former development results in the new development cycle later on. But we do not see how such analysis will support writing a specification document itself.
Attributing cases and searching for them, as proposed by [1, 4] is a library approach as mentioned above and rejected for our situation.
Generating specifications from domain models (e.g. [7]) as a part of a product line approach [2, 5, 6, 28] is a fascinating idea, but far away from the current state of technique at DaimlerChrysler Development. It has to be regarded as a very long term goal.
All this approaches are very interesting. But in order to support the people at DaimlerChrysler Development in their current work and meet them at their present abilities and possibilities, we have to start more low-level.
5.1 The framework
Before studying possibilities how Use Cases can support recycling of requirements, we should state our position about requirements recycling:
We distinguish three logical steps, named archaeology, preparation and recycling in a narrow sense (see Figure 3). These steps are not thought to be separate tasks, as in most cases you will do archaeology and preparation simultaneously.
The requirements base is not necessarily a database: it might also be a (couple of) specification document(s) prepared according to a suitable structure or model.
The actual recycling step comprises finding suitable parts in the base as well as adopting and integrating them into the new document. But unlike reuse approaches known from e.g. software reuse, we do not have to deal with sophisticated retrieval mechanisms in order to find a component in a library that contains many things we do not need. Instead we suggest simply browsing the contents of predecessor system releases arranged in a tree-like structure (see Figure 4). We can then pick the nodes we need, and if applicable, we get the leaves below, representing the next level of detail, for free.
Figure 3: Logical steps in requirements recycling The activities described in the Experiment section are mainly dedicated to the preparation step, but there was also a archaeology component: When writing the Use Cases we did a kind of reverse engineering to find out what was written in the specification documents and what might be the reason behind it. But the Use Cases cannot be the only result. In the preparation step there is also the need for establishing proper relationships between this Use Cases and the technical details in the specification document.
In accordance with [3, 19] we distinguish horizontal and vertical links. The vertical links relate different levels of abstraction and represent refinement steps. They are expected to build the backbone of the supposed tree structure (see Figure 4). Obviously the mentioned relationships between Use Cases and technical details belong to this kind of links. Horizontal links connect pieces of the same abstraction level and represent mutual dependencies or interference.
The resulting structure for the requirements base is the goal of further research, but the direction is quite clear: Introducing Use Cases establishes a more abstract level above the technical requirements, which often merge into design or interface description. This offers a new starting point for recycling activities. The Use Cases themselves are not supposed to change completely over the evolution of system releases. There may be extensions or minor revisions but in generally they are expected to be highly stable. Thus they are themselves strong candidates for recycling, when a new specification is developed. In addition, they support recycling of system requirements. Assuming that accurate traceability was established between Use Cases and requirements by means of links of high quality as regards completeness and consistency, the recycling of Use Cases naturally points out the relevant parts of the requirements specification to be recycled. Obviously, the job is not done by simply copying these parts of the old specification document. In fact the requirements have to be checked and edited carefully. One has to examine all the horizontal traces that point outside the current branch to make sure that there remain no inconsistencies and all dependencies have been taken into account (see Figure 4).
But coming from Use Cases, you have access to packages of requirements that are strongly interrelated by content. This means most traces are within the current branch. If you recycle the whole branch, you do not have to deal with them. So you can concentrate on the few outgoing links and handle them with adequate attention. That guides the revision process for a specification document in a manner that helps the author to take into account the dependencies between requirements and to avoid inconsistencies that result from not editing all relevant points.
Figure 4: Sketch for levels of abstraction in a specification document
vertical traces/refinements are drawn as red arrows, horizontal traces/dependencies as teal lines, recycling possibilities as blue arrows, implementation as dotted arrows
5.3 Challenges and benefits
Obviously there is some effort to be made when introducing the Use Case approach. At first sight, it is an additional task to write the Use Cases and set up the relations to the other documents. But people not only have to spend time to do this task, they also have to learn and be trained in a new method, comprising a notation and probably a tool, as well as another way of thinking about the problem. This implies that people have to be convinced of the Use Case approach.
To achieve this, one has to state clearly the benefits of the approach. As already indicated in the Findings section, Use Cases help people to get started and give a helpful overview. They reduce the danger of losing the plot, but they also help in identifying aspects like stakeholders and exceptions that would probably have been forgotten when working only at a very technical level. This is important for writing new requirements, and essential when advancing an existing system based on an available specification document.
In our example the expected benefits were not particularly large, but on the other hand there was not too much effort spent. This is probably because the example specification was already in a good condition and did not feature all the shortcomings mentioned in the introduction. Therefore, we predict that for a real system there will be a higher hill to climb in order to get the approach working, but in return there should be more benefits gained as well, because people will recognize a significant difference between the two products.
In order to underpin those arguments, needed for introduction of the approach, we are carrying out a empirical experiment with students at the University of Ulm. The results of the experiment will hopefully confirm the expected benefit.
6. References
[1] Klaus-Dieter Althoff, Andreas Birk, Christiane Gresse von Wangenheim, Carsten Tautz: Case-Based Reasoning for Experimental Software Engineering, IESE Report No. 063.97/E, Kaiserslautern, Germany, 1997.
[2] K. Suzanne Barber, Thomas J. Graser, Stephen R. Jernigan, Brian J. McGiverin, Srini Ramaswamy: "Enterprise-wide Requirements Reuse and Evolution Using The Systems Engineering Process Activities Methodology (SEPA)" in AJIS Special Edition 1999 – Requirements Engineering, University of Wollongong
[3] J.Z. Bedocs Jr.: "A Data Architecture for DOORS Projects"; InDOORS 1999, http://www2.telelogic.com/doors/index.cfm
[4] R. Bellinzona, M. G. Fugini, V. de Mey: "Reuse of Specifications and Designs in a Development Information System" in Proceedings of the IFIP WG 8.1 Conference on Information System Development Process, Como, Italy, 1993.
[5] Jan Bosch: Design & Use of Software Architectures – Adopting and evolving a product-line approach. Addison-Wesley, London, 2000.
[6] Regina M. M. Braga, Cláudia M. L. Werner, Marta Mattoso: Odyssey: "A Reuse Environment based on Domain Models" in Proceedings of IEEE Symposium on Application-specific Systms and Software-Engineering Technology (ASSET’99), Richardson, Texas, 1999.
[7] S. Castano, V. De Antonellis: "Reuse of Conceptual Requirement Specifiactions" in Proceedings of IEEE International Symposium On Requirements Engineering (RE’93). San Diego, California, 1993.
[8] Alistair Cockburn: Writing Effective Use Cases, Addison-Wesley 2001
[9] Jacob L. Cybulski, Karl Reed: "Requirements Classification and Reuse: Crossing Domain Boundaries" in Proceedings of the 6th International Conference on Software Reuse, Vienna, June 2000.
[10] Jacob L. Cybulski: "Reusing Informal Requirements: Review of Methods and Techniques", in Proceedings of the 1st Australian Requirements Engineering Workshop, (ARE’96). Monash University, Caulfield Campus, Australia, Sept. 1996.
[11] Jakob L. Cybulski: "Reuse of Early Life-Cycle Artefacts: Reusing Requirements with a Word Processor?" in Proceedings of WISR‘8, Ohio State University, March 1997.
[12] Jakob L. Cybulski: Application of Software Reuse Methods to Requirements Elicitation from Informal Requirements Texts. Dissertation, La Trobe University, Bundoora, Australia, March 2001.
[13] DOORS:
http://www.telelogic.com[14] W.B. Frakes and C.J. Fox: "Sixteen questions about software reuse". Communications of ACM, 38(6): 75-87, June 1995.
[15] Frank Houdek: TSG, Türsteuergerät, (in German) Technical Report, University of Ulm, Ulm 2002.
[16] Friedemann Kiedaisch: "Systematic Requirements Recycling" in Proceedings of the RE’01 Doctoral Workshop in associaton with 5th IEEE International Symposium on Requirements Engineering, Toronto, Canada, August 2001.
[17] Friedemann Kiedaisch, Martin Pohl, Joachim Weisbrod, Siegfried Bauer, Stefan Ortmann: "Requirements Archaeology: From Unstructured Information to High Quality Specifications" in Proceedings of the 5th International Symposium on Requirements Engineering (RE’01), Toronto, Canada, August 2001.
[18] Friedemann Kiedaisch, Martin Pohl, Joachim Weisbrod, Siegfried Bauer, Stefan Ortmann: "Experiences on Outsourcing Requirements Specifications" in Proceedings of the European Software Process Improvement Conference (EuroSPI’2001), Limerick, Ireland, October 2001.
[19] D.P. Kirkman: "Requirements Decomposition and Traceability": Journal of Requirements Engineering, vol. 3: 107-114, 1998.
[20] P. Kruchten: The Rational Unified Process – an Introduction, Addison-Wesley 2000.
[21] C.W. Krueger: "Software reuse". ACM Computing Surveys, 24(2): 131-183, 1992.
[22] D. Kulak and E. Guiney, Use Cases: Requirements in Context, ACM Press 2000.
[23] W. Lam, J.A. McDermid and A.J. Vickers: "Ten Steps Towards Systematic Requirements Reuse" in Requirements Engineering Vol. 2(2):102-113, Springer, 1997.
[24] Axel van Lamsweerde: "Goal-Oriented Requirements Engineering: A Guided Tour" in Proceedings of the 5th International Symposium on Requirements Engineering (RE’01), Toronto, Canada, August 2001.
[25] N. Maiden: Analogical Specification Reuse During Requirements Analysis. PhD Thesis, City University London, July 1992.
[26] Philippe Massonet, Axel van Lamsweerde: "Analogical Reuse of Requirements Frameworks" in Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE‘97), Annapolis, USA, 1997.
[27] Johan Natt och Dag, Björn Regnell, Pär Carlshamre, Michael Andersson, Joachim Karlsson: "Evaluating Automated Support for Requirements Similarity Analysis in Market-Driven Development" in Proceedings of Seventh International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ’01), Interlaken, Switzerland, 2001.
[28] Paolo Predonzani, Giancarlo Succi, Tullio Vernazza: Strategic Software Production with Domain-Oriented Reuse. Artech House, Boston, 2000.
[29] Scenario Plus:
http://www.scenarioplus.org.uk[30] George Spanoudakis, Panos Constantopoulos: "Analogical Reuse of Requirements Specifications: A Computational Model" in Applied Artificial Intelligence: An International Journal, Vol. 10(4), 1996.
More Papers, Consultancy and Training on
Ian Alexander's Home Page