The Old Joel on Software Forum: Part 3 (of 5) - Requirements versus object model

Requirements versus object model

I keep seeing attempts of various kinds (Rational Unified Process, Rapid Development something or other) to take a project rather mechanically from a detailed set of requirements straight through to functioning software.

The idea seems to be that if your requirements are done properly and in enough detail there must be a method that a chimp could use to turn them into software.

I think this is misguided. In my experience it is far more important to create a good object model. I think it's because reality changes less frequently than requirements. I look for a fairly minimal set of requirements to start and then try to do a really good model of the "reality" of the business space.

I then look to the GUI to mediate between the ever changing set of requirements and that model. I admit this must seem a bit too mid-1990s but I don't see how the newer way can work on anything but a simple project.

Agree? Disagree? What sorts of projects have you had success on using the aforementioned methods?

Name withheld out of cowardice
Monday, January 5, 2004

Uh, the process is supposed to be

Requirements->object/data model->application

Where, exactly, do you get your object model if you have no requirements?

Philo

Philo
Monday, January 5, 2004

My company's mission statements?

"Requirements? Requirments are whatever the business team comes up with at any given moment."

"Specs? We Don't Need No Stinking Specs!!!!"

GenX'er
Monday, January 5, 2004

Philo-

Not "no requirements". Just general not incredibly detailed requirements. The requirements tell you what the program is supposed to do and what space you are working in. Then you model that space. It is the same order you are talking about it's just the emphasis is on getting the objects right.

I just don't think it works terribly well to start with, for example, a bunch of very detailed use cases, elaborate those with sequence diagrams and then say that the names on the arrows in the sequence diagrams give you the methods of your objects.

I might not be expressing this well. I just don't have faith in this idea that a user's (graphical often) interaction with the system translates directly into object methods.

To take an example of the sort of projects I work on in the medical space: I know that if I am working with patient encounter documentation that certain objects will be required. I need an Encounter object, a Patient object, maybe a lab results object. I decide how these objects should behave to reflect their real world equivalents. A patient has a first name and a medical record number. A lab result has a test name, a value and units.

If these are well modeled they should be able to handle any requirements that are thrown at them. THe rest of the software and the GUI intermediate between the underlying object model and the user's metal model/requirements.

Detailed requirements are still needed. I am just making a point about the relative importance of each and disputing the idea that requirements can robotically be turned into working code.

Name withheld out of cowardice
Monday, January 5, 2004

I think he's saying he just tries to model everything rather than picking a subset which may change later. Obviously that results in extra complexity and time wasted creating and debugging features the customer will never use, but it does make it easier to extend in the future (or to other customers).

But most usually on't have the luxury of cost to over-create like that, and especially if it's a one-shot project it's just wasted time.

Rick
Monday, January 5, 2004

Rick:

I think you are closer to the idea though I would only over create in the object model; not in any of the glue or GUI stuff.

As for one shot projects, they are rare in practice. Too often they prove useful and then need to grow. I don't find it time prohibitive to over create for these eventualities. I don't have to code the methods until they are needed.

I also find that this exercise teaches enough about the problem to be worth it. It tends to reveal integration issues.

Name withheld out of cowardice
Monday, January 5, 2004

Deriving software (implementation) from requirements (constraints) goes back a long way. Superficially it goes back to Prolog and 'logic programming' but really you can go as far back as you'd like (Russell/Whitehead's Principia Mathematica to axiomatize mathematics and create a mechanical proof generator especially).

In some cases you can get a lot of implementation from a small number of constraints. Things like formal grammars (context free grammars deriving parsers for example), database queries, and even (if you're liberal enough with the notion of computational reduction) the quantitative sciences.

However, that doesn't work forever (as Goedel proved), and you eventually get to a point where adding constraints results in little or no effect in the generated implementation.

K
Monday, January 5, 2004

K,

Do you read your posts before you actually post them? Do you want to prove something about yourself?

Incidentally, I'm a graduated in Mathematics and CS so I am familiar with the terms/names/concepts you’re talking about, however I mostly fail to understand how they relate to the discussed topic.

DP
Monday, January 5, 2004

DP,

I'm sorry that I wasn't clearer. I posted that message a bit late and missed all the discussion before it.

I was specifically responding to this part of the original message:

"The idea seems to be that if your requirements are done properly and in enough detail there must be a method that a chimp could use to turn them into software."

I didn't mean to browbeat anybody. I'm sorry if I gave that impression.

My point was that there's a lot of historical precedent for this idea and that it's been attacked from a lot of different angles. There might be a mechanical procedure for converting the original poster's requirements into implementation, but it depends on the type of project. I also tried to list a few examples of areas where mechanical procedures exist to convert simple specifications into implementations.

K
Monday, January 5, 2004

"But most usually on't have the luxury of cost to over-create like that, and especially if it's a one-shot project it's just wasted time. "

How many one-shots do you spend your time on? For my own work, I have several applications (with more to come) built on top of a shared business model, so this "bottom-up" approach actually saves me a great deal of time, and ensures a higher quality, more consistent result for obvious reasons.

What kinds of apps are folks writing that represent a "one-shot" effort? I'm curious.

anon
Monday, January 5, 2004

K

I understood what you meant and I thought it was on point to some extent.

Name withheld out of cowardice
Monday, January 5, 2004

anon:

Thanks- "bottom up" is another good way of putting it. Possibly Philo could now provide a less sarcastic comment?

Name withheld out of cowardice
Monday, January 5, 2004

Nonono!!! I've done exactly what you've done a number of times, and I always had to redo to my object model to some extent. Sometimes a little, sometimes maor changes. Finally, I started doing something different, and it is 100% better:
Gather requirements enough to were you can write individual user stories. Then, if you need to write psuedo-code, do it. NOW your ready to develop your object model, once you see how your going to be using your objects. Good luck!

vince
Monday, January 5, 2004

Name Withheld - it sounds like you've backed into extreme programming. Check it out, but don't get distracted by the pair programming stuff - that's severable from the general concept.

Philo

Philo
Monday, January 5, 2004

Start with a vague, nebulous idea.

"Just write the code then we'll tell you if that's what we wanted".

Repeat.

Converge.

Don't you just love corp IT?

fool for python
Monday, January 5, 2004

It's good to have written requirements.

Otherwise, the b0ss will tell you something, you will implement it, and then he will tell you "that is not what is needed, and not what I told you to do - bad, bad programmer!"

So - you need to have a written spec - even if it doesn't contain all the details.

Scintilator
Monday, January 5, 2004

I like K's point. The comparison to an automatic proof generator is especially apt. Even trivial software is more complex than most mathematical proofs, yet the idea that software can be automated continues to keep returning. Solve the problem of the mathematical proof generator first and then we can talk about automatically generating software from requirements.

Dennis Atkins
Monday, January 5, 2004

"Start with a vague, nebulous idea.
'Just write the code then we'll tell you if that's what we wanted'.
Repeat.
Converge."

Now that sounds more like Kansas to me.

Just me (Sir to you)
Tuesday, January 6, 2004

Proof has to be correct.

Software doesn't. At least, most software isn't "correct" in the mathematical sense, and the sky isn't falling.

Automatic proof is not simpler a-priori.

Ori Berger
Tuesday, January 6, 2004

Extreme programming? Curses, I never wanted to participate in anything with the word "extreme" in it. I have looked at XP and I think they have some good ideas but I agree the pair programming thing is not for me.

I also agree that you need written requirements because there has to be some point of agreement between you and the customer.

I also agree that no one could get the object model correct the first time any better than he could get the requirements right the first time.

I was merely making a point about the approach, the philosophy in a way. Perhaps I am suggesting an XP sort of approach.

Name withheld out of cowardice
Tuesday, January 6, 2004

"NOW your ready to develop your object model, once you see how your going to be using your objects."

This is essentially a top-down approach. It's great for speedy development, but it definitely optimizes for a case-by-case solution (absent continuous refactoring). This is probably the right way to go about implementing the "one-shot" solutions mentioned earlier. I disagree, though, that this is the best way to develop a shared business-tier, meant to support more than one or two specific applications.

anon
Tuesday, January 6, 2004

Ah, I never read about validating requirements. Are requirements such simply because someone describes them as such? Personally, just give me screen shots, describe purpose broadly and I'll put something together for you to critique. Nothing I hate more than the chicken soup approach to requirements which I define as the just keep writing about it method. Mix it all up; talk about the database and then how you want the states to show in a select list and then mention that some users should get provinces as well and .... just all mixed up. I've never worked on a project that had some sort of requirements that I could put through a validator to be sure they adhered to some system other than stream of consciousness. Screen shots, give me concrete items. Yet, most people prefer to just meander and hope you understand what they mean.

Me
Wednesday, January 7, 2004