BA Bites - Mastering Non-Functional Requirements - podcast episode cover

BA Bites - Mastering Non-Functional Requirements

Jun 21, 202411 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Struggling to write clear and concise non-functional requirements (NFRs)? Join Benjamen as he breaks down the essentials of NFRs in bite-sized episodes on BA Bites.

This podcast is your go-to guide for understanding how to structure your NFRs effectively, ensuring they are measurable, achievable, relevant, and time-bound (SMART).

Whether you're a seasoned BA or just starting out, BA Bites will equip you with the knowledge and skills to write rock-solid NFRs that set projects up for success. Tune in for actionable tips, practical examples, and clear explanations that will have you mastering NFRs in no time

Subscribe now and take a bite out of better NFRs!

Transcript

The Better Business Analysis Institute presence, the Better Business Analysis podcast with Tinsman Walsh. Welcome back to the BA bite session. And this week we are going to be talking about how to capture non functionals the right way. That's right. Non functional requirements are a special type of requirement. They focus on the non functional elements of the solution or process that you're going to be capturing requirements for.

But unlike other user story types, other requirement types, non functional requirements are deeply coupled and deeply focus on the solution components. OK, so one way of looking at that or explaining that are the features or the solution behind the features that ultimately is going to be built or bought or considered as part of options analysis.

And So what you need to do when you do non functional requirements is actually something that's not, I guess, traditional in terms of BA. What you need to do is you really need to work really closely with the architecture team within your organization. And if you don't have one, then you can look at external sources to help you with this non functional requirements. Talk about different elements of

the system. There are categories for non functional requirements and there actually is if you like a pretty good finite list that you can use. Saying that another way, non functional requirements can actually be used as a checklist exercise. OK, so you can actually have a pre list of non functional requirement areas and you can work through with your product owner, business owner, whoever your your setup is for your

project. And you can go through them one by one, ideally with the help of a tick league or an architect to explain what those non functionals mean. They are generally in technical language, but they should be written as a requirement in more business language. And I'll and I'll give you an example in just a minute. This is not how you do business analysis when capturing requirements at the highest level or at the functional

level. And IIBA talk about solution requirements or requirements that actually relate to the solution. This is one of the areas, but specifically non functional requirements is unique. And so you use different techniques for this, right? So how do you actually do this? So top tip, the top tip is you load up an Excel spreadsheet, right? You put in the different conceptual solution component. Don't worry about what they that you've got them, right?

So they might be simply back end UI, just really, really high level chunks of the solution. So these are the ones where users are wanting to perform functions with or interact with. So they are actually your feature areas. We'll go on to that on another day. And they, they can just be conceptual, OK, enough that the architect generally knows what you're talking about when

talking about them. The solution and how that's put together, the Lego blocks that they use may be completely different and that's OK. OK, It's just talking about areas. So that's your that's your focus area. So I would say that it's good to use that as your actor. So what I say is as a new education website, right? That's the feature or that's the feature group. So that's cool. New website. So we've talked about the general conceptual area. I want to write so that I can.

So you use the same language you use as user stories and it's #1 same template. But some of our non functional requirements have something that I would refer to as metrics and measures. All right, so you can actually expand that user story pattern for those types. OK, it doesn't. This applies to about 8090% of the non functional requirements you might have. You can probably use some someone can take the opportunity to read and write them all. So they have a metrics measure,

you know, and A and a pattern. So they have the ultimate non functional list. But I'll give you an example. So as a new education website, I would like loading response times. That's the non functional element loading response times, right? And yes, you could have a functional requirement that talks about I want the I want to be able to quickly, you know, access or I want the page to load. But this is really a non functional requirement.

So sometimes you don't pick these up as a functional area. And that's why non functionals are so important. They actually translate to non functional areas. So you need to use this list, which is a finite list and you'll say as a education website, I want to respond right? Or load within. And then you could have a metric load within X seconds.

OK, So load within being the being the metrics and X seconds being the measure so that I load like the most common website that users are used to experiencing, right? So a user, for example, will get the experience of what they think fast load times are on a website based on the general loading that's expected from a website, right? So that metric is usually captured by eco programs or web performance programs. And they generally say about two

seconds. If if you're website takes longer than two seconds, it's going to take a while to load. OK. And there are so many technical elements that go into making sure that that runs that way. OK, It's not as easy as just running in two seconds. It's actually easy to create a website and make it reload in

five seconds, right? But if your website is reading information from other systems, is responding with content that needs to be pulled from a back end, is running on CMS system, a content management system like WordPress, it will need to be optimized to be able to run in two seconds. It can't too much content. There are so many implications of that requirement that it actually matters, right?

But let's just say our product owners saying, well, we need this website to run like the standard website out on the Internet that users are used to using. So we have a non functional requirement. That's one example. There will probably be about 50 non functional requirements if it was both a web and back end project. OK, that gives you an idea of the magnitude. And they're all written the same kind of format, the same pattern. And I just want to be clear that some of these are not just

metrics based. Some of them are binary based. So if you have a piece of legislation that requires you to hear with, for example, native language, you're in a country which has native speakers and your responsibility is to serve them as well, then it could. It's just simply that as an education website, I will be able to present content in both English and in native language X so that I can cater for both English speakers and our native audience, right.

So you would replace that with whatever your native peoples are and in our case Maori in New Zealand, that's pretty common. So you know, you would be able to do bilingual on the website. Again, that has huge implications to how you build the system, how you translate and all the rest of it and how you capture content. But that's the non functional requirement. So this is quite a a really good topic. You can spend hours on it, but I want this to be a bite. So you go through that list,

right? And you get that list from a list of architects and there are categories and there are sub questions. So that list is finite. If you don't have it, search on the Internet. We have a great list at the Better Business Analysis Institute. Once you get onto our courses, it's part of our toolkit. But there is a finite list. You can start building yours today and if you don't have any for your project, just start right for that one project.

You'll start that 50 or whatever you'll get close and then you can take that and reuse that across any of your other projects. So it's like a one off exercise. Yes, they evolve OK, and they get they they change as system solutions change. And that's why non functional requirements are so deeply coupled with solutions. When we when single sign on was introduced, that now became a

feature that people wanted. They didn't know it and they might not tell you as ABA in the functional area and the requirements captured that they want to not have to log in twice when they used a multiple systems across your organization. But that's now a feature that's there. So that would be included in your non functionals and you'd be prompted as ABA to go, Oh, would you like the system to allow users to just log in once to the domain and then they can have access to this new

solution? And they're like, yes, yes, of course. And they would have you would have never come up with that if it wasn't in this checklist. That's why it's so important. Obviously the non functional requirement would say, you know, or as a solution, I, I'm going to implement single sign in so I don't have to maintain my own list of usernames and passwords, which is a, which is causes the potential for security risk. That's really why why we have single sign on from technical point of view.

So you have your your Excel spreadsheet, you load in your actor, which is your solution components. You have what they want to do just in the user format. And some of those will have metrics. You have a checklist and you go through down with the product owner, ideally with a technical person who can explain some of those things. And those won't just have technical things in them. Just to be clear, some of them will have legislation and laws and company policies that need

to be applied to the solution. So if there is something around you, you are building something that's extra secure as holding personal information. There'll be non functional requirements will most likely be must have as in the product owner doesn't really have much choice around how you store that information because there's legislation that's imposed on you. They should all be in the non

functional requirements. OK, so the easy way is to do that in Excel, have a standardized list, go around, do a bit of work on that, and then it's actually really easy. You just take that list every single project and you just go through it and you evolve it. And I believe that the ultimate list of non functionals for your organization, the matrices, and it won't be written perfectly and it won't be written in your Excel spreadsheet format, should be owned by the architecture

team, right? That's my Bo bite. I hope you learned something about non functionals and how you can get started on those. Obviously not an in depth secession, but I'll make sure I do one in the future.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android