Requirements Ownership Process Pattern

Establishing who is qualified to change Requirements

Note - bear with me on this one, it's not quite there yet!

Problem

Our development projects require us to talk to more than one person to establish the software product. These may be stakeholders who are interested in the high-level benefits the product should offer, or technical experts (domain experts) who are knowledgeable of a certain area of the problem domain. Quite often, different people will provide requirements that directly contradict ones that have been provided earlier. For example:

A technical expert indicates that some information in a report is not required, but it has been asked for previously by someone else.
An internal member of staff indicates that the client wasn't a feature to work in a certain way, but you recall them wanting something different.
...

Notes - The problem's posed here are a) detecting that a requirement has been specified more than once and b) determining which requirements are correct

Consequences

If measures aren't taken to determine which requirements are correct, and which aren't, then problems will most certainly arise later in the project. The most visible time for realising incorrect requirements is unfortunately after the product is developed, which is also the most expensive time to correct them. Investors may not be willing to pay for re-work to be done, so the product developers may have to fund this themselves. In an ideal world, the client would accept responsibility for thier domain experts giving incorrect information, but this is seldom the case. Either way, it is better to prevent such problems than suffer the consequences of them.

Solution

Clearly establish who is allowed to submit requirements for each area of functionality - I call these 'feature experts'. It is likely that there will only be certain people on the project can specify how things should be for a given feature or use-case of the product. You could maintain a simple table in your project documentation indicating which people are responsible for which use-cases or features. Alternatively, you could record this information against each use-case. Either way, it is important that all project participants have access to this information, and are aware of the related processes surrounding it.

In the event of contradicting requirements, for example, one person says that orders should be arrive via email, and someone else says they should arrive via fax - then make all feature experts aware of the contradiction and ask for a resolution (be sure to give a time-scale for when this should be resolved). This prevents burdening the requirements gatherers with responsibility yet ensures a definitive outcome is agreed.

So what happens if a non-feature-expert provides requirements on a given area of functionality? These should always treated as 'suggestions' and submitted back to the relevant feature-experts for approval.

Resultant Context

A mechanism is in place for managing who can formally contribute to what. Also, you have a pre-determined reaction for contradicting requirements.

Dismissed Solutions

Giving a party ownership of requirements in a particular area of functionality, and assume they are always correct. This is not possible since aspects of the requirements will overlap. Also, one person may be responsible for high livel requiremnts for that area, and another may be responsible for the more technical details. Therefore it is not reasonable to give total ownership to any party.
Make all project participants read requirements documents and sign them. I don't believe this to be the most effective way of gathering and validating correct requirements. Clients often don't like reading large quantities of text, nevermind scrupulously scanning them for defects. If anything, have an internal team inspect the requirements documents for defects and contradictions, and then handle these from there.

Example

TODO:

Examples, How to spot contradictory requirements, develop on resultant context

Any suggestions of feedback would be appreciated!