10

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.

Improve this question

3 Answers 3

Reset to default
7

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.

Improve this answer
2
  • I agree - I personally had doubts about dealing with them at such a fine grained level.
    – PhD
    Jan 29, 2012 at 18:19
  • I agree, but would add that for the simplest of cases described in the question (like date formats and terminology), decisions should be made that establish a standard. This standard should then be documented, publicized, and enforced. The value of a common lexicon for discussing complicated things cannot be overstated and the cost savings from making a decision once and saving the trouble of having to constantly rehash it integrates over the produce life cycle.
    – Adam Wuerl
    Feb 1, 2012 at 1:42
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.
Improve this answer
2
  • I'm still not clear how hierarchical structuring would help if conflicts are across hierarchies (i.e., same level but different sub-trees, so to speak)? We do structure our requirements this way but sometimes identifying conflicts across subtrees becomes problematic
    – PhD
    Jan 29, 2012 at 0:37
  • Could you please elaborate on structuring the stories? You gave an example of structuring them by functional and process area - do you mean both? I'm not sure I understood the reconciling approach you suggested. Could you please clarify?
    – PhD
    Jan 29, 2012 at 0:39
2
  • 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.
Improve this answer
2
  • just how would you know which requirements are at a high risk of conflict? You just don't know which future requirement will conflict with which requirement? Everything could be risky so to speak - effectively making risk management trivial or redundant. I'm not sure what you are suggesting. Could you please give an example?
    – PhD
    Jan 29, 2012 at 5:19
  • @Nupul, look, you can't predict the future so don't sweat it so much. Your focus should be on delivering value to your customer today. Future requirements will need to be vetted as they are introduced. There is no magic answer to this -- someone on your team is going to have to take responsibility for "owning" the requirements, for knowing them inside and out. In terms of risk management, "everything could be risky" but it's not. Look into a risk management approach such as the SEI's continuous software risk management paradigm for more background on how to identify and manage risk.
    – Michael
    Jan 30, 2012 at 4:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.