To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
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.
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."
|
