What Makes a Good Requirement in Agile Development?

Written By Andre Jahn

In the agile world, requirements are often secondary. Instead of page-long documents, there are often developer tickets with a few keywords about the function that needs to be implemented.

However, a good requirement is important for several reasons:

* Fewer queries

* Better estimation of the effort

* Improved quality, as it ensures developers have all the necessary information.

Efficiently describing a requirement can save considerable time and enhance the quality of the outcome.

This is especially true when working with distributed or remote teams. A good requirement also compensates - up to a certain point - for the different skill levels of the developers.

High-quality requirements can be created with the help of AI. The AI does most of the writing for you and ensures that the requirements are correctly structured and complete and takes into account the compliance rules stored.

Ticket Size

Regardless of the used development methodologies in the project (Scrum, Kanban, etc.), the implementation of a ticket should ideally fit within a 2-week timebox.

Tickets that require more effort should be split into smaller tickets.

Heading

The heading should be short and concise so that it can be easily assigned on an overview page (Kanban board).

Context of the Function

Developers do not usually take part in discussions with the specialist departments. They therefore need a context in which the planned function is to be used. This should also explain details which are summarized later in the acceptance criteria.

Nevertheless, care should be taken to ensure that the context description does not become too extensive - a long context description is a good indication that the ticket is too extensive and should be split up.

It is also helpful for the developer to reference to other requirements that are related to the ticket (e.g. by linking the tickets or summarizing them under an epic). This allows the set context to be taken into account during development.

Acceptance Criteria

The acceptance criteria contain the conditions that must be met for the product owner (or customer, project manager, etc.) to recognize the functionality as complete.

These criteria are the developers to-do list and can also be presented as such. If further explanations are required, these are included in the context description.

Test Cases

Traditionally, test cases are not considered part of the requirement. However, it is practical to include them as acceptance criteria. This approach is beneficial as it allows developers to identify potential errors early on. The test cases, being more technical in nature, highlight the importance of specific functionalities.

Compliance rules

Like test cases, compliance rules are also not part of the classic requirements. Nevertheless, as compliance is of great importance - especially in the area of critical infrastructure - they should be included. Viewing compliance rules is also not a developer task and is therefore often overlooked.

Example

Heading: Upload PDF File

Context: The application requires functionality that allows users to upload PDF files via a REST API. This function is intended for users who are already authenticated via Single Sign-On (SSO). Each PDF file must be assigned to a unique identifier (UUID)

Acceptance criteria:

  • Development of a REST API: The API should make it possible to upload PDF files.

  • Authentication: Only users who are logged in via SSO are allowed to upload files.

  • Storage in S3: The uploaded PDF files should be stored in an Amazon S3 store and all files must be encrypted. (compliance rule)

  • Unique ID: Each uploaded file should be given a unique ID so that it can be easily identified.

  • File size limit: The uploaded PDF must not exceed 5 MB.

Test cases:

  • Test case for successful upload: Verify that an authenticated user can successfully upload a PDF file.

  • Test case for authentication: Ensure that a non-authenticated user cannot upload a file.

  • Test case for storage and ID assignment: Verify that each uploaded file is correctly stored in the S3 Store and assigned a unique ID.

  • Test case for file encryption: Ensure that all uploaded files are stored encrypted in the S3 Store.

  • Test case for file size restriction: Confirm that files larger than 5 MB cannot be uploaded.

Andre Jahn