Eliciting non functional requirements

Editor's Notes

• #4: 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.
• #6: 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.
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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/
• #11: 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
• #12: 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.
• #13: Reference: Ben Shneiderman, Jakob Nielsen
• #15: 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.
• #19: 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.