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.