nd software architecting are
two key activities in software life cycle. Researchers have
paid much attention to mapping and transformation from
requirements to software architecture, but theres still lack
of effective solutions. In this paper, the inadequacy of
traditional mapping approaches (such as approaches in
structured method and OO method) for this challenge is
analyzed, and further a feature-oriented mapping
approach is introduced. The rationale, process and
guidelines for this approach are specified, and the
approach is illustrated by an example of bank account and
transaction (BAT) system.

1. Introduction
Requirements engineering and software architecting are
two important activities in software life cycle.
Requirements engineering is concerned with purposes and
responsibilities of a system. It aims for a correct, consistent
and unambiguous requirements specification, which will
become the baseline for subsequent development,
validation and system evolution. In contrast, software
architecting is concerned with the shape of the solution
space. It aims at making the architecture of a system
explicit and provides a blueprint for the succeeding
development activities. It is obvious that there exist quite
different perspectives in user (or customer) requirements
and software architecture (SA). Mapping from
requirements to SA is by no means trivial work. In
traditional software development methods, the mapping
relationship between requirements and SA is indirect and
not straightforward, and existing mapping solutions are
inadequate for mapping user (or customer) requirements to
SA. In order to adapt to iterative, incremental and
evolutionary development paradigm, it is necessary to
make the mapping relationship between user (or customer)
requirements and SA direct and straightforward, so as to
support the traceability between requirements and SA more
effectively.
As we have noticed, today more and more researchers
pay their attentions to the research of feature-oriented
software development methods. There have been efforts to
apply feature to software development. In 1982, Davis [1]
identified features as an important organization mechanism
for requirements specification. In 1990 Kyo C. Kang [2]
etc. proposed feature-oriented domain analysis (FODA)
method. In this method, the concept of using feature model
for requirements engineering was introduced. As a main
activity in domain modeling, feature analysis is intended to
capture the end-users (and customers) understanding of
the general capabilities of applications in a domain. Later,
FORM method [3] extends FODA to the software design
and implementation phases and prescribes how the feature
model is used to develop domain architectures and
components for reuse. FORM method is quite fit for software development in mature domain where standard
terminology, domain experts and up-to-date documents are
available. C. Reid Turner [4] puts forward a conceptual
framework for feature engineering in 1999. Turner prefers
to look feature as an important organizing concept within
the problem domain and proposes carrying a feature
orientation from the problem domain into the solution
domain. Turners framework comes from software
development experience in telecommunication domain,
and is still conceptual and incomplete. It does not provide
particular solution for mapping requirements to SA from
software engineering perspective. But above researches
and practice show that it is feasible and effective to make
features explicit in software development and to take
feature orientation as a paradigm during the software life
cycle.
In this paper, we will explore how to apply feature
orientation as a solution for the mapping problem between
requirements and SA from general software engineering
perspectives, focusing on the mapping and transformation
process. Our solution is to organize requirements in
problem domain into a feature model, and then base our
architectural modeling on the feature model, with the goal
maintaining direct and natural mapping between
requirements model and architecture models. Further, we
will address functional features and nonfunctional features
separately in different architectural models. Our approach
is not a replacement of but an improvement on traditional
methods. Our approach can integrate closely with OO
method. The modeling concepts and notation adopted in
this paper are based on UML, but have appropriate
extension.
The rest of this paper is organized as follows. Section 2
analyzes the relationship between requirements
engineering and software architecting, and specifies the
necessity for supporting traceability between requirements
and SA. Section 3 analyzes the inadequacy of mapping
approaches in traditional methods. Section 4 proposes a
feature-oriented mapping solution, and specifies the
rationale, process and guidelines for this approach. Section
5 concludes the paper and further research effort is
envisioned. Application of our mapping approach to the
bank accounts and transactions system (BAT) has been
used in this paper as an illustrative example.
2. Requirements Engineering and Software
Architecting
The IEEE standard [5] defines requirement as
(1) A condition or capability needed by a user to solve
a problem or achieve an objective.
(2) 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.
(3) A documented representation of a condition or
capability as in (1) or (2).
This definition is not so clear. In practice, requirements
for a software system may exist in multiple different
abstract levels, varying from organizations business
requirements, through users task requirements, to eventual
software requirements specification (SRS).
Requirements engineering aims at reaching a good
understanding of the problem domain and users (or
customers) needs through effective problem analysis
techniques, and producing a correct, unambiguous,
complete and consistent requirements specification which
serves as a baseline for developers to implement the
software system. Requirements engineering only focuses
on problem domain and system responsibilities, but not
design and implementation details.
SA has become an important research field for software
engineering community. There exists a consensus that for
any large software system, its gross structure-that is, its
high-level organization of computational elements and
interactions between those elements-is a critical aspect of
design [6][7]. It is widely accepted that SA is a very
important product and software architecting is a necessary
phase in software life cycle. As an important design
concept, SA can serve as the key milestone in the entire
software life cycle process. SAs support of the needs of
system engineers, customers, developers, users, and maintainers, also implies that is involved in all phases of
the software and system life cycle[8].
Until now software engineering researchers dont reach
an agreement about the relationship between requirements
engineering and software architecting. Following waterfall
development model, software architects should not begin
software architecting until a complete, correct and
consistent requirements specification is reached. But some
researchers[10] have pointed out that this model is
discredited. In multilevel life cycle chart model,
proposed by Merlin Dorfman [10], requirements
engineering is involved throughout the software
architecting process, that is, the steps of requirements
analysis and design alternate. Rational Software
Corporation [9] proposes the Unified Process, which is a
use case driven, architecture-centric, and iterative and
incremental process framework. In spite of existing
different perspectives, now iterative, incremental,
evolutionary and concurrent development paradigms are
gaining more and more wide-spread acceptance. In
development following such paradigms, it is more
important to maintain direct and natural mapping and
traceability between requirements specification and SA.
3. Traditional mapping approaches
Looking back on the development of software
development methodology, it is not difficult to find that
keeping the traceability and the consistency in concepts
between requirements and designs always are the goals
that we pursue. Two main software development methods,
structured method and object-oriented method, both
provide solutions for mapping analysis model to design
model.
In structured method, software requirements are
captured in Data Flow Diagram (DFD), and design is
described in Module Structure Chart (MSC). Because there
exists evident difference between the basic concepts and
principles of DFD and MSC, mapping DFD to MSC is
difficult and just by heuristic rules. Object-oriented
approach cured the symptom that the structured paradigm
did not. Because Object-Oriented Analysis (OOA) and
Object-Oriented Design (OOD) use the uniform basic
concepts and principle, the mapping between OOA model
and OOD model is natural and direct. Also, keeping
traceability is easy and transformation could be done
mechanically.
But both structured method and OO method dont
provide complete solution for mapping requirements to SA
indeed. On one han