How to Capture Nonfunctional Requirements

Information Management published this week a nice post entitled How to Capture Nonfunctional Requirements, written by Sastry Kolluru and Shantaram Nishtala, where they commented about an important issue: the nonfunctional requirements gathering.

The business users define the functional requirements substantially well but are challenged when detailing nonfunctional requirements. Asking business the right questions can achieve a better business-IT alignment, they wrote. In a typical data integration initiative, it is not uncommon that functional requirements may not be completely defined early in the project lifecycle; they get clarified as the project progresses. The clarity on nonfunctional aspects is much lower. NFRs are stated informally during the requirements gathering, are often contradictory, difficult to enforce during software development and hard to validate when the software system is ready for delivery.

They listed some reasons because the nonfunctional requirements seem less clear:
- There’s a lack of understanding about what to include as nonfunctional requirements;
- No one is sure what should be specified, this results in exclusion or specification of unrealistic nonfunctional requirements; and
- People assume it is implicit.

They defined some key questions that could be used to define Nonfunctional Requirements in some areas: Performance, Scalability, Reliability, Maintainability, Extensibility, Security and Resource Utilization.

Effectively gathering NFRs is a key success factor for all data integration initiatives. Understanding the types of NFRs and following a systematic approach for capturing them can help identify quantifiable and measurable NFRs, they concluded.

A requirements gathering (functional and nonfunctional) is a vital step to develop a succesful data integration initiative. You should understand well what the business users need, the difference between mandating “what” versus “how” and also define a transparent process to follow through the entire project lifecycle.