Discover Non-functional Requirements

Posted by on January 27, 2012 in Software Architecture | 0 comments

Discover Non-functional Requirements

I talked about the importance of Non-functional requirements in my earlier post “Non-functional requirements define a Software Architecture”. What I did not describe was how you can discover the Non-functional requirements?

My preferred method when it comes to requirements gathering, functional or Non-functional, is through interactive workshops. During these workshops you facilitate the requirements gathering using interactive methods. I find that workshops with the main stakeholders are very time effective and create a common ground.

You should decide a standard set of Non-functional requirements for your company. This list of standard Non-functional requirements will function as your checklist at the start of a project. By using a standard you create consistency through all of your projects. You can choose from a number of existing standards or you could create your own. The thing is that not all of these standard will fit your organization, some will be too small, too complex or too large.

You can use any of the following standards or a combination as your Non-functional requirements checklist

A workshop is the process in which you find the Non-functional requirements of your application. If you have done a number of these requirements workshops, you often find a stable set that are important for all the applications that you develop. For example, in industrial applications, reliability and time behavior are often the most important. What would be the contents of such a workshop?

Which non-functional requirement

Depending on the maturity of your organization, you first need to create awareness about the importance of Non-functional requirements. Next,  invite the stakeholders of your application to a QUINT workshop. In this first workshop you are going to find the most important Non functional requirements of your application. For this first step I often use the main categories of QUINT (Functionality, Reliability, Usability, Efficiency, Maintainability and Portability). In the invitation of the workshop add some home-work for the participants which explains these categories.

At the start of the workshop explain the main categories and answer any questions about the home-work. The goal of this workshop is to determine a prioritized list with the most important QUINT categories for your application. An effective method to create this list is dot-voting. Each participant gets three dots that he or she can use to vote on a category. The total number of votes on a category determines the order.

After a first voting round, the stakeholders need to discuss the outcome, is this what they expected? Reassure the stakeholders that all Non-functional requirements are important and will get a place in the software architecture. This prioritized list is used as a basis for our design decisions. After the discussion, do another voting round to create the final list.

This workshop, which can be done in one or two hours creates a prioritized list of Non-functional requirements. This list will be the basis of the software architecture of your application. In a follow-up of this workshop you could descend to the real attributes of QUINT.