Reuse in requirements engineering: Discovery and application of a real-time requirement pattern

Abstract

Abstract. We apply a reuse approach to formally specify system requirements. The approach is based on requirement patterns, which are related to design patterns well-known in object-oriented software development. The focus of this paper is on the application-driven discovery of an interesting, non-trivial real-time requirement pattern, and its subsequent application. In particular, we demonstrate how a given natural language requirement for a real-time system has been transformed into a precise and concise formal specification using real-time temporal logic. Finally, we motivate and illustrate the reuse potential of requirement specifications by a diverse collection of examples.

Vertical Reuse in the Development of Distributed Systems with FDTs

“…There is, for instance, no reason why the pattern idea can not be applied during requirements analysis. In [19], we have introduced the notion of requirement patterns, and have applied them successfully in the area of building automation systems [8,17]. Similar observations hold for frameworks and components.…”

“…In [8], a complete pattern discovery process for a non-trivial requirement pattern is documented. In [17], the degree of reuse is increased by incor-porating object-oriented concepts (class definitions, specialization) and parameterization.…”

“…Example: LAZYREACTION [8]. This pattern captures the result of refining a timed predicate such that the satisfaction of the predicate depends on a number of temporal constraints.…”

“…As a general rule, domain statements and machine statements, taken together, have to imply the requirement statements. All statements are specified using tRTTL, the tailored Real Time Temporal Logic [8]. Composition is directly supported by the concept of composite classes: in FoReST, a composite class is defined by specifying, for each constituent, an attribute that is classified as object, and is associated with a class (see Table 2).…”

“…These timing constraints are formally expressed in the definition, which uses the operator ! ≤ t (delayed implication), a tailored operator of tRTTL [8].…”