We have written much on product requirements on the blog.  Requirements are those statements, derived from the project scope, upon which we will build the product.  A clear understanding of these and the circumstances surrounding the use of the product will improve our chances of achieving the desired development objective.

Nonfunctional Requirements

One of the more difficult types of requirements to evoke, write and test can be the non-functional requirements.  Nonfunctional requirements articulate criteria that the system will be evaluated against that are not functionally or use case based.  These are performance based requirements, for example, the capacity of the system.

• extensibility
• scalability
• reliability
• availability
• reliability
• maintainability
• serviceability

Each of the above requirements may not be associated with a specific feature and are therefore not functional requirements.  These may appear in the specification. I say may appear because unless those who are writing the specification think about these things and how to explicitly document, these may not be included.  Recall that requirements are written in a specific way and reflect tangible and measurable expectations.  For example, consider extensibility. Extensibility is the measure or degree to which software system can be appended or extended.  Finding tangible ways to express this attribute of the software may be difficult, and so too determining ways to test or verify this particular aspect of the software is met can be difficult.

Standards and Nonfunctional Requirements

We may be able to rely upon standards for some of these requirements, for example perhaps, our industry or company has specific serviceability and maintainability expectations identified in standards to which our requirements document may refer.  Sometimes, our team will have to create these attributes of the product using precise wording as these product attributes are also bound by the same qualifiers as the functional attributes.

Things that can help

Writing requirements is not a trivial task and it becomes even less trivial when we work to document these in a way that minimizes omission and possible misinterpretations.  In the case of nonfunctional requirements, the difficulty can be even greater.  Taking time to do this work, doing it iteratively, that is not attempting to write all requirements in one pass, and constant review with the customer and the team will improve the chances of success.