You see, building software is a lot like cooking your favorite dish. Just as you add ingredients to make your meal perfect, software developers consider various elements to craft software that’s top-notch. These elements, known as “software quality attributes” or “non-functional requirements (NFRs),” are like the secret spices that elevate your dish from good to gourmet.
Questions that Arise During Requirement Gathering
When embarking on a software development journey, one of the crucial initial steps is requirement gathering. This phase sets the stage for the entire project and helps in shaping the ultimate success of the software. However, as you delve into this process, a multitude of questions arises
1. Is this a need or a requirement?
Before diving into the technical aspects of a project, it’s essential to distinguish between needs and requirements. A “need” represents a desire or a goal, while a “requirement” is a specific, documented statement that must be satisfied. This differentiation helps in setting priorities and understanding the core objectives of the project.
2. Is this a nice-to-have vs. must-have?
In the world of software development, not all requirements are equal. Some are critical, often referred to as “must-have” requirements, while others are desirable but not essential, known as “nice-to-have” requirements. Understanding this distinction aids in resource allocation and project planning.
3. Is this the goal of the system or a contractual requirement?
Requirements can stem from various sources, including the overarching goal of the system or contractual obligations. Distinguishing between these origins is vital to ensure that both the project’s vision and contractual commitments are met.
4. Do we have to program in Java? Why?
The choice of programming language is a fundamental decision in software development. Understanding why a specific language is chosen, such as Java, is essential for aligning the technology stack with the project’s needs and constraints.
Types of Requirements
Now that we’ve addressed some common questions during requirement gathering, let’s explore the different types of requirements that guide the development process:
Functional requirements specify how the system should function. They define the system’s behavior in response to specific inputs, which lead to changes in its state and result in particular outputs. In essence, they answer the question: “What should the system do?”
Non-Functional Requirements (Constraints)
Non-functional requirements (NFRs) focus on the quality aspects of the system. They don’t describe what the system does but rather how well it performs its intended functions.
Functional requirements are like verbs
– The system should have a secure login
NFRs are like attributes for these verbs
– The system should provide a highly secure login
Two products could have exactly the same functions, but their attributes can make them entirely different products.
|Aspect||Non-functional Requirements||Functional Requirements|
|Definition||Describes the qualities, characteristics, and constraints of the system.||Specifies the specific actions and tasks the system must perform.|
|Focus||Concerned with how well the system performs and behaves.||Concentrated on the system’s behavior and functionalities.|
|Examples||Performance, reliability, security, usability, scalability, maintainability, etc.||Input validation, data processing, user authentication, report generation, etc.|
|Importance||Ensures the system meets user expectations and provides a satisfactory experience.||Ensures the system performs the required tasks accurately and efficiently.|
|Evaluation Criteria||Usually measured through metrics and benchmarks.||Assessed based on whether the system meets specific criteria and use cases.|
|Dependency on Functionality||Independent of the system’s core functionalities.||Dependent on the system’s functional behavior to achieve its intended purpose.|
|Trade-offs||Balancing different attributes to achieve optimal system performance.||Balancing different functionalities to meet user and business requirements.|
|Communication||Often involves quantitative parameters and technical specifications.||Often described using user stories, use cases, and functional descriptions.|
Understanding NFRs: Mandatory vs. Not Mandatory
First, let’s clarify that Functional Requirements are the mandatory aspects of a system. They’re the must-haves, defining the core functionality. On the other hand, Non-Functional Requirements (NFRs) introduce nuances. They can be divided into two categories:
Mandatory NFRs: These are non-negotiable requirements, such as response time for critical system operations. Failing to meet them renders the system unusable.
Not Mandatory NFRs: These requirements, like response time for user interface interactions, are important but not showstoppers. Failing to meet them might mean the system is still usable, albeit with a suboptimal user experience.
Interestingly, the importance of meeting NFRs often becomes more pronounced as a market matures. Once all products in a domain meet the functional requirements, users begin to scrutinize the non-functional aspects, making NFRs critical for a competitive edge.
Expressing NFRs: a Unique Challenge
While functional requirements are often expressed in use-case form, NFRs present a unique challenge. They typically don’t exhibit externally visible functional behavior, making them difficult to express in the same manner.
This is where the Quality Attribute Workshop (QAW) comes into play. The QAW is a structured approach used by development teams to elicit, refine, and prioritize NFRs. It involves collaborative sessions with stakeholders, architects, and developers to identify and define these crucial non-functional aspects. By using techniques such as scenarios, trade-off analysis, and quality attribute scenarios, the QAW helps in crafting clear and measurable NFRs.
Good NFRs should be clear, concise, and measurable. It’s not enough to list that a system should satisfy a set of NFRs; they must be quantifiable. Achieving this requires the involvement of both customers and developers. Balancing factors like ease of maintenance versus adaptability is crucial in crafting realistic performance requirements.
There are a variety of techniques that can be used to ensure that QAs and NFRs are met. These include:
- Unit testing: Unit testing is a type of testing that tests individual units of code.
- Integration testing: Integration testing is a type of testing that tests how different units of code interact with each other.
- System testing: System testing is a type of testing that tests the entire system.
- User acceptance testing: User acceptance testing is a type of testing that is performed by users to ensure that the system meets their needs.
The Impact of NFRs on Design and Code
NFRs have a significant impact on high-level design and code development. Here’s how:
- Special Consideration: NFRs demand special consideration during the software architecture and high-level design phase. They affect various high-level subsystems and might not map neatly to a specific subsystem.
- Inflexibility Post-Architecture: Once you move past the architecture phase, modifying NFRs becomes challenging. Making a system more secure or reliable after this point can be complex and costly.
Real-World Examples of NFRs
To put NFRs into perspective, let’s look at some real-world examples:
- Performance: “80% of searches must return results in less than 2 seconds.”
- Accuracy: “The system should predict costs within 90% of the actual cost.”
- Portability: “No technology should hinder the system’s transition to Linux.”
- Reusability: “Database code should be reusable and exportable into a library.”
- Maintainability: “Automated tests must exist for all components, with overnight tests completing in under 24 hours.”
- Interoperability: “All configuration data should be stored in XML, with data stored in a SQL database. No database triggers. Programming in Java.”
- Capacity: “The system must handle 20 million users while maintaining performance objectives.”
- Manageability: “The system should support system administrators in troubleshooting problems.”
The relationship between Software Quality Attributes and NFRs
As and NFRs are both important aspects of software development, and they are closely related.
- Software Quality Attributes are characteristics of a software product that determine its quality. They are typically described in terms of how the product performs, such as its speed, reliability, and usability.
- NFRs are requirements that describe how the software should behave, but do not specify the specific features or functions of the software. They are typically described in terms of non-functional aspects of the software, such as its security, performance, and scalability.
In other words, QAs are about the quality of the software, while NFRs are about the behavior of the software.
The relationship between QAs and NFRs can be summarized as follows:
- QAs are often used to measure the fulfillment of NFRs. For example, a QA that measures the speed of the software can be used to measure the fulfillment of the NFR of performance.
- NFRs can sometimes be used to define QAs. For example, the NFR of security can be used to define a QA that tests the software for security vulnerabilities.
- QAs and NFRs can sometimes conflict with each other. For example, a software product that is highly secure might not be as user-friendly.
It is important to strike a balance between Software Quality Attributes and NFRs. The software should be of high quality, but it should also meet the needs of the stakeholders.
Here are some examples of the relationship between QAs and NFRs:
- QA: The software must be able to handle 1000 concurrent users.
- NFR: The software must be scalable.
- QA: The software must be able to recover from a system failure within 5 minutes.
- NFR: The software must be reliable.
- QA: The software must be easy to use.
- NFR: The software must be usable.