Specifications guide for program changes

[ngr]

We are looking to implement a more robust method of documentation for
program changes and modifications.

Does anyone use or recommend a particular method of defining a program
change and it's requirements that we could use as a guideline to develop our
own program specification design.

The problem we have is that we have an accountant who has self taught
himself programming telling programmers how to program, which is all very
well, but since the accountant is in charge and has had no training on
program specification - we as programmers argue about the kind of
information we need to retrieve from the management.

My request is to pick up from somewhere else in the real world - a sample
specification for a program change. It is all well me continulally asking
questions because of currently bad communication - but if I could present
some material which is already out there in the real world - then maybe I
can build a minimal requiremants policy which we have to maintain before
undertaking any program change.

Thanks in advance for any feedback.
Apologies for cross posting this into three groups but I want to put feelers
out to a wide spectrum of programmers etc who may be able to advise.

Terry

 

[JB]

We are looking to implement a more robust method of documentation for
program changes and modifications.

Does anyone use or recommend a particular method of defining a program
change and it's requirements that we could use as a guideline to develop our
own program specification design.

The problem we have is that we have an accountant who has self taught
himself programming telling programmers how to program, which is all very
well, but since the accountant is in charge and has had no training on
program specification - we as programmers argue about the kind of
information we need to retrieve from the management.

My request is to pick up from somewhere else in the real world - a sample
specification for a program change. It is all well me continulally asking
questions because of currently bad communication - but if I could present
some material which is already out there in the real world - then maybe I
can build a minimal requiremants policy which we have to maintain before
undertaking any program change.

Thanks in advance for any feedback.
Apologies for cross posting this into three groups but I want to put feelers
out to a wide spectrum of programmers etc who may be able to advise.

Terry

Hi Terry,

I can't offer you a methodology here but I see 2 main "common sense"
things you should think about and research/document before any program
change:
- Valid reason(s) for the change(s). If you can't clearly describe and
justify them... The change is probably not required.
- Impact of the change(s). To try minimising the "tree hiding the
forest" syndrome

Then there's obviously the cost versus benefits aspect but it's
somehow more of a business decision.

JB

 

[Marv]

Hi Terry,

I can't offer you a methodology here but I see 2 main "common sense"
things you should think about and research/document before any program
change:
- Valid reason(s) for the change(s). If you can't clearly describe and
justify them... The change is probably not required.
- Impact of the change(s). To try minimising the "tree hiding the
forest" syndrome

Then there's obviously the cost versus benefits aspect but it's
somehow more of a business decision.

JB

Having responsibility years ago for a large unit in developing large
integrated systems I cannot think of anytime the user who wanted changes
made did not consider the change to be valid and justified. We, as the
development team may not have thought so but inmost situations if the user
could convince management it was valid, then like it or not it is valid.

Second, the last sentence seems to imply that determining the cost benefit
is almost a secondary issue. In fact it should be the single most important
issue. If there is insufficient business case for a system, or a
modification of a change to an existing system then is should not be done.
Realistically, the world,however, does not always work this way.

Marv

 

[dpb]

We are looking to implement a more robust method of documentation for
program changes and modifications.

Does anyone use or recommend a particular method of defining a program
change and it's requirements that we could use as a guideline to develop our
own program specification design.
....
My request is to pick up from somewhere else in the real world - a sample
specification for a program change. It is all well me continulally asking
questions because of currently bad communication - but if I could present
some material which is already out there in the real world - then maybe I
can build a minimal requiremants policy which we have to maintain before
undertaking any program change.

Thanks in advance for any feedback.
Apologies for cross posting this into three groups but I want to put feelers
out to a wide spectrum of programmers etc who may be able to advise.

Not so much specific to your question regarding a precise or sample
change order/requirements documentation but to point you to a guy who
has a wide spread general practice of promoting software design
principles and scheduling estimation, etc., for ideas.

As I come from that side, I first saw him in the Embedded Systems
Programming monthly a number of years ago, the follow on to which he
still writes for. While he specifically concentrates on firmware, the
ideas and techniques espoused are generic. The guy is Jack Ganssle, and
you can find his web site at www.ganssle.com

I think resources there can probably provide you an excellent starting
point and if you don't find what you're looking for directly, he's one
of the "good guys" and a note to him would almost certainly get you back
a bunch of pointers plus probably a well-thought-out reply (unless he's
currently off on his sailboat in the Atlantic somewhere, of course...
although I just got the latest monthly e-letter yesterday).

HTH at least w/ a starting point, maybe...