We always say we shall provide high quality product to our customers. What does quality mean, anyway?
If you ask a programmer, I bet the answer would be “no bugs.” Is that it? Would you please define “bug”? Say, if I deliver a stone to you, and tell you there is not a single bug in it, does that count as high-quality software?
Quality is a vague concept, and could be better defined as “fitness to purpose.” If the software doesn’t help our customers achieve their purpose, how bug-free doesn’t even matter.
What is our customers’ purpose? Selling the phones, yes, but through right functionality, smooth execution, and robust performance. The functionality, or feature set, can be elicited through several proven methods, and we might discuss that later. The other two lead us to “Quality Attributes.”
Quality Attributes cover all those vague items we usually use to describe a software system. Some of the common ones are listed here:
- Extensibility: how difficult it is to extend the feature set
- Maintainability: how difficult it is to fix a bug in it
- Performance: how fast it is
- Robustness: how strong it is when abused
- Usability: how easy it is to use the system
- Capacity: how many requests it can handle
One major goal of requirement elicitation phase of the project would be to nail down use cases for these “-ilities.” For example, usability can be defined as how much time or how many key strokes it would take a novice user to accomplish a certain task.
How important these Quality Attributes, or the requirements describing them, are? I’d say very important, because our architecture would be decided by them.
No comments:
Post a Comment