Quality software performance doesn't happen accidentally

Quality software performance doesn't happen accidentally

Roxanne Miller

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.





Let's start by placing performance requirements in the context of software requirements. While functional software requirements define what functions the software will enable the user to do, nonfunctional software requirements describe the user needs for the following:

  • Ease of operation. Operational needs deal with the use of the software to perform the tasks it was intended to perform. That is, the system needs to be available (accessible), reliable (operational) and usable (easy to learn and use). It must provide information that is accurate, dependable and secure.

  • Optimal performance. Performance needs address how well the software does the functionality it is intended to. Performance requirements deal with the efficiency of the software in enabling the users to carry out day-to-day tasks, providing the ability of the software to interface with other systems, and the ability to verify that the software works correctly.

  • Ease of adaptation. Adaptation deals with modifying the software in one way or another to aid the user. Since any system can somehow be changed to almost any other state, given enough resources, the primary concern focuses on the resources (such as people, time, money and tools) needed to make a certain type and degree of change.

Performance user concerns
Now let's focus specifically on performance requirements. As indicated above, the performance user need category of nonfunctional requirements describes the users' need for a system that functions well. This group of nonfunctional requirements addresses the following user concerns:

  1. Efficiency -- How well does the system utilize resources?
  2. Interoperability -- How easy is it to communicate with another system?
  3. Robustness -- How well will the system perform under adverse conditions?
  4. Testability -- How easy is it to verify the system's performance?

Explaining these user concerns further, efficiency requirements describe the performance and speed of operation of a system. Efficiency requirements identify the need to perform tasks in a given amount of time or a certain level of accuracy. These requirements express the expectations with regard to response time, throughput, degradation, capacity, demand spikes and growth potential. Efficiency requirements could be specified by using the following scales of measure:

  • Process capacity -- a measure of the ability to process units of work in specified units of time.
  • Responsiveness -- a measure of reaction to a single event.
  • Storage capacity -- the capacity of a part of the system to store units of any defined element.

Interoperability requirements describe the ease with which the system collaborates with partner applications and external operations. Interoperability requirements also identify the ability to add or remove interfaces without disrupting the core system.

Robustness requirements identify the ability of the system to respond reasonably to unexpected events. Robustness requirements may also be called survivability requirements, as they reflect the ability to continue to deliver essential business-critical services to legitimate users while the system is under attack or after part of the system has been damaged as a consequence of an attack or a system failure. Robustness requirements are also referred to as fault-tolerance, which measures the degree to which techniques are applied to ensure that faults in a system do not result in system errors or that system errors do not result in system failures. There are four aspects to fault-tolerance:

More expert advice on software requirements
Functional and nonfunctional requirements

Don't overlook nonfunctional software requirements

Clarifying software requirements

Software requirements: A picture is worth a thousand words

  1. Fault detection involves checking that the system state is consistent.
  2. Damage assessment consists of assessing the parts of the system state that have been affected by a fault.
  3. Fault recovery includes actions to restore the damaged system to its normal state.
  4. Fault repair involves making modifications to the system so that the fault does not occur again.

Testability requirements, also called verifiability, identify the process of verifying through inspections, tests, demonstrations and analysis that the designed and constructed product can meet the requirements. Verification work is accomplished through comparison. That is, the characteristics of an element under inspection are compared to a pre-determined standard. In making this comparison, there are four commonly accepted test methods that might be applied:

  1. Test -- A test element is subjected to a controlled series of stimuli, and the article response is monitored and compared with a standard, expected and predicted result.

  2. Analysis -- Product item features are examined for compliance with requirements by understanding its elements and relations.

  3. Demonstration -- A product is manipulated in accordance with a pre-determined process and specific set of instructions, and the actual results are compared with planned results.

  4. Examination -- A person (usually aided by tools) or mechanical device used for gauging and measuring, compares the measured or observed characteristics of an object with a standard.

Performance requirement metrics
Quantifying performance requirements is the essence behind the user-need approach described above for defining requirements. The table below provides a number of common metrics for performance requirements that will help you both elicit and write performance requirements.

Summary
Quality performance cannot be achieved unless you specify it. Software performance requirements address important user concerns for efficiency, interoperability, robustness, and testability. There are a number of quantitative measures that can be used to specify performance requirements. The performance requirements must be precise and measurable to establish realistic expectations and monitor attainment.

----------------------------------------
About the author: Roxanne Miller, Certified Business Analysis Professional (CBAP), is the founder of Requirements Quest and president of the International Institute of Business Analysis (IIBA) Greater Madison chapter USA.


This was first published in February 2008

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

Back to top