Conflict identification and resolution for software attribute requirements

A critical success factor in requirements engineering involves determining and resolving conflicts among candidate system requirements proposed by multiple stakeholders. Many software projects have failed due to requirements conflicts among the stakeholders. The WinWin system developed at USC provides an approach for resolving requirements conflicts among the stakeholders. The Winwin system provides a framework for negotiation between the stakeholders to identify and resolve these conflicts. However, such systems do not scale well for large software projects containing many requirements. Based on an analysis of the options for addressing this problem, I have focused on semiautomated tools and techniques for identifying and resolving conflicts among software quality attributes. I have developed two prototype support tools, QARCC and S-COST, which expand the capabilities of the WinWin system. QARCC focuses on software architecture strategies for achieving quality attribute objectives. S-COST focuses on tradeoffs among software cost, functionality, and other quality attributes. I have also developed portions of underlying theories and models which serve as the basis for the prototype tools. Finally, I evaluated the theories, models, and tools with the results of WinWin negotiations, such as the CS577 15-project samples.

[1]  Barry W. Boehm,et al.  Some Steps Toward Formal and Automated Aids to Software Requirements Analysis and Design , 1974, IFIP Congress.

[2]  Barry W. Boehm,et al.  Software Cost Option Strategy Tool (S-COST) , 1996, Proceedings of 20th International Computer Software and Applications Conference: COMPSAC '96.

[3]  Leonard J. Bass,et al.  SAAM: a method for analyzing the properties of software architectures , 1994, Proceedings of 16th International Conference on Software Engineering.

[4]  Vasant Dhar,et al.  Supporting Systems Development by Capturing Deliberations During Requirements Engineering , 1992, IEEE Trans. Software Eng..

[5]  Hermann Kopetz,et al.  Dependability: Basic Concepts and Terminology , 1992 .

[6]  Barry W. Boehm,et al.  Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach , 1995, 1995 17th International Conference on Software Engineering.

[7]  D. E. Bell,et al.  Decision making: Descriptive, normative, and prescriptive interactions. , 1990 .

[8]  Robert D. Logcher,et al.  DICE: An object-oriented programming environment for cooperative engineering design , 1992 .

[9]  Barry W. Boehm,et al.  Identifying Quality-Requirement Conflicts , 1996, IEEE Softw..

[10]  Eric S. K. Yu,et al.  Using non-functional requirements to systematically support change , 1995, Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95).

[11]  Ralph Johnson,et al.  design patterns elements of reusable object oriented software , 2019 .

[12]  Tom Gilb,et al.  Principles of software engineering management , 1988 .

[13]  Barry Boehm,et al.  Conflict Analysis and Negotiation Aids for Cost-Quality Requirements , 1998 .

[14]  Michael Böttner,et al.  Natural Language , 1997, Relational Methods in Computer Science.

[15]  Barry W. Boehm,et al.  Software Engineering Economics , 1993, IEEE Transactions on Software Engineering.

[16]  Suren N. Dwivedi,et al.  Concurrent Engineering: An Introduction , 1991 .

[17]  Christopher Tong,et al.  Artificial Intelligence in Engineering Design , 1992 .

[18]  K. Sycara.  Problem Restructuring in Negotiation , 1991 .

[19]  Ronald R. Willis,et al.  Software quality engineering: a total technical and management approach , 1988 .

[20]  Kishore Sengupta,et al.  Managing Cognitive and Mixed-motive Conflicts in Concurrent Engineering , 1994 .

[21]  Barry Boehm,et al.  Analysis of System Requirements Negotiation Behavior Patterns , 1997 .

[22]  Petri Pulli,et al.  Concurrent engineering for real-time systems , 1993, IEEE Software.

[23]  Barry W. Boehm,et al.  Theory-W Software Project Management: Principles and Examples , 1989, IEEE Trans. Software Eng..

[24]  Rick Kazman,et al.  The architecture tradeoff analysis method , 1998, Proceedings. Fourth IEEE International Conference on Engineering of Complex Computer Systems (Cat. No.98EX193).

[25]  Duvvuru Sriram,et al.  The MIT Dice project , 1993, Computer.

[26]  Victor R. Basili,et al.  Tailoring the software process to project goals and environments , 1987, ICSE '87.

[27]  Mark Klein.  Core services for coordination in concurrent engineering , 1996 .

[28]  Alan C. Gillies,et al.  Software Quality: Theory and Management , 1992 .

[29]  Mario R. Barbacci,et al.  Steps in an Architecture Tradeoff Analysis Method: Quality Attribute Models and Analysis , 1998 .

[30]  Steve Easterbrook,et al.  Handling conflict between domain descriptions with computer-supported negotiation , 1991 .

[31]  Barry W. Boehm,et al.  Software requirements as negotiated win conditions , 1994, Proceedings of IEEE International Conference on Requirements Engineering.

[32]  Len Bass,et al.  Toward Deriving Software Architectures from Quality Attributes , 1994 .

[33]  Peter Alan Lee,et al.  Fault Tolerance , 1990, Dependable Computing and Fault-Tolerant Systems.

[34]  Mark Klein,et al.  Supporting conflict resolution in cooperative design systems , 1991, IEEE Trans. Syst. Man Cybern..

[35]  Leonard J. Bass,et al.  Scenario-Based Analysis of Software Architecture , 1996, IEEE Softw..