bundle-combo-sap-trm-ecc-and-s4hana By Uplatz<\/a><\/h3>\nSection 1: Foundations of Non-Functional Requirements as Architectural Drivers<\/b><\/h2>\n
<\/p>\n
This section establishes the fundamental concepts of NFRs, moving from informal definitions to their formal role as the primary drivers of system architecture.<\/span><\/p>\n <\/p>\n
1.1 Redefining NFRs: Beyond “Ilities” to Architecturally Significant Requirements<\/b><\/h3>\n
<\/p>\n
The term “Non-Functional Requirement” is often informally associated with a list of “ilities,” such as reliability, scalability, or maintainability.<\/span>1<\/span> This terminology, however, understates their importance. A formal definition clarifies that NFRs specify <\/span>how<\/span><\/i> a system should operate and define its quality attributes and constraints, as opposed to <\/span>what<\/span><\/i> it should do (the functional requirements).<\/span>2<\/span><\/p>\nThe central premise of modern software engineering is that NFRs are “architecturally significant requirements,” also known as “architectural characteristics”.<\/span>1<\/span> This distinction is paramount: the plan for implementing functional requirements is detailed in the <\/span>system design<\/span><\/i>, while the plan for implementing non-functional requirements is detailed in the <\/span>system architecture<\/span><\/i>.<\/span>1<\/span> They are the primary drivers of architectural decisions.<\/span><\/p>\n <\/p>\n
1.2 The Critical Distinction: Functional (“What”) vs. Non-Functional (“How”)<\/b><\/h3>\n
<\/p>\n
To engineer NFRs, one must first clearly distinguish them from their functional counterparts.<\/span><\/p>\n\n- Functional Requirements (FRs):<\/b> Define specific behaviors, features, and functions.<\/span>2<\/span> They are typically binary; the system either performs the function, or it fails.<\/span>6<\/span> An example is, “A user <\/span>can<\/span><\/i> log in with a username and password” <\/span>2<\/span> or “A system must send an email whenever a certain condition is met”.<\/span>5<\/span><\/li>\n
- Non-Functional Requirements (NFRs):<\/b> Define the qualities of <\/span>how<\/span><\/i> that function is performed.<\/span>8<\/span> They are often evaluated on a spectrum or against a threshold.<\/span>6<\/span> An example is, “The login action <\/span>must respond<\/span><\/i> in less than 2 seconds”.<\/span>2<\/span><\/li>\n<\/ul>\n
This distinction reveals a critical process challenge. Because FRs are binary (“it works\/it doesn’t”), they are generally straightforward to define and test. Because NFRs exist on a spectrum (“how fast,” “how secure”), they are inherently “harder to define” <\/span>6<\/span> and require a specialized engineering process to make them specific and measurable. This difficulty is a root cause of their common neglect.<\/span><\/p>\nTable 1: Functional vs. Non-Functional Requirements Comparison<\/b><\/p>\n
<\/p>\n
\n\n\n| Aspect<\/b><\/td>\n | Functional Requirement (FR)<\/b><\/td>\n | Non-Functional Requirement (NFR)<\/b><\/td>\n<\/tr>\n\n| Defines<\/b><\/td>\n | What<\/span><\/i> the system does (Features, Behaviors) <\/span>2<\/span><\/td>\n | How<\/span><\/i> the system performs (Qualities, Constraints) <\/span>4<\/span><\/td>\n<\/tr>\n\n| Example<\/b><\/td>\n | “The system shall send a confirmation email.” <\/span>5<\/span><\/td>\n | “The system shall send the email within 5 seconds.” <\/span>8<\/span><\/td>\n<\/tr>\n\n| Subjectivity<\/b><\/td>\n | Straightforward to define; often explicit.<\/span><\/td>\n | Harder to define; often implicit and “fuzzy.” [6, 9]<\/span><\/td>\n<\/tr>\n\n| Testability<\/b><\/td>\n | Tested via functional testing (Pass\/Fail). <\/span>8<\/span><\/td>\n | Tested via non-functional testing (e.g., performance, security). <\/span>8<\/span><\/td>\n<\/tr>\n\n| Impact of Failure<\/b><\/td>\n | The system doesn’t work; a feature is broken. <\/span>6<\/span><\/td>\n | The system works, but poorly; it fails user expectations. [6, 8]<\/span><\/td>\n<\/tr>\n\n| Implementation<\/b><\/td>\n | System Design \/ Component Logic. <\/span>1<\/span><\/td>\n | System Architecture (Architecturally Significant). <\/span>1<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n <\/p>\n 1.3 The Business Impact: Why NFR Neglect Leads to System Failure<\/b><\/h3>\n <\/p>\n NFRs are not optional extras. While a system can <\/span>technically<\/span><\/i> “work” if NFRs are not met (e.g., a login function that takes 30 seconds still “works”), it will fail to meet user expectations and business goals.<\/span>6<\/span><\/p>\nIgnoring or neglecting NFRs leads to concrete and catastrophic failures: systems that crash under high loads (a failure of scalability and reliability), poor user satisfaction and abandonment due to slow response times (a failure of performance), and critical data breaches (a failure of security).<\/span>8<\/span> Because NFRs are essential inputs for architectural decisions, addressing them late in the development cycle radically increases the cost and risk of change, often requiring a complete system re-architecture.<\/span>10<\/span><\/p>\n <\/p>\n 1.4 A Formal Framework: Classifying System Qualities with the ISO\/IEC 25010 Model<\/b><\/h3>\n <\/p>\n To engineer NFRs, a formal classification is necessary. The industry standard is ISO\/IEC 25010, part of the SQuaRE (System and Software Quality Requirements and Evaluation) series.<\/span>13<\/span> It defines a “product quality model” composed of eight main characteristics, which are further subdivided into 31 sub-characteristics.<\/span>13<\/span><\/p>\nTable 2: The ISO\/IEC 25010 Product Quality Model Characteristics<\/b> 13<\/span><\/p>\n\n- Functional Suitability:<\/b> (Sub-characteristics: Functional Completeness, Correctness, Appropriateness) <\/span>17<\/span><\/li>\n
- Performance Efficiency:<\/b> (Sub-characteristics: Time-behaviour, Resource utilization, Capacity)<\/span><\/li>\n
- Compatibility:<\/b> (Sub-characteristics: Co-existence, Interoperability) <\/span>17<\/span><\/li>\n
- Usability:<\/b> (Sub-characteristics: Appropriateness recognizability, Learnability, Operability, User error protection, User interface aesthetics, Accessibility)<\/span><\/li>\n
- Reliability:<\/b> (Sub-characteristics: Maturity, Availability, Fault tolerance, Recoverability)<\/span><\/li>\n
- Security:<\/b> (Sub-characteristics: Confidentiality, Integrity, Non-repudiation, Accountability, Authenticity)<\/span><\/li>\n
- Maintainability:<\/b> (Sub-characteristics: Modularity, Reusability, Analysability, Modifiability, Testability)<\/span><\/li>\n
- Portability:<\/b> (Sub-characteristics: Adaptability, Installability, Replaceability)<\/span><\/li>\n<\/ol>\n
The evolution of this standard itself provides a crucial lesson. ISO\/IEC 25010 (published in 2011) superseded the older ISO\/IEC 9126 (published in 2001).<\/span>13<\/span> The primary difference was the elevation of <\/span>Security<\/b> and <\/span>Compatibility<\/b> to top-level characteristics.<\/span>13<\/span> This change was not a minor academic adjustment; it was a direct reflection of the industry’s shift over that decade. The rise of the internet, distributed systems, and sophisticated cyber threats <\/span>11<\/span> forced “Security” to be a primary architectural driver, not just a sub-quality. Similarly, the move from monolithic applications to interconnected services made “Compatibility” (specifically Interoperability <\/span>17<\/span>) a first-class architectural concern.<\/span><\/p>\nA simpler, complementary classification also exists, dividing NFRs into two categories <\/span>1<\/span>:<\/span><\/p>\n\n- Execution Qualities (Runtime):<\/b> Observable during operation (e.g., Security, Usability, Performance).<\/span><\/li>\n
- Evolution Qualities (Static):<\/b> Embodied in the static structure (e.g., Testability, Maintainability, Scalability).<\/span><\/li>\n<\/ul>\n
<\/p>\n Section 2: The NFR Engineering Lifecycle: A Systematic Process for Quality<\/b><\/h2>\n <\/p>\n This section details the core engineering process: how to systematically move from implicit stakeholder desires to testable, architectural requirements.<\/span><\/p>\n <\/p>\n 2.1 Elicitation Strategies: Discovering Implicit Quality Expectations<\/b><\/h3>\n <\/p>\n Elicitation is the most critical and difficult stage.<\/span>18<\/span> NFRs are often overlooked <\/span>11<\/span>, described as “soft” or “fuzzy” <\/span>9<\/span>, and stakeholders, who are focused on features, may not know how to articulate them.<\/span>19<\/span> Developers, also focused on delivering features, may likewise neglect them.<\/span>20<\/span><\/p>\nStandard elicitation techniques include <\/span>21<\/span>:<\/span><\/p>\n\n- Interviews:<\/b> Direct engagement with individual or small groups of stakeholders.<\/span><\/li>\n
- Workshops:<\/b> Structured, collaborative sessions to define, discuss, and agree on requirements.<\/span><\/li>\n
- Surveys\/Questionnaires:<\/b> Collecting data from a large number of respondents.<\/span><\/li>\n
- Document Analysis:<\/b> Reviewing existing reports, business manuals, and industry standards to extract constraints.<\/span><\/li>\n<\/ul>\n
A more specific methodology is the <\/span>UML Use-Case Based Questionnaire Approach<\/b>.<\/span>18<\/span> This technique creates a direct link between functional and non-functional requirements. The process involves identifying FRs as UML Use Cases, and for each Use Case, attaching a set of probing questions for stakeholders. The answers to these questions are the elicited NFRs.<\/span><\/p>\nFor example <\/span>18<\/span>:<\/span><\/p>\n\n- Actor:<\/b> User<\/span><\/li>\n
- Use Case (FR):<\/b> Login<\/span><\/li>\n
- NFR Question:<\/b> “What is the user friendliness needed?”<\/span><\/li>\n
- Elicited NFR (Answer):<\/b> “Show message if submit without user name or password.”<\/span><\/li>\n
- NFR Category:<\/b> Usability<\/span><\/li>\n<\/ul>\n
This can be formalized using “NFR Quality Elicitation Templates” based on standards like ISO\/IEC 25010 (or its predecessor, 9126) to guide the requirements engineer in asking the right questions for each quality characteristic.<\/span>22<\/span><\/p>\n <\/p>\n 2.2 Specification and Quantification: The Core Challenge<\/b><\/h3>\n <\/p>\n An NFR that is not measurable is not an engineering requirement; it is a wish. The core task of NFR engineering is to make all requirements “specific and measurable”.<\/span>1<\/span> Two primary methods are used for this.<\/span><\/p>\n <\/p>\n Method 1: The Goal-Question-Metric (GQM) Framework<\/b><\/h4>\n <\/p>\n GQM is a top-down approach for defining measurable objectives.<\/span>25<\/span> It consists of three levels <\/span>26<\/span>:<\/span><\/p>\n\n- Level 1: Goal (Conceptual):<\/b> Define the purpose or objective.<\/span><\/li>\n<\/ol>\n
| | | | | | |
![\"\"](\"https:\/\/uplatz.com\/blog\/wp-content\/uploads\/2025\/11\/Non-Functional-Requirements-Engineering-A-Systematic-Approach-to-System-Quality-and-Architecture-1024x576.jpg\")
<\/p>\n