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.

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 data base, and reports (from request submission to return).

Let's start by positioning performance requirements as a type of quality attribute, a category of nonfunctional requirements. (Refer to the answer to "What is the difference between functional and nonfunctional requirements?" for a description of the two types of requirements.)

Performance requirements define how well the system performs certain functions under specific conditions. Examples are 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 when designing and testing the product.

Performance requirements need to be considered along with other types of quality attributes (e.g., 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 (ability to process a large volume of transitions within a timeframe) can degrade response time. Or, battery life on a hardware device (another performance requirement) can impact strength of the lighting on a visual display, potentially degrading usability.

Two ways to help you elicit performance requirements are: 1) clearly define the scope for your project so you don't spend time on requirements that are not necessary and 2) ask questions based on your analysis models.

Analysis models should be developed collaboratively with business subject matter experts. These analysis models help you explore and validate user requirements while also providing you with a foundation for eliciting both functional and nonfunctional requirements. (For more on analysis models, see "Software requirements: Using models to understand users' needs.")

Let's look at some examples of how you can use analysis models to elicit performance needs:

  • For behavior requirements 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?

  • For structural requirements defined in data or object models, ask, for each subject area: What is the expected number of instances per day/week/month/year, as well as at peak periods? What is the projected growth rate?

  • For interfaces requirements initially identified on a context diagram and subsequently elaborated in report details or user interface prototypes/storyboards: What is the triggering event for this interface? How frequently does the event occur? For a UI (user interface), 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 minimum number of keystrokes or clicks for certain tasks? Would a specific probability of task completion be important? These specific questions help you understand type of performance requirements such as ease of learning, ease of use and probably of completion.

  • Requirements engineering resources:
    Don't overlook nonfunctional software requirements

    Defining good performance requirements a joint effort

    Software requirements elicitation and documentation
  • Across all models, business rules: 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. They do not presuppose a design or require detailed technical knowledge. They are expressed in terms that can be validated by the business subject matter experts. But elicitation is not the end of our work! For ideas on specifying nonfunctional requirements see the reference in the answer "Using Six Sigma for software project management."

    Dig Deeper on Topics Archive

    Join the conversation


    Send me notifications when other members comment.

    Please create a username to comment.

    Thanks, it really helps me a lot
    Awesome, glad we could help :)
    These are definitely some helpful tips to keep in mind. My team is responsible for a number of back-end data processing services. We haven't really got subject matter experts to go to, though. In most cases, there is no one who could give us clear answers to these questions. We may be able to get some time from a DBA to review our applications' data access, but that's about it.

    It's definitely an area we need to put more though into, though. We recently had a major incident due to performance issues with our data ingress process.