Stating Problems

Page last updated 04/21/99

 

The Difficulty in Stating Problems

  1. The more complex the problem, the more difficult it is to specify the details.
  2. Spoken languages are ambiguous.
  3. Writings contain assumptions based on experiences (common sense).
  4. Different people have different biases and different sets of priorities.
  5. Overlooking details is easy.

 

 

 

 

Assumptions

Given the following problem statement

Write program to sum a list of numbers.

What assumptions do you make in your thinking of a solution?

What range of data inputs?

Input form?  Output?

 

 

 

 

 

Ambiguity and Inconsistencies

Given the following problem statement:

Write a program to sum a list of numbers that ends with 0.

Is this clear to you?

What different interpretations are there?

 

 

 

 

 

Omissions

Consider the OPAC system for Beeghly Library.

What functionality is missing? Do not criticize the user interface--that's another issue.

Is what you wish realistic?

 

 

 

 

 

Writing Specs -- Reviews

Specifications are developed iteratively. 

Users are consulted; experts are consulted;

Specifications are drafted, reviewed and rewritten.

Eventually a set of specifications are agreed upon.

The language (technical terms) must be agreed upon as part of the process.

 

 

 

 

Computer Aided Software Engineering (CASE) Tools

  1. Aid in the initial specification of a problem.  The specs can be in graphical or textual form (can switch between the two for different needs).
  2. Specifications include calculation, input and output assumptions.
  3. As tasks are analyzed, they can be further subdivided.  The assumptions made at a higher level can be checked against the subdivided components.
  4. Once the design has been refined completely the tool may generate much of the code for an algorithm.  The code includes tests to help ensure that specifications are met.

These tools have their own biases, assumptions, and omissions.