Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Eliciting Non-Functional Requirements
1. How Do I Elicit
Non-Functional
Requirements?
(Even when my business representative doesn’t understand them?)
2. In This Session You Will Learn
How vital non-functional requirements are
The value and definitions of several key non-
functional areas
Practical techniques for eliciting these
types of requirements.
3. Functional Versus Non-Functional
Functional Requirements: defines a function
of a system or its components. A function is
described as a set of inputs, behavior, and
outputs.
Non-Functional Requirements (NFR): specify
criteria that can be used to judge the
operation of a system, generally
architecturally significant requirements
4. NFRs Are A Huge Requirement Domain
Often referred to as the “-ility” requirements
The big ones are:
Usability
Availability
Scalability
Performance
But there are so many more such as…
5. Do I have to specify every category?
Probably not
Consider your
project, its preproduction and production environments
company’s plans for the product
company’s growth plans
customer’s sophistication
competition
Choose based upon your project’s considerations
6. NFRs Can Be Challenging
If you are uncomfortable with an NFR area, do
your research before addressing the topic
Plan elicitation ahead to frame the NFRs well
for the business
Once you’re ready, define the NFRs by
interpreting them into business-relatable ideas
7. NFRs Can Be Challenging
Frame your questions as real-world scenarios
using
What if…
Given, When, Then
Drill down techniques
8. Is Your Technical Team NFR Friendly?
Reasons for resistance to delving into NFRs
Not in the habit of planning ahead for NFRs
May not plan for them at all
There may be some unknowns that have to be
cleared
Team members may be at various levels of
comfort with the different NFR areas
Recruit a champion to help you get NFR buy-in
9. Break through with
Doing your “homework” ahead of time
Priming questions sent ahead of your meeting
Volunteering to help discovery efforts
Bringing people together, such as operations
and support
Emotional Intelligence
Scenario-based elicitation
10. Let’s talk about the “-ilities”
Usability
Availability
Scalability
Performance
11. Non-Functional Areas - Usability
The degree to which a software can be used by
specified consumers to achieve quantified
objectives with effectiveness, efficiency, and
satisfaction in a quantified context of use
12. Non-Functional Areas - Usability
Who are our target user populations?
What is the common context for use of the
software?
What are the most frequently performed
tasks?
What is the optimal time for each task?
What is the longest acceptable time for
each task?
What are the alternative flows for each
task?
13. Non-Functional Areas - Usability
What is the tolerance for user navigation
errors?
How do we define and measure user
satisfaction?
What is the target for ease of learning
(intuitive)?
What is the longest tolerable wait between
steps for the task?
14. Non-Functional Areas – Availability
The proportion of time a system is in a
functioning condition, expressed as 100% minus
the percentage of time a system is unavailable
16. Non-Functional Areas – Availability
When the system is down, or sluggish, what does
this mean to our customer?
How is our reputation affected if the system is
unavailable more than our stated service level
agreement (SLA)?
When the user is in the middle of a session and
the DB or application goes down, how is the user
affected? How is our reputation affected?
17. Non-Functional Areas – Availability
What are your employer’s and your customers’
tolerances for system unavailability or lack of
reliability?
Is this function critical to the business, to the
customer, to the technical team?
Do any other systems which may be critical to
customer, business, or technical team rely on the
system or its output?
If a certain module becomes unavailable, how
does that affect the system’s availability?
18. Non-Functional Areas – Availability
If a certain piece of hardware is unavailable,
what is the effect on the system and how does
that affect our system’s availability?
What is the business’ or the customer’s
tolerance for the system to be down for
scheduled maintenance?
What are the contractual obligations specified
for the client(s)?
What compliance requirements might affect
our system’s acceptable availability? How can
those be mitigated?
19. Non-Functional Areas - Scalability
Refers to the capability of a system, network, or
process to handle a growing amount of work or
its potential to accommodate growth
20. Non-Functional Areas - Scalability
What is the projected user growth over the
lifetime of the system?
What is the projected resource use per user
over the lifetime of the system?
How large is an average user’s data set?
What is the demand for the CPU under normal
working conditions?
21. Non-Functional Areas - Scalability
What would be considered a very heavy load
day for users/data/computing?
What plan can we have in place in the event
that we receive an unusually heavy load?
What monitors can we put into place to be
advised when we are reaching a peak in
users/computing/storage?
What would constitute a very high number of
users accessing the system?
22. Non-Functional Areas - Scalability
What would constitute a high load on our
CPUs?
What would constitute a high storage usage?
Who should be notified in the event of such
large loads?
How many transactions per second can we
expect in normal load and peak load?
23. Non-Functional Areas - Performance
The amount of work accomplished by a
computer system. It may involve one or more of
the following:
Short response time for a given piece of work
High rate of processing work (throughput)
Low utilization of computing resources
High bandwidth
Short data transmission time
24. Non-Functional Areas - Performance
What are the time constraints does the user
have when performing this task?
What if the system slows to the point that the
users are unable to complete the task in a
timely manner?
What if our system exceeds the contractually
agreed upon SLA?
25. Non-Functional Areas - Performance
What have we heard from the customer
regarding response time from the existing
system?
When working on this task, how quickly will
other users need to have access to the data?
What will happen if the user does not
receive a response to their submission
within X seconds?
26. Non-Functional Areas - Performance
How many transactions per second should the
system be able to handle in normal and peak
usage times?
What constraints are there on CPU usage in
normal and peak times?
What other systems are running on this server
that may impact performance? How can that
be mitigated?
27. Non-Functional Areas - Performance
What is our network bandwidth? How will that
be impacted by our system at normal and peak
times?
How quickly does the data need to be
available for use by other users and/or
systems?
28. In This Session You Will Learn
How vital non-functional requirements are
The value and definitions of several key non-
functional areas
Practical techniques for eliciting these
types of requirements.
Notas do Editor
Functional Requirements are things like “The system must allow users to access their account information.” or “The system must calculate the employee’s pay and print it on a check.” They are statements of what the system must do in order to fulfill its purpose. Non-Functional requirements define the attributes of how well the system fulfills its purpose today and tomorrow. For instance “The system must perform all payroll calculations using six decimal places and use Monte Carlo arithmetic for rounding to two decimal places for actual pay and display.” or “The system should use end-to-end encryption when transmitting account information.” As you can see, these requirements are getting a little into the how of the system, but are essential because they describe what the system will need to enforce and how it will need to behave in order to meet and fulfill the customer’s needs.
Go to Wikipedia to show NFRs
Fortunately, most products will not require you to write requirements for every single non-functional requirement category. Good news, huh? You should, however think about most of them at the beginning and ask yourself if they need apply. Always remember to think about the future as well as current plans. What works fine today may not work so hot in the future.
Sometimes, even we BAs are not 100% comfortable with non-functional requirements, so imagine how your business team members might feel. It is important for us to become conversant in these project aspects so that we can best serve our clients and represent them and their needs in the best way possible. Fortunately, the only thing that stands in our way is learning and we do that all day, every day. The Internet is a wonderful tool to help with just-in-time knowledge acquisition and reminders. I “Google” things constantly to help jog my memory or to learn a new tool or technique.
Once we know what the NFR area we need is all about, we can more easily frame scenarios and come up with probing questions to surface our client’s expectations or help them consider things they may not have even thought of yet. This latter point is often the case, since they don’t generally live and breathe software. Scalability is not something on the minds of healthcare documentation administrators.
Sometimes, even we BAs are not 100% comfortable with non-functional requirements, so imagine how your business team members might feel. It is important for us to become conversant in these project aspects so that we can best serve our clients and represent them and their needs in the best way possible. Fortunately, the only thing that stands in our way is learning and we do that all day, every day. The Internet is a wonderful tool to help with just-in-time knowledge acquisition and reminders. I “Google” things constantly to help jog my memory or to learn a new tool or technique.
Once we know what the NFR area we need is all about, we can more easily frame scenarios and come up with probing questions to surface our client’s expectations or help them consider things they may not have even thought of yet. This latter point is often the case, since they don’t generally live and breathe software. Scalability is not something on the minds of healthcare documentation administrators.
When working with your architecture team on NFRs for the technical requirements, you will need to use your knowledge of your team members and some emotional intelligence. I have had teams resist NFR collection in the discovery stages. I had to go through some discovery of my own to find out why they were pushing back. In my experience, it is most often the result of teams being in the habit of waiting till later to make their plans, usually toward a project’s end, close to deployment time. Sometimes, teams just don’t collect NFRs and that’s a bit scary. If that is the case, you must work with influencers in the development group to promote the benefits of NFR elaboration early in a project. Recruiting a champion to help you get a foothold into doing NFR elicitation will be your best bet.
Sometimes, teams don’t have the answers they need to tell you everything. That’s fine. Work with the team to identify what you know and what you don’t know. That will help make the tasks ahead less daunting. If there is some new architecture or technology being used, that needs to be captured as risk. Either way, you can work with your development team to answer the unknowns and facilitate decision making so that NFRs can be determined early as possible.
Finally, some team members, especially junior ones or members who specialize in particular areas of software development may not be comfortable with every NFR area. If that is the case, pare down the people you work with to elicit your NFRs. That way, people don’t feel uncomfortable or that their time is being wasted. If you need people to be engaged but sense hesitance, you can use your “I’m a newbie” card and get the more senior team members to help explain things or talk through the NFR so that everyone is informed but not put on the spot when they may feel like should have known a topic.
Be sure to have your knowledge of the NFR areas primed and ready to go before you engage in discussion with any of your SMEs but be really primed and ready to go when you talk to your development teams. In most organizations, BAs exist in slight tension with the development teams since it is our jobs to advocate for the business in the face of technical concerns. For that reason, we should be in good form when engaging our developers so that we can represent the business in all facets of discussion.
I have found that sending the developers priming questions in the agenda helps get the conversation rolling. Since developers are problem solvers at heart, they generally can’t resist thinking about things, once you get them started.
If your team realizes there is a good deal of discovery needed, especially when it involves other teams, such as operations and infrastructure, volunteer to get the people together and find out some of the information for them. That shows you are in it with them and builds bonds of trust. Make sure you follow through and communicate your findings well.
Emotional intelligence is one of the most important tools you have. If you see resistance building or someone digging in about something, if your development team is not forthcoming in discussions or is reticent to talk to others, use your emotional intelligence to help you discover the root causes of the issue. Then, use it again t help resolve the issue. If you are unfamiliar with emotional intelligence, read about it here: http://www.talentsmart.com/products/emotional-intelligence-2.0/
Many, many organizations gloss over usability requirements and measurement, much to the regret of users and, sometimes, of the organization. Companies are especially guilty of this when developing applications for internal use. Why?
Usability is difficult to define and measure. What may be easy to use for one person with expert computer skills may be nearly impossible for someone with limited exposure to computer interfaces. Fortunately, there are ways to specify and measure usability that can help software development companies avoid mistakes that can doom a piece of software to obscurity.
https://www.usability.gov/what-and-why/usability-evaluation.html
http://www.usabilitynet.org/prue/requirements.htm
If you start your design and specification process with the target users in mind and even assisting in the process, it is much easier to accomplish usability targets than if you think of them later or only expose them to the product at user acceptance testing. Contextual considerations will enhance your understanding of the user and therefore the considerations and psychology of the moment when they access and use the software. Is your software something they will need to use casually? Is it something that they will need to use during times of pressure? Is it related to something very important to them? What are they trying to do? Are the users under a time crunch, such as in a setting where transactions per minute are used for performance appraisal purposes? What is their tolerance for the system making them wait while it performs necessary tasks in the background? If there are possible alternative flows for the tasks, what triggers them? In the case of an alternate workflow, what support does the user need in a less familiar navigation pattern?
Talk through these considerations either as a separate discussion, or include them in your functional requirement gathering as you work with your users. This user driven focus will help to ensure you have a happy user community at the end.
Reference: Ben Shneiderman, Jakob Nielsen
Availability is a non-functional area all of it’s own, but it is contributed to by many other areas. Often times, it’s difficult to talk about one without considering the others. For that reason, I suggest that when you talk about availability, you make sure you at least touch on these related areas so that you have a full picture of the contributing and related areas.
We all want our user base to grow. It’s part of the reason we make software products, to get it into more and more people’s hands. Scalability is achieved through the ability to add resources. Resources may include more memory, more storage, a load balancer, etc. Scalability can also be achieve through the design of highly efficient algorithms and the writing of efficient code so that it can handle situations where large input sets are supplied, where the output for a scenario is very large, or when there are large spikes in users.
