5.4.1. Types of NFRs

Requirements that define how the system should behave, focusing on system qualities and constraints rather than specific behaviors.

Non-Functional Requirements, or NFRs, are essential descriptors of how a system works rather than what it does. They provide guidelines about the qualities and constraints of a system, influencing aspects like performance, usability, and security. For example, while functional requirements tell you that a user should be able to log into a system, NFRs specify how fast that login should happen (performance) or how secure the login process should be (security requirements).

Think of NFRs like rules in a game. While the rules dictate what players can do (functional requirements), NFRs tell you how to play the game effectively. For instance, in soccer, while the rules define how to score a goal, the NFRs are about maintaining good sportsmanship and following fair play — the qualities that make the game enjoyable.

Key Characteristics: ● Quality-related (performance, security, usability, etc.) ● Often cross-cutting across many functional components ● Measurable or testable

NFRs are characterized by their focus on system quality instead of its functionalities. They cover areas such as performance, which could be the responsiveness of a system; security, which ensures data safety; and usability, focusing on the user experience. Additionally, NFRs often affect multiple parts of the system, making them integral to overall system design. Lastly, it's vital that these requirements are quantifiable so they can be objectively measured or tested, for instance, determining if a website can handle 5,000 users simultaneously.

Imagine ordering a meal at a restaurant. The menu items (functional requirements) are what you're choosing from, while the quality of service, ambiance, and food presentation (NFRs) determines your dining experience. Just like you expect your food to be served in a reasonable amount of time (performance), you also want it to be safe to eat (security), and the set-up should be comfortable (usability).

Examples: ● The system should load the homepage in under 2 seconds ● The application must support 5,000 concurrent users ● Data should be encrypted in transit and at rest

Non-Functional Requirements can be illustrated through various examples. First, having a system requirement that specifies the homepage loads within 2 seconds is a performance goal aimed at providing fast user interactions. Secondly, stating that the application must support 5,000 concurrent users highlights scalability, ensuring the system can grow with its user base. Lastly, encrypting data in transit and at rest addresses security needs, ensuring user data is protected both during transfer and when stored.

Consider the online shopping experience. When you visit a site, you expect pages to load quickly (performance). You want to know that when many others are shopping at the same time, the site remains functional (scalability). Additionally, you'll feel safe knowing that your payment information is encrypted (security) when you finalize your purchase.

Types of NFRs: ● Performance (e.g., response time, throughput) ● Security (e.g., authentication, encryption) ● Usability (e.g., intuitive design, accessibility) ● Reliability (e.g., system uptime, error handling) ● Scalability (e.g., ability to grow with demand) ● Compliance (e.g., GDPR, HIPAA)

Different types of NFRs cover various critical aspects of system quality. Performance NFRs deal with how quickly the system reacts to user inputs. Security NFRs ensure that users' information is protected against threats. Usability NFRs focus on how user-friendly and accessible a system is. Reliability NFRs address how dependable the system is under certain conditions. Scalability NFRs refer to how well the system can adjust to an increasing number of users or transactions. Lastly, compliance NFRs ensure that the system adheres to regulatory standards, such as GDPR for data protection.

A good analogy for different types of NFRs could be thinking about a theme park. Performance is akin to ensuring rides run smoothly and quickly. Security is like having sufficient safety measures in place to protect visitors. Usability refers to having clear signs and helpful staff for visitor navigation. Reliability means rides should operate when promised without frequent breakdowns. Scalability is the park's ability to accommodate more visitors during peak seasons, and compliance is following safety regulations and food safety standards that keep everyone safe.

Deliverables: ● NFR Documentation ● Service Level Agreements (SLAs) ● System Design Constraints

NFRs come with specific deliverables that help ensure they are tracked and implemented effectively. NFR Documentation outlines the measured qualities that the system must fulfill and serves as a reference for stakeholders. Service Level Agreements (SLAs) are formal contracts that specify the performance standards expected from the service provider, including uptime guarantees. Finally, System Design Constraints detail any limitations on design choices due to NFRs, ensuring that these requirements are met during the development phase.

Think about these deliverables like the blueprints for building a house. NFR Documentation is like the detailed plans showing what needs to be included (like a strong foundation). The Service Level Agreements are akin to warranties on work performed, promising contractors will fix issues if they arise. System Design Constraints are the zoning laws that dictate what can and cannot be built in a particular area.

BA's Role: ● Elicit NFRs through stakeholder interviews and system reviews ● Ensure NFRs are testable and documented ● Collaborate with architects and developers to plan for NFRs

Business Analysts (BAs) play a crucial role in managing NFRs throughout a project. They must actively elicit NFRs by interacting with stakeholders and reviewing existing systems. It’s essential for BAs to ensure that NFRs are not only documented effectively but also measurable, which enables their validation during testing. Additionally, BAs work closely with architects and developers to incorporate these requirements into the system design and implementation processes, ensuring that they are aligned with overall project objectives.

Think of BAs as project conductors of an orchestra. They must gather input from all musicians (stakeholders), ensuring everyone understands the music score (NFRs). They also need to ensure that the sound produced is harmonious and meets certain standards (testable/documented) while working with the musicians (developers and architects) to create a beautiful symphony (successful project).

--