A clear understanding of the relationships between requirements and architecture
structures is important for several reasons. First, because in any system
there is a need for architectural stability in the face of changing requirements.
Requirements inevitably change over time because of a changing system environment
and user needs, but a stable architectural foundation is essential for system
dependability. Second, because a reliable development method must be able
to proceed from initial requirements to developed software in a systematic
way: at the end of the development process it must be clearly demonstrable
that the implementation satisfies the requirements. Third, because many systems
are feature-based: they either evolve by adding commercially significant
increments of function, or belong to product families whose members share
a common functional base and differ in the additional features they offer.
For feature-based systems, it is particularly important to maintain a coherent
mapping between user features and software modules. Adding a new feature
often 'breaks the design': that is, it undermines, in ways that are understood
neither well enough nor early enough, the assumptions implicit in the software
structure that implements existing features. Moreover, features also interact
at the requirements level, making it difficult to understand what behaviour
should be expected when different features are combined. We propose to investigate
the initial development and subsequent maintenance of the relationship between
software architectures and the structures of functional requirements that
they support. Essentially, our goal is to understand how user functions,
or features, can be systematically mapped to software modules, and vice versa,
and to make that mapping a practical intellectual tool in software development
and maintenance, both in forward and in reverse engineering.
Aims and objectives
The overall aim of this project is to investigate and exploit the relationship
between software architectures and the structures of functional requirements
that they support. We will therefore study the relationships between problem
structures and solution structures. The specific objectives of the project
are to:
investigate the correspondence between problem frames and features,
in order to capture features as problem frames, and reason about feature interaction
through problem frame composition;
develop practical techniques to identify and exploit matches between
problem and solution structures and, where appropriate, to understand the
cause of absence of a match;
validate the approach through its application to significant case studies.
Description of proposed research and its context
The Problem
It is now widely recognised that incremental or evolutionary development
of software is the rule, not the exception: even where evolution was not
initially envisaged by the developers, it is necessitated by feedback from
customers and users, by evolving requirements, and by competitive market
pressures. The evolutionary dimension highlights the need for clarity in
the relationship between changing customer requirements and a stable yet
maintainable system structure.
We propose to investigate the initial development and subsequent maintenance
of the relationship between software architectures and the structures of
functional requirements that they support. Essentially, our goal is to understand
how user functions, or features [18], can be systematically mapped to software
modules, and vice versa, and to make that mapping a practical intellectual
tool in software development and maintenance, both in forward and in reverse
engineering. This cannot be a simple one-to-one mapping in which each feature
is implemented by one module. Except for some special cases, such a simplification
is tenable only for a very small class of trivial systems, and takes
no account of the complexity of realistic systems that provide realistic
functionality. Further, we do not expect forward engineering in this manner
to result in homogeneous architectures: different features will give rise
to different local architectures, so their composition will be architecturally
heterogeneous (For example, having some parts in a pipe-and-filter style,
some in a blackboard style, and some in a layered style¾it then becomes
necessary to compose these heterogeneous parts to achieve solution of the
whole problem.)
Importance of the Problem
Clear understanding of this relationship between requirement and architecture
structures is important for several reasons. First, because in any system
there is a need for architectural stability in the face of changing requirements.
Requirements inevitably change over time because of a changing system environment
and user needs, but a stable architectural foundation is essential for system
dependability. Second, because a reliable development method must be able
to proceed from initial requirements to developed software in a systematic¾but
not necessarily monotonic¾way: at the end of the development process
it must be clearly demonstrable that the implementation satisfies the requirements.
Third, because many systems are feature-based: they either evolve by adding
commercially significant increments of function, or belong to product families
whose members share a common functional base and differ in the additional
features they offer. For example, web publishing or XML output may be added
to a word processor, an authentication scheme to a co-operative editing system,
customer profiling to an e-commerce system, or a large-scale conferencing
feature to a telephone switching system.
For feature-based systems, it is particularly important to maintain a coherent
mapping between user features and software modules, both for the more general
reasons given earlier and as an aid to addressing the feature interaction
problem [19, 20]. The feature interaction problem, well known in telephony,
has two visible aspects. One is that adding a new feature often ‘breaks the
design’: that is, it undermines, in ways that are understood neither well
enough nor early enough, the assumptions implicit in the software structure
that implements existing features. The other is that features interact also
at the requirements level, making it difficult to understand what behaviour
should be expected when different features are combined [21].
Existing Approaches
Traditional approaches [22-24] have treated requirements informally, expressing
them purely in natural language within an entirely informal structure. The
resulting loose grip on the requirements precludes a clear mapping to software
modules. At the other extreme, some researchers, and many practitioners,
have aimed at seamless processes of refining requirements to software design,
in which the software structure is derived stepwise from the requirements
structure [25-27]: for example, in [27] a development process is suggested
in which the class structure is established at the early analysis stage.
Such a refinement process may succeed in many cases, but it does not comfortably
handle feature composition. The class clusters of [27], for example, are
primarily an organisational tool, and can not be identified with features.
Goal-based approaches can address both functional and non-functional requirements.
The non-functional aspects [28, 29], although crucially important, are beyond
the scope of the work we propose. On the other hand, the goal-driven requirements
engineering approach of KAOS [30] does provide an important form of problem
structuring, but we consider it inadequate in two respects: first, goal structuring
is liable to conceal a feature-based structure of requirements; and second,
it does not provide a sound basis for understanding incremental development
as it does not make a distinction between identifying and solving problems
and addressing the composition of the subproblems and their solutions.
In the work on design patterns [31, 32] each pattern is related to a briefly
stated problem; but the focus of the work is on small-scale solution structures.
Design patterns do raise the level of granularity above that of individual
object classes, but not high enough to correspond to deliverable features.
Framework [33] are on a larger scale, but a framework corresponds to a tailorable,
partially implemented system rather than to a feature that can be configured
with other features. Similarly, Fowler’s analysis patterns [34] offer one
of the few approaches to identifying recurring problems. However, like design
patterns, while they do raise the granularity of the problem above programming
problems [35], they are not high enough to correspond to deliverable features.
In contrast, problem frames [6] can be seen as a form of problem pattern,
with problems of varying degrees of complexity being addressed by collections
of problem frames, represented collectively in a problem diagram.
Most work on the relationship between requirements and software architecture
has focused on architecturally driven approaches [36, 37]. For example, Shaw
and Garlan’s notion of architectural styles offers intriguing possibilities
of relating such styles to the problem world, however, this is never explored,
and architectural styles remain, at best, general architectural design patterns.
Their early work on ADLs (Wright) is important in providing an abstract notion
of connectors and enabling corresponding tool support. Additionally, their
work on the Acme ADL provides a form of meta-ADL, in which multiple architectural
styles can be supported and integrated. Their work extends the utility of
architectural support, but does not show directly how to move between requirements
and architecture. An exception is the CBSP approach [38], which bridges the
gap between requirements and architecture by a process in which individuals’
functional requirements are judged to entail architectural choices. There
are certain similarities between the CBSP approach and the approach we propose.
But we believe that the very lightweight notion of a requirement in CBSP
makes it difficult to be explicit about the finer-grain relationships to
architectures. Further, the CBSP work pays little attention to the composition
of subproblems, and the associated concerns. We regard composition as a fundamental
aspect, corresponding as it does to the issues surrounding feature interaction.
In recent years, domain engineering research [39] has regained momentum in
the context of software product line development [40]. While the development
of product lines is precisely the kind of application area for our proposed
work¾indeed it is a one of the drivers of our research¾domain
engineering research has not offered the kinds of domain abstractions [41,
42] that are needed to relate problem to solution structures promised by
earlier work [43].
In summary, existing approaches have not succeeded to anything like the extent
needed: moving between functional requirement structures and software architectures
is still a difficult, obscure, and error-prone journey in both directions.
Using Problem Frames
The approach we propose will be based on the use of problem frames [6], extending
and broadening work we have already done in this area [1, 2, 10]. A problem
frame captures a class of small and simplified application problems that
are well understood: for example, transforming a lexical input (such as a
source program) to a lexical output (a machine-code program); or controlling
a part of the real world (such as the throttle of a motor-car) in response
to an operator’s commands; or providing timely information about some part
of the world (such as information about constantly changing prices in a stock
exchange). Problems of realistic scale are decomposed into subproblems, each
fitting a known problem frame. Initially, each subproblem is treated as a
pure instance of the simplified frame it fits, allowing the analysis and
design knowledge associated with the frame to be directly applied to its
characteristic problem concerns.
This initial decomposition intentionally ignores the composition concerns
that arise from inter-subproblem relationships. These composition concerns
may be trivial—for example, two orthogonal subproblems may demand no more
than simple conjunction for their composition—or they may give rise to fresh
subproblems in their own right. For example, two subproblems with rich interactions
may demand an explicit scheduler to control their execution, and possibly
an explicitly designed data structure to mediate their interactions. To take
another example, two subproblems may have conflicting requirements and must
be placed in an environment in which one takes priority over the other. (It
is worth observing, incidentally, that such priority can be more easily implemented
in a pipe-and-filter architecture than, for example, in a blackboard architecture.)
The Value of Problem Frames
The value of problem frames for our proposed work is that they bring together
requirements concerns and software structure concerns at a useful intermediate
level of abstraction and granularity. We believe that features, that is,
commercially and practically useful increments of functionality¾can
be shown to correspond closely to subproblems. Each problem frame has essentially
three parts: a problem domains part, corresponding to the part of the world
where the problem is located; a requirement part, corresponding to the behaviour
that the customer demands in the problem domain; and a machine part, corresponding
to the software/hardware machine that will ensure that the requirement is
satisfied.
For example, Figure 1 shows the problem frame for simple Information Display
problems. There are two problem domains: the Real World, about which information
is required, and the Information Display, where the information must be shown.
There is a machine, here called the Display Machine. And there is a requirement,
in this case a stipulation that the data of the Display must correspond in
a certain way to the state of the Real World. The annotations on the connecting
lines indicate the phenomena concerned and their locus of control: for example,
the interface between the Display Machine and the Information Display is
controlled by the Display Machine. The emphasis on a clear distinction between
the problem domains and the hardware/software machine to be built is particularly
important: functional requirements are always about the problem domains and
the effects produced there by the machine.
Figure 1: Simple Information Display Problem Frame
The initial decomposition into subproblems is therefore a structuring of
the overall requirements into subproblem requirements: we believe that these
will be found to correspond to features. At the same time it is a decomposition
of the software into subproblem machines, corresponding to a tentative identification
of the system’s software modules. Additional modules arise from the subproblems
introduced to address composition concerns. The resulting modular structure
is subject to further systematic perturbations, including some forms of what
is currently known in the object-oriented community as refactoring [44],
to produce the final software architecture.
Benefits of Success
If our work, based on this approach, is successful, it will allow us to present
a coherent view of the relationship between functional requirements and architectures,
and a coherent practice of both forward and reverse engineering. The relationship
between requirements and architectures is not a simple mapping between function
types and architectural styles; rather, it arises from the concerns of composing
heterogeneous features. The forward engineering practice can contribute substantially
to a reliable approach to software development, starting from a sound identification
of separately implementable features in a large body of requirements and
arriving at a software architecture. The reverse engineering practice is
advantageous for two reasons. First, because software development is inevitably
iterative: developers must be able to move easily between deriving software
architecture from requirements and identifying the constraints that architectural
choices already made place on the requirements that can be supported. Second,
because maintenance of existing software by addition of functional increments
demands a clear analysis of the compatibility, or incompatibility, between
the existing architecture and the proposed new function.
Methodology
Methodologically, we hope to validate a number of hypotheses on which the
approach is based. In practice, because no approach to software development
can be universally valid, this will mean identifying the ranges within which
such hypotheses are valid. The hypotheses to be validated are these:
Problem frames correspond closely to desirable increments of functionality
that can be considered as requirement units and hence as deliverable features.
We call this frame-feature mapping.
Practical architectures can be understood as modifications and elaborations
of a simple initial design in which one software module is assigned to each
subproblem machine. We call this subproblem-module mapping.
Feature interaction can be understood in terms of the composition of
problem frames, and the combined requirement can be clarified and refined
by exploring these interactions at the problem frame level. We call this
interaction-by-frames.
Concerns arising in the composition of subproblems and of their solutions
can be usefully seen as partial requirements for the resulting architectures.
We call this architecture-as-composition.
We will use case studies in the development and validation of the approach.
The case studies will be taken from our industrial collaborators and publicly
available open source and COTS products. They will be used to identify features
and functional increments, to specify problem frames and software architectures,
to analyse their relationships, and to test our hypotheses.
References
Hall, J., M. Jackson, R. Laney, B. Nuseibeh, and L. Rapanotti, "Relating
Requirements to Architectures Using Problem Frames", Proc. of 10th IEEE Int.
Requirements Engineering Conference (RE'02), 9-13 Sept 2002, Essen, Germany.
Rapanotti, L., J. Hall, M. Jackson, and B. Nuseibeh, "Architecture-Driven
Problem Decomposition", in 12th International Requirements Engineering Conference
(RE'04), 2004, Kyoto, Japan, IEEE Computer Society Press.
Nuseibeh, B. and S. Easterbrook, "Requirements Engineering: A Roadmap",
in ICSE-2000 Future of Software Engineering, 2000, Limerick, Ireland, ACM
Press.
Nuseibeh, B., S. Easterbrook, and A. Russo, "Leveraging Inconsistency
in Software Development", in IEEE Computer, April 2000, 33(4): 24-29.
Nuseibeh, B., "Weaving Together Requirements and Architectures", in
IEEE Computer, March 2001, 34(3).
Jackson, M., Problem Frames: Analysing and Structuring Software Development
Problems, 2000: Addison-Wesley.
Jackson, M. and P. Zave, "Distributed Feature Composition: A virtual
architecture for telecommunications services", in IEEE Transactions on Software
Engineering, October 1998, 24(10):831-847.
Hall, J., L. Rapanotti, and M. Jackson, "Problem frame semantics for
software development", Software and Systems Modeling, to appear, 2004.
Barroca, L., J. Hall, and P. Hall, eds. Software Architectures - Advances
and Applications. 2000, Springer-Verlag.
Laney, R., L. Barroca, M. Jackson, and B. Nuseibeh, "Composing Requirements
Using Problem Frames", in 12th International Requirements Engineering Conference
(RE'04), 2004, Kyoto, Japan, IEEE Computer Society Press.
Hall, J. and L. Rapanotti, "A Reference Model for Requirements Engineering",
in Proceedings of 11th IEEE International Requirements Engineering Conference
(RE'03), September 2003, Monterey, USA.
Haley, C.B., R.C. Laney, and B. Nuseibeh, "Using Problem Frames and
Projections to Analyze Requirements for Distributed Systems", in Proceedings
of the Tenth International Workshop on Requirements Engineering: Foundation
for Software Quality (REFSQ'04), 7-8 Jun 2004, Riga, Latvia: Essener Informatik
Beiträge.
Haley, C.B., R.L. Laney, J.D. Moffett, and B. Nuseibeh, "The Effect
of Trust Assumptions on the Elaboration of Security Requirements", in 12th
International Requirements Engineering Conference (RE'04), 2004, Kyoto, Japan,
IEEE CS Press.
Bush, D. and A. Finkelstein, "Requirements Stability Assessment Using
Scenarios", in Proceedings of 11th IEEE International Requirements Engineering
Conference (RE'03), September 2003, Monterey, USA.
Hammond, J., R. Rawlings, and A. Hall, "Will it work?" in Proceedings
of 5th IEEE International Symposium on Requirements Engineering (RE'01),
August 2001, Toronto, Canada.
Magee, J., J. Kramer, B. Nuseibeh, D. Bush, and J. Sonander, "Hybrid
Model Visualization in Requirements and Design: A Preliminary Investigation",
Proc. of 10th IEEE Int. Workshop on Software Specification & Design,
Nov. 200l, USA.
Robertson, S. and J. Robertson, Mastering the Requirements Process,
1999: Addison-Wesley.
Turner, C.R., A. Fuggetta, L. Lavazza, and A.L. Wolf, "A Conceptual
Basis for Feature Engineering", Journal of Systems and Software, December
1999, Elsevier, 49(1): 3-15.
Calder, M. and E. Magill, eds. Feature Interactions in Telecommunications
and Software Systems VI. 2000, IOS Press.
Hay, J.D. and J.M. Atlee, "Composing Features and Resolving Interactions",
in ACM International Symposium on the Foundations of Software Engineering
(FSE), November 2000, 110-119, San Diego, USA.
Zave, P., "Requirements for Evolving Systems: A telecommunications
perspective", in Proceedings of the 5th IEEE International Symposium on Requirements
Engineering (RE'01), August 2001, 2-9.
Alexander, I., "Capturing Requirements with DOORS", in Proceedings
of the 5th IEEE International Symposium on Requirements Engineering (RE'01),
August 2001, page 264.
Hull, E., K. Jackson, and J. Dick, Requirements Engineering: A Structured
Project Information Approach, 2002: Springer.
Thayer, R.H. and M. Dorfman, eds. System and Software Requirements
Engineering. 1990, IEEE CS Press.
Corradini, F., P. Inverardi, and A. Wolf, On Relating Functional Specifications
to Architectural Specifications: A Case Study, Technical Report CU-CS-933-02.
June 2002, Dept. of Computer Science, University of Colorado, USA.
Jacobson, I., G. Booch, and J. Rumbaugh, The Unified Software Development
Process, 1999: Addison-Wesley.
Meyer, B., Object-Oriented Software Construction, Second Edition, 1997:
Prentice-Hall.
Yu, E. and J. Mylopoulos, "Towards modelling strategic actor relationships
for information systems development - with examples from business process
reengineering", Proc. of 4th Workshop on Information Technologies & Systems,
1994.
Yu, E., "Towards modelling and reasoning support for early-phase requirements",
in Proceedings of the 3rd IEEE International Symposium on Requirements Engineering
(RE'97), January 1997, Annapolis, USA.
Lamsweerde, A.v., "Goal-Oriented Requirements Engineering: A Guided
Tour", in Proceedings of the 5th IEEE International Symposium on Requirements
Engineering (RE'01), August 2001, 249-261.
Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stahl,
Pattern-Oriented Software Architecture: A System of Patterns, 1996: John
Wiley.
Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Object-Oriented Software, 1994: Addison-Wesley.
Fayad, M., D. Schmidt, and R. Johnson, eds. Implementing Application
Frameworks: Object-Oriented Frameworks at Work, 1999, Wiley.
Fowler, M., Analysis Patterns: Reusable Object Models, 1996: Addison-Wesley.
Coplien, J., Multi-paradigm Design for C++, 1999: Addison-Wesley.
Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice,
1998: Addison-Wesley.
Shaw, M. and D. Garlan, Software Architecture: Perspectives on an Emerging
Discipline, 1996: Prentice-Hall.
Grünbacher, P., A. Egyed, and N. Medvidovic, "Reconciling System
Requirements and Architectures: The CBSP Approach", in Proc. of the 5th IEEE
Int. Symposium on Requirements Engineering (RE'01), August 2001, 202-211.
Ardis, M.A. and J.A. Green, "Successful Introduction of Domain Engineering
into Software Development", in Bell Labs Technical Journal 3(3), July-September
1998, 10-20.
Weiss, D. and C.T.R. Lai, Software Product Line Engineering, 1999,
Reading, MA: Addison Wesley.
Sutcliffe, A. and N. Maiden, "The Domain Theory for Requirements Engineering",
IEEE Transactions on Software Engineering, 1998, 24(3): 174-196.
Rubenstein, H. and R. Waters, "The Requirements Apprentice: Automated
Assistance for Requirements Acquisition", IEEE Transactions on Software Engineering,
1991, 17(3): 226-240.
Kang, K.C., S.G. Cohen, J.A. Hess, W.E. Novak, and A.S. Peterson, Feature-Oriented
Domain Analysis (FODA) Feasibility Study, in (CMU/SEI-90-TR-21, ADA 235785).
1990, Pittsburgh, Pa.: SEI, Carnegie Mellon University.
Fowler, M., K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring:
Impoving the Design of Existing Code, 1999: Addison-Wesley.
Berry, D., R. Kazman, and R. Wieringa, eds. Proceedings of Second International
Workshop From Software Requirements to Architectures (STRAW'03). May 2003:
co-located with ICSE-03, Portland, USA.
Castro, J. and J. Kramer, eds. Proceedings of First International Workshop:
From Software Requirements to Architectures (STRAW'01). May 2001: co-located
with ICSE-01, Toronto, Canada.
This is a temporary website,
under construction. Last updates: 28th June 2005.
