Smith x Kano = …

Some reflections on B.C. Smith’s “Limits of Correctness” 1985
Part II

Writing specifications that capture the intention is difficult. To illustrate this, Smith starts off with a simple example:

“Suppose you write a program to factor a number C, producing two answers A and B. Your specification might be: Given a number C, produce numbers A and B such that A x B = C .”

Now when applying the Kano Model to the example, one can nicely see several ways the intention can get lost:

Basic factors are so obvious to the customer that they would probably not mention them, like 1 x C = C, which is ‘of course’, not an acceptable solution.

Excitement factors are by definition not explicitly known by the customer, so they would probably not mention these until they become aware of them, either during the development, after it, or possibly never at all. For example, after coming across the concept of square numbers, the customer demands that whenever possible, A x A = C must hold.

Performance factors have a more difficult cost benefit relationship than the above ones. The customer can only identify the benefits. The costs depend on the technical design. This results in a cost benefit function, which is pretty hard to determine in detail – or at the very least requires extremely fluent communication between customer and designer.
Therefore, it is not easy to fulfill the right intention at the right price. For example, customer: “I want to impress my teacher with the program, so the more complicated A and B look the better”, designer:  “the more systematic the results are, the cheaper the program will become”.

So far, just a few thoughts.

About modelpractice

Modeling Theory and Abstraction Awareness in strive for scientific rigour and relevance to information systems engineering.
This entry was posted in Software_Engineering and tagged , , , . Bookmark the permalink.

2 Responses to Smith x Kano = …

  1. There’s one very important other factor: dependencies between the parts of the systems you attempt to create specification for.
    Important are currently detected dependencies that you can foresee and embrace in your specification.
    BUT even more important are dependencies that you don’t see at the moment and which will appear in future when other factors will come into play.
    Example: suppose you have 2 modules of the software system: one module for keeping citizens registry, other module which takes the list of citizens from the first one and is dealing with taxation. Suppose the first version of specification declares that when a person dies the first module should delete the record of that person from registry since no more taxation is needed for that person 🙂 System is built accordingly to specs, everyone is happy.
    Then years after city want to add one more module that will keep the financial history of people, even after their death. The person who will design this module will see that Registry modules must be changed to not delete the person after their death. He might forget about taxation module has a dependency on it and you’ll get undocumented problem 🙂

  2. Hi Alex,

    strongly agree, this redundancy stuff is a big issue. Thx for the example. Even when you have structured your application properly, low coupling, ideal cohesion, normal forms, etc., there is always some redundancy left. Architects and Developers have things like aspects to handle this problem. Okay, in analysis one can put constraints to the model, but OCL-constraints are like writing your requirements directly in SQL.

    Models (programs/ mograms) and queries (aspects/ constraints) should be thought of as a pair, and how to deal with queries reasonably in Analysis is imho the next big challenge in the requirements area.


    ‘Coincidently’ I’m currently thinking quite a lot about this Analysis issue, no breakthrough as yet …

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s