tek@ms.uky.edu (Thomas E. Kunselman) (03/01/91)
What types of specifications do you require from your programmers before
embarking on modifications/enhancements to a large software application?
I have recently been placed on a committee which is to advise and review
changes to our Student Information System software. Currently there
seems to be no written or formal procedure for informing committee
members exactly what the changes will be and what the new screens will
look like, or new procedures for using whatever the enhancement will be.
I am interested in learning about what existing organizations use when
they are undertaking chanes of this type. I am especially interested
in learning what types of information we should request from our
programmers to aid us in discovering whether an enhancement will actually
meet our needs when it is copleted, or whether it will need further
enhancements itself.
Some of the types of items I can think of are mentioned in the above
paragraph, for example, screen layout of data elements, key strokes
required by the operator, time estimate for completion, examples of
real life situations that will need to be handled by the enhancement,
etc. Any additions to this list would be greatly appreciated. Also
appreciated would be any examples of software specifications, or some
sources where I might get a general idea of a standard form to be used
for this type of thing.
Thanks,
--
Thomas Kunselman {rutgers,uunet}!ukma!tek
Institutional Research and Planning bitnet: vaatek@ukcc.bitnet
University of Kentucky internet:tek@ms.uky.edu
Lexington, KY 40506-0032 (Educate, Don't Legislate!)djbailey@skyler.mavd.honeywell.com (03/01/91)
In article <1991Feb28.184021.22862@ms.uky.edu>, tek@ms.uky.edu (Thomas E. Kunselman) writes: > > What types of specifications do you require from your programmers before > embarking on modifications/enhancements to a large software application? I don't get to require anything, but I recommend you make them write a preliminary user's manual that answers the questions in the rest of your posting. It will help them think about the system features that should be considered early and help you to understand what you will get. A user manual may not cover everything you need but it should cover a lot. -- Don J. Bailey
jls@yoda.Rational.COM (Jim Showalter) (03/02/91)
Regarding specifications, I have always felt the right way to do it
was to write the user's manual first, and make that the formal spec
for the product. From the standpoint of the user, this is all that
matters anyhow (I include system administrators in the user category).
If the members of the user-community-to-be read the manual and don't
like parts of it, you can make changes at very low cost.
I'm told at least some divisions/projects at HP use/used this approach.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine.
-- "When I want your opinion, I'll beat it out of you."