Mapping requirements to software architecture by feature-orientation

Dongyun Liu, Hong Mei

Institute of Software, School of Electronics Engineering and Computer Science
Peking University, Beijing 100871, P.R.China
liudy@cs.pku.edu.cn, meih@pku.edu.cn

Abstract

different perspectives in user (or customer) requirements

Requirements engineering and 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

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.

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

1. Introduction

apply feature to software development. In 1982, Davis [1]

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

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

envisioned. Application of our mapping approach to the

terminology, domain experts and up-to-date documents are

bank accounts and transactions system (BAT) has been

available. C. Reid Turner [4] puts forward a conceptual

used in this paper as an illustrative example.

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

2. Requirements Engineering and Software

Architecting

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

The IEEE standard [5] defines requirement as

(1) A condition or capability needed by a user to solve
a problem or achieve an objective.

particular solution for mapping requirements to SA from

(2) A condition or capability that must be met or

software engineering perspective. But above researches

possessed by a system or system component to satisfy a

and practice show that it is feasible and effective to make

contract, standard, specification or other formally imposed

features explicit in software development and to take

document.

feature orientation as a paradigm during the software life

(3) A documented representation of a condition or

capability as in (1) or (2).

cycle.
In this paper, we will explore how to apply feature

This definition is not so clear. In practice, requirements

orientation as a solution for the mapping problem between

for a software system may exist in multiple different

requirements and SA from general software engineering

abstract levels, varying from organizations business

perspectives, focusing on the mapping and transformation

requirements, through users task requirements, to eventual

process. Our solution is to organize requirements in

software requirements specification (SRS).

problem domain into a feature model, and then base our

Requirements engineering aims at reaching a good

architectural modeling on the feature model, with the goal

understanding of the problem domain and users (or

maintaining

between

customers) needs through effective problem analysis

requirements model and architecture models. Further, we

techniques, and producing a correct, unambiguous,

will address functional features and nonfunctional features

complete and consistent requirements specification which

separately in different architectural models. Our approach

serves as a baseline for developers to implement the

is not a replacement of but an improvement on traditional

software system. Requirements engineering only focuses

methods. Our approach can integrate closely with OO

on problem domain and system responsibilities, but not

method. The modeling concepts and notation adopted in

design and implementation details.

direct

and

natural

mapping

this paper are based on UML, but have appropriate

SA has become an important research field for software

engineering community. There exists a consensus that for

extension.
The rest of this paper is organized as follows. Section 2

any large software system, its gross structure-that is, its

requirements

high-level organization of computational elements and

engineering and software architecting, and specifies the

interactions between those elements-is a critical aspect of

necessity for supporting traceability between requirements

design [6][7]. It is widely accepted that SA is a very

and SA. Section 3 analyzes the inadequacy of mapping

important product and software architecting is a necessary

approaches in traditional methods. Section 4 proposes a

phase in software life cycle. As an important design

feature-oriented mapping solution, and specifies the

concept, SA can serve as the key milestone in the entire

rationale, process and guidelines for this approach. Section

software life cycle process. SAs support of the needs of

5 concludes the paper and further research effort is

system engineers, customers, developers, users, and

analyzes

the

relationship

between

maintainers, also implies that is involved in all phases of

did not. Because Object-Oriented Analysis (OOA) and

the software and system life cycle[8].

Object-Oriented Design (OOD) use the uniform basic

Until now software engineering researchers dont reach

concepts and principle, the mapping between OOA model

an agreement about the relationship between requirements

and OOD model is natural and direct. Also, keeping

engineering and software architecting. Following waterfall

traceability is easy and transformation could be done

development model, software architects should not begin

mechanically.

software architecting until a complete, correct and

But both structured method and OO method dont

consistent requirements specification is reached. But some

provide complete solution for mapping requirements to SA

researchers[10] have pointed out that this model is

indeed. On one hand, in both methods, SA and components

discredited. In multilevel life cycle chart model,

are not paid enough attention to; On the other hand, both

proposed

DFD and OOA model describe internal structure of the

by

engineering

Merlin

involved

[10],

system from developers view and not external behavior

architecting process, that is, the steps of requirements

from end users view. They contain some information that

analysis

Software

is not of interest to end-users (or customers). So there is

Corporation [9] proposes the Unified Process, which is a

still a gap between analysis model (DFD or OOA model)

use case driven, architecture-centric, and iterative and

and user requirements description. Based on above

incremental process framework. In spite of existing

analysis, we can conclude that, the mapping approaches in

different

traditional methods are inadequate for mapping from

design

perspectives,

throughout

requirements
software

and

is

Dorfman

alternate.

now

the

Rational

iterative,

incremental,

evolutionary and concurrent development paradigms are

requirements to SA.

gaining more and more wide-spread acceptance. In

development following such paradigms, it is more

4. Feature-oriented mapping

important to maintain direct and natural mapping and

traceability between requirements specification and SA.

In this section we will explore how to apply feature

orientation as a solution for mapping and transformation

3. Traditional mapping approaches

from requirements to SA aiming at improving traditional

methods.

Looking back on the development of software

Feature has been defined in various ways, some

development methodology, it is not difficult to find that

important definitions are as follows: A feature is a

keeping the traceability and the consistency in concepts

coherent and identifiable bundle of system functionality

between requirements and designs always are the goals

that helps characterize the system from the user

that we pursue. Two main software development methods,

perspective[4]; A feature is a prominent or distinctive

structured method and object-oriented method, both

user-visible aspect, quality, or characteristic of a software

provide solutions for mapping analysis model to design

system or systems[2]; A feature is an externally desired

model.

service by the system that may require a sequence of

In structured method, software requirements are

inputs to effect the desired result [11]; A feature is a

captured in Data Flow Diagram (DFD), and design is

service that the system provides to fulfill one or more

described in Module Structure Chart (MSC). Because there

stakeholder needs[12]. We think that a feature is a

exists evident difference between the basic concepts and

higher-level abstraction of a set of relevant detailed

principles of DFD and MSC, mapping DFD to MSC is

software requirements, and is perceivable by users (or

difficult and just by heuristic rules. Object-oriented

customers). So it is reasonable to identify features as

approach cured the symptom that the structured paradigm

first-class entities in requirements modeling, and

combine feature modeling and traditional requirements

Users (or customers) knowledge about problem domain

modeling together to describe requirements in different

is main source of features. Books, user manuals, etc. are

levels. Further, in architectural modeling we will take

also

feature orientation as a goal, and try to maintain direct and

techniques include interview, questionnaire, requirements

natural mapping between feature model and architectural

workshop, and so on. In mature domains, analyzing the

models at higher levels. By feature-orientation, we aim at

terminology of the domain language is also an effective

making the mapping relationship between requirements

and efficient way to identify features.

and SA straightforward, which is impossible by traditional

approaches.
We also have recognized the different effect of
functional features and nonfunctional features on software
architecture and address them separately. First, we get an
initial partition of the proposed system into components
based on functional features. Then, further optimization
and transformation can be imposed on the partition,
iteratively and incrementally, considering nonfunctional
features.
The feature-oriented mapping process consists of two
stages:

feature-oriented

requirements

modeling

and

feature-oriented architectural modeling.

sources of

features. Main

feature elicitation

Feature analysis and organization

As potential features are identified and elicited, they are
analyzed and organized into a feature hierarchy in a tree
form. The features collected can be divided into functional
features and nonfunctional features. All features reflect
stakeholders need to solve their problems. According Karl
E. Weigers view [13], stakeholders requirements may
exist in multiple levels, including business requirements,
user requirements and functional requirements. As
abstraction of functionality, features may exist at either
business level or user level. A feature at business level
describes the high-level desire of an organization or a
customer for future system. Features at user level describe
services which future system should provide for user tasks

4.1 Feature-oriented requirements modeling

and constraints on the services. We first partition the

Feature-oriented requirements modeling is intended to

capture users (or customers) high-level expressions of
desired system behavior in terms of application features,
analyze the relationship between features, and then
organize and refine the features into a feature-oriented
requirements specification. Feature-oriented requirements
modeling can be divided into three activities: feature
elicitation, feature organization and analysis and feature
refinement.

features into the two levels, and we then further organize

the features based on following criteria:
The features to support a specific business process
can be grouped and abstracted as a higher-level
feature
The features to support a specific user class can be
grouped and abstracted as a higher-level feature
A nonfunctional feature that is a constraint on a
functional feature becomes a sub-feature of the
functional feature.
If a feature at user level is used to realize a feature at

Feature elicitation
user

business level, then the former becomes a sub-feature

requirements in terms of features. Keeping elicitation at

of the latter. For instance, in the bank account and

abstract feature levels, we can avoid plunging into detailed

transaction system (BAT) example (see Figure 1),

functional requirements too early. Also, as the user often

identify client feature is a realization of the

has expertise in the domain and knows the value of the

nonfunctional feature security, so identify client

features, problem analysis effort can be concentrated on

feature becomes a sub-feature of security feature.

user-desired features and unnecessary work can be reduced.

There exist various relationships among the features. We

Features

elicitation

focuses

on

eliciting

have

identified

several

composed-of,

kinds

of

relationships:

withdraw money is a mandatory feature, but transfer

generalization/specialization,

money is an optional feature.

derived-from, constrained-by and dependent-on, etc.

Feature refinement

As shown in Figure 1, identify client is derived from

Now we have a feature hierarchy, but it is not specific

security, withdraw money is constrained by response

enough for implementation. The next task is to refine the

time <= 1min, all customer services is dependent on

features into detailed functional requirements. Here use

identify client.

case technique can be used to elaborate a feature into a set

Features themselves may be mandatory or optional.

of functionality.

A mandatory feature is necessary for general users, and an

Figure1 presents the resulting requirements model

optional feature is necessary for partial users. For example,

through feature-oriented modeling.

BAT services

Business
level

User
level

customer
services

fail-safe

security

deposit money

identify client

withdraw money

Account
management

Remote
client

transfer money

various UI

Response
time <= 1 min

function
level

Identify
client

Check
funds

Mandatory
feature

Debit
account

Dispense
money

function

Optional
feature

Figure 1. The feature model of BAT system

4.2 Feature-oriented architecture modeling

Also, we have recognized that functional features and

nonfunctional features have each different contribution to

After we have got requirements specification organized

SA. A functional feature can be mapped to a subsystem or

by features, we can take it as an input to architecture

a component. Nonfunctional features can generally not be

modeling and derive SA from it. We will take feature

pinpointed to a particular component, but have impacts on

prominence as a goal and try to maintain direct and natural

the system structure and behavior as a whole. So we can

mapping between feature model and architecture models.

address them separately in different models. We define SA

from three different viewpoints: conceptual architecture,

components, the responsibilities of each component, and

logical architecture, and deployment architecture. As

relationships between components in terms of application

shown in figure 2, conceptual architecture focuses on the

domain concepts. It tries to preserve the structure of

systems partition based on functional features, not

problem domain by partitioning system based on

considering nonfunctional features. Logical architecture

functional features and problem domain structure. Each

focuses on logic design for addressing nonfunctional

functional feature is mapped to a conceptual subsystem in

features, considering the implementation environment.

the conceptual architecture, and each function at the

Deployment architecture focuses on physical distribution

function level can be mapped to an operation of a class in

of the system, addressing related nonfunctional features.

the class diagram. Figure3, Figure4 and Figure5 illustrate

the three views of conceptual architecture in different

Conceptual architecture
The conceptual architecture identifies the system

levels of details, among which the lower-level view is a

refinement of the higher-level view.

nonFunctional
features
Requirements
model

nonFunctional
features

logical
architecture

Conceptual
architecture

Deployment
architecture

Functional
features

*
*

*
*

Figure 2. Mapping feature model to architecture models

<<conceptual
subsystem>>
Transfer moeney

BAT
System
<<conceptual
subsystem>>
Customer
Services

<<conceptual
subsystem>>
Account
management

<<conceptual
subsystem>>
Identify client

<<conceptual
subsystem>>
Deposit money

<<conceptual
subsystem>>
Account
management

<<conceptual
subsystem>>

Figure 3. Business view of BAT conceptual architecture

Withdraw money

Figure 4. User view of BAT conceptual architecture

fy
enti
1: id ent
cli

2: w
ith
mon draw
ey

ATM interface

Dispense money

customer

3: validation
and
Withdrawal money withdrawal

Account

e
ns
pe y
s
i
d ne
4:
mo

Figure 5. Withdraw money conceptual subsystem specification

even transformed. As shown in figure 6, considering

Logical architecture
Logical

architecture

is

architecture

nonfunctional feature various UI, we apply separation

specification that defines the system components and

of concerns strategy to the conceptual architecture. We

interactions

separate

between

the

detailed

components.

Comparing

with

responsibility

for

user

interface

from

conceptual architecture, the logical architecture introduces

responsibility for transaction management. So we got a

more logical structures or mechanisms considering the

new system partition: ATM interface subsystem,

implementation context and nonfunctional features. The

Transaction management subsystem and Account

form of the conceptual architecture may be adapted or

management subsystem.

withdrawal
<<subsystem>>
Transaction
Management

<<subsystem>>
ATM interface

transfers

<<subsystem>>
Account
Management

dispensing

transferral deposits

Figure 6. Logical architecture of BAT system

architecture

Deployment architecture
The

deployment

architecture

focuses

on

how

style

is

selected,

and

the

CHAP

acknowledgement protocol is adopted to ensure connection

functionality is distributed among computational nodes

safety.

and how computational nodes interact, to meet related

architecture and logical architecture, such as withdraw

nonfunctional features. As shown in figure 7, considering

money subsystem, is distributed to the three nodes in this

remote client and fail-safe features, a Three-Tier

view.

ATM

Transaction

components

ATM
application
server

ATM
client

Cash
card

Some

Internet

Transaction
management

<<chap>>

identified

ATM
data server

Intranet

Account
management

<<chap>>
Transaction

Figure 7. Deployment architecture of BAT system

Transaction

in

conceptual

3-15

5. Conclusion

[5] Institute of Electrical and Electronics Engineers. IEEE

In this paper, we analyze the gap between requirements

and SA and the inadequacy of mapping approaches in
traditional structured method and OO method. Based on
this analysis, we propose a feature-oriented mapping and
transformation

approach.

Our

solution

is

to

take

feature-oriented as a paradigm both in requirements

engineering and software architecting, so as to maintain
direct

and

natural

mapping

between

requirements

specification and SA. Further, considering the different

effect of functional features and nonfunctional features on
SA, we address them separately in different models,
iteratively and incrementally. So our approach can fit into
iterative,

incremental

or

evolutionary

development

paradigm.
We believe that feature-oriented development paradigm
will gain more and more wide-spread acceptance. Further
work will be to integrate our approach with existing CBSD
development paradigm in order to support components
reuse at different stages in software life cycle.

[6] David Garlan and Mary Shaw, An Introduction to Software

Architecture, In Advances in Software Engineering and
Knowledge Engineering, Volume 1, World Scientific
Publishing Company, 1993.
[7] Dewayne E. Perry and Alexander L. Wolf, Foundations for
the Study of Software Architecture, ACM SIGSOFT
Software Engineering Notes, 17(4), 1992.
[8] Cristina Gacek, Ahmed Abd-Allah, Bradford Clark, and
Barry Boehm, On the Definition of Software System
Architecture, ICSE 17 Software Architecture Workshop,
1995.
[9] Ivar Jacobson, Grady Booch, James Rumbaugh. The Unified
Software Development Process, Addison Wesley Longmon,
1999
[10] Merlin Dorfman. Requirements Engineering, SEI Interactive,
March,1999

Practice

for

Software

Requiements

Specifications (IEEE Std 830-1998), New York, N.Y.:

project under the contract 60125206. We would like to

thank all the teachers and students who have discussed
with us about this topic and give us good advice.

Reference
[1] Davis, A.M. The design of a family of application-oriented
requirements languages. Computer 15 (5) (1982) 21-28.
[2] Kang, Kyo C. etc. Feature-Oriented Domain Analysis
(CMU/SEI-90-TR-21,

Electrical and Electronics Engineers, 1990

Recommended

This effort gets support from China Natural Science Funds

Study

(IEEE Standard 610.12-1990). New York, N.Y.: Institute of

[11] Institute of Electrical and Electronics Engineers. IEEE

Acknowledgements

Feasibility

Standard Glossary of Software Engineering Terminology

ADA235785),

CMU-SEI, 1990.
[3] Kyo C. Kang , Sajoong Kim etc. FORM: A feature-oriented
reuse method with domain-specific reference architectures,
Annals of Software Engineering 5 (1998) 143168
[4] C. Reid Turner e.tc, A conceptual basis for feature
engineering, The Journal of Systems and Software 49 (1999)

Institute of Electrical and Electronics Engineers, 1998

[12] Dean Leffingwell, Managing Software Requirements: A
Unified Approach, AT&T, 2000
[13] Karl E. Wiegers, Software Requirements, Microsoft
Corporation, 2000