Power Apps – Requirements

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.

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 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.

Story’s

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.