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:
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 Software Requirements Gathering Techniques
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.