The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Software Intent/Requirements

From a quote I just saw here:

"Unit tests don't answer the interesting question about software: why. It's related friend is intent."

And I started thinking about the general problem of turning requirements into software.  Unit tests are *almost* right, but there still isn't a way to really "program" the intent.

I've played around with modelling some languages that map expectations, and they end up looking a lot like old commandline adventure games from Infocom.  A map of expectations.

I wonder if anyone has ever really modelled intent, or requirements, as a sort of language unto itself... I know from experience that there are "design patterns" in requirements, especially within any given organization... but its like programming without a programming language.

You build all these design docs and things to try and capture what you want, but I feel that its like we're missing some simple language we could use to codify our problem, need, desire, etc and expectations in some machine readable format that is abstracted from individual programming languages.

Yes, I understand there is UML, and other such tools.. but I mean something you could pop open notepad and write up.  Unit tests would end up a part of it, but I suppose you would build an "interface" that the design talks with.

This also goes along with something I saw on half-bakery called "articulate" programming.. sort of pre-emptive logging...

Unfortunately, theres this little seed of a thought in my head, and I'm not sure I can explain it well enough yet that would enable some sort of dialog, instead of just getting examples of existing technologies or methods.
Michael Johnson Send private email
Tuesday, August 30, 2005
Perhaps "intentional programming" is what you seek...
Former COBOL Programmer
Tuesday, August 30, 2005
There's a package called 'FIT' which is aimed at letting non-programmers provide test cases in a sort of "if I do this, I want this to happen" style. See

Never used it myself, would be interested if others have
Edwin Young Send private email
Tuesday, August 30, 2005
As a side issue on the page
Reverand Cobol seems to be a proponent of a Big design up front ...
"I'm not sure the documentation would have to be that cumbersome, as part of coding any project (in an ideal world) you already have a design doc implemented that contains a flowchart mapping every possible function call and result. "

should you realy mix requirements/intent with all code? if you have a reusable widget that displays a table you intent is to display a table of information - for the widget - but when you actualy use the widget in some instance it could be used, say as a paired item picklist.

I'd prefer a system that just said, I can't look up site x, would you like to know the root problem?  I can't open your config because it's not readable, go and check file X or run the config tool to fix it.

Wednesday, August 31, 2005
"but I mean something you could pop open notepad and write up"

You mean like project scope/goals, use cases, and operational scenarios?  :)

My initial thought is: if there were really a way to codify intent such that the average customer were able to express it fully, then a number of older professions would've figured it out by now.  If converting intent to specification were a simple mathematical transformation, the world wouldn't need architects or designers.
Matt Brown
Wednesday, August 31, 2005
Don't get me wrong Matt, I *know* the value of a designer. (Boy Howdy), like I said - I'm not sure I have the vocabulary to correctly articulate my thought.  Not necessarily the intent of the customer, *my* intent... I guess a sort of amalgamation between unit tests, psuedo-code, and "articulate" stuff.
Michael Johnson Send private email
Wednesday, August 31, 2005

Why not have a look at Design by Contract?  The contracts are all about capturing intent during analysis and design work, and then "enforcing" it at runtime.

Here's a link to a brief introduction by Bertrand Meyer, but if you google, you'll get a large number of useful sources.
why not DbC?
Wednesday, August 31, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz