Key Characteristics of Effective Agile Requirements

7 min readNov 26, 2023

This tutorial is part of the “Mastering Agile Requirements: A Guide for Business Analysts” series. For an overview of all tutorials in this series, please visit https://medium.com/@kiphughes/mastering-agile-requirements-a-guide-for-business-analysts-62b54564def8.

Great requirements are the bedrock of Agile projects, steering development to ensure that the final product resonates with user needs and business objectives. They encapsulate a set of characteristics that are essential for a dynamic and responsive Agile environment:

1. Relevant

A requirement must first and foremost be relevant, addressing a real business need or delivering value to the customer. This ensures that the project’s efforts are aligned with its goals and provides a clear direction for the team.

2. Clear

Clarity in requirements is pivotal for the successful execution of a project. It ensures that all stakeholders have a shared understanding of what is expected, leading to precise implementation and effective communication. To achieve this level of clarity, the language used must be explicit, leaving no room for ambiguity, and should be universally understood within the context of the project.

Utilizing RFC 2119 for Clarity

RFC 2119 is a cornerstone in the realm of technical documentation, offering a standardized set of keywords to express the degree of requirement within technical standards. These terms include:

MUST or SHALL: These terms indicate that a requirement is absolutely mandatory. There is no room for negotiation; the specified action is essential.
SHOULD: This term conveys a strong recommendation. While not mandatory, a “SHOULD” requirement carries an expectation of compliance unless there is a justifiable reason not to.
MAY: This term offers flexibility, suggesting that a requirement is optional. It allows for discretion in deciding whether or not to implement a particular feature or function.
MUST NOT: This term is used to express prohibition. It clearly states that a certain action or feature is not allowed.
SHOULD NOT: This term advises against a certain action or feature. While not absolutely prohibited, there is a strong preference to avoid it unless necessary.

RFC 2119’s Role in Contractual and Compliance Contexts

In contractual and compliance contexts, the clarity provided by the precise language of RFC 2119, coupled with qualitative and quantitative requirements, is invaluable. It ensures that all parties have a common, unequivocal understanding of the requirements, which is essential for mitigating the risk of disputes and ensuring aligned expectations.

RFC 2119’s Role in Shaping Development and Stakeholder Expectations

The use of RFC 2119 terms, along with a focus on qualitative and quantitative clarity, sets clear, actionable expectations for both the development team and stakeholders. It defines the boundaries and expectations of what the system or project is supposed to achieve, which is critical for the subsequent stages of design, development, testing, and acceptance.

Emphasizing Qualitative and Quantitative Clarity

To further enhance clarity, requirements should be both qualitative and quantitative:

Qualitative: Requirements should provide a clear description of the quality characteristics or attributes that the system should exhibit. This includes aspects like usability, security, and aesthetics.
Quantitative: Requirements should include measurable criteria whenever possible. This means specifying numbers, percentages, or other units of measure that can be objectively assessed.

By ensuring that requirements are qualitative and quantitative, we provide a comprehensive understanding of what is expected, allowing for better planning, execution, and assessment of the work to be done.

3. Concise

Each requirement should be concise, containing no more information than necessary. This brevity ensures that the focus is maintained on the essential aspects of the requirement, making it easier to understand and implement.

4. Atomic

The concept of atomicity in requirements is pivotal for creating a clear and manageable set of expectations for a system. To be atomic, a requirement must encapsulate the smallest unit of functionality that provides value and stands as a complete element in its own right. This concept draws from the principle of cohesion in software engineering, which advocates for a module or class to have a single, focused responsibility.

An atomic requirement is characterized by its singular focus. It addresses one specific function or business need, which streamlines the processes of comprehension, estimation, and testing. This focus on singularity avoids the pitfalls of conflating multiple functionalities into a single, complex requirement, which can lead to ambiguity and complications during the development cycle.

Consider the requirement:

“The system SHALL provide the ability to save and print reports.”

This statement, while seemingly straightforward, actually conflates two distinct functionalities: saving reports and printing reports.

To adhere to atomicity, this should be decomposed into two separate requirements:

“The system SHALL provide the ability to save reports.”
“The system SHALL provide the ability to print reports.”

This decomposition not only clarifies the requirement but also allows for each function to be developed, tested, and potentially released independently. It enables developers to prioritize tasks more effectively and testers to create more focused test cases. Moreover, it facilitates clearer communication with stakeholders who can better understand and track the progress of each discrete function.

5. Testable

For a requirement to be actionable, it must be testable. It should come with clear acceptance criteria that define how to confirm the requirement has been met, allowing for objective verification.

6. Feasible

Requirements must be feasible; they should be realistic given the project’s constraints, such as time, budget, and technology. This ensures that the team can actually deliver what is being asked for.

7. Prioritization

In Agile project management, prioritization is a critical process that determines the order in which requirements are addressed. It ensures that the most valuable and impactful requirements are developed first, providing quick wins and early value delivery to stakeholders. One popular method for prioritizing requirements in Agile is the MoSCoW method, which categorizes requirements into four buckets:

Must Have: These are non-negotiable requirements that the project needs to be successful. Without these, the project delivery would be considered a failure.
Should Have: Important but not vital requirements, which could be included in the product if time and resources permit.
Could Have: Desirable requirements that are not necessary for launch and can be included if they do not impact the delivery of more critical requirements.
Won’t Have: Requirements that have been agreed upon as the least critical, lowest payback items, or not appropriate at this time.

By using the MoSCoW method, Agile teams can focus their efforts on what truly matters for the project’s success, ensuring that the most critical functionalities are delivered first. This approach aligns with Agile’s iterative nature, allowing for flexibility and re-prioritization in subsequent iterations or sprints based on feedback and changing needs.

8. Traceable

A great requirement is traceable. It has a unique identifier that allows it to be tracked from its origins in business needs through to its realization in the final product.

9. Solution-Agnostic

When drafting requirements, it’s crucial to adopt a solution-agnostic perspective. This means that the requirements should emphasize the desired outcomes rather than prescribing the methods to achieve them. Such an approach affords the technical team the latitude to explore various solutions, fostering innovation and potentially uncovering more efficient, cost-effective, or robust ways to meet the requirement. It encourages creative problem-solving and leverages the team’s collective expertise, often leading to better system design and architecture.

Advantages of Solution-Agnosticism:

Encourages Innovation: By not dictating the solution, teams are free to brainstorm and propose novel approaches that may offer superior results or efficiency.
Optimizes Resource Use: Technical teams can select the most appropriate technologies and methods based on current resources, expertise, and project constraints.
Future-Proofing: A solution-agnostic requirement is less likely to become obsolete as new technologies emerge, since it’s focused on outcomes rather than specific technologies.
Vendor Neutrality: It avoids locking the project into specific vendors or technologies, which can be beneficial from a procurement and maintenance standpoint.

Necessity for Solution-Specific Requirements:

When detailing requirements, while a solution-agnostic approach is generally beneficial, certain circumstances warrant specifying particular solutions or technologies to ensure the system’s effectiveness and compliance. Here are those scenarios:

Integration with Existing Systems: When the new system must integrate with existing infrastructure, specifying technologies may be required to ensure compatibility.
External Technical Standards: Certain industries have established technical standards or protocols that must be adhered to, and in such cases, the requirements may need to specify these standards.
Legal and Regulatory Compliance: Legal or regulatory frameworks may mandate specific security measures, data handling procedures, or audit trails that dictate certain technical solutions.
Organizational Strategy: Sometimes, an organization may have strategic partnerships or commitments to certain technologies that must be reflected in the requirements.

For example, a requirement might typically state, “The system MUST authenticate users securely, ensuring compliance with current data protection standards.” without specifying the authentication method. This is solution-agnostic and allows the team to consider various authentication protocols.

However, if there’s a legal requirement that all user data must be encrypted with a specific encryption standard due to privacy laws, the requirement would then need to be specific: “The system MUST use AES-256 encryption to ensure all user data is encrypted in compliance with [specific privacy law or regulation].”

In essence, while a solution-agnostic approach is generally preferred in Agile environments for its flexibility and encouragement of innovation, there are times when the nature of the project or external constraints necessitate a more prescriptive approach to requirements. The key is to strike a balance that maximizes innovation and flexibility while ensuring compliance and integration needs are met.