The Hidden Heroes of Tech - Non-Functional Requirements

The Better Business Analysis Institute presence. The Better Business Analysis Podcast with Kenjamin Walsh Hi everybody, and welcome back to the Better Business Analysis Podcast with Benjamin Walsh. And today we're going to get to a topic which is often left to the side done notoriously badly by BAS, are sometimes done by our architects, sometimes list listed in a kind of a checklist, and have caused more product application failures than you know anything to do with the

functional side. And they are non functional requirements. OK, so they're the unsung heroes of tick, the non functional requirements, and we've got to dive into what they actually are. There is debate in the borderline sometimes and we have to talk about them. And you know, this realm is often shrouded in mystery. It's a world where speed and security and even the happiness of your users hang in the balance. OK, and the Savior, the overlooked corner or hero is doing non functional

requirements. Well, I do get asked about them quite a bit. And we do focus a lot when we talk about Agile or we talk about, you know, getting things out out the door or a typical day in the life of ABA. You're looking at jobs to be done and you look at the functions, right. You look at the features, you look at the the functional requirements of getting from A to B. But we often the getting from A to B is important. Yes, it is.

And you know, you might have preferences around UX and UI and we'll we'll touch on that in terms of where that sits in terms of categorization of requirements. But a great example is, have you ever gone to a website? I know I've been on the opposite end. I've built a website and then it's bloody slow. Then you know there's nothing more frustrating then a slow website to kick users off and there's, you know, plenty of stats around how long it needs to take.

And less than two seconds is the is the common term, which I'm sure will get shorter. If users aren't saying content on your website loading appropriately within two seconds they're going to move on. And it's even more frustrating when you don't have choice. So like a government website, you know you may be some meta form and then you wait and now you and then and and if things go wrong there is a a mistake.

Then sometimes you go back to the form with your with all your information and then you need to submit again and that if that happens in a payment collection screen for example, you can start to think when I clicked submit the first time and the page started to spin was it taking my money? And now if I clicked submit again, am I now doing a double purchase? These are the kind of questions that users end up having when things aren't working well and

it's not just around speed. So what are non functional requirements? If you're a BAI want you to think of a definition, I'll give you a few seconds to think of that. What is a non functional requirement? And a good enough answer isn't everything that isn't functional, despite the fact that that's usually the yardstick, it's everything else that might come up a non functional requirements are.

You know, I'm not going to give you a formal definition, you can actually go on to Wikipedia or just Google that, but they're simply. I just want to explain what they are in a conceptual way, because I think that's easy to remember. That's simply the how behind the what. OK, so they tell us not what the system does, but how it should do it and there are actually clear categories of non functional requirements definitely come from the TOG

LOFT world. It's just the architecture world, one of the bodies of knowledge there and we are talking about speed, security, usability and reliability. There are more but they they kind of are categorized into these higher level buckets and so you can actually start to have a bit of a it's not hard to prompt yourself is if you have these high level non functional requirement categories you can start to prompt yourself and and you can actually ask users.

More importantly, is it important that there that this that the information you get or this process happens straight away or is it overnight, They'll always say straight away but you can push them on the cost of that. If you're working on web app then you know obviously you want

fast feedback to users. But for example if you are taking data, a data feed which you get once a day and you're wanting to get that into the database, it look it might not matter whether or not that's done daily for example as opposed to hourly. That process overnight could be OK or otherwise you know it's going to cost more to build tech

that works on a hourly basis. One of the other things around if we just go down that rabbit hole with cloud computing is that you're paying for commute computing power now. So non functional requirements and the relationship with the cost, the ongoing cost of your solution are really important. And I've seen a number of cloud implementations across government and the private sector where people have moved to cloud and non functional requirements haven't been

captured. So simply just taken the application they had on Prem or pseudo on Prem or a SAS provider and brought it on to PES and they've moved, let's just say if you don't know what those acronyms mean, we'll go through those. But effectively you've taken your application, which might have been old, and you've moved

to the cloud version. You've moved over all the functions and data that you need and you go success and and you should pat yourself on the back because that's easier said than done. But then suddenly you haven't captured how much it costs to hold that information. And you're like, oh, we've got enough. We've bought enough storage, just like your OneDrive, your Google Drive. But actually if you're running on an enterprise piece of software, there's transactions

that happen. So you're sending information from one system to another and you'll find that that is charged and that can be very expensive. Transactions become can become exponentially expensive depending on how often you're running those. So any of those kind of speed to run processes really need to be written down in your requirements matrix, in your backlog. You know as a card, as a user story if you like.

They need to be in there and I would even suggest running epochs for these high level non functional categories and then stories around them. They do need to be captured and you might think, well that doesn't matter, you know, it's not as important as getting, you know our new CRM system, maybe our in house CRM system onto the cloud because we've got to reduce kit and we're going to you know host it in the cloud and it's going to be great and everyone can access it.

But if that CRM system has an integration point for example with another cloud provider, then you're paying what's called address fees or fees to send information in and out of the system and they are expensive. So if you're running that, you used to run it on Prem, it didn't matter. You're running it, you know, all the time, every second. If you moved it to the cloud, you're now paying a per second charge for for that transfer and the systems that control that.

And I've seen people literally you know quote a system for a couple of $1,000,000 maybe $5 million of implementation cost and their operational cost for just transactions just for sending information in and out of systems be moved from say maybe zero, 100,000 to 5 million. So you know and and they didn't, they didn't budget for that, that was never catered for in the capital or or project cost. So no one ever talked about that.

So you've got to be really careful with that and that non functional requirements are becoming, there's a bit of a trend to you know be hot on this again because of cloud computing even though we should have always been hot on this. OK. So non functional requirements are simply the how behind the what let's say we talk about and the and the different categories you can there's actually some really good templates out out there for going through here.

If you look at cloud assessment matrix, they're actually a really good starting point. I actually have one that I've used in New Zealand. We have the we have the Department of Internal Affairs or the the I can't remember what the American equivalent is or the British one.

But it's effectively the the government department that looks at looks at internal issues and internal things and they as a result they set standards sometimes for how other government departments or you know the government the New Zealand will interact or what systems we're allowed to have or not. For example you know if they're a security threat you know if there's any hosting overseas for example from a kind of a spine network point of view.

And they put out early actually a cloud assessment tool just an excel spreadsheet which had a whole lot of non functional requirements and it kind of made you think a really really really good starting point for in these categories.

But a whole lot of questions like you know the time it takes for a transaction to go through and into security, it was like does it does the system allow multi, multi center, multi factor authentication, TFA, all of that stuff that that's the requirements I'm talking about and actually you know multi factor authentication or two if I if you like. Which means that you've got two ways of authenticating who you

are. You would have experienced which is you log into a new website, the website goes you know into your phone number. They send you a code, you enter the code and so they know that you're you're not only the person who is on the website, you're also the person with the phone number. And so those two things, two things, multi factor or two. Usually they use two as opposed to thousands. Those two things validate who you are and it makes it more secure next time you log on.

So you create an account and then no one can copy who you are unless they've got both your mobile device to devices of yours. And so that can increase the security around your account. Now that won't happen, that there's there's some, there's some set up costs involved in setting that up and some cloud providers make it easier than others. And that whole kind of process of logging in, getting a code, getting it sent to your phone,

you know, that's that's work. And if you haven't included that in your requirements as ABA, it won't be done. You know it'll just be a username and password so you have to explicitly ask for it. So that's a great example of a non functional requirement that that would hit most people today. Even things around the complexity around the the password and you know making X amount of characters long, which again is a security requirement, that's a non functional requirement.

So a non functional requirement is anything that that you're it's connected to a what? So you don't have non functional requirements that aren't just out in the ether they're connected to a greater process step you're trying to perform. But it's like are there any business rules or any how rules that you need to worry about when that step happens.

So the best thing to do is to focus on your process levels as you're running in your requirements and then you go OK well this step is logging in for example and you might go down lower and you might have some screens you go. What do we need to worry about in terms of logging in Look at the checklist go OK well these you know these lots of applications have done this before. What a list of non functional requirements I need to worry about Well OK well I need to think about multi factor

authentication. I need to think about password resets, which is a function by the way. So not there might be non functional requirements there which is not to include the e-mail address from security point of view in the e-mail these a lot of these can non functional requirements also can come from your development team so they can just they just do it by default. Some of these things even though you don't ask them ask them so

you need a conversation. I've once for example we're doing an MVP which was an internal an internal piece of cat and application. We just wanted to test it. I didn't really care about the function around multi factor authentication at this point. We could have added that later. You know it was an internal system, it was already.

There's something called SSO as well which is Single Single Sign on which is allowing your credentials from your I guess Active Directory or your security system that controls who you are, your identity management system. For it to you only have to log in once and then say for example you logged onto the corporate network and then when you use this application it takes your details and knows you are who you are and so you don't need to sign in at all.

So all those features anyway, I wasn't explicit about not wanting those features to start off with and I there was a delay in terms of getting this application out the door to show people and I just wanted a simple kind of username and password. And actually the devs, when I examined the work they'd done and they demoed it to me, I realized they had implemented those features.

And you could say that's great and it would have been fantastic as they brought that up with me. But actually they were trying some new stuff, they wanted to do it. And so if you're not explicit about these things, sometimes your devs can actually just go and do them or do the wrong thing. And in that case you know maybe I should have said out of scope for this piece of work or a

won't have requirement. Would have been a bit for me to manage that I should have done a won't have requirement said multi factor authentication and single sign and just won't require won't have requirements for now and make it really explicit that I'm not having those things. So some of those non functional requirements, your architect definitely your architect and your devs may even implement or worry about those non functional requirements and do them for

you. So being ABA you should really be leading those through. They should be things that your end user has thought about that you've raised with them. It usually does come from bottom up, as opposed to them asking for it. Then a lot of times people won't ask. For example, we'll just assume that your website's going to work fast.

Now the technical team might know that because you've got a lot of features on your website, for example, you know a low a very simple kind of content management system, WordPress for example, which is a a system you can use to make websites. It's notoriously yet slow as you add more and more features. Plug Insurance, they call it, because there's a whole lot of code that runs and it doesn't necessarily need to run.

They call it bloatware. And so you install this and actually it's fantastic for making a quick website. But then as you add more and more features, the speed drops. And without someone who knows what they're doing and without optimizing it, their website could be very slow at the end. Now your customer may not be happy about that and they may not have asked for it to be fast. So you as a VA need to prompt these questions. You need to think about these things. OK. I hope that's clear.

Now the other thing about non functional requirements is that they they impact your everyday life. OK, so we talked about the example of a slow website for online shopping, right? Like if you went to a website, maybe it's not like the eBay or Trade Me in New Zealand Where or Gumtree in the UK. Those websites where you would go to them anyway and if they were slow then they were you knew they were so big that they'd probably resolve the

issue. But say you went, your friend recommended you going to, I don't know a local website to look up some crafts or some, I don't know jewelry they were making and you went to the website and it took you know a good 3 minutes to load. You might think about not visiting there again. It could be just put you off, especially if it was just a favor you were doing again.

If that website was slow and you went to the checkout and you clicked pay and then it took two minutes to load or and you know and you moved on, you might get worried that your payment hasn't been successful and things like that. It it it isn't It isn't true that just because the website's slow there might be more bugs or functions that are not working and more you know other other things wrong with the website,

for example like security. But it does mean that they that whoever's been involved in that hasn't thought about these non functional requirements. And there can be a perception for example with speed, that if a website is slow, you know is there something wrong and therefore there could be security concerns about the website. OK, security. Another area of non functional requirements is huge at the moment. I have obviously the Better Business Analysis Institute.

We have a website and I get well, I get so many people signing up and that's great, thank you listeners, but not all of them are real people. Some of them are bots, some of them are effectively people that are trying to create fake accounts to see if they can get content.

Probably most of it might be a little bit, you know, just scraping our website for content, but there could be well people in there who are trying to hack the website, probably mainly spammers who are trying to spam on on our content, but they could also hack the website and bring it down or try and find payment details. Now we have quite a lot of security plugins actually because it is it is running on WordPress, but which we've got advice on that blocks that.

And then we have, you know, examples where IP addresses are blocked, which are the unique ID you get when you log onto the Internet. It's not fail safe because people use things called VPNs, virtual private networks to mask their IP address, but we have some automatic spam blocking.

Now that's hard because you make it to put in spam blockers and capture, which is can be annoying when you have to say whether or not you know how many please pick the traffic light and you're not sure if that one square has the traffic light or it doesn't have the traffic light. All that all of that kind of extra functional work you have to do is driven by the non functional requirement of

security. And so you know there are sometimes where non functional requirements are driving functional changes and that's a bit annoying. And I I would say, I'll give the example of the fact that, you know, the few are effectively wrecking it or making it more difficult for us to do some simple things. And there's a constant evolution, and I can see some great evolution from Microsoft and Google lately.

We're using passcode, for example, where you have one code to get into your computer and then you can use that again and again with websites without holding a password, which is a functional way of dealing with a security problem, but also the problem of you having to reset passwords all the time. So that's fantastic. But I'll take another example. We just take it out of IT for a second.

Is the airport and for example you know there were a couple of some obviously some serious terrorist incidents specifically you know some larger ones like 911 and and in the uki think it was 7 July there was some a nasty incident there too with the trains and buses. And though that fear and the fear of people threatening to do things on planes has made it really difficult. If you go through Heathrow, you go through JFK really difficult to get through the airport.

Right. You've got screening you've got you know you can't have a bottle more than 100 milliliters to get on the plane. They check you know your hair gel to make sure it's not explosive and you can you know get that thrown away your whole new kit you just bought at the shop at the airport which you think they would have you know, managed that. But anyway, you have to take your shoes off, your belt off your laptop. Now that is all that whole process which costs money, costs

more stuff for them. It's a big pain in the ass for anyone who has to catch an airplane is there as a as a a functional change to your life. More things you have to do slow things down because of the security concern, which is that you know, one in a million chance that someone will, you know, try to take down an airplane or you know, have something in their shoes. So they do all these things to minimize that chance. Now that's exactly the same with

capture on your website or bots. You know, some of that could be just with a with a airplane. You know, taking down airplane is pretty damn serious and will affect a lot of people. With a website, you know, you could say that's not so much serious, but if you're stealing people's information or selling them on the black market, that can be quite serious. So you do need to worry about these things.

So that if you think about when you're doing your work, just think about slow website and think about capture, I just keep those in the back of your head there and then that should be a trigger next time you're doing web app for example. And it could be any application that you need to worry about some things. We take the extreme, the extreme level here, we'll just ramp it up from planes and terrorists to

nuclear power stations. And the fact that, for example, say you write some requirements for a new control system for a nuclear power station, right. You might go, well, you know, OK, this is a bit scary. But, you know, I understand what they want. They want this button to do the following and this button to do that, and they want some overrides and all the rest of it.

Now if you've ever been involved in a mission, what we call mission critical requirements, you'll probably know that firstly those requirements need to be clear and the business rules need to be tight and there's a lot of peer review there. But equally the language, the even the I'm going to talk about programming languages here the we use some we when they program these features or these

functions. The language they use isn't all the mod con languages like you know React or JavaScript and all these ones that you use to to use the website. They actually use languages that are more closely related to the operating system. Or C for example, which is an old programming language is used for control units for security

in a lot of companies. And the amount of steps that the programmer writes and then you know the sorry, the amount of steps it takes for that Lang that those, those commands, those functions to be transferred, compiled to the

actual hardware are really low. And so the chance of having a bug or something going wrong or the speed of that code not running fast enough or any any chance of anything going wrong between the the kind of programming language and the speed of that and the hardware is lessened. And so those in that situation, what do you think non functional requirements would would be in terms of the list of priority? It would be right up there, right the speed if something

went wrong. You would have you know they have they have to be milliseconds or less than milliseconds in terms of override. You would have to have lots of you know error checking. You would have to know if things were going wrong. There would have to be hardware checks. There would have to be all sorts of bits and pieces.

So you might find that the functional requirements around just having some buttons to control something are far little far smaller than the list of non functional requirements you need to have. So that's just an example of environment can actually change and technology can change what you may need in regards to the length and the amount of effort you put into your non functionals.

So we talked about the fact that you're focusing on the how this is a what in terms of non functional requirements and we talked about the fact that non functional requirements describe how a system should work or how those steps should be carried out. Because it may it's a system in the in the sense of IT, but it also could be a physical system. It also should state what the system should not do.

OK, so you're we talked about the fact that a login system needs to be secure, but it also should for example maybe say that what it shouldn't do, for example. And maybe if you've entered your name into a website, e-mail for example, and the sending of e-mail, even though you can do it in a secure way, e-mail isn't secure. OK, so don't think for a minute that your emails are secure. They really are not secure. A message within your WhatsApp is actually more secure than your e-mail.

OK, if you've got NT and encryption on emails are not encrypted, they're text. So it's VE. They're very very very easy to hack unless you're using a secure e-mail system which is wrapped on top of it. But Gmail, Hotmail, not so lucky. So for example, it's not a great idea to ever e-mail a password

to a user. So if you and I sometimes shake my head when there are some quite well to do websites or websites doing quite well where I reset my password or you know I asked for it to be changed or I do, I forgot my password option and it actually emails me the password one, you know, it's not I haven't even logged in. So it there's no way the system knows it's me. I just know that this e-mail address, you know I put my e-mail address in and that's it.

So a lot of people know my e-mail address. I've emailed them all the time. So for example, I don't know, it could be your ex. You know, someone that you were seeing previously. Maybe they you know you, you didn't have a good break up. They know your e-mail address, They can put your e-mail address in, they click forgot password, maybe you shared your password. They can get into your e-mail and then they'll know what your password is there.

There's a high likelihood that the password you've used for that website is another one or very close to a password you've used for other websites. And now I can get into all your websites and I can see I don't know who what your life's like. And you know maybe you're maybe you're banking app which is luckily probably more secure than anything else. So this, this, this is the kind of use cases that you need to

think about here. The other thing around non functional requirements is they they're talking about I guess kind of quantitative areas. So when you're talking about we're talking about speed time measurables here. So you might say this. For example, the there's a functional requirement around the ability for the. I'm just going to, I'm not going to use use the story proper kind of terminology here. However, non functional requirements should and can be written in story form.

But let's just say as a website application I would like to load within two seconds so that users are not frustrated and move on or try and refresh the page. You know what I mean. And so that's the example there. Whereas that's how you can write those requirements if you like. So usually it's Azar and then it's the solution that you're doing.

If you're more comfortable when you're writing a functional requirement, split the non functional out because even if and there's a bit of confusion here. So for example, I've said as a user I want to be able to log log on with my username and password as an existing user. Actually let's take this as an existing user so this is a different user story to creating my account.

So as an existing user, I want to use my username, e-mail address and select a password so I can log on to the application so I can view my details and be securely logged in. That might be just a really high level user story to start off with and you may have a non functional requirement that's linked to that which is around the fact that the password needs

to be X amount of characters. Now the reason I'm bringing this up is that a lot of people can write that within the functional requirement as a business rule and that's OK too. But I do think it's probably worth looking at the response to that requirement and writing a non functional. What do I mean by that? If you've ever done a sequence diagram right, then you'll know what I'm talking about. If you haven't done a sequence diagram, think about a baton.

OK, think about a baton. So as a existing user, I want to log in with my username and password. That's the function. Now what happens next? What logically happens next? And a lot of you might say, well then I can see my desktop. I'm logged in successfully, You know, if I've got my details right. And you know, that's cool. What actually happens next? What actor? What actor is as an as an actor? What actor is playing their part next?

So, well, the baton is actually being handed over to the system. What do I mean by that? So as you log on, your details are being sent to the application, right, your username and password and that it was, it's going to say, you know it does that. It's going to do a couple of things. It's probably going to say is

the e-mail registered? So are you an existing user And it's going to check your password and it's going to make sure that your password matches the password that it has on its system to know that you are who you are. And then it's probably going to check that even though you are who you say you are, what access you have. And then it's going to, you know, give you that access. For example, if your account has been suspended and might send you back to a suspension page, you know.

And if your e-mail address isn't correct, or you're not registered, or your password is incorrect, then it needs to show that message. Or it might take you to a forgot password area now. So that battered the solution. There's a reply to the requirement. This is the mindset you as a BA need to worry about. No, you're not a systems analyst. You're not a solution designer, but you should know in a general logical sequence that there is a reply that something a process

happens. So the process is actually, you know, if you drop down logging in, it's taking your details and it's doing something. It's doing functions by the way. Functions. It's doing functions. And some of those functions there are actually require you to tell it what you want it to do from a non functional point of view, right? So you're assuming that it knows how to do the login. That's OK and sometimes you

don't need to get to that level. But what I would say is in have another requirement underneath the logging in the existing user. And you might say as a system I want to apply, you could just say best practice login security to verify accounts maybe. And then you list what is that and so then the the devs could have that as a separate card and

then they could go through that. You could equally include that within the functional story and say you know the acceptance criteria are ABCD 3, but you need to explicitly say if there's anything special you want that to happen. And when I say special, that's over and above a pattern you've defined. So if you say best practice,

that doesn't mean anything. But if you've got a standard at your organization for logging in like a pattern, you don't have to write it every single time you write a login. You might say our standard security pattern for logging in to a website and then that's defined as a separate document.

OK, so you do. That's the good way of triggering non functional requirements, but it's also making you think about them by looking at the batten and the reply to it. And so drawing a sequence diagram, or going down to the steps, knowing that data travels from your step to the system and back is really important. You might say bin, which you know that's too much work. Well, it is if you're drawing a process diagram.

This is what I suggest you do. Just show that there's an error between your process of logging in an existing user flow, because it will be different to, there will be different gates for a new user. Show an error going down to the system and then because it could be a a separate system, the website could be an authentication system and then show an error back and then you're following the error and then you're thinking about the login.

So in that case, when I say an error back, you would have a box login to system for example, existing user logging in system, that would be your actor on there and maybe a timing indicator, it logs down to your system, your authentication system or your web app and then an error up to the next step. So you could say, well there's now a decision which is you're not verified and it could go back to a page of like sign up or you've forgotten your username and password and move

on to the next step. So you know going there's no problem with your process diagram showing those system steps and a bottom swing line for example, and then connecting an arrow down there and then showing what the reply is. And then you're using the Batten technique all the way through and that's actually, even if you're just using it and show and then actually hiding those steps the system steps later for

presentation purposes. It actually makes you think of all the non functional requirements you need to think about. And what you could do in the arrow is write down the timing that's expected or less the minimum maximum time that's expected for that to happen. OK. So if you just say, you could even do it on the login step, you could say well logging in, you know that should take X amount of time.

And when you talk about when it's a new system that should be or you're using new technology, new system or new technology, you should be explicit about that timing or say the whole time to to log in or to navigate on the website, it needs to be quite fast. And when we remain fast, when you might say as fast as this website, you know and you can measure the speed for that. OK.

So we've just talked about security and speed, but there's also the performance of the system which is around speed and it's a subcategory of but there's other performance steps in there. The other area that is important is kind of like around availability. So availability is how often is the website available. And sometimes I notice for example some American based website ancestry.com is one of them.

You'll find that the maintenance jobs that they run every night to run their scripts or do whatever happens in the middle of the night for an American. Or you know, there's different time zones in the states, but generally at A at a time where most people would be sleeping and what that means and actually Xbox does the same sometimes or some games do it.

The performance in New Zealand which is kind of at the other side of the world, it degrades and so they're like oh, up time's fine because no one's using it, but they haven't thought about the fact that that website and their their customer base is actually over the other side of the world as well.

So that's another problem. The other thing is that sometimes systems do break, but you have to have a as up time is a is a measure we use in terms of in terms of availability, how often it's going to be available. If you're on a cloud system, you generally inherit that availability. So if they have an outage, you have an outage. We have things of our own reliability, but the one I want to just jump into here because this is a area which can get very confused when you're ABA.

And so I just want to make it really clear that a non functional requirement, one of the non functional requirement areas is usability. And for some people that can be a bit of a shock. Usability. Usability means a lot of stuff. I I like the fact that usability in there as opposed to what used to be called a design or content. But usability is a better, a

better term. And it's about not just the IT can impact the features that you have, but it makes you think about the design of your website and sometimes the design of the website which is done. You know, maybe after you've done your first cut of requirements, you just kind of just have them as pictures throughout your spec. Well, I do anyway, and I point to the requirements. But this is another area which triggers a whole lot of non

functional requirements. So if you think about usability, I'm going to throw at some basic usability and then I'll look through about some specific usability we should all be worried about. Some basic usability is the design of the screens OK? It's the fact that if you're using a system which is made for data entry purposes, you've got tabs in and all the information that you enter more often or not is probably at the top and the stuff you enter later is down

below. So you requirements around, they're all non functional requirements and I'm thinking about Dynamics 365 or Salesforce where you might have someone who's just dragging, dropping, configuring your system, you know adding some custom fields. Those non functional requirements there around screen layout They should be. Requirements. They should be non functional requirements and so for example, yeah, it should be around. Well you know, I want to easily get into this.

You should be prompting your users, you should be asking questions around this sequence in which they enter their information. Or you know, are they going to be using a tablet? Are they going to be using a mouse? Can the screen, can the screen

resize automatically to tablet? I actually just spent some time working on a project that I'm involved in and I was doing some very simple landing page website work, drag and dropping some stuff for this kind of MVP we're trialing out and I completed it and I thought it looked pretty good. To be honest I'm not a designer but I was using a template and I was mucking around and I got it sorted and I thought it was good and I sent it to a friend of mine who clicked on the link.

Now I was using my PC, my laptop, and he was looking at it on his mobile device and he clicked on the website and he said, oh, OK. And I thought, oh man, that's a bit gutting. I just spent, you know, a good half day on this. And I clicked on the link on my mobile phone and the website wasn't what we call responsive or not, Well, responsive design or when it was being responsive,

it was moving things around. So responsive design is the ability for a web app to kind of respond to the type of device you've got based on its size, which is all fine and dandy, but in this case there were some videos on there and there was some text and it moved everything around and I could read everything but it looked bad.

So sometimes people especially with the move to mobile devices, a lot of people you have a non functional requirement around mobile first and mobile first means design for mobile so it looks good on that and then manage the desktop version after the fact. And that was that's a lesson for me because I'm going to have to redo it and or pay someone to do it and I should have designed for mobile first. I should have designed on a small screen and then allowed it

to stretch out for for web work. So that's a non functional area. That's important when it comes to usability. So we've got those usability requirements around how people are going to be using it, what their preferences are. If you start getting into colors, then you really need to start to say, well you know, changing this from if it's an out-of-the-box product like Dynamics or Salesforce and they're saying, can I have that? Can I allow that button to be

blue? Then you know you end up with the blue button scenario where you need to really talk about cost. There's preference. That's not usability. You also need to think about if it's external, not just you. What do I mean by that? Wow, a large percentage of our population in the world, if you're looking at launching to the world, don't speak English. So what are you going to do about bilingual languages? Are you going to have a language pack which does its best to

change the language? Are you not going to bother if you're in a situation like New Zealand where we actually have an indigenous, indigenous people, the Maori, they, you know that that's hugely important to others New Zealanders or to most New Zealanders anyway, and we're trying to promote Maori as a language. Well, most government websites need to be in both in Maori and English, OK? There are two major languages

there as well as sign language. So for example, if you are for example someone who's blind, then you need screen readers to read your website. And if you put a image on your website and you don't put text, then the whole experience of that image will just not have any impact. If for someone who has who's blind or has low vision, now there is something called alt tags, alternative tags, alt tags and websites. And you can actually add A tag

in there. You can describe what the picture is. And if you go to a website and you add your old tags in, then people with low vision, they can, the screen reader will say there is an image on the right of, you know, a person kicking a soccer ball. And then so they get more of a interest around that. Sometimes, you know, it could be video about whatever and then they can play it so they know that it's a a video, so they can click on the video and listen to it.

Google also will look for alt tags. It uses it for indexing and making sure that your content is good and it actually gives you a better rating. It's called ECO, a search engine optimization. It'll give you a better rating on Google if you've got alt tags on your website. So that's usability is not just thinking about, you know, the the simplest design features. We're also thinking about those who may have not had the same abilities as yourself or people that speak a different language

to yourself. People with a lot of colorblind men out there, generally they're a woman who are colorblind, but men? There's a huge percentage because men don't generally talk about their things. But I know a lot of people that are colorblind have your website uses colors that are really hard to be seen by someone who's colorblind. They may not be able to read your text and so you're actually making them a little bit, you know, you're actually making it really difficult for them to

navigate your website. Now the I guess there's a spectrum here. If you're if you're if you're got a very targeted audience and you think that disabilities of one way or another aren't important and you're just one of those kind of people, then maybe you don't really care about that and you know, good on whatever. If that's your preference, go for it. But it doesn't mean anyone's going to read your website. It doesn't mean that you know people you didn't know who had a disability.

Maybe it's something like someone who's dyslexic and can't read big words and you're using big words on your website, but you've got to limit who wants to visit your website and you can literally isolate yourself. Plus, in Google's not going to do a good job of allowing your website to be clear across the Internet. Now if we go to the other extreme and you're for example working with a specific group of people that may have different abilities or different skills to

you. For example you're working with indigenous people and you're a web design company that only you know doesn't have an expert in indigenous languages. Then you know that is something that's a really important, I would say functional and non functional requirement that needs to be captured and cost because you're going to have to get someone to translate all your content into the native

language that you're using. You need to understand that there might be differences of design just because of that. There might be specific colors or even navigation or even ways of expressing different elements of the website that for example that you wouldn't have thought about or wouldn't have come up when you're working with another client.

So non functional requirements are hugely important that you know as we said that the attribute that describe how the system function not what it does and there's an emphasis, there's an emphasis that they are really, really important. Now we're going to move to well, OK, who writes them.

So if you have a if you're an internal team or you're working with an architecture team, they may have a great list of non functional requirements you should worry about and they may even ask us during say architectural review. So I would say first go to the architecture team and ask them about non functional requirements. It is your job as ABA to talk to users and to think about these

and prompt them. But I would suggest just looking to see if there's a common list of that you should go through as well as anything you think of. So if you think of something that's not on their list, it's valid. If it gets brought up, it's valid response time, up time, you know how often upgrades happen. All those things are really, really really important. So if they're not on the list, add them.

OK, It's not around having a perfect list, it's just making sure that those things that are important for whatever application system process you're improving put together. You know, having templates, having checklists, having articles on non functional requirements are really important. Having them listed in the project plan as a piece of work you need to do, not just the functional requirements. Have you captured the

requirements? Yes, I'm going to do a whole work on non functional requirements. Doing interviews on non functional requirements on experts in those areas are really important. Make sure that you are spending time on this and making sure that everyone on your project is aware of it. Now before we go today, before we get on, I want to just talk about some real life examples just to bring in the importance of non functional requirements here.

Why? I'll just give you 3 examples that have happened, you know, relatively recent in recent history when in there was a new website that was going to be launched called healthcare.gov OK. It was supposed to be launched in 2013. And this is in the states. So if you live in America, you may know about this. This was all to do with health insurance and changes in that area. Now no one thought about and this is another non functional requirement which is scalability.

OK, I'm not I'm I'm purposely not giving you the loss. So you can go and actually research this bit of homework, but scalability is really important. And this is, this is scalability has hit us in recent times because of COVID-19 and people accessing information on mass. And so a lot of times things fail because they were written to handle 100,000 visits, not a million visits.

OK, So scalability and performance of that, of the functions when you've got lots of people on board and security that were all overlooked. So with no functional requirements really focused on here, they probably work with a design firm and they got the functions done. And So what happened was that that website, healthcare.gov, it crashed due to overwhelming traffic. OK, So it meant that millions of Americans could not enroll in healthcare insurance. And what it meant, it looked

politically terrible. I think it was a bummer at the time. Looked terrible for the Democrats at the time who would roll out this new function. It cost lots to repair because the architecture, the way in which the system was designed and never no one had ever thought about the fact that millions of Americans or 10s of millions of Americans would want to access the website on the same time. Now that doesn't mean you need to spend hundreds of billions of dollars allowing that to happen.

You can deal with peak performance. But what they could have done was just had like a queuing system. And there's some problems with that design as well. You know you have a queue system like if you buy tickets for a sporting event or for example you buy tickets for to see a band you like. This happens all the time. You'll notice you go into a queue and so you just get let in.

And that really a really good experts actually about dealing with high volume requests at one time without having you know hugely expensive long term equipment and design that allows that to happen every day or you know, every single event. So they're good people to speak to. If you are going to scale quickly to that level, sometimes it's not possible to worry about scale. You just become really popular. A popular website just becomes popular overnight as a fad and the website crashes.

That's kind of different to rolling out government website that everyone should have access to now. Yeah, there was huge reputational damage. This was in 2013 reputational damage. It was costly repairs, It was a disaster. All because those non non functional requirements weren't just a checklist wasn't gone through. They should have known that there could have been a chance

of a scalability problem there. There was also an example with Knights Capital. There was a trading glitch in 2012. Software testing is you could say as a as a now an integrated part of your project plan, but it's actually a non functional requirement and risk management or the management of risk wasn't. Those two things weren't measured well or taken care of. So no one was worried about the what would happen if there was a mistake and what would be the consequences there.

So in that example, there was a problem with an algorithm within the trading mechanism. And what it did is it meant that there was a problem with they weren't able to execute these trades, these high speed trades. And you know, trading is hugely important. I mean it's one of the areas where I know that, for example, Rupert Murdoch, I have a friend of mine who worked for routers which Rupert Murdoch owns.

He's a rich, very rich Australian guy who owns a lot of media around the world and owns Fox News. So if you're from the States, this is your buddy. So he you know he's a character and has strong political views on the right, but equally he also makes most of his money not from his news outlets. He makes his money from trading foreign exchange and doing other bits and pieces.

Now there's no law or stopping Rupert from spending multi billions of dollars on having better equipment than everyone else. And so this friend of mine was working for doing some work for routers which was, which is the company that sends information through Stock Exchange and and news and he was installing these very premium routers with

routers. Sorry routers, full routers gets a bit confusing but effectively switches which allowed information to travel through routers much quicker than the competition which actually meant that rapid trading team, it's not him, it's he's got thousands of people that work for him allowed them to get information very quickly and they were able to execute on trades. So that was done the right way from what I hear. However, this example here was, you know, there was a faulty algorithm.

They didn't do testing. They didn't think about the cost of doing extensive testing. What would be the reputational cost? They lost 440 US million in 45 minutes, OK. And it meant that they, they lost so much money and the shareholders, you know no one was happy and the investors weren't happy and they got acquired by a competitor as a result. So you've got to be really in, in those examples you could say

mission critical. I would say well you know trading is a kind of a bonus, but still it is critical to that organization. And so if you're ahead of testing there, you would need to really push for that and work with the BA to make sure that people are aware of the testing.

And if they decided to go live with a change without everything being tested to the NTH degree, then you need to make it really clear from a risk management point of view that we're outside the risk profile that the board expects or the organization as well. It could even recover from. I'll give you one more. It was around Target. So Target is in Australia but it's also in the US and they had a data breach in 2013. So there was a data security

breach and access control. So around security, about security, non functionals, access control. So what happened was that they really hadn't implemented modern day security techniques around access. OK, so things like we did talk about modern passwords, we talked about resetting passwords, we talked about two

thing factor authentication. They just went up to the speed and and the problem with these large organizations like Target and even if you're not Amazon or Google or tech company, there's even more important Walmart, Target, all those big companies, McDonald's, they need to be at the forefront of technology as well. So what happened was effectively hackers stole personal information. There were 70 million customers there.

They not only that is that the way in which they stored information, they were able to get into the user accounts, but they were also able to get into their credit card numbers. So they shouldn't been storing that information in a place where you know, if there was an access threat that information could, they could get to both personal information as well as financial information like credit card information and they also connected to their address information.

OK, it ended up costing just indirect expenses, about 200 million for them to solve and it tarnished its brand image. You and I were pretty bad. I would say most people are pretty bad at kind of ignoring that or even knowing a data leak happened. I actually got notified the other week, just had a little a little e-mail suggesting that there was a data breach on a a big application. On that I've used. I can't actually remember what it was. I have to go through my inbox

and I knew it was bad. It meant that mostly my information was going to be leaked. I do respect those companies that come out and then tell you there has been a data breach. We highly recommend you change your password because they've got your password and then even

doesn't. If there isn't a direct stealing of your information or your credit card information in terms of you needing to cancel your credit card, at least they're coming out and telling you that your password's been stolen so you can reset that. Google has some good tools for telling you if you've been hacked and your password's been put on the Internet, so they're just some examples. I just want to emphasize how important non functional

requirements are. I'll summarize by saying they're not optional extras, they are critical for system success. Ignoring non functional requirements can lead to cost, costly failures, reputational damage, political damage, even business collapse. You need to proactively identify, prioritize, and manage non functional requirements. There should be a whole area on your requirements matrix. They should be on your backlog. You need to worry about user experience. You need to worry about data

security. You need to worry about availability, performance, scalability and business continuity. So I hope you've learned something today and I'll speak to you. Next time. Remember to think about non functional requirements.