Requirement Conflicts Resolution: Using

Requirement Filtering & Analysis

Wasi Haider Butt1 , Sameera Amjad2 , Farooque Azam3

Department of Computer Engineering

College of Electrical and Mechanical Engineering
National University of Sciences and Technology
Rawalpindi, Pakistan
email: wasi@ceme.nust.edu.pk1 , sameera@ceme.nust.edu.pk2

Abstract. Varied frameworks of Requirement Engineering have been

proposed by numerous research works most of them focusing on the
process as a whole. Few have managed to look beyond the basic frame-
work focusing on complexities that lie within each activity of this crucial
framework. One such complexity often faced by requirement engineers
is the conflict resolution between the elicited set of requirements which
are directly or indirectly related to one another. This research provides
a conflict resolution strategy.
OBJECTIVE-The objective of this research is to present a systematic
approach to resolve software requirement spanning from requirement elic-
itation to requirement analysis activities of requirement engineering pro-
cess.
PROPOSED MODEL-Proposed in this study is a ”Requirement Conflict
Resolution Framework” which uses requirement filter and an analysis
strategy for resolving conflicts arising during development.
METHODOLOGY- This model is based on both empirical results that
we carried out and our extensive research on Requirement conflict res-
olutions and the area of Requirement Engineering. Our model is based
on filtering the elicited requirement set into three sets of requirements
according to their nature of implementation and then analyzing them by
applying CRS methodology.
CONCLUSION-Initial validation of the model indicates that the model
is effective in identifying and resolving conflicts software conflicts that
arise during a requirement engineering process, but more case studies
need to be carried out implementing the proposed model to make more
conclusive empirical results.

1 Introduction
Requirement engineering necessitates classification of elicited requirements based
on their nature of implementation and the analysis of relationships among these
requirements. Conflicts often arise while eliciting these requirements from dif-
ferent stake-holders with varying interests and perspectives; detection and res-
olution of these conflicts is mandatory making analysis of requirements as the
mainstay of requirement engineering process. If no requirement or subset of
requirement interferes with other stakeholder requirements then the Software
Requirement Specification document is said to be stakeholder consistent [1]. In-
accurate, ambiguous, and conflicting requirements are the most common reasons
for a products cost and schedule overruns failing to satisfy user expectations in
terms of functional and quality aspects of the delivered system [2]. Requirement
Engineering is not just a single phase of software development process rather it
is a complex process comprising of different sub activities that together lay the
foundation of a software product on which software development of a product
commences [3]. Requirement problems are widely responsible for the quality and
effectiveness of the software [4] making their elicitation and analysis a critical
pair of activities of the RE phase.
This paper identifies some core areas from RE research literature to develop a
deeper understanding of conflicts that arise between software requirements dur-
ing RE process. This research investigates the identification of conflicts, their
classification based on the nature of their criticality and their treatment be-
fore exiting the RE process to prevent propagation of these conflicts minimizing
their affect in later phases of software development process. A conflict oriented
requirement process has been proposed called COREA spreading over of two
major activities of the RE process for conflict resolution starting from require-
ment elicitation and spanning to the requirement analysis activity. Each of these
activities are organized into a predefined set of sub activities that together ease
conflict identification and resolution for a requirement engineer. Mode of valida-
tion used for studying effective of COREA involves a case study conducted on
software development process of a module of a University Management System.
Section 2 provides a coarse grained overview of the RE process. Section 3
presents some research methodologies studied as part of literature. Section 4
explains the working of the COREA framework. Section 5 presents the case
study results that evaluate behavior of COREA to develop a customer consistent
software requirement specification. Section 6 gives conclusion and future work
for this research.

2 Background and Motivation

Requirements engineering covers all of the activities involved in discovering,

documenting, and maintaining a set of requirements for a software system. The
use of the term ’engineering’ implies that systematic and repeatable techniques
should be used to ensure that system requirements are complete, consistent
and relevant. Zave [5] defines RE as: ”Requirement engineering is the branch
of software engineering concerned with the real world goals for, functions of,
and constraints on software systems. It is also concerned with the relationship of
these factors to precise specifications of software behavior, and to their evolution
over time and across software families”. Pressman [6] divides RE process into
the following major activities:
1. Requirement Elicitation: This activity is responsible for gathering require-
ments from the user dealing with different problems like requirement scope,
requirement understanding and requirement volatility.
2. Requirement Analysis: This activity analyzes requirements against ambigu-
ities, inconsistencies and conflicts. Requirement conflicts are widely respon-
sible for risks associated with incorrect requirement implementation making
their identification and resolution mandatory.
3. Requirement Specification: This activity is responsible for transforming the
above elicited and analyzed requirements into a requirement specification
document.
4. Requirement Verification: The requirement specification document is exam-
ined to verify that all conflicts, inconsistencies and other such errors are
removed and that the requirements conform to the stakeholder needs.
5. Requirement Validation: Requirements gathered are tested for execution.

Requirements are statements of stakeholders about the system that when im-
plemented will satisfy their needs. Further, a single software requirement can
consist of many parts. Problem arises when one or more requirements or part of
a requirement is inconsistent with and contradicts with other requirements. Such
requirements are called conflicting requirements and can lead to fatal feature or
quality failures of a software product. Absence of a formal conflict resolution
process can lead to dissatisfaction of stakeholders eventually ending up in fail-
ure of the resultant system. Barry Boehm and Hoh In [7] presented numerous
case studies which suffered drastic failures due to requirement conflicts of the
developed systems.
The purpose of this research is to investigate the existing methods and deter-
mine a suitable framework for conflict resolution that is easy to understand and
implement by a requirement engineer having limited conflict resolution expertise.

3 Research Methodology

Our studies of some existing methodologies for resolving requirement conflicts

have brought forth some methods: the WINWIN System, the NFD Model and
CORA framework proposing different techniques for identifying and resolving
requirement conflicts.

3.1 The WINWIN System Barry

Boehm and Hoh In used a knowledge based tool called the Quality Attribute
Risk and Conflict Consultant (QARCC) that operated on the WinWin system
that worked on the following principles:

1. Identify and negotiate quality attribute requirement conflicts and tradeoffs

2. Diagnose quality attribute conflicts on the basis of early information.
A knowledge base approach illustrated in Figure 1 was used by the QARCC tool
to identify the conflict from past knowledge and then providing different options
and suggestions to resolve these conflicts. Based on the knowledge collected us-
ing the WinWin negotiation system the QARCC tool prioritized requirements
into a hierarchy valued by the different classes of stakeholders [7]. This tool
assisted the stakeholders to identify and negotiate risks associated with require-
ment conflicts and helped resolve them using negotiation. Conflict resolution is
not computerized analysts select appropriate alternatives which are generated
by the QARCC tool.

Fig. 1. A WinWin Negotiation QARCC Tool Technique

3.2 The Non-Functional Decomposition Model

The Non-Functional Decomposition (NFD) [8] model looks at requirements from
system architectural point of view decomposing requirements into functional
and non functional sets of requirements. Functional requirements come under
the primary requirement umbrella and are directly responsible for achieving
the system goals while non functional requirements along with some secondary
set of functional requirements were brought under the supplementary set of
requirements. This hierarchical decomposition of requirements by NFD depicted
in Figure 2 is then resolved for conflicts using the below observations [8]:
1. Cohesive force of supplementary requirements: good architectures tend to
cluster functions with similar supplementary requirements in the same sub-
system.
2. Divide-and-conquer conflict resolution principle: if a sub system has to satisfy
conflicting requirements, it is useful to separate the parts that cause the
conflict(s).
3. Entanglement of function, structure and building process of software: these
three elements are highly interrelated.
NFD model maps non functional requirement onto functional requirements and
then resolves these conflicts using above strategy.
Fig. 2. The NFD Model for relationship between system requirements and architecture
[8]

3.3 The Conflict-Oriented Requirement Analysis Framework

William N. Robinson [1] proposed a general framework for requirement conflict
called Conflict Oriented Requirement Analysis (CORA) framework. CORA tar-
gets require-ment conflict resolution using requirement ontology as have many
studies. CORA basic process is depicted in Figure 3 which follows a cycle of
following activities for requirements analysis [1]:
1. System requirements are defined as instantiations of a requirement ontology.
2. Issues arise through analysis of requirements that may lead to stakeholder
positions.
3. Conflict analysis defines the specific objects that vary among stakeholder
positions. (A focusing strategy guides the order in which issues are to be
analyzed for conflict.)
4. Resolution generation removes conflicts through the application of restruc-
turing transformations. (A restructuring strategy guides the application of
the restructuring transformations.)
5. A resolution is selected among a set of possible resolutions for each con-
flict.The requirement document is updated with the newly defined require-
ment resolutions.
CORA starts from requirement analysis phase of the RE process following the
CORA cycle to resolve the conflicts.

4 Proposed Conflict Oriented Requirement Elicitation &

Analysis
We have used two major dimensions to achieve COREA. The first dimension
includes focusing on the hierarchy of requirements depending on the nature
of their criticality which is to be targeted by COREA. Unlike other existing
models [8, 13, 14, 15, 16, 17] who use requirement architectural decomposition,
 Fig. 3. CORA Process Activities [1]

COREA focuses on both functional and non functional aspect of requirements

for conflicts. Second dimension includes the strategy that will be used to resolve
conflicts from these different sets of requirements. This COREA requirement
decomposition and its strategy is discussed below. 4.1.

5 Nature of Requirements

Requirements can be broadly divided into two major types’ namely functional re-
quirements (FRs) and non functional requirements (NFRs). Every FR has one or
more NFRs associated with it. Issues often arise due to technical or stakeholder
conflicts preventing successful implementation of requirements [1]. These unde-
sirable interactions or contradicting elements among requirements that hinder
mutual satisfaction of requirements produce conflicting set of requirements that
need to be resolved. Over-lapping or conflict parts of a requirement can be better
illustrated in Figure 4 below. Conflicts in functional requirements mainly arise
due to participation of multiple stakeholders while defining operational features
of a system. Such conflicts are even more obvious to incur for non functional
or quality requirements of a system. Optional requirements are those which can
be integrated into the system but can be delayed for implementation in later
versions of the system. Conflicts in functional set of requirements can lead to
immediate failure of the operational features of the system while conflicts in
quality requirements of a system can lead to dissatisfaction on part of the user
which disintegrates system performance. Hence, functional and non functional
requirements both need to be resolved for different conflicts.
 Fig. 4. Overlapping or Conflicting Requirements

5.1 Proposed COREA strategy

Conflict Oriented Requirement Elicitation & Analysis (COREA) begins from

requirement elicitation activity of the RE process. It structures elicited require-
ments into three basic types of requirements based on the nature of their imple-
mentation. COREA works on the below listed set of requirement observations:

1. Mandatory Requirements (MR): Primary set of functional and non function-

al requirements that are crucial for the success of a system and cannot be
compromised.
2. Essential Requirements (ER): Secondary set of requirements that directly
constraint the mandatory requirements need to be satisfied to provide sup-
port to the primary requirements of the system.
3. Optional Requirements (OR): These are additional requirements that can
wait and can be neutralized for initial release accommodating them in up-
coming features of the system.

The COREA approach does not venture into the details of the different types
of func-tional and non functional requirements as ample literature is already
available in that regard focusing majorly on the relationship of requirements
both FRs and NFRs that are necessary for success of the software. Since both
are equally important for the successful deployment of a software system, there-
fore, it just classifies them broadly into the above MR, ER, and OR classifica-
tion. COREA applies its conflict resolution strategy on these set of requirements
starting from the requirement elicitation phase which is where these conflicts ac-
tually get injected in. It follows cycle of the following sub activities to accomplish
conflict resolution:

1. Requirement Filtering: Filter requirements as requirements get elicited de-

pending on the nature of their criticality.
 2. Conflict Prevention: Prevent conflicts to occur while eliciting the mandatory
requirements. Document these requirements resolving conflicts as and when
they arise in the presence of stake holders.
3. Conflict Detection & Removal: Requirements that enter requirement analy-
sis sub activity are analyzed and detected for conflicts. These conflicts are
negotiated [11] and resolved using agreed upon alternatives.
4. Conflict Containment: Conflicts are left untreated as their containment has
less or no impact on User Acceptance Test.
As illustrated in Figure 5 COREA adopts the following depicted strategy for
resolving conflicts staring from elicitation and spanning to requirement analy-
sis which marks end of conflict resolution. Requirement conflicts in mandatory
and essential require-ments are resolved by the end of Elicitation and Analysis
activities of the RE process while optional requirements are left. That is,
1. Conflicts are prevented in the mandatory requirements (resolved while re-
quirement elicitation itself)
2. Conflicts are detected and analyzed in requirement analysis phase and are
resolved using the divide & Conquer principle of NFD [8].
3. Conflicts in optional requirements are contained.

Fig. 5. COREA Strategy

5.2 Conflict Oriented Requirement Elicitation

Requirement elicitation plays a critical role in the foundations of a requirement
speci-fication document since it is here that the requirements get documented
for further analysis and it is here that the conflicts actually get infused into the
requirement docu-ment. We filter requirements as and when they get elicited
namely into MR, ER and OS requirements. After filtering requirements, we pre-
vent conflicts in requirements that are directly responsible for contributing into
the system goals or yield direct value to its users leaving minor conflicts that
 Fig. 6. COREA Requirement Filter

has less or no impact on actual implementation. Identification of such primary

FR and NFR is similar to identifying processes that are deemed most important
for the success of an organization. An example of mandatory functional require-
ment conflict includes; stakeholder A states a mandatory requirement as”the
exam cell coordinator must be able to generate a cumulative total of individual
PhD students and assign them grades accordingly”. Another stakeholder B states
a requirement that contradicts the previous version of the same requirement as
”the exam cell coordinator must be able to generate a cumulative result of PhD
students who have cleared the GRE test”. Since both stakeholders are partici-
pants of the RE process necessary for successful implementation of the system
therefore, the RE engineer will negotiate with both stakeholders to prevent the
contradicting statements that are form major feature of the Exam Management
System of a university. Any one perspective of the two stakeholders is selected
for implementation after agreement of both stakeholders through negotiations as
illustrated in Figure 7. For example, the perspective that maps with the policy
of the University for grading eligibility will be used after negotiation. We let the
essential and optional set of requirements to get elicited in the requirement elici-
tation activity and enter into the requirement analysis phase for conflict analysis
rather than resolving them here.

5.3 Conflict Oriented Requirement Analysis

Essential requirements define functionality (FR and NFR) that are secondary
to the goals of the system consisting majorly of non functional requirements.
 Fig. 7. Mandatory Requirement Conflict Prevention

These require-ments are those without which a system cannot pass acceptance
testing in its opera-tional environment. Essential requirements are the same as
secondary requirements explained in [8]. Examples include functions that aid the
mandatory requirements like managing them or the data generated by the sys-
tem making conflict resolution of such requirement necessary. Different conflict
resolutions have been proposed in research literature [12]. Conflict resolution
strategy used in our proposed framework is illustrated in Figure 8 for above
identified requirements is as follows:
1. Requirements are analyzed for conflicts.
2. Conflicting parts of ER are divided using the Divide-and-Conquer principle
[8] which states that if a requirement has parts that contradict or conflict
with parts of other requirements then it is useful to separate these parts and
resolve the conflicts.
3. Using Divide and Conquer, conflicts are detected and resolved through nego-
tiations using suggested alternatives. Since majorly these requirements are
quality oriented NFRs therefore these can be resolved for conflicts by divid-
ing them and then integrating both requirements by combining them and
achieving a common perspective for its implementation.
For example, ”after three incorrect log-in attempts the system should block the
user account which being tried to gain access”, related conflict ”system should
never block the account of a user for incorrect log in attempts”. Since, ER is
necessary set of requirements providing support to the mandatory requirements
their fulfillment is necessary. Hence, by applying the above strategy of Conflict
Detection and Removal; by the end of requirement analysis conflicts in ER are
completely resolved.
Optional requirements (OR) are requirements which can be left untreated
and do not have an impact on the deployment of the system and on the user ac-
ceptance tests that are conducted in the operational environment. For example,
if Stakeholder A has a requirement that means changing the entire layout of the
system user interfaces. This would mean following the COREA cycle again, ne-
gotiating with other involved stakeholders who may have different opinions and
making amendments. When the cost of resolving such a conflict of additional
requirements is greater than the benefit of the requirement implementation then
 Fig. 8. Requirement Conflict Detection & Removal

we group such requirements under OR group and delay their resolution to fu-
ture implementations when these requirements will undergo COREA cycle for
resolution of these conflicts. We will contain affect of these requirements. The
customer will be ensured that future version of the product will entertain this
change request. Conflict containment is depicted in Figure 9 below.

Fig. 9. Requirement Conflict Containment

5.4 COREA Basic Workflow

COREA begins from requirement elicitation phase of the RE process and follows
a cycle of the below listed steps to resolve conflicts that may arise in requirements
start-ing from elicitation and spanning to the requirement analysis activity. After
filtering requirements as they are elicited, conflicts are prevented in mandatory
requirements as they are most crucial for fulfillment of primary features of the
software system. Essential requirements and optional requirements are passed
on to the requirement analysis where these requirements are further analyzed.
Essential requirements are analyzed using divide and conquer principle and then
are resolved for identified conflicts through negotiations with the participating
stakeholders. Optional requirements are not resolved for their conflicts neutraliz-
ing their affect they are documented in the Software Requirement Specification
(SRS) Document for postponed implementation. MR, ER and OR are docu-
mented in the SRS after which they are passed on to the validation phase of the
RE process for testing their execution. This process has been illustrated in the
below given COREA workflow when working within a RE process.

Fig. 10. Basic COREA workflow in a RE Process

6 Model Validation
In order to check and validate the practical functioning and impact of the pro-
posed approach, the approach was applied during the requirement phase of one
module of an information system named university management system that
was under development in our own university. Following are the details of im-
plementation, results and the findings.
The whole system as a whole was intended to automate all the business
processes running in the university Academics, Administration, Accounts and
so on. For the validation of our model we selected Hostel Management System
which was a subpart of the large university management system.
Development was done within the campus development cell. There was a
team of six people consisting of a team lead, two developers, a tester and two
requirement engineers. Time assigned for the completion of version 1.0 of the
module was one month.
Development started on 1st july, 2010. Requirement phase started after ap-
proval from project manager. For requirement elicitation, open interviewing was
used as it was experienced very good mode of elicitation in that environment.
The stakeholders identified were the hostel provost, wardens, supervisors, top
management and the faculty.
In the manual process, Provost was supposed to manage all hostels, their
capacity, adding deleting space to hostels etc. Hostel wardens were supposed
to assign students hostels or vacate hostel seats. In this article, 24 requirement
samples have been extracted from the initial requirement draft.
Warden A, was interviewed the first day and the following requirements were
elicited:
RA 1. System should allow warden to assign student a seat in his hostel
RA 2. System should allow warden to shuffle multiple students seats
RA 3. System should maintain a log of all allotments and vacations
RA 4. System should allow warden to see log of allotments and vacations of
his hostel
RA 5. System should allow warden to check trend of which class students
like to live with which class students.
RA 6. System should allow warden to put a student in waiting list if a seat
is not available and student requests for a seat
RA 7. System should not allow warden to assign a student a seat from outside
the waiting list if there is any student in the waiting list
RA 8. System should allow warden to check the waiting list
RA 9. System should not allow warden of any other hostel or provost to
interfere his hostel matters
RA 10. System should allow students to register their complains
RA 11. System should allow warden to check those complains
RA 12. System should allow warden to check those complains in date wise
order
RA 13. If any user other than the designated warden tries to access a specific
hostel information, system should block his account immediately.
 Warden B, was interviewed the second day and the following requirements
were elicited:
RB 1. System should allow warden to assign student a seat in his hostel if
he has approval from provost.
RB 2. System should maintain a log of all allotments and vacations
RB 3. System should allow warden to see log of allotments and vacations of
his hostel
RB 4. System should allow warden to put a student in waiting list if a seat
is not available and student requests for seat with provosts approval
RB 5. System should allow warden to assign a student a seat from the waiting
list or from outside the waiting list if he has approval from management
RB 6. System should allow warden to check the waiting list
RB 7. System should allow management, provost to view status of all hostels
RB 8. System should allow student to register their complains
RB 9. The registered complains should be visible to all wardens, provost and
the management
RB 10. The complains should be viewed in any selected order that user should
be allowed to select from a list etc
RB 11. Top management, provost should be allowed to view records of each
hostel to check all wardens performance
After detailed discussion with the wardens, provost and management, follow-
ing ranking of requirements was made as our proposed approach suggests.
Mandatory Requirements (MR): Essential Requirements (ER): Optional Re-
quirements (OR): Conflict Prevention (CP): Conflict Detection & Removal (CD):
Conflict Containment (CC):
After treating the above conflicts, requirement draft was finalized. The con-
flict that arouse in mandatory was prevented from entering in to the final re-
quirement draft for instance the conflict that arouse between RA 1 and RB 1 was
prevented by developing a consensus among provost, management and all the
wardens. Actually before writing down RB 1 that was extracted after elicitation
of RA 1, it was checked amongst previously extracted requirements because it
is mandatory requirement. And when conflict was found, before writing down
RB 1, the conflict was resolved, this is what prevention is. Similarly the re-
quirements that were essential were straightly wrote as they were taken without
checking them against the written set of requirements but when the require-
ments were analyzed, conflicts were detected and so were removed by going back
to the provost, management and wardens. Similarly the optional requirements
were left untreated. We can see clearly that the conflict between RA 12 and RB
10 has no impact on implementation and acceptance as if all options of sorting
are provided, date wise sorting can be made default sorting.
After requirements process, system was developed, tested and deployed suc-
cessfully. After successful operation of the deployed system, a feedback workshop
was conducted in which feedback about system was taken from them. Following
graph depicts the users’ level of satisfaction. From the case study graphs below
it is clear that the user acceptance test for system performance, quality and con-
formance to user needs has been achieved successfully with all system impacting
conflicts being identified by COREA.

Fig. 11. User Acceptance Performance Feedback Chart

Fig. 12. User Acceptance Quality Feedback Chart

7 Conclusion and Future Work

Conflicts pose a great challenge to the requirement engineering process of a soft-

ware development framework. These conflicts hinder successful deployment of
the soft-ware leading to user acceptance test failures. The objective of this re-
search was to propose a conflict resolution framework that identifies different
types of conflicts and suggests resolution techniques to resolve each type of con-
flict. Three groups of requirements were identified that needed to be targeted to
overcome conflicts in a requirement specification. Research literature was studied
 Fig. 13. Conformance to User Need Feedback Chart

to identify these requirements that were more liable to conflicts and a Conflict
resolution strategy was pro-posed to resolve these conflicts. A case study was
conducted in which the proposed model was employed while the RE process to
identify and resolve different types of conflicts that arise in a real world envi-
ronment. The results of this case study indicated successful identification and
resolution of different types of conflicting requirements involving stakeholders
from different perspectives and interests.
The concept of using a simulation in this regard is appealing to our fu-
ture work. It involves identifying other existing conflict resolution techniques
(not discussed in this paper) and simulating a virtual environment validating
and comparing performances of these varying models to identify the position of
COREA against these models. Since practically it is time consuming and risky
to employ existing conflict resolution models for an RE process, it was thought
wise to use a simulation for achieving our future goal to study this challenging
area.

References
1. William N.Robinson, Vecheslav Volkov. ”Requirement Conflict Restructuring”.
Conflict-Oriented Requirement Restructuring, GSU CIS Working Paper 99-5, pp.
1-47, 1999
2. El Emam Khalid and Madhavji H.Nazim. ”A Field of Requirements Engineering
Practices in Information Systems Development”. Second International Symposium
on Requirements Engineering, 1995, pp.68-80.
3. Sommerville I., Sawyer P. and Viller S. ”Improving the Requirements Process,
Fourth Inter-national Workshop on Requirements Engineering: Foundation of Soft-
ware Quality, 1997, pp.71-84
4. Sommerville I. Software Engineering fifth Edition, Addison-Wesley, 1996.
5. Pamela Zave. ”Classification of research Efforts in Requirement Engineering”, ACM
Computing Surveys, Vol. 29 No.4, 1997, pp.315-321.
6. Roger S. Pressman. ”Software Engineering: A practitioner’s Approach”, McGraw-
Hills Publication, Fifth Edition, 2001.
7. Barry Boehm and Hoh In. ”Identifying Quality- Requirement Conflicts”. Proceed-
ings of IEEE Software, March 1996, pp.26-35.
8. EltjoR.Poort.””. Proceedings of the Fourth Working IEEE/IFIP Conference on Soft-
ware Architecture (WICSA’04),2004, pp.1-10.
9. R R Dube and S K Dixit.” Process-oriented Complete Requirement Engineering
Cycle for Generic Projects”. International Conference and Workshop on Emerging
Trends in Technology (ICWET 2010) -TCET, Mumbai, India,2010, pp. 194-197.
10. T. Gilb. ”Principles of software Engineering Management”. Addison Wesley, 1988.
11. M. T. Jelassi, A. Foroughi.”Negotiaition Support Systems: An Overview of Design
Issues and Existing Software”. Decision Support Systems,1989, pp.167-181.
12. M. Klein. ”Supporting Conflict Resolution in Cooperative Design Systems”, IEEE,
Trans-actions on Systems, Man and Cybernetics, 1991, pp. 1379-1390.
13. J. Boch.”Design And Use of Software Arcgitectures”, Addison Wesley, 2000.
14. F. Bachmann, L. Bass and M. Kevin. ”Preliminary Design of Arche: A Soft-
ware Architec-ture Design Assistant. Technical Report CMU/SEI-2001-TR-035,
SEI, 2003.
15. F. Bachmann, L. Bass and M. Kevin. ”Deriving Architectural Tactics: A Step
toward me-thodical Architectural Design”, Technical Report CMU/SEI-2001-TR-
035, SEI, 2003.
16. H. de Bruin H. Van Vleit.”Top to down Decomposition of Software Architectures”.
Pro-ceedings of 9th Annual IEEE software, pp. 25-35, 1996.