In this next post as part of my series on Power Platform solution architecture, following on from my last on capturing requirements and workshopping around this, I’d now like to focus on how we can categorise the requirements we’ve gathered to take these further, and finalise.
Categories
So let’s start by discussing the categories we can use to put requirements into. We can categorise these as non-functional and functional requirements.
Functional requirements describe what a solution needs to do, or behaviours it should demonstrate to the user. On the flip side, non-functional requirements refer to commonly more non-behavioural aspects of the solution such as performance requirements, requirements for data location and more.
Why categorise like this?
So you might be wondering why we’d categorise requirements like this? Well lets think about the categories we actually have here and who we’d then perhaps say have conversations about each type with. Conversations we have about functional or behavioural requirements are probably going to be had with stakeholders such as business owners and solution users, whereas non-functional or technical requirements are going to be had with people who have skills focused in these areas and perhaps sit in IT teams.
It’s important to categorise like this so we then have conversations with the correct people about the right chunk of requirements. This will ensure we get the correct detail out of our customer that we need and that we build a solution that works for the customer and all stakeholders on their side.
Handling functional requirements
Theres a few different ways we can handle the two different types of requirements we might look at gathering. When it comes to functional requirements we need to make sure we’ve finalised these and tidied them up by capturing things like acceptance criteria and exceptions.
Acceptance criteria will give us something to properly work against and determine work items as complete using. Make sure you capture this friends to make project progress happen more smoothly!
Handling non-functional requirements
When approaching non-functional requirements there’s a couple of other things we may want to consider. The ability to actually achieve a requirement and its feasibility is a huge thing here. It’s important to manage expectations with your customer and not over promise on things that won’t be possible, or that will align with functional requirements.
Another thing to consider when approaching non-functional requirements is to measure compliance against policies or rulesets you’re working against. This should be baked into testing you do as well so be sure to handle these requirements with the appropriate work items which embeds this into your implementation and wider engagement.
What’s coming up?
So friends, what’s coming up? 👀 In the next post, we’ll look at how we can wrap things up and finalise requirements to move into the next phase of our engagement! Stay tuned friends 💖