The System in So Many Words - The Ilities
(Page 3 of 5 )
The purpose of requirements is not only to validate what the user wants, but also to verify that the implemented systems meet those wants. Requirements include more than just functional specifications as supplied by use cases. These other requirements relate to the software's quality. They are often called the ilities, since many of the terms end in ility. These quality specifications include reliability, testability, deployability, and performance.
Often these quality requirements are not documented for a system. They are implicit, such as in the case of Sam's system. It is assumed that the system will meet reasonable requirements. For example, its performance should ensure that users do not notice a delay.
For larger, more complex systems, documenting these quality requirements is essential. You can find further information on eliciting and documenting requirements in Software Requirements, Second Edition, by Karl E. Wiegers (Microsoft Press, 2003).
Reinvention Avoidance Once Tim and I understand Sam's system requirements, our first step is to determine whether an existing program provides the features that we need. There is no sense in recreating the wheel if an existing wheel works the way we want. Our goal as developers is to solve the clients problem, not to just write code.
Sam had searched for a commercial program and did not find anything. It appears that he is in a unique business, so nothing has been written, which is not surprising.*
We suggested to him that the process of renting a CD is similar to the process of renting a videotape or DVD. He could purchase one of those programs and it would already have many of the features that he wanted. He decided that he would rather have his own custom program instead of dealing with the terminology and handling differences among CDs and DVDs. We recommended that if he decides to expand into selling CDs, we should investigate retail sales systems. A lot of functionality already exists in those systems that should not be re-created. If a preexisting solution fits into the overall system, at least that part of the wheel need not be recreated.
DON'T REINVENT THE WHEEL
Look for existing solutions to problems before creating new solutions.
Since Sam wants us to develop a custom system, Tim and I start to analyze the problem. We need to outline the concepts involved in the problem and clarify our understanding of what needs to be solved.
Next: What's in a Name? >>
More Practices Articles
More By O'Reilly Media
|
 This article is excerpted from Prefactoring, written by Ken Pugh (O'Reilly; ISBN: 596008740). Check it out today at your favorite bookstore. Buy this book now.
|
|
