Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Exercise Solutions (Restricted)

Chapters 1 2 3 4 5 6 7 8 9 11 12

Chapter 5

Question 5.1
How many different kinds of requirements can you think of? List them. For example, you might include functional requirements and security requirements.

  • cost
  • functional
  • timescale
  • availability
  • reliability and robustness
  • usability
  • speed
  • security
  • compliance and conformance
  • legal
  • environmental
  • ergonomic
  • social and political

Question 5.2
Classify the following requirements using your answer to the previous question. You can improve your answer to the previous question if necessary. (I am sure that the wording of these requirements could be improved as well.)

  • "The system must never be unavailable for more than three minutes."
    - availability
    ("The system must never be continuously unavailable for more than three minutes, nor unavailable for more than a total of ten minutes in any 24-hour day (using local time).")
  • "The machine room must have less than 0.1 ppm ozone."
    - environmental
    ("The machine room must have less than 0.1 ppm ozone, averaged over its entire volume and averaged over any ten minute duration.")
  • "The system must calculate the optimum angle of attack for the aft hydrofoil."
    - functional
    (Optimal for what? I don't know enough naval engineering to say, but I'd want to find out.)
  • "The system must be operating to the downtime requirements by 0001 hours 11 December 2003."
    - availability
    ("... by 0001 hours 11 December 2003, UCT.")
  • "The system must pass a FAST (Federation Against Software Theft) audit – no unlicensed software for example – and must not require registration under the Data Protection Act."
    - legal
  • "The system must play back at least 48 tracks of 24 bit/96 KHz uncompressed audio data, with one digital effect (e.g. reverb) per channel, simultaneously."
    - functional

Question 5.3
Break the following scenario down into "atomic", i.e. irreducible requirements.

"We would typically call up yesterday's menu. We would check with Chef to see if any particular stock items need using up via any particular dishes. I guess that maybe the system could help us with alerts as to any expensive stock approaching its use-by date. We would amend the menu to remove dishes not on offer today and to add the new dishes like the stock-using dishes and any other dishes that the manager or Chef have planned."

(You) "Would you type up the details of each new dish?"

"Well I guess there might be totally new dishes; but mostly we would want to call up some kind of overall dish list, where the typical price, description, etc. was already entered. Sometimes we would have to amend the defaults – for expensive ingredients whose prices fluctuate wildly, for example."

(You) "And would you be changing yesterday's menu to become today's? Or would you be leaving yesterday's menu on record and creating today's from it?"

"Oh, we would definitely want to keep a record of previously used menus; we'd simply be using yesterday's as a typical starting point. I imagine there would be times, though, when we'd create a menu completely from scratch."

The system must/should:

  • locate the menus used on a given date, and warn if the number of qualifying menus isn't exactly one.
  • display [please see interface/look/feel requirements section] a selected menu.
  • create a new menu by copying a selected, existing menu.
  • note dish(es) selected from a selected menu.
  • remove selected dish(es) from selected menu.
  • locate any dishes including those that are not necessarily related to any menus.
  • support the specification and creation of new dishes.
  • register and record changes to the specification of an existing dish.
  • register and record the addition of a selected dish to a selected menu.
  • record the details of the menu used on a given day (including but not limited to the details of the dishes it offered).
  • create a new and empty menu from scratch, ready to accept any dishes that will be selected for it.

[I have left these pretty much in the order in which they occurred to me as I read the question. JD]

The system could/won't:

  • according to a chosen periodicity, indicate (for example by printout) the stock item batches satisfying previously recorded criteria (including but not necessarily limited to stock item batches that will expire within an established time period).

[I decided to list the speculative requirement (or "change case") separately. JD]

[I, like many of my students, was tempted to put down that the system would help select the dishes that could use up the ingredients that were about to go off. But there's no evidence for that. That would be fantasy and a rod for my own back. JD]


Question 5.6
(Difficult) Quantify the following requirements. Come up with numbers that the system-to-be can be measured against in order to establish if it has met the requirement.

  • "The data shall be more consistent."
    A bison (version 1.875) compiled parser to transform our data into valid (quinge.dtd version 2.2), well-formed XML should be directly feasible and have no more than 83 terminal symbols and require no more than 300 grammar rules. (I.e. Assessing or establishing the complexity of a parser written to reformulate this data, into XML for example.)
  • "The system must register the details of a booking request."
    ... confirming that the details have been stored within 3 seconds, with a throughput of at least 20 bookings an hour, such that parsable fields -- for example, hour of booking and minutes past the hour of start time -- could be extracted. (I.e. working on the words 'register' and 'detail'.)
  • "The system must portray in a readily-assimilated fashion, the selected statuses (for example, location and/or readiness and/or ...;) of a flexibly selected sets of active personnel (for example, an individual, all personnel matching an input declarative query (e.g. SQL), or all active personnel)."
    The system must portray ... such that Comprehension Test 12a from Appendix B of document 2004-08-19_fullReq.doc is passed with a score of greater than 89% by 8 out of 10 randomly selected (see Appendix D of document 2004-08-19_fullReq.doc for randomization and selection procedures) full-time booking agent employees. (I.e. establishing the time taken to form a mental picture good enough that a comprehension test could be passed with a required degree of accuracy.)
  • "Usability is our number one priority."
    [This one defeated me. I went to [Principles of Software Engineering Management, Tom Gilb, Addison-Wesley, 1988, 0-201-19246-2.] and discovered how he thought about it and broke usability down into things that could be measured: JD]
    "- Level of personal ability required to enter training course for product
    - Training time required to attain a pre-determined level of productivity with the product
    - Specified amount of work to be produced by a person so trained
    - Rate of errors made by a trained user, operating at the normal work rate
    - The opinion (survey) of the users of the product as to how well they liked it."


Question 5.8
What are the subject matters for the following computer packages: a word processor, desktop publishing, a sales ledger and vehicle number plate recognition?

The subject matter of a word processor is writing (editing) and the written (printed) word. When searching (years ago) for inspiration as to the beginnings of the structure and content of a word processor, one would have considered the structure of text -- such concepts as letters, words, hyphens, dashes, stops, line endings, sentences and paragraphs; and nature of the output media -- such concepts as screen width and height, paper width and height, paper margins and page numbers.

[I am harking back to earlier, pre-bloatware days here. A "word processor" from the dark empire today seems to add, for example, the world-wide web as a subject matter. JD]

[It's interesting to think about our other route into a development during the early stages -- something that I will make more of if there's a second edition -- metaphor. There would have been at least two obvious, candidate metaphors: writing by hand and writing by typewriter. We, sensibly, chose the typewriter as our metaphor, with, for example, tab stops. I remember, however, at several times during the last 20 years, people jumping up and down excitedly about "pen" computing. Despite all the hype though, it's pretty clear that hand writing is the less useful metaphor. Yes, if I am holding some device and only have one hand, or if the device is small, hand writing is the appropriate metaphor. If there is some desk space available, however, most people would consider hand writing a severely backward step; surely only the one-fingered, hunt-and-peck-would-be-a-major-advance, brigade would use hand writing with a computer. JD]

The subject matter for DTP or desk top publishing is, of course, publishing. This would be an example of a subject matter so vast that clear requirements would be absolutely essential in providing boundaries. They would lead to a subset of publishing that would include word processing, computer graphics, typography, typesetting, pre-press, printing, binding, indexing, numbering, ...

The subject matter of the typical sales ledger works would be financial sales accounting and credit control.

A vehicle number plate recognition system addresses the subject matters of national vehicle registration marks, typography, image processing and pattern matching.