0

How to manage (find out and preserve) the consistency of different types of requirements?

Example: That is great to have gathered many functional requirements (e.g. IS functionality that the system should perform, gathered through brain storming), but what if all this functions will violate the ergonomics of the future system (all these functions could not be placed in menues, GUI or are very problematic to describe with icons or words)? Such kind of problems could not be clear from the beginning of the project.

Are there some good techniques to manage such business inconsistencies? Good Papers, books, articles?

Does somebody know more examples of such inconsistencies?

Upd.: How to manage (find out and preserve) the consistency of different types of requirements?

Improve this question

3 Answers 3

Reset to default
2

Security is a non-functional requirement. Security is frequently in tension with functional requirements. As you increase the effectiveness of simplistic security implementations you will increasingly choke off the ability of the system to support functional requirements. This is an opportunity; creative, elegant implementations of security can actually enhance the functional requirements.

Although it isn't my field, I understand that Section 508 Compliance is frequently in tension with the requirement for ergonomics (GUI, etc.). Once again, I believe that there are solutions to that problem, but they aren't simplistic.

The solution must provide all the functional requirements. The solution should be evaluated on how well it provides non-functional requirements. I prefer to assume that non functional requirements discriminate between solutions that completely fulfill the functional requirements.

These are principles, and the real world is always more complicated than any articulation of principals. I think the underlying truth is that you want to find creative ways to reconcile requirements to provide the best possible value.

Improve this answer
1
  • Thank you for examples (Security, Section 508) - they are good to keep in mind. Your ideas clarified the problem some way better for me now.
    – static
    Commented Feb 27, 2013 at 19:19
1

Non-functional requirements are requirements just as much as the functional ones. Often people forget this.

An example I deal with daily is stability vs features. Stability does not violate any functional requirements but adding stability to a project will often require bumping features and functions off of a project (or sprint) roadmap in order to meet the same deadline.

I've found the best way to get the product guys to understand this is to ask them to quantify their need for stability. "If you get all the features you want but the product crashes 5% of the time - is that acceptable?" Once they are willing to quantify their need for stability, they are willing to treat stability (a non-functional requirement) as a "real" requirement.

Improve this answer
1
  • Stability conflicts with Functionality (as I understand it) in that sense, that than Functionality is not satisfied. I mean some functions doesn't work correct. So the acceptance tests will not succeed. But the idea of the prioritizing and iterative refinement is a good point to hear, to imagine the real development process with the roadmaps.
    – static
    Commented Mar 1, 2013 at 3:41
0

TL; DR

While functional and non-functional requirements often compete for schedule priority or resources on a project, they aren't inherently in conflict. It's simply a matter of prioritizing both types of requirements within the project's constraints.

Stakeholders Must Prioritize

How to manage the consistency of different types of requirements?

As a project manager, this is only indirectly your problem. The responsibility for defining which requirements are most important—and balancing any conflicting objectives—is the job of the stakeholders or their proxy (e.g. the Product Owner).

As a project manager or Scrum Master, you can certainly educate the stakeholders on the Theory of Constraints as they apply to your project. One useful tool, which I often employ myself in such situations, is a Project Success Slider. A slider enforces constraints on project objectives such that the sum of n project variables remains equal to 3n.

Functional and Non-Functional are Both Requirements

The type of requirement (e.g. function or non-functional) is frequently irrelevant to the planning process. The questions surrounding requirements generally remain the same:

  1. What requirements provide value?
  2. Which requirements will be funded?
  3. Who gets the blame when every single requirement can't be Priority Number One?

The third question is the most universal. In this respect, your mileage will not vary.

Improve this answer
2
  • I wrote manage, but meant find out and preserve. So, that still the goal of the requirements engineer or (if the project is not so huge) project manager. Do you think that if requirements conflicting conceptually, then the product owner or other stakeholders should find it out? Theory of Constraints is a good link. I saw it already before, but that time it was just a new term among many others. Peoject Success Slider is also good overviewing tool (not only that implementation from your link, but generally).
    – static
    Commented Mar 1, 2013 at 3:30
  • @static "Do you think that if requirements conflicting conceptually, then the product owner or other stakeholders should find it out?" They should already know; if they don't, it's your job to make sure the issues are effectively communicated and that management is properly informed. The responsibility for managing priorities and conflicts remains theirs--that doesn't change.
    – Todd A. Jacobs ♦
    Commented Mar 1, 2013 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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