I call a conflict a requirements conflict when two or more stakeholders hold incompatible requirements. First, I look at people and their needs. Then, I check ideas, facts, and feelings. In short, I treat a requirements conflict as a social conflict that affects requirements engineering.
I define a requirements conflict as an incompatibility of requirements. For example, two stakeholders may want different system behavior. Moreover, they may describe the same feature in contradictory ways. Therefore, I pay attention to both communication and documentation.
I detect conflict early by watching for indicators. For example, I notice denial, repeated objections, and hidden assumptions. Also, I spot repeated changes, contradictions in documents, and stalled decisions. Consequently, I ask more questions. I collect evidence through reviews and interviews. Furthermore, I track who feels restricted or misunderstood.
I classify conflicts by type. First, I consider subject matter conflicts. For example, stakeholders may need different functionality because they use the system in different environments. Second, I look for data conflicts. Here, stakeholders disagree about facts or data definitions. Third, I find interest conflicts. In this case, parties pursue different goals or priorities. Fourth, I examine value conflicts. Stakeholders disagree on principles or trade-offs. In addition, I note structural conflicts and relationship conflicts. However, structural and relationship conflicts often fall outside the requirements engineer’s main responsibilities. Therefore, I escalate those to project managers or organizational leaders.
I analyze each conflict to decide if it is a requirements conflict. First, I gather indicators. Second, I clarify the nature of the incompatibility. Third, I check whether the conflict concerns requirements or other issues, such as personal grievances. If personal issues appear, I escalate them. Otherwise, I work on resolving the requirements conflict.
I choose resolution techniques based on type and context. For example, I use agreement and negotiation when stakeholders can compromise. Moreover, I use clarification and data collection when the issue is factual. In addition, I use prioritization and trade-off analysis when interests and values clash. However, organizational constraints matter. For instance, when time is short, I may prefer faster, pragmatic techniques. Consequently, I balance quality with project constraints.
I keep in mind that most conflicts show mixed characteristics. Therefore, I avoid narrow labels. Also, I remain alert during elicitation. I encourage stakeholders to state their positions clearly. As a result, I reveal hidden problems sooner. Finally, I document conflicts and resolutions. This helps prevent the same issues from returning later.
I do not ignore conflicts. If I ignore them, unresolved issues will cause low-quality requirements and frustrated stakeholders. Therefore, I monitor, record, and resolve conflicts continuously. In short, I treat conflict as a normal and manageable part of requirements engineering.