CSC 205
Professor Stearns
Unusual Requirements
This list of unusual requirements provides good material for a system
boundary lecture and software design discussion. These are all
actual cases that, in some way, had a profound effect on Dan's life.
- The 8 day week
Dan had a customer that was quite proud of their 8 day week because it
solved the week/month problem. For this customer, each month has
exactly 4 weeks. Each week contains either 7 or 8 days; for example
January has weeks containing 7,8,8,8 days. September has weeks containing
7,8,7,8 days. This customer requires that their software vendor handle
8 day weeks.
- Grenade requirement
A digital telephone exchange customer requires their systems to survive
a grenade explosion in the [geometric] center of the system. Question:
how would you test such a feature?
- Optimize
A city in California specified a requirement to "optimize the
efficiency" of one of their computer systems. Unfortunately, this
requirement isn't all that unusual. Wait until you hear the result!
- Sort Order
A telephone company specified that the phonebook listings have
an unusual sort order. All the Macs (Mac, MC, Mc) were required
to be grouped; the normal sort order doesn't do this.
- Made in the U.S.A
A customer specified that all components of a large embedded
system be "Made in the U.S.A".
- We can't read
A customer, who had many functionally illiterate employees,
required a large application with no displayed text. This
requirement was stipulated only after a previous system, with
much displayed text, had failed badly.
- Solve this one!
A company ordered an embedded software system (ROMs, no disk) to be
installed in several countries using a variety of languages.
Two requirements made for quite
a difficult design problem (but they were insistent):
- The binaries must be identical across all installations. (you can't
fault them for this requirement)
- The software may not ask the users their language choice. (a reasonable
requirement)
- "Perfect" testing
A customer, obviously weary of software defects, requested that a
large software system be
100% path tested. (i.e. The test cases must exercise every possible
path through the software).
Last updated on 10/13/98