Friday, November 6, 2009

Competing Requirements: Functional versus Non-functional

It is a common situation that can be encountered in many software projects that functional and non-functional requirements intersect. It is generally difficult to make correct decision among these 2 types of requirements. Moreover, some non-functional requirements can also have interrelationships.

Functional requirements are the behavior of software that a user wants to use. Non-functional requirements are invisible attributes that indirectly affects users. These attributes may be sometimes related with developer-side or user-side or system-side. Let’s remember non-functional requirements; Availability, Maintainability, Efficiency, Portability, Flexibility, Reusability, Integrity, Testability, Interoperability, Reliability, Robustness and Usability.

Even when making best selection we have to pay some trade-off cost. In our software requirements review meetings, it is a very usual such a case that an analyst wants a functional feature and programmer rejects for the benefit of non-functional such as performance considerations. What do you do in such conflicts? Performance or a user requirement. Rejecting user requirement is a very easy action but it decrease user satisfaction. We usually start a field analysis, so programmer inspects that feature in his program if a better way would be found. In second meeting, results are evaluated and final decision is taken.

Requirements gathering, elicitation and validation are very precious in software development. Everything begins with requirements. If requirements are not engineered enough, the project is deemed to failure. In this aspect, requirements analysts should be educated and well-informed about both functional and non-functional requirements. In this way, they can filter and design requirement solutions better with non-functional parts in mind. That would only filter some requirements but the final authority for non-functional aspect is programmers and architects.

Sometimes, this competition may lead to personal conflicts. For this kind of situations, we developed a rating system that analysts’ leader has 2-point vote, analyst has 1 point-vote and programmers’ leader has 2-point vote, programmer has 1-point vote and referee (manager) has 3-point vote. We just rate the feature and make the final decision.

To prevent conflicts, another important helper is to declare development priorities. What values do you give prominence as a software team? What are your strategies? Do you plan long-term software? If so, than maintainability would be important then.

You may prepare a “Requirement Documentation“ document that lists best practices of writing requirements for your team. This document may state priorities and make a common agreement for your team.

Links:
Software Requirements

More About Software Requirements: Thorny Issues and Practical Advice

Mastering the Requirements Process

No comments: