FPGA Central

"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
news:[email protected]..

> One reason the requirements need to be understood is to avoid changes.
>
> You should have a process to prevent changes.

ACK!

Preventing changes, the good old "requirements freeze" is a sure way to kill
a project.

Requirements are going to change. To pretend otherwise is just putting your
head in the sand. The name of the game is to manage the requirements. For
some reason, many software professionals seem to believe that "requirements
management" is the same as requirements elicitation, but there is a bunch
more than that.

You need to understand the impact of requirements changes, and deal with
them. Yes, some changes should be resisted. Requirements changes that will
significantly affect the development effort must be identified, and then the
effort re-sized. That may mean renegotiation. The renegotiation may cause
the customer to re-think how urgent the change is, or not. Most
requirements changes, though, are not of that nature. Most are probably just
refinements of our understanding of the requirements. Usually, we try to
pretend that these are not changes by simply not documenting them. That way
we'll have to re-learn them. Other times we discover that we misunderstood
the requirement in the first place. Well, recognize that as soon as
possible when it has the minimum impact, and recognize the impact.

Requirements management isn't easy, but it's not a black art either. It's
mostly about keeping your eyes wide open.

...

"xpyttl" <[email protected]> wrote in message
news:IWAEe.15990$[email protected]..
> "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
> news:[email protected]..
>
>> One reason the requirements need to be understood is to avoid changes.
>>
>> You should have a process to prevent changes.
>
> ACK!
>
> Preventing changes, the good old "requirements freeze" is a sure way to
> kill a project.
>

I'm sure we could argue about this forever.
I think it's mostly a matter of context.
One can just as easily say: "allowing changes is a sure way to kill a
project".
Then, all you have to do is sort out what the heck either of us is talking
about...
Because both perspectives are fine.

I once worked on a project where the box was going to be painted blue. And
then it was going to be painted silver. And then it was going to be painted
green. So, we kept going to meetings and never finishing. That's a good
example for when a requirement should have been frozen. At least it would
have saved a lot of precious time! It really didn't matter all that much
but a lot of stuff was left hanging pending the decision on the color of the
box!

Sure requirements change with new awareness, changed conditions, etc.
Here's an example of how "new awareness" messed up a project:
We were building a processor-based system. It was new technology. The
operating system had been selected and we were on a path to getting the
system implemented.
Then, the principal in software went to a symposium and met a real OS guru.
Actually our software principal was a guru in his own right. Anyway, he
came home convinced that our OS could have a much smaller footprint in
memory. He trashed everything that had been done and started over because
it appeared that "better" was indeed better and "good enough" wasn't good
enough.

........ and the project did not complete on time to matter. It fell off the
edge of the table.

Ever hear: "if it ain't broke don't fix it" ? That's a design freeze and it
makes sense.

Fred