More Related Content
What's hot
What's hot (15)
Similar to Eliciting non functional requirements
Similar to Eliciting non functional requirements (20)
Recently uploaded
Recently uploaded (20)
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…
- 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. 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
- 11. 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?
- 12. 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?
- 13. 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
- 14. Non-Functional Areas – Availability
- 15. 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?
- 16. 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?
- 17. 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?
- 18. 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
- 19. 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?
- 20. 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?
- 21. 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?
- 22. 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
- 23. 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?
- 24. 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?
- 25. 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?
- 26. 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?
- 27. 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.
Editor's Notes
- 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.
- 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.