Goals vs. Business objectives

[MJMurphy]

There is another meaningful distinction. Decide what set of problems the product is going to solve and avoid. Then specify the least stringent conditions that must hold to verify that those problems are not present (e.g. "It shall take no longer than x seconds for a user with profile y to book a reservation."). These conditions are the requirements. Any conditions that are more stringent (e.g. "The product shall guide the user through a reservation-booking wizard with the screen sequence specified in appendix A.") are design.

As we've already established, specifying the least stringent condition is just the starting point. Analysis, not design, is the process that results in a complete, precise, verifiable requirements specification. Your example is a good one, as a starting point. If the product users care about the screen sequence it is important to find out why. If the requirement is not identified in the specification it will be discovered in testing or after deployment.

Johnson is quite clear that he is referring to both kinds of specifications:

"So a requirement states the problem. A specification states the solution. Joel defines two kinds of specification: functional, which is the intended approach to solving the problem, and technical, which is a detailed internal implementation."

Couldn't be clearer.



Again, Spolsky clearly states that the topic of his articles is functional specifications. He repeatedly characterizes such specifications in design terms.

Johnson and Spolsky do refer to both functional and technical specifications and the quotes Johnson chose from Spolsky clearly state that the implementation details are in the technical specification. The functional specification is "entirely from the user's perspective". Again, as we have already established, not all specifications are design. And, the RUP analysis model, the IEEE SRS, and Spolsky's functional specifications are all descriptions of the external behavior of the product. They are all requirements specifications. Johnson and Spolsky are writing about a different topic, the importance of writing specs, and you should stop trying to twist their words to mean something they didn't intend.

I think you're reading too much into this statement. Requirements should be "short" in the sense that they should do no more than define the problems. I don't think it's fair for you to intimate that Johnson advocates requirements that are "incomplete", "imprecise", or "unverifiable".

I'm not intimating anything of the sort. Again, a "short statement of the problem" is an excellent starting point for analysis.

Nope. My definition of "requirement" excludes user interface and interaction design, so there is no contradiction.

But your silence in addressing the explicit contradiction I exposed in your nomenclature is deafening.

The contradiction is in your use of the term 'design' to mean either specifying external behavior or specifying internal implementation.

I've addressed your flawed logic repeatedly. There is no contradiction in my use of the terms.

But, you have not answered my question. Are you saying the implementation details belong in the functional specification? Or, are you saying this is what Johnson means so you disagree with him?

[MJMurphy]

Failure to distinguish between the external and internal is one source of confusion. Failure to distinguish between problem and solution is another source of confusion. But the real confusion - evidenced by explicit contradictions that you refuse to address - is in equating these two distinctions, as you have done.

No one is equating two distinctions so either you are deliberately misrepresenting this discussion or you are confused. I'm glad you at least agree that the external/internal distinction is important and can be a source of confusion.

By characterizing user interface design (quoted or not) as a "separate task" requiring a "specialized skillset", you have thereby admitted a "meaningful distinction" other than just the external/internal dichotomy.

You seem to like making statements about what other people think, believe, or have done, but I have not 'admitted' anything. Some requirements analysis tasks clearly require special skillsets. If a client asked for help defining requirements for an implantable defibrillator I would recommend analysts with the right skillset. That has nothing to do with whether they are analyzing or designing.

There are two very simple reasons for the importance of distinguishing between external behavior and internal implementation. First, the product users care about the external behavior. If the users care about it, it should be explored as a possible requirement. That does not mean we should not ask why they care. It means we need to know about it before the product is designed and built. Second, a particular set of requirements can be implemented in various ways. If the requirements and the design are co-mingled it is not possible to create an alternate design and implementation using the same requirements. This is just as true of user interface requirements as any other kind.

Some user interface requirements can and should be stated in very non-stringent terms. Others must be very specific. The user interface requirements for an implantable defibrillator for example are going to be very specific. In your reservation booking example the requirements can probably be non-stringent. But it would be a mistake to assume that without asking.

[rcauvin]

We're both repeating ourselves, MJMurphy, so I will focus my attention on two points.

First, you raise the following smokescreen:

Are you saying the implementation details belong in the functional specification? Or, are you saying this is what Johnson means so you disagree with him?

No. Johnson uses the term "implementation detail" loosely, and uses it differently from Spolsky. He nonetheless distinguishes requirements from specifications and then states explicitly, in the very next sentence, that functional specifications are among the specifications to which he is referring.

Now, you insist:

There is no contradiction in my use of the terms.

Well, then, forgive me, but I still don't see how you escape the reductio ad absurdum argument below:

P1. User interface designers produce specifications that describe only external aspects of the product.
P2. If a specification describes only the external aspects of the product, it does not contain design.
C. Therefore, the specifications that user interface designers produce do not contain design.

To make it easy on me, please answer the following questions with "Yes" or "No":

1. Is premise P1 true?
2. Is premise P2 true?
3. Does conclusion C follow from premises P1 and P2?
4. Do you believe conclusion C is true?

I look forward to reading your responses so that we don't have to repeat ourselves again.

[MJMurphy]

I will focus my attention on two points.

First, you raise the following smokescreen:

You have raised a pretty good smokescreen yourself by choosing to focus on two points that are relatively meaningless to this discussion.

I suppose the compassionate thing to do would be to let this thread die a well deserved death. It's been fun but I'm not sure repeating the same questions and answers is adding much value.

Johnson uses the term "implementation detail" loosely, and uses it differently from Spolsky.

This emphasizes the point: Using terms loosely causes confusion.

He nonetheless distinguishes requirements from specifications ...

As we've agreed, a specification can specify requirements. Distinguishing requirements from specifications does not make much sense.

reductio ad absurdum

A debate about the proper construction of arguments would be an interesting topic for another forum.

[rcauvin]

You have raised a pretty good smokescreen yourself by choosing to focus on two points that are relatively meaningless to this discussion.

<grin> You raised a parallel distinction between requirements/design and external/internal aspects of a product. I produced an explicit argument argument showing your own statements lead to a contradiction in terms. Which part was "meaningless to the discussion", the point you raised, or my having debunked it?

I suppose the compassionate thing to do would be to let this thread die a well deserved death. It's been fun but I'm not sure repeating the same questions and answers is adding much value.

It might add value if you actually addressed my reductio ad absurdum argument. Perhaps this thread would have ended long ago had you done so.

This emphasizes the point: Using terms loosely causes confusion.

As does using terms strictly but in a contradictory fashion, as you have done.

As we've agreed, a specification can specify requirements. Distinguishing requirements from specifications does not make much sense.

You and I define "specification" more broadly than does Johnson.

Nonetheless, leaving aside his loose use of such secondary terms as "implementation detail", his primary nomenclature is internally consistent. You, on the other hand, have failed to address the argument in which I show yours is internally inconsistent.

Well, then, forgive me, but I still don't see how you escape the reductio ad absurdum argument below:

P1. User interface designers produce specifications that describe only external aspects of the product.
P2. If a specification describes only the external aspects of the product, it does not contain design.
C. Therefore, the specifications that user interface designers produce do not contain design.

To make it easy on me, please answer the following questions with "Yes" or "No":

Is premise P1 true?
Is premise P2 true?
Does conclusion C follow from premises P1 and P2?
Do you believe conclusion C is true?

A debate about the proper construction of arguments would be an interesting topic for another forum.

Indeed. Feel free to e-mail me directly at r o g e r @ c a u v i n . o r g (without the spaces). Or is it really that you are afraid to address the argument?

[MJMurphy]

Feel free to e-mail me directly at r o g e r @ c a u v i n . o r g (without the spaces). Or is it really that you are afraid to address the argument?

An email exchange with you does not sound very appealing. Find an appropriate forum and we can debate the flaws in your logic ad infinitum.

In spite of what you may think your weak attempt at constructing an argument is not relevant.

What is relevant is your continued mistaken assertion that writing a requirements specification is design simply because a person called a 'designer' may be involved.

[rcauvin]

What is relevant is your continued mistaken assertion that writing a requirements specification is design simply because a person called a 'designer' may be involved.

What I have shown is that your definitions would entail that the specifications user interface designers produce do not contain design. I have never maintained that requirements specifications are design in my nomenclature.

If you truly believe the argument is flawed, why don't you simply address what, specifically, is wrong with it? The argument has two premises and a conclusion. Do you reject one or both of the premises? Or do you maintain that the conclusion does not follow from the premises?

You and I have been discussing how best to distinguish and define requirements and design. The internal consistency of a nomenclature is one of the primary ways of determining its value and utility. The argument I've laid out strikes at the heart of the consistency of your nomenclature. Thus it is highly relevant to what we have been discussing.

[MGoyal]

i just read this thread and I must say I'm sorry to see rcauvin and mjmurphy decided to let it end. very interesting and entertaining.

[AlanAJ]

i just read this thread and I must say I'm sorry to see rcauvin and mjmurphy decided to let it end. very interesting and entertaining.

Well...it had its moments but it was probably right to call it a day.

A game I like to play is to avoid using the word "requirement" altogether. Something about the word and its association with authority seems inappropriate in the context of the progressive elaboration of problems and their solutions.

There is some appeal to Roger's "least stringent condition" idea. One of the expressions I sometimes use in place of the R word is "loose constraint" (and sometimes I just use the word "constraint" loosely). The point is that for there to be any design there must be some freedom, but not too much. Adjusting the tightness of proposed constraints is one way of exploring what is a sensible amount of freedom for the design process.