The software architect collates and leverages knowledge about the domain and the system under development. Analysis and planning for non-functional requirements includes leveraging an organization-specific NFR framework and artifacts and initial gathering of non-functional requirements. Certain non-functional requirements can be arrived at via planning and analysis activities. As a case in point, business continuity requirements can be arrived at via business impact analysis, service impact analysis, and risk analysis; all three analytical activities are part of the service continuity management in the ITIL framework. Similarly, cost of service unavailability analysis can help the organization arrive at service availability requirements. These analytical methods that produce requirements documentation are typically part of an IT process and involve business and technology stakeholders.

Artifacts documenting business scenarios and use-case scenarios associated with non-functional requirements can benefit the enterprise from a planning perspective, particularly when these artifacts are re-used and applied when different groups are engaged in documenting non-functional requirements related to the service they are developing or maintaining.

The architect draws on the catalog of NFRs knowledge and design and development techniques. The framework is leveraged to provide a taxonomy and classification of NFR principles and concepts.

The preceding diagram shows the NFRs framework aka catalog. The NFR will be arranged in a hierarchical structure. The NFR KRA and KPI provide a vocabulary to represent requirements. Standard development practices, including the methodology for decomposing NFRs, are also organized in the framework. The framework can be extended to other phases for example, design or development, to deal with additional concepts which can also be addressed.

By leveraging NFR framework, the architect establishes an initial list by identifying the crucial NFRs that the system under development should fulfill. These NFRs are business goals to be delivered and which needs to be analyzed, decomposed, ranked, operationalize. The architect identifies possible development techniques and methodologies. The architect will choose options for target state that will meet the business requirements. Thus the architect begins by thoroughly disintegrating the initial NFR into sub-goals.

The following NFR framework steps are leveraged for analysis of requirements, followed by architecture and design stages:

• First, the business goals are broken down into smaller goals. The ambiguities are resolved and domain information and priorities and leveraged.
• Next, the architect creates solutions to build quality into the system under development, SuD.
• Thirdly, all alternatives and options are considered for the target system, then the best option is finalized and design decisions are established.
• Finally, an analysis is done to check if deviation from stated NFRs is made.

The architect may choose to decompose the NFRs by topic or type. To efficiently tackle with such a broad set of requirements, the NFR may be broken down into smaller goals, so that the solution architecture can be defined. There may be times that the requirements are ambiguous. There may be different concepts of security controls in the context of customer bank information. Treating this high-level requirement will need decomposing it into more specific sub-goals which together satisfice end objective of the NFRs. All the several sub-goals will be required together to meet a final goal. For example, if confidentiality, integrity, and availability are met, then the overall contribution will be achieving the security NFR.