We are working with Common methods for Requirements Specification. A part of this is a process for finding non-functional requirements for systems. I have based this on our EA-work. The structure of finding the non-functional requirements is:


Our EA-vision and principles should be discussed, which will result in non-functional requirements for the system. The case is same with our reference architecture and common architecture requirements. The reference architecture shows the preferred modules and layers with guidelines for our future systems, which will result in non-functional requirements for the system. The common architecture requirements are generic requirements, which should be discussed for finding specific non-functional requirements for the system.

The EA-vision, principles and reference architecture should be inserted directly in the requirement specification of large systems. Moreover should they be presented to the vendors for asking them for their solutions.

Producing architecture documentation for a system, is an obligatory discipline in our Common developmentprocess based on RUP. In the discipline the project should see their system based on our 5 architecture views after performing a global analysis. All the architecture thoughts and decisions should be documented. This will of course result in non-functional requirements for the system.

We will document requirements for the functionality of the system by Context diagrams, Use Cases and functional requirements. All this will of course result in non-functional requirements. This process should be done by reviewing and discussing all the actors, Use Cases and functional requirements according to our 10 requirement types. Requirement types is a device to help you to find non-functional requirements and act as a checklist inspired by the Volere-process. Examples of requirement types are Look and feel Requirements, Security Requirements, Maintainability Requirements etc.