Home arrow Practices arrow Page 3 - The System in So Many Words

The Ilities - Practices

This article will show you how to talk to a client so that you are both on the same page when designing a system and understanding what it will be required to do. It is excerpted from Prefactoring,  Written by Ken Pugh (O'Reilly; ISBN: 596008740). Copyright 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

  1. The System in So Many Words
  2. Sam's Use Cases
  3. The Ilities
  4. What's in a Name?
  5. Splitters Versus Lumpers
By: O'Reilly Media
Rating: starstarstarstarstar / 2
May 15, 2008

print this article



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.


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.

>>> More Practices Articles          >>> More By O'Reilly Media

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: