Explanations should take around 40 words. Some slack will be given to 50 or 60 word explanations (however, don't press your luck too many times on this); explanations a page or more long will lose five points.

1. Prototyping can be used in requirements analysis and in requirements validation. Explain how the objectives of prototyping differ in each case.

   ---

   In requirements analysis, prototyping would be used to help the customer explore unresolved or poorly defined issues; rapid prototyping with little concern for prototype longevity would be appropriate. In requirements validation, prototyping would be used to check the SRD to determine its usefulness as a basis for system design; here a more formal and organized approach to prototyping with the potential to carry the prototype on into system design would be appropriate.

   ---

2. Explain under which conditions you would consider using only informal techniques for requirements analysis.

   ---

   The two main conditions on the problem are that it be small, so that the process of gathering and organizing the information can be adequately handled by informal techniques, and that it be familiar to the requirements analyst, so that the differences between the current problem and previous problems can be identified easily with informal techniques.

   ---

3. A colleague of yours argues that it's bad for a system requirements document to use more than one specification language because it can lead to confusion. What is your reply to your colleague's remark?

   ---

   Your colleague raises a valid point, but an even greater confusion can result from using a design language that is mismatched to the problem feature it's describing. It might be possible to represent a system's state transitions using a decision table, but it's more straightforward and intuitive to use a finite state machine.

   ---

4. System requirements document quality metrics are vague because it's difficult to quantify quality. However, there is one quality metric that is important and meaningful. What is it and explain why it's important and meaningful.

   ---

   Error-counting metrics are important because errors represent expensive disruptions in the software development process. They are meaningful because there is little room for interpretive doubt when an error occurs.

   Some people gave change requests as an answer to this question. Change requests are important, because each request represents a potentially expensive set of alterations to the project, and because there's a high correlation between errors and change requests. However, change requests may arise from other sources, such as changes in the environment, so it's a bit harder to ascribe meaning to change requests than it is to ascribe meaning to errors.

   Size was a third answer given. Size is important in its own right and as a basis for estimating other important quantities. But it's difficult to get meaningful measures of size early in the project, which makes size a less reliable metric than change request or error counts, at least in the early stages of work.

   ---

This page last modified on 14 February 2000.