Software Quality Attributes
Functional requirements describe functions and features the users need for the system to work. They represent the requirements we typically think of when we describe systems, and make up the majority of a functional specification document.
The following statements are examples of functional requirements for an online store:
- The online store shall store items and quantities in a shopping cart until the end user is ready to purchase them.
- The online system shall calculate the total of the purchase, and include applicable taxes.
- The online store shall accept credit cards as a form of payment.
- The online store shall confirm to the end user once the order has been processed, and provide a confirmation number.
Nonfunctional Requirements
In addition to the functional requirements are other requirements that don't actually do anything, but that are critical nevertheless. These nonfunctional requirements, also called “quality attributes”, specify system characteristics that are required for acceptance of the system by the end user. It is therefore imperative that you document such requirements in the functional specification.
An example of a quality attribute is reliability: the extent to which the system will execute without failure for a specific period of time. If this requirement is not specified, chances are it’s not going to be properly tested by your Quality Assurance team. On the other hand, if it’s properly documented and you use a Requirement Traceability Matrix to map it to a series of test cases, then you will be able to verify the system’s reliability and improve it if required before releasing it.
While customers do not generally provide such requirements, it is your responsibility to gather them. I've seen systems that met the functional spec, but were in the end rejected because they didn't meet the customer’s security and performance requirements. Don't let this happen to you. Make sure you capture nonfunctional requirements in your functional spec, and that you test against these requirements before releasing the product.
While there are dozens of nonfunctional requirements, you generally do not need to specify all of them. As a general rule, just like when identifying features, you only need to specify nonfunctional requirements that are important to the acceptance of the system. Following is a list of quality attributes, along with a brief description and some sample requirements.
Reliability: The extent to which the system will execute without failure for a specific period of time.
- The system should meet an SLA of 99.5%
- The Mean Time to Failure should be at least three months.
Availability: The percentage of “up-time” during which the system is fully operational.
- The system shall be available 24 hours/day.
- It shall be possible to upgrade the system while it is running.
Security: The ability to prevent and/or forbid restricted actions.
- Each page in the system shall authenticate the user.
- User’s that are not allowed to view specific areas of the systems will be redirected to the login page.
Performance: The systems ability to meet latency, throughput, and resource utilization requirements.
- All Web pages must download within 3 seconds during an average load, and 5 second during a peak load.
- While executing a search, the system must be able to display 500 search results per page.
Usability: The end user’s ability to learn the system and complete tasks.
- The end user shall be able to place an order within 30 seconds.
- The end user shall be able to access any page within 4 clicks.
Scalability: The system’s ability to handle a large amount of data.
- The system should be able to contain 1,000,000 users.
- The system shall accept 100 requests per second.
Summary
When managing your next project, make sure the nonfunctional requirements are clearly specified and well documented. This will not only help out your product development team make decisions while designing the system’s architecture. It will also make possible the acceptance of the product by the customer.
This article was originally published on www.gantthead.com.