What are the best practices/methods/tools/techniques for conflict identification in requirements?

Question

For the sake of this discussion requirements = user-stories (since I'm not differentiating any process per se and would like to get rid of any ambiguities).

It's quite common to have a set of about 100-500 requirements for small-medium systems. It's but natural that it takes a while for one to figure out which requirements are conflicting (more so when >1 stakeholder is involved). Either they are capture using Excel or index cards/post-its or maybe in some project management tool.

So just how does one go about conflict identification within requirements? What are the practices that you have employed and found useful (w.r.t. time/effort expended and conflicts identified).

Is conflict identification even worth it or is it preferable to resolve it 'when you get there' since it could lead to an expectation mismanagement if resolved later?

I'm NOT talking about -ility conflicts. Those are but obvious and should be clarified earlier IMO. I'm talking about conflicts between various functional requirements along with functional vs. non-functional clashes.

Some examples are:

• Terminology conflicts - i.e. different terms used to refer to the same concept
• Structure conflicts - classic one being 'Date' - referred to as MM/DD/YY and as DD/MM/YYYY somewhere else
• Direct conflicts - giving one requirement will be known to not satisfy another e.g. for a calendar app participants time slots will be private vs the meeting organizer should be able to see the meeting time of all participants before deciding on a meeting slot

The latter (direct one) may or may not be negotiable, but identifying it early on will be quite worthwhile IMO.

It's quite cumbersome to go through each requirement at a time to identify conflicts. The best is to divide the effort and speed it up. Another strategy is to analyze the requirements hierarchically, but that may hide certain conflicts which would occur in the lower 'nodes' (and those are the ones that come to bite you later IMHO :)

I'm not aware of any tools/techniques/best practices that would help one identify conflicts with minimal time/effort overhead and hence the question. The above manual step is the best I know of. Yes, in an ideal world it'd be great to have the tool spew out potential conflicts but I don't know if any tool does it (or even a reasonably good job. Help?)

So in an ideal world (without natural language capable machines :) what's the best technique to apply for conflict identification (assuming it's human intensive) and what's been your experience in doing so? If it's not worth it, please elaborate on that too.

Answer 1

Conflicting or inconsistent requirements are not just part of an IT project but span across all types of projects. You can be certain, no matter how hard you try not to, that you will create a requirements baseline with a host of inconsistent or conflicting set of requirements. On top of that, the solution derived to meet a requirement could break another solution for another requirement or make a third requirement an impossibility.

I find no value, i.e., money not well spent, to try to minimize or eliminate this phenomenon. The reason? Because as you deconflict a set of requirements, you are introducing other conflicts or inconsistencies on another set of category and class of requirements.

Requirements conflicts are certain, and so is change. This is why every project needs to have a change management process, so that when conflicts arise, and the team gets smarter, a change can be processed and approved. So through iterations and progressive planning, requirements are deconflicted, made to be consistent, or removed and replaced.

So instead of trying to build a capability to avoid these conflicts, build a powerful capability to deal with them when they materialize.

Answer 2

You can address this type of situations as follows:

• Conflicts related to processes such as the ability to perform an action in the system. You need to structure and group your requirements or stories in a logical way.

  => You can structure your stories on multiple levels: for example by functional area (eg. calendar functionality) and process area (eg. creating appointments & meetings). This allows you to slice and dice your stories to identify conflicts.

  => You should also map your processes as this allows you to walk through your story end-to-end: this way you can identify conflicts but also refine/clarify stories. In your example, "participants time slots will be private" could be instead "my time will show only as available or unavailable to others, with details of my appointments and meetings private", and for "the meeting organizer should be able to see the meeting time of all participants before deciding on a meeting slot" could be instead "as a meeting organizer, I can view participants 'availability"). This will also help facilitating decisions on business rules when such conflicts arise (here, is people's availability public or not?).

• Conflicts related to reference information or data such as terms & definitions, data formats (e.g. numbers, currencies, dates, phone numbers, etc.) or list of values (e.g. dropdown lists, default values, etc.): create a Reference Data Dictionary (RDD) that acts as a centralised document and socialize it amongst your team. Whenever a new requirement/story is identified, if it involves reference data, the RDD is your checkpoint to make sure there are no conflicts from one story to another (such as the one you mention). Bear in mind the RDD is an evolving document so you update and complete it as you build the stories. It's also a very important document for developers when coding the system, and for user training.
• Note: you will likely still have conflicts that can subsist and only become apparent when coding or testing the system, but the above would address most of them, and importantly, the big conflicts that need to be resolved before you start coding the story.

Answer 3

• Terminology conflicts -- this can be resolved by creating a dictionary for the project. Make it widely available to all stakeholders.
• Structure Conflicts (dates) -- ignore the requirements from a system perspective and/or add a requirement to make it allow dates to be configurable. Having different date formats displayed to the user really isn't that big of a deal... what could be a big deal is having multiple formats across the backend your system. Implementation details shouldn't be in the requirements, so make things make sense in the areas of the system in which you have control
• Direct Conflicts -- The key assumption to this question seems to be that all of the requirements must be known and correct up front. The reality is that 500-some requirements will need refinement overtime for a variety of reasons. You may not even end up implementing some of those features which may conflict so is there really a point in worrying about them now? "Fixing" requirements incrementally will not only make it easier to analyze them but also draw a line in the sand, creating a reference point for refining future requirements. Pick the high-value requirements first and design the system with modifiability in mind for features that are at high risk for requirements conflict/thrashing (good risk management plays a key role here). Try to stay an iteration ahead with requirements analysis, much beyond this is a waste for typical IT projects.