Power Apps - Requirements
Tags: powerapps, powerplatform, lowcode, agile
Published: 2024-04-22 05:37:57

Agile has its lovers and haters, but one thing I hope everyone can agree on is the value of requirements.

With any Power Platform project requirements should be completed. Requirements are kind of the contract between the developer and solution owner, they ensure everything 'required' is complete before the project is signed off. Even with a citizen developer project, where you are the developer and owner, requirements should be completed. They ensure that nothing is missed and help future developers understand what was done and why.

![requirements](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zoe81x2btclztzbheqpq.png)

As I said it should be looked at as a contract, and allows a set criteria for completion. Without detailed requirements you will often get 'scope creep', where the solution owner continuously changes their mind and adds new features. With this uncertainty you will generate inefficiency by:

- Be unable to plan work effectively 
- Miss return on investment deadlines (ie saves £100 per week, 4 weeks late equals £400 waste) 
- Inefficient build order 
- Wasted development time on dropped features

Requirements also have the added benefit of being the basis for your testing plan (to read more about testing check [this](https://dev.to/wyattdave/power-automate-how-to-test-your-flows-130n) out).

There are 2 main types of requirements, Objective and Technical.

I generally recommend Objective for Apps/Bots, and technical for automation (but this is guide not a rule, with different tasks within the same project being different types).

## Objective 

These are designed to replicate a user interaction, focusing on the users experience rather than set actions. The developer has the freedom to implement the solution as long as it meets the users desired outcome. As an example the requirement could say "show details", the developer could then either implement a page navigation, or make a container visible.

To ensure the requirements follow a user journey they are structured in a particular way, with the following format:

> Given, When, Then

**Given** This is the current situation the user is in, it could be is on a screen, has pressed a button, or received a success response.

**When** The action taken by the user, this is generally a click/tap, swipe, long press, etc.

**Then** This is the expected behaviour to happen after the when, so could be shown details, submit update, cancel, etc.

The 'Given,When,Then' is collectively called a AC (Acceptance Criteria), and are sequentially numbered in the most logical order.

> AC1
> **Given** the user is on the home screen
> **When** they click the add button
> **Then** show the new input form

The ACs should cover both the happy and sad path (when things work and when things don't):

> AC3
> **Given** the form has been completed correctly
> **When** the user clicks submit
> **Then** send the data to the database
> 
> AC4
> **Given** the user has clicked submit
> **When** the data is saved successfully
> **Then** display success message
> 
> AC5
> **Given** the user has clicked submit
> **When** the data is not saved successfully
> **Then** display the error message from the api

## Technical

These are more focused on specific needs, almost like a checklist. They can be very prescriptive and give the developer less flexibility. An example could be the table must have these fields.

They are generally single sentences and are also called ACs, but with a leading T (Technical), and follow the sequential pattern, though the order often has no impact.

> **TAC1** All orders over 7 days should be deleted
> **TAC2** All orders under 7 but over 4 should be tagged as "ready"
> **TAC3** All orders under 5 days should be added to the "to email list"

NFRs (Non Functional Requirements) are very similar to Technical Acceptance Requirements and follow the same pattern.

![objective vs technical](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gr4rgoevejikj387crwq.png)


## Stories

The requirements should be grouped into a story, the story should cover a piece of value, so when all of the requirements are complete value can be added to the project. This is because grouping the requirements into a block of value helps the developer understand the reasoning and motives of the requirements. In addition to help this is the user description, which lists all of the users of the solution, with how they use it to get value.

This should follow the below pattern:

> As a, I want to, So That

An example would be:

> **As a** customer support operator
> **I want** to enter customer details
> **So that** I can track their case

And each story can have multiple different user descriptions, so the above could also have

> **As a** data analysis
> **I want** all customer details entered accurately
> **So that** I can use the data to forecast demand

---

I know my flavour of requirements is based on Agile, which might be unpopular, but the key message is that you should have requirements, however you structure them. Making the solution owner think about exactly what they want, and documenting it in a way that everyone understands it is key for any project.