Non-functional requirements refer to aspects such as operations, security, performance, and usability – factors that do not directly affect the functionality of the system but affect the user experience and the performance of the solution. For the PMI Agile Certified Practitioner (PMI-ACP) exam, let’s delve deeper into how these requirements can be elicited and prioritized taking into consideration the environment in which the solution will be used to minimize the probability of system failure.
Non-Functional Requirements and Project Environment
Non-functional requirements are elements that define how the solution should work as opposed to what the solution should do. Examples include how fast the solution should respond, how secure it should be, and how well it should operate in its intended environment. The intended environment here refers to the actual setting where the solution will be applied, encompassing factors like user diversity, hardware, software, network, and geographic location.
For instance, if a solution is to be used in an area with poor internet connectivity, then the non-functional requirement of high offline functionality becomes crucial. Similarly, if the solution will be used mostly by non-tech savvy people, considerations for user-friendly, intuitive interfaces become more essential.
Elicitation and Prioritization of Non-functional Requirements
Elicitation of non-functional requirements revolves around capturing, understanding, validating, and recording the constraints, and product properties required for the solution. This involves several stages:
- Capturing: This begins with brainstorming possible non-functional requirements based on the environment of the solution. Stakeholders, including users, decision-makers, and project team members, should be involved in this process.
- Understanding: This involves analyzing the interactions and impacts of each requirement, and how they affect the functionality and usability of the solution in its environment.
- Validation: This includes confirming if the identified non-functional requirements are relevant and achievable.
- Recording: This involves documenting all the elicited non-functional requirements in a traceable and manageable way.
Prioritization of the non-functional requirements can be done using several techniques, but a popular one in Agile methodology is the MoSCoW method: Must have, Should have, Could have, and Won’t have.
| Priority | Definition |
|---|---|
| Must have | These requirements are fundamental to the system and must be included in the solution. Without these, it can’t function. |
| Should have | These are important but not critical for system operation. The solution should function reasonably well without these. However, their absence may affect user satisfaction |
| Could have | These are optional requirements that can enhance user experience or system performance but aren’t essential to operations. They are typically included if there’s enough time or resources. |
| Won’t have | These are least-critical, least-impact factors that won’t be included in the current version of the solution, but could be considered for future versions. |
For instance, in a digital banking solution, data encryption (Must have), user-friendly interface (Should have), personalized content (Could have), and voice command features (Won’t have) could potentially be classified under the MoSCoW method.
Conclusion
Understanding the environment wherein the solution is to be used provides a critical context that aids in the effective elicitation and prioritization of non-functional requirements. This ensures the production of more reliable, effective, and user-centered solutions, with minimized failure risks- a key skillset for an Agile practitioner preparing for a PMI-ACP examination.
Practice Test
True or False: Non-functional requirements such as operations and security are less important than functional requirements.
- True
- False
Answer: False.
Explanation: Non-functional requirements are equally important as they define the system’s operational and security characteristics, which are critical for minimizing failure probability.
Multiple Choice: Which of the following is a non-functional requirement?
- a) Database schema
- b) Password encryption
- c) User registration
- d) All of the above
Answer: b) Password encryption.
Explanation: Password encryption relates to security, which is a non-functional requirement.
True or False: The environment in which the solution will be used does not affect the non-functional requirements.
- True
- False
Answer: False.
Explanation: The environment does affect non-functional requirements. Different environments will have different demands on the operational and security aspects of the system.
Multiple Choice: Who should be involved in prioritizing non-functional requirements?
- a) Only project manager
- b) Team members only
- c) Clients only
- d) All stakeholder groups
Answer: d) All stakeholder groups.
Explanation: Prioritization should be a collaborative effort involving all stakeholders, as different groups will have their perspectives and concerns regarding the non-functional requirements.
True or False: The prioritization of non-functional requirements is a one-time activity in Agile project management.
- True
- False
Answer: False.
Explanation: Prioritization is an ongoing activity throughout the project’s lifecycle as requirements may change based on evolving customer needs or changes in the environment.
Multiple Choice: Why is it necessary to prioritize non-functional requirements?
- a) To identify critical system characteristics
- b) To ensure adequate resource allocation
- c) To reduce the probability of system failure
- d) All of the above
Answer: d) All of the above.
Explanation: Prioritizing helps identify critical system features, ensures resources are allocated to the most important aspects, and reduces system failure chances by focusing on critical non-functional aspects.
True or False: Non-functional requirements cannot be identified early in the project.
- True
- False
Answer: False.
Explanation: Non-functional requirements can and should be identified as early as possible to set the right expectations and plan accordingly.
Multiple Choice: What is one tool used to prioritize non-functional requirements?
- a) User stories
- b) MoSCoW method
- c) Story points
- d) Agile Manifesto
Answer: b) MoSCoW method.
Explanation: The MoSCoW method (Must have, Should have, Could have, Won’t have) is commonly used for prioritizing both functional and non-functional requirements in agile projects.
True or False: Agile models do not consider non-functional requirements.
- True
- False
Answer: False.
Explanation: Agile models do consider non-functional requirements, and they are an integral part of the backlog.
Multiple Choice: Agile process mitigates risks associated with non-functional requirements by:
- a) Ignoring them
- b) Regular backlog refinement
- c) Implementing them all in the first sprint
- d) Relying on customer feedback
Answer: b) Regular backlog refinement.
Explanation: Regular backlog refinement involves reviewing and reprioritizing requirements, including non-functional, based on the changing project context and customer feedback.
Interview Questions
What are non-functional requirements in software development?
Non-functional requirements are specifications about how the system works, like security, reliability, performance, maintenance, scalability, and usability. They are often key considerations in the operations environment where the solution will be used.
How does considering the environment in which the solution will be used help in minimizing the probability of failure?
Understanding the environment helps in aligning the non-functional requirements with the actual usage scenarios. This ensures the developed solution is optimally designed and implemented to perform efficiently in the target environment, thereby reducing the chances of failure.
What is the process of eliciting non-functional requirements?
Eliciting non-functional requirements consists of identifying, capturing, and documenting requirements. It can involve techniques such as interviews, questionnaires, document analysis, observation, and brainstorming in order to understand the environments and expectations of stakeholders.
How can we prioritize non-functional requirements?
Prioritizing non-functional requirements can be done using techniques like the MoSCoW method, where requirements are categorized as Must have, Should have, Could have, or Won’t have. Factors like business needs, the potential impact on the solution, risk, and dependency can also be considered.
What role do security requirements play within non-functional requirements?
Security requirements ensure the system’s ability to resist unauthorized access, data corruption, and potential attacks. They encompass a critical aspect of non-functional requirements and directly influence the reliability and trustworthiness of the developed solution.
Why is it important to consider non-functional requirements in Agile software development?
In Agile, customer satisfaction is prioritized. By considering non-functional requirements, teams can ensure the product not only does what it’s supposed to do (functional requirements), but also works well in the intended environment, provides a good user experience, and meets the users’ expectations about performance, reliability, and security.
How does defining non-functional requirements early in the project help?
Defining non-functional requirements early helps team members understand the expected performance, security, usability, and other such aspects. This can guide the selection of appropriate technologies, influence design decisions, and avoid costly changes later in the project.
How does Agile methodology help in managing non-functional requirements?
Agile encourages continuous feedback and iterative development, which enable teams to understand, incorporate, and adjust non-functional requirements throughout the project. This contributes to developing a product that not only meets functional needs but is also dependable, secure, and user-friendly.
How should non-functional requirements be documented in the Agile process?
Non-functional requirements can be documented as user stories or conditions of satisfaction. They can also be noted in the definition of ‘Done’, included in acceptance criteria, or represented on a separate ‘Non-Functional Requirement Backlog’.
How are operations requirements considered non-functional requirements?
Operations requirements define how the system will operate, including factors like system performance, availability, and recoverability. As these aspects describe how the system should behave rather than what it should do, they are considered non-functional requirements.
How can non-functional requirements impact the cost of a project?
Non-functional requirements can significantly impact the cost as they often influence the choice of technology, design considerations, and testing efforts. Ignoring or inadequately considering non-functional requirements can lead to expensive and time-consuming adjustments later in the project.
What is the role of a PMI-ACP in eliciting and prioritizing non-functional requirements?
A PMI-ACP is well-equipped to facilitate the elicitation, documentation, and prioritization of non-functional requirements by engaging with stakeholders, considering the environment, and guiding the team in aligning the solution with these requirements.
How can you minimize the probability of the failure of a solution?
The probability of failure can be minimized by thoroughly considering non-functional requirements, understanding the operational environment, and maintaining continuous engagement with stakeholders. Regular testing, iterative development, proactive risk management, and proper prioritization of requirements can also contribute.
Why are non-functional requirements sometimes called ‘quality attributes’?
Non-functional requirements are often referred to as ‘quality attributes’ because they define the qualitative aspects of the system, such as usability, reliability, performance, and security. These inform how well the system performs and meets users’ expectations, determining the overall quality of the solution.
Can non-functional requirements become functional requirements over time?
Yes, certain non-functional requirements can evolve into functional requirements as the system matures. For instance, a requirement about the system’s response time may become more specific, turning into a functional requirement about the implementation of a performance enhancement feature.
extutorials.com