Rawpixel - Fotolia
How to elicit performance requirements
Eliciting performance requirements from business end users necessitates a clearly defined scope and the right set of questions. Expert Mary Gorman explains how to effectively gather information.
Reader question: I need advice on how to elicit performance requirements from business end users. And we need to know what is fair to ask for, such as web pages, data file loading, search/retrieve from database, and reports (from request submission to return).
There are two types of requirements in software requirements specifications: functional and nonfunctional. Consider performance requirements as a type of quality attribute, a category of nonfunctional requirements.
Performance requirements define how well the software system accomplishes certain functions under specific conditions. Examples include the software's speed of response, throughput, execution time and storage capacity. The service levels comprising performance requirements are often based on supporting end-user tasks. Like most quality attributes, performance requirements are key elements in the design and testing of a software product.
What are software quality requirements?
A development team should consider performance requirements along with other types of quality attributes: reliability, robustness, security and usability as well as availability, interoperability, safety, efficiency and flexibility.
Some quality attributes can conflict with one another and require the business to make tradeoffs. One example is among different types of performance requirements: High-throughput performance is the ability to process a large volume of transitions within a timeframe. But higher throughput can degrade response time, which is how quickly the software delivers what the user requested. In another example, the expected battery life on a hardware device can impact the strength of the lighting on a visual display, potentially degrading usability.
When you establish performance requirements, consider the influence of dependencies. A software project that relies on OS services or access to an enterprise database must contend with the performance limitations in these separate components. For example, a bottleneck accessing SQL will adversely impact the software's response time returning the data. Design and test software with dependencies in mind.
How to gather performance requirements
Although gathering requirements is an essential part of the software development process, it can be a daunting challenge. The three principal problems in gathering performance requirements are scope, skill and stability.
Often in the business of software development, the project's scope is uncertain, or multiple stakeholders offer conflicting or confusing scope assessments. For example, if one stakeholder discusses local requirements, but another discusses regional or national coverage, the implications on system design and performance can be radically different. Establish a clear scope with the stakeholders to underpin performance requirements.
Requirements are only useful if the stakeholders fully and correctly understand the goals, capabilities and limitations of the project. Users, customers and other stakeholders might not understand the performance issues involved. They might leave details ambiguous or fail to communicate issues to the developers. Consider a software development organization eliciting requirements for an application designed for a medical organization. To those stakeholders, HIPAA compliance is an obvious requirement, and they might not convey it explicitly to the developers. HIPAA compliance might even conflict with some of the quality or other requirements stakeholders assert for the project. Developers must clarify the goals, limitations and other essential factors in the requirements to build a suitable product.
Your work doesn't stop once you have a set of requirements. New or changed requirements are commonplace in software development, a phenomenon sometimes dubbed requirements volatility. Performance requirements can evolve at any time. Ensure that the software development team has a process to receive, prioritize and assimilate requirements changes without disruption. A change system also helps prevent overlooked or delayed changes.
How to use analysis models
In addition to the elicitation techniques described above, software leaders should ask questions based on analysis models. Analysis models build a scenario that covers activity frequency, importance to the user and ease of usability.
Create analysis models collaboratively with the business subject matter experts. These analysis models help you explore and validate user requirements, while also providing a foundation to elicit both functional and nonfunctional requirements.
Let's look at some examples of analysis models to elicit performance needs.
Behavior requirements
These requirements are detailed in process maps or use cases.
- How frequently does this activity occur?
- What are the minimum, maximum and average executions per hour/day/week/month/year, as well as any peak periods?
- When must this activity be available for use?
- What is the minimum, plan and wish level of throughput time?
Structural requirements
These requirements are defined in data or object models. For each subject area, ask these questions:
- What is the expected number of instances per day/week/month/year, as well as at peak periods?
- What is the projected growth rate?
Interface requirements
Interface requirements are initially identified on a context diagram, and subsequently elaborated in report details or user interface (UI) prototypes and storyboards. Questions shown below help developers understand the type of performance requirements such as ease of learning, ease of use and probability of completion.
- What is the triggering event for this interface?
- How frequently does the event occur?
- For a UI, what are the usability needs such as the minimum, plan and wish level of completing a certain type of task?
- How quickly would you expect novice users to learn the product?
- Would there need to be a minimum number of keystrokes or clicks for certain tasks? Would a specific probability of task completion be important?
Business rules
These rules apply across all the analysis models for the software project.
- How should the system react to error conditions?
- How frequently may the error occur?
- How much time should it take for a user to recover from an error?
These questions are a fair way to elicit performance requirements from the business community. They are accurately linked to the functional scope. These queries do not presuppose a design or require detailed technical knowledge. They are expressed in terms that the business subject matter expert can validate.
In general, use simple and consistent language when discussing the project and phrasing requirements. Saying the same things in the same ways prevents ambiguity and misunderstanding among the project's stakeholders.
Beyond analysis models, developers can gather software performance or other nonfunctional requirements via templates. Organizational guides or policies can identify or clarify requirements that team members would otherwise inadvertently overlook.
Finally, developers will often rely on visualizations or simulations -- mockups -- to offer stakeholders a first view of the software, before development gets underway. Mockups such as menu structures and dashboards and even rough prototypes can reveal flawed or missing nonfunctional requirements. Developers can address these problems before the final build.
Editor's note: Mary Gorman wrote the original response to this question in 2008, as vice president of quality and delivery at EBG Consulting. In 2021, senior technical editor Stephen J. Bigelow expanded the information to provide more guidance on performance requirements for software.
