Quality of requirements specifications
Arno Vermunt
Hi,
I am new to this newsgroup, so I hope my question is appropriate for it
and not asked recently before.
I am wondering of the opinions you have of what is a good quality
requirements specification. This document is reported to have
characteristics as completeness, clarity, consistency, accuracy. How do
we operationalize characteristics like these? How can we say a
specification is good? How can we compare specifications, and say one is
better than another one?
What is your opinion about this? What are frequently used references to
literature on this?
Warm regards,
Arno Vermunt,
Ph.D.student, Tilburg University
Wayne Woodruff
If you have a process, policy, or product and you want to measure
the effectiveness/quality/whatever of it, you will need some metrics.
One way you can start this process is to track defect against the
Requirements Specifications. Look at the root causes and see where
the defects are coming from.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/ Wayne Woodruff \
home page: http://www.jtan/~wayne
\ email: wa...@bmwmat.bucks.pa.us /
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Dr. Micheal Mac an Airchinnigh
Hi,
I am new to this newsgroup, so I hope my question is appropriate for it
and not asked recently before.
I am wondering of the opinions you have of what is a good quality
requirements specification.
[[chop]]
= There are criteria other than those cited.
= Let us assume that the requirements spec is written in English.
=
= Then "written in *good* English" is the first measure of quality.
=
= Regrettably much "reqs spec" is written in Englishese
= which might be defined as something that seems like English
= but which is really full of technical jargon assumed to be
= understood by all.
=
= After that, one distinguishes between that part of the
= "spec" which might be "formalized" in some sense and that
= part which could never be. A good reqs spec will make it
= easy for the reader to distinguish between the two parts.
=
= After that .........
= ....... well.........
= all those things you mention are usable :-)
Warm regards,
Arno Vermunt,
Ph.D.student, Tilburg University
=======
= Regards, MMaA
--
To get random signatures put text files into a folder called ³Random
Signatures² into your Preferences folder.
Jonas Andersson
On Wed, 27 Aug 1997 16:03:32 +0200, Arno Vermunt <A.H.V...@kub.nl>
wrote:
>Hi,
>
>I am new to this newsgroup, so I hope my question is appropriate for it
>and not asked recently before.
>
>I am wondering of the opinions you have of what is a good quality
>requirements specification. This document is reported to have
>characteristics as completeness, clarity, consistency, accuracy. How do
>we operationalize characteristics like these? How can we say a
>specification is good? How can we compare specifications, and say one is
According to my oppinion it is very hard to say that a specification
is complete, clear and consistent.
A good but costly way to insure that the requirements are clear would
be to follow the ISO-guidelines for requirement specifications. It was
some time ago I read these so I don't know the number.
One of the basic guidelines for the requirements is that every
requirement should be numbered and also that every requirement should
be testable. This is a pretty big statement but it would provide a
good requirement specification, but costly.
Jonas
---------------------------
Jonas Andersson
E-mail: jonas.a...@adiuvabo.se
Jon Jacky
On Wed, 27 Aug 1997 16:03:32 +0200, Arno Vermunt <A.H.V...@kub.nl>
wrote:
>I am wondering of the opinions you have of what is a good quality
>requirements specification.
An important thing that is sometimes overlooked: the future users of
the system should be able to understand it and agree that it describes
the system they want.
- Jon
--
Jonathan Jacky j...@radonc.washington.edu
Radiation Oncology, Box 356043 voice: (206)-548-4117
University of Washington FAX: (206)-548-6218
Seattle, Washington 98195-6043 USA
John D Salt
In article <5uh4fk$rpm$1...@trsvr.tr.unisys.com>,
L. Darrell Ray <NotG...@ReqD.com> wrote:
> [snips]
>Cheaper than getting the requirements wrong. IMO and in *every* case were
>I've seen it done making sure you get the requirements right is *much*
>cheaper in the long run than trying to save a few dollars or days at the
>beginning of a project (for a non-trival project of course).
While not disagreeing with the sentiment, the way it's expressed
implies that getting requirements "right" is something that happens
only at the beginning of a project.
If you use evolutionary development, you're homing in on the
requirements the whole time -- they are moving the whole time,
too, right?
All the best
John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.
L. Darrell Ray
In article <340baa3e...@138.221.200.100>, jonas.a...@adiuvabo.se (Jonas Andersson) says:
>
>
>On Wed, 27 Aug 1997 16:03:32 +0200, Arno Vermunt <A.H.V...@kub.nl>
>wrote:
>
>>Hi,
>>
>>I am new to this newsgroup, so I hope my question is appropriate for it
>>and not asked recently before.
>>
>>I am wondering of the opinions you have of what is a good quality
>>requirements specification. This document is reported to have
>>characteristics as completeness, clarity, consistency, accuracy. How do
>>we operationalize characteristics like these? How can we say a
>>specification is good? How can we compare specifications, and say one is
>
>According to my oppinion it is very hard to say that a specification
>is complete, clear and consistent.
>A good but costly way to insure that the requirements are clear would
>be to follow the ISO-guidelines for requirement specifications. It was
>some time ago I read these so I don't know the number.
>One of the basic guidelines for the requirements is that every
>requirement should be numbered and also that every requirement should
>be testable. This is a pretty big statement but it would provide a
>good requirement specification, but costly.
>
>Jonas
>
>
Cheaper than getting the requirements wrong. IMO and in *every* case were
I've seen it done making sure you get the requirements right is *much*
cheaper in the long run than trying to save a few dollars or days at the
beginning of a project (for a non-trival project of course).
I've heard many claims about wasting time and expense on requirements
but have never seen a case were the evidence supported the claim. In the
case (all to many) were there is very little info. to go on an evaluation
of reported defects (test and field) has *always* found evidence that
many of the defects were caused by poor requirements.
L. Darrell Ray (CSQE)
ASQ Certified Software Quality Engineer
John D Salt
In article <340D42...@tpgi.com.au>, Andrew Gabb <ag...@tpgi.com.au> wrote:
>John D Salt wrote:
>>
>> If you use evolutionary development, you're homing in on the
>> requirements the whole time -- they are moving the whole time,
>> too, right?
>Starting evolutionary development with an assumption that you don't need
>to capture requirements at the start is for the very rich, those with
>lots of time, or those with very small projects (or those with fabulous
>mind-reading software developers, of course, and I MEAN fabulous).
I'm not aware that anyone has ever suggested that you shouldn't try
to capture requirements at the start. However, the main way of capturing
requirements that I know works is to show something to the user and
say "is this what you want?". A sadly high proportion of software people
I've come in to contact with seem to imagine that they are "capturing
requirements" when they are merely producing incomprehensible documents.
Yes, I have seen a metre-high software requirement document. I didn't
read it, though, and neither, I suspect, did anyone else. I am quite
confident that people who use this system will be discovering requirements
they didn't know it didn't address for the whole operational lifetime
of the system.
>In virtually any project you have to get the requirements into good
>shape at the start, or how are you going to start your design and
>budgeting? And you have to revalidate/update the requirements as often
Something of an aside here, but I just can't bring myself to see design
and budgeting as the same thing at all.
I'd say an engineer should try to get requirements as right as possible,
as quickly as possible, as simply as possible, for as long as economic
justification remains.
All the best,
Uta Birk
John D Salt wrote:
> In article <5uh4fk$rpm$1...@trsvr.tr.unisys.com>,
> L. Darrell Ray <NotG...@ReqD.com> wrote:
> > [snips]
> >I've seen it done making sure you get the requirements right is *much*
> >cheaper in the long run than trying to save a few dollars or days at the
> >beginning of a project (for a non-trival project of course).
>
> implies that getting requirements "right" is something that happens
>
> If you use evolutionary development, you're homing in on the
> requirements the whole time -- they are moving the whole time,
> too, right?
But the main point is: before you perform one step the requirements
for this step have to be clear, testable and you need acceptance
criteria to tell when a requirement is incorporated in a system.
When you are doing evolutionary developement you need a policy
for changing requirements during the process and configuration
management must be able to handle differen versions of requirements
and/or specifications.
MB
--
<priv.>
John D Salt
In article <5ukrje$7ta$1...@newsgate.sps.mot.com>,
Robert Altizer <alt...@fasolt.sps.mot.com> wrote:
>In article <5ujtsj$e...@molnir.brunel.ac.uk>, John...@brunel.ac.uk (John D Salt) writes:
>>
>>I'm not aware that anyone has ever suggested that you shouldn't try
>>to capture requirements at the start. However, the main way of capturing
>>requirements that I know works is to show something to the user and
>>say "is this what you want?". A sadly high proportion of software people
>>I've come in to contact with seem to imagine that they are "capturing
>>requirements" when they are merely producing incomprehensible documents.
>
>can get a grasp (sometimes it must be a physical one!) of a significant
>portion of the whole system. For example, CAD systems, cellular phones,
>microwave ovens, email tools, or anything with a user-visible front panel
>works well here. But what about the cellular base station, the real-time
>factory equipment controller, the enterprise management system, or others
>where most if not all the functionality -- and complexity -- is hidden from
>any user? Unfortunately, many of the requirements for these *must* be
>captured in some form other than a prototype about which you can say "is
>this what you want?"
Okay -- let's tighten the nuts on my terms here, before they fall to
pieces in my lap:
"User" is probably too loose a term. What I should probably have
said is "specifier" or "customer" or "client" or "owner". I mean
"the person with whose desiderata the project is intended to comply",
[henceforth TPWWDTPIITC, which I challenge anybody to pronounce]
which normally means "who's paying".
Note also that I said you need to show TPWWDTPIITC "something", not
"a prototype", and ask "is that what you want?" Granted, the something
may very well be a prototype [a word I always use to mean "throwaway
prototype"], but it might also be some other kind of executable
specification, either a computer simulation or a manual simulation
(pushing coloured tokens around an activity-cycle diagram, say).
Quite early in the project, I'd expect "something" to be a working
version of the system -- albeit with precious little functionality
early on.
Now, with those qualifications in mind, is there any useful way to
capture requirements other than showing TPWWDTPIITC something and asking
"Is that what you want"?
As a further aside, I suspect that the politics of many projects
prevent disinterested efforts at complying with the desiderata
of the person who's paying; but that's a whole nother can of worms.
Ralph DeCarli
John D Salt wrote:
-- snip --
> Now, with those qualifications in mind, is there any useful way to
> capture requirements other than showing TPWWDTPIITC something and asking
> "Is that what you want"?
Shouldn't you start by asking your users what they want to accomplish?
The customers' job is to do somthing profitable with the software we
create.
Our job is to understand the essence of that profitability so that we
can write
programs that will facilitate it's capture. Your initial questions
should be
business specific:
What does your widget do? How do you uniquely identify an individual
widget?
what other information about widgets would be useful to you?
What market are you trying to capture? Who are the major buyers in this
market?
What information sources do you currently use to understand that market?
When customers are focused on teaching you their business and not on
learning
your software they should be able to tell you what they want.
--
Ralph De Carli | "I'm in a phone booth at the
msusah0...@eds.snorp.com | corner of walk and don't walk"
My opinions are not necessarily | anonymous
held by the fine people at EDS | Dead silence is the best flame.
Bill Bolton
>I am wondering of the opinions you have of what is a good quality
>requirements specification.
One which results in the system developed verifiably meeting the
customers real needs.
>This document is reported to have
>characteristics as completeness, clarity, consistency, accuracy. How do
>we operationalize characteristics like these?
The application of Quality Function Deployment approaches is a VERY
big step along the road of achieving these characteristics.
>How can we say a specification is good? How can we compare specifications, and say one is
>better than another one?
By the results.
An end to end systems approach should be strongly associating outcomes
with inputs, so the specifications should form the core of the
acceptance criteria. As an element of a specification is developed,
the method of acceptance testing it should be simultaneously
developed. This is one case where if its not testable, the
specification is probably truly meaningless (i.e. the often
encountered "sub-second response times").
You might want to look at:
The Art of Systems Architecting"
Rechtin/Maier
CRC, 1997
for some further development of these issues.
Cheers,
Bill
Bill Bolton billb...@acslink.net.au
Sydney, Australia
Merlin Dorfman
John D Salt (John...@brunel.ac.uk) wrote:
: In article <340D42...@tpgi.com.au>, Andrew Gabb <ag...@tpgi.com.au> wrote:
: >In virtually any project you have to get the requirements into good
: >shape at the start, or how are you going to start your design and
: >budgeting? And you have to revalidate/update the requirements as often
: Something of an aside here, but I just can't bring myself to see design
: and budgeting as the same thing at all.
They are not the same thing...but good requirements are needed
before either is started!
Merlin Dorfman
DOR...@COMPUTER.ORG
John D Salt
In article <dorfmanE...@netcom.com>,
Okay... now where do I get my budget for the requirements phase, please?
John D Salt
In article <340EE8...@eds.blerf.com>,
Ralph DeCarli <msusah0...@eds.blerf.com> wrote:
>John D Salt wrote:
> -- snip --
>> Now, with those qualifications in mind, is there any useful way to
>> capture requirements other than showing TPWWDTPIITC something and asking
>> "Is that what you want"?
> -- snip --
>
>Shouldn't you start by asking your users what they want to accomplish?
Maybe you've been luckier in the users you've worked for than I have,
but in my experience this leads to hand-waving dream-sheeting very
quickly. I have heard users request tasks that would not be finished
until the sun goes cold; I have been told that my application must
take no time to run, consume no disk space, and need no training
time to understand. Users usually have a very poor idea of what's
possible, what's easy, and what can never be done. I would also
argue that they often don't even know what they want until they see
it; there are what marketing men call "unarticulated needs".
Out of politeness, you may well start by asking what the user wants
to accomplish; but I think you'd be very lucky indeed if the answer
helped you capture requirements.
A pal of mine once expressed the advantages of evolutionary
development as follows:
"Since we moved to evolutionary development, we give the users
what they want, instead of what they asked for."
Ralf Comtesse
[Posted and mailed]
In article <340F1B...@ford.com>,
Larry Diehr <ldi...@ford.com> writes:
>
> There is a relatively new IEEE standard/guideline for developing system
> requirements specifications that may provide some guidance/clarity in
> the matter. Look up IEEE STD 1233-1966 - IEEE Guide for Developing
> System Requirements Specifications. It is mercifully short for an IEEE
> standard (or ISO/ANSI/ASQC/...) and could just provide the answers you
> are looking for.
>
> Larry Diehr
Where can I find this IEEE standard? Is it, or a paper about it, on
the net? I would appreciate any pointers to it!
Thanks in advance
Ralf
--
_____________________________________________________________________
Ralf Comtesse Tel: +49-30-28599230
Gipsstr. 15 Fax: +49-30-28599231
10119 Berlin
e-Mail: r...@socrates.in-berlin.de
_____________________________________________________________________
Andy Brice
John D Salt <John...@brunel.ac.uk> wrote in article
<5urcdv$e...@molnir.brunel.ac.uk>...
> Maybe you've been luckier in the users you've worked for than I have,
> but in my experience this leads to hand-waving dream-sheeting very
> quickly. I have heard users request tasks that would not be finished
> until the sun goes cold; I have been told that my application must
> take no time to run, consume no disk space, and need no training
> time to understand. Users usually have a very poor idea of what's
> possible, what's easy, and what can never be done. I would also
> argue that they often don't even know what they want until they see
> it; there are what marketing men call "unarticulated needs".
>
> Out of politeness, you may well start by asking what the user wants
> to accomplish; but I think you'd be very lucky indeed if the answer
> helped you capture requirements.
The requirements gatherer has to take an active part in the requirements
process. They are there to help guide the user, not just to write down what
the user asks for verbatim. There is little point coming up with a set of
requirements that cannot be implemented.
It is a good idea to distinguish between different levels of importance for
requirements (e.g. categorise into 'essential' and 'desirable'). Then,
during analysis, you can decide to ignore requirements with an unfavourable
ratio of cost to implement against importance.
That said, bad customers (users) make for bad projects. Unfortunately, not
many of us have the luxury of choosing our customers!
>
> A pal of mine once expressed the advantages of evolutionary
> development as follows:
>
> "Since we moved to evolutionary development, we give the users
> what they want, instead of what they asked for."
>
Distinguishing between wants and needs should be an important part of
requirements and analysis.
regards
Andy Brice
Jon Jacky
In article <5urcdv$e...@molnir.brunel.ac.uk> John...@brunel.ac.uk (John D Salt) writes:
Users usually have a very poor idea of what's
possible, what's easy, and what can never be done. I would also
argue that they often don't even know what they want until they see
it; there are what marketing men call "unarticulated needs".
The users' role isn't to design the solution, that's your job. Get
them to describe the problem, or better yet, show you. That's where
they know more than you do.
haim_...@ml.com
In article <JON.97Se...@bilbo.radonc.washington.edu>,
j...@bilbo.radonc.washington.edu (Jon Jacky) wrote:
...
> The users' role isn't to design the solution, that's your job. Get
> them to describe the problem, or better yet, show you. That's where
> they know more than you do.
>
Yes. Also, get the users to explain you the business domain: you have to
understand and precisely specify the relevant fragments of it in order to
deal with the problem. In this activity, you will ask a lot of
questions... and the users perhaps will not be able to immediately answer
some of them.
After the business domain and business problem have been specified (in a
business specification), a possible solution can be specified in business
design (where you will, in particular, have to distinguish solutions
realized by a human from solutions realized by a computer system), and in
a system specification.
-Haim Kilov
haim_...@ml.com
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Markus Beckmann
Andy Brice wrote:
> ...
> The requirements gatherer has to take an active part in the requirements
> process. They are there to help guide the user, not just to write down what
> the user asks for verbatim. There is little point coming up with a set of
> requirements that cannot be implemented.
>
> It is a good idea to distinguish between different levels of importance for
> requirements (e.g. categorise into 'essential' and 'desirable'). Then,
> during analysis, you can decide to ignore requirements with an unfavourable
> ratio of cost to implement against importance.
Who do you think should decide which requirement is 'essential'
or 'desirable' - users, (customer) managers, requirement-gatherers?
> That said, bad customers (users) make for bad projects. Unfortunately, not
> many of us have the luxury of choosing our customers!
>
> >
> > A pal of mine once expressed the advantages of evolutionary
> > development as follows:
> >
> > "Since we moved to evolutionary development, we give the users
> > what they want, instead of what they asked for."
Like said in the first paragraph: Requirements engineers should
help users to 'ask for' 'what they want'...
> Distinguishing between wants and needs should be an important part of
> requirements and analysis.
> ...
M. Beckmann
Markus Beckmann
Jon Jacky wrote:
> In article <5urcdv$e...@molnir.brunel.ac.uk> John...@brunel.ac.uk (John D Salt) writes:
>
> Users usually have a very poor idea of what's
> possible, what's easy, and what can never be done. I would also
> argue that they often don't even know what they want until they see
> it; there are what marketing men call "unarticulated needs".
>
> The users' role isn't to design the solution, that's your job. Get
> them to describe the problem, or better yet, show you. That's where
> they know more than you do.
> ...
But - if it's not the users job to _design_ the look and
feel of an application - users should at least be involved
in gathering requirements and layout for the (G)UI so that
they can see what they will get early.
It's not only the problem domain where they know more than
the developer. They also know what they want and what they
don't want better than the developer - even if they are not
able to tell. So you have to show them what they might expect.
If the (end) users - not the managers - don't want it you
will have problems to pass acceptance tests.
M. Beckmann
Andy Brice
Markus Beckmann <beck...@informatik.uni-mainz.de> wrote in article
<34165A...@informatik.uni-mainz.de>...
...
>
> Who do you think should decide which requirement is 'essential'
> or 'desirable' - users, (customer) managers, requirement-gatherers?
In an ideal world everyone should agree. In the real world probably it is
whoever signs the cheque!
Requirements gathering is definitely a 'soft' problem.
regards
Andy Brice
Todd
Who decides system requirements is a fun, yet dangerous problem.
IMHO, The key to managing project scope is the consensus on priority of
functionality. When possible, it should be done as an interactive group
excercise instead of a 'take home' assignment. These are not fun to
facilitate with clients, since dissagreements will occur. Much of this
can be handled by setting proper expectations for the session and
defining the different priority levels. For example
Must have or system is not useable
Should have for speed ease of use
Would like to have for convenience
Not necessary but its really cool
Totally ridiculous or impossible to implement
I find that the check writer is often surprised by what the users deem
as 'must have', and it is much easier on the developer if they can
remove themselves from the decision by letting the check writer work it
out with the users.
I've done a quite a few of these priority sessions, and it usally takes
two. The first one allows initial pricing, and the second one is for
'horse trading' to get the price down. If your costing method is good,
you can assign a price (person weeks works well) to the different
functionality. In the end you're hopefully closer to a system that both
sides will like, or at least understand how/why the final functionality
was chosen.
Any other methods out there?
Todd.
--
+-------------------------------------------------------------------+
| Todd A. Loomis, Manager SW R&D tlo...@ctron.com
| Cabletron Systems, Nashua NH voice: 603-337-5566
| "I need Relational DB, C++, Java, Corba, Web developers & leads"
| "Cool projects, Casual environment, Will pay for move, Call me"
Andrew Gabb
Robert Munck wrote:
>
> On Fri, 05 Sep 1997 18:16:52 +0930, Andrew Gabb <ag...@tpgi.com.au>
> wrote:
>
> >.... ISO 12207, which sets the framework for software
> >engineering life-cycle issues, defines and uses the words operator/user,
> >acquirer, supplier, developer, maintainer. ...
>
> Much too simplistic. For instance, the acquirer must be
> divided at least into the person (or group) that deals with
> the supplier, the person who needs the new system, the person
> who pays for it, and the person who will certify completion.
> These people are generally at different levels of authority,
> in different parts of the acquirer organization, and have
> different views of the user needs.
Agreed, and you can probably find another 10 in some projects, like the
group that has to pay for the training, the watchdogs on the project and
so on. However, like many models it is useful - like all it is
imperfect.
> >Note that only the Users can know what they want - they are the owners
> >of the requirement.
>
> This isn't true when the users are being given new functions
> to perform with the help of the new system. In that case, some
> higher authority is specifying what the new system will do, but
> may have an unclear or incorrect idea of what the users do now
> and what they're capable of doing.
>
> We worked all of this out in much greater detail in the SADT
> requirements analysis methodology.
Our mileages obviously vary. Discounting the value of user
participation when designing new systems is not wise in my experience.
Neither is blindly following their lead (or wishlist), of course.
So I suggest again that the users are the owners of the requirement -
the keepers of the flame - regardless of which beancounters or acquirer
engineers hold the mortgage. The supplier must satisfy both groups, and
a few others as noted above. Who said it was easy?
Andrew
--
Andrew Gabb
email: ag...@tpgi.com.au
phone1: +61 8 8342-1021
phone2: +61 8 8269-1635
.
-----
P Young
In article <34165B...@informatik.uni-mainz.de>,
beck...@informatik.uni-mainz.de says...
course on Mastering the Requirements Process that deals with just these
issues and focuses on how to build the system your user wants and will
use. Response to this course has been very positive. If your interested,
you can check out a description at http://www.sqe.com (click on the
"development seminars" button).
Markus Beckmann
Andy Brice wrote:
>
> Markus Beckmann <beck...@informatik.uni-mainz.de> wrote in article
> <34165A...@informatik.uni-mainz.de>...
> ...
> >
> > Who do you think should decide which requirement is 'essential'
> > or 'desirable' - users, (customer) managers, requirement-gatherers?
>
> In an ideal world everyone should agree. In the real world probably it is
> whoever signs the cheque!
>
> Requirements gathering is definitely a 'soft' problem.
>
> regards
>
> Andy Brice
What do you mean by 'soft'?
Markus Beckmann
Harald M. Mueller
Markus Beckmann wrote:
[..]
> > Requirements gathering is definitely a 'soft' problem.
> >
> > regards
> >
> > Andy Brice
>
> What do you mean by 'soft'?
>
> Markus Beckmann
"Soft issues" are the human/society/psychology-related issues in softwar
engineering. The computer science people, even in the SWE field, have
long ignored this issues and favored the "hard", i.e. technical aspects
of building software. However, the history of successful and failed
projects shows that the major factors influencing the outcome of a
project are the "soft" ones.
For further information read e.g.
Gerald Weinberg: The psychology of computer programming (AFAIK the 1st
comprehensive book on soft issues; written in 1971)
Lister & De Marco: Peopleware
Harald Mueller
------------------------------------------------------------------------
Dr. Harald M. Mueller
Siemens PSE Information Technology Office tel +1-408-764-9242
4900 Old Ironsides Drive, Building 6, Mailstop 600 fax +1-408-764-9217
Santa Clara, CA 95052 email: harald....@siemenscom.com
------------------------------------------------------------------------
Martin ELLISON
John D Salt wrote:
>
> In article <dorfmanE...@netcom.com>,
> Merlin Dorfman <dor...@netcom.com> wrote:
> >John D Salt (John...@brunel.ac.uk) wrote:
> >
> >: Something of an aside here, but I just can't bring myself to see design
> >: and budgeting as the same thing at all.
> >
> > They are not the same thing...but good requirements are needed
> >before either is started!
>
> Okay... now where do I get my budget for the requirements phase, please?
??? From the same place that you get the budget for the rest of the
project, presumably.
--
Martin Ellison
mail to: m.ellison(at)computer.org
http://www.jrcase.mq.edu.au/~martin/
Markus Beckmann
Harald M. Mueller wrote:
> Markus Beckmann wrote:
> [..]
> > > Requirements gathering is definitely a 'soft' problem.
>
> > What do you mean by 'soft'?
>
> engineering. The computer science people, even in the SWE field, have
> long ignored this issues and favored the "hard", i.e. technical aspects
> of building software. However, the history of successful and failed
> projects shows that the major factors influencing the outcome of a
> project are the "soft" ones.
Ok, then I got it right: The "soft issues" are related with
the "hard problems", because all technical solutions won't
help if the "soft issues" are not treated carefully. In the
following scenario the requirements engineer is the one who
has to map the customers needs to the developer's abilities.
And often there is nothing that can be seen as the counter-
part for the soft issues.
Soft issues Technical aspects Cusomer needs
| |
| |
+-----------+------------+
|
|
Requirements
Engineer
|
|
+-----------+------------+
| |
| |
????? Technical skills Developer abilities
So the technical skills of the developer are used to deal with
hard and soft issues - which is not the solution to problems
with soft issues. I think this is where management comes in...
Markus Beckmann
Francis J. Webb
>
>"Soft issues" are the human/society/psychology-related issues in softwar
>engineering. The computer science people, even in the SWE field, have
>long ignored this issues and favored the "hard", i.e. technical aspects
>of building software. However, the history of successful and failed
>projects shows that the major factors influencing the outcome of a
>project are the "soft" ones.
I disagree that requirements are "soft" issues, even with this definition.
When the system
is in System Test, or User Acceptance Testing, or even in service, every
"soft" issue which was
short-changed during requirements has become a "hard" Deficiency report.
The goal of a software system design is to meet some need of the end "user".
If the requirements
have been shortchanged, then come delivery, there will be finger-pointing,
cries of "foul!", etc.
this is particulary true in areas outside of the more traditional
"functional requirements". In reviewing hundreds of
large projects over the past ten years, we have found consistent failures in
three areas - Performance, Error Handling,
and Operations, Administration and Maintenance (OA&M). In almost all cases,
these can be traced back
to inadequate requirements (or specifications). One of the primary job of
the System Architect is to uncover
the areas where the requirements are inadequate, and either get
clarification, or to drive a stake into the
ground, and identify what will really be designed. Consider that one of the
most important things
which we get from good requirements is a clear definition of what we will
NOT be doing. If we wait until
the customer is trying the software, the demand will be that the system
should have done everything.
George X. Kambic
Jon Jacky wrote:
>
> In article <5urcdv$e...@molnir.brunel.ac.uk> John...@brunel.ac.uk (John D Salt) writes:
>
> Users usually have a very poor idea of what's
> possible, what's easy, and what can never be done. I would also
> argue that they often don't even know what they want until they see
> it; there are what marketing men call "unarticulated needs".
>
> The users' role isn't to design the solution, that's your job. Get
> them to describe the problem, or better yet, show you. That's where
> they know more than you do.
Two useful items;
Exploring Requirements: Quality before Design by Gause and Weinberg is
one
of the best requirements books that you can read and use. See also Alan
Davis' books on requirements. I lost his web site.
The IEEE has a standard coming out called Concept of Operations.
Without
going into a lot of stuff, it deals with the softer side of
requirements.
It is a place for stuff like: "It oughta work like this, etc."
I like the concept of concept of operations. I thought it would be
better placed as part of another standard but that's life. It is
supposed to be IEEE 1362-1996, Guide for Concept of Operations.
Merlin Dorfman
Martin ELLISON (mar...@mpce.mq.edu.au) wrote:
: John D Salt wrote:
: >
: > In article <dorfmanE...@netcom.com>,
: > Merlin Dorfman <dor...@netcom.com> wrote:
: > >John D Salt (John...@brunel.ac.uk) wrote:
: > >
: > >: Something of an aside here, but I just can't bring myself to see design
: > >: and budgeting as the same thing at all.
: > >
: > > They are not the same thing...but good requirements are needed
: > >before either is started!
: >
: > Okay... now where do I get my budget for the requirements phase, please?
: ??? From the same place that you get the budget for the rest of the
: project, presumably.
The question--a valid one--is how do I know what to budget for the
requirements phase if I can't determine the budget until I have written
the requirements?
There are several answers, none of them overwhelmingly good:
- If somebody is paying you to write the requirements, make your best
estimate based on previous experience, but don't sign a contract to
develop the system until after the requirements are completed and
factored into the development estimates. You may lose some money if
you have underestimated the requirements phase, but you may go
bankrupt if you underestimated the entire development.
- If you are deciding whether or not to build the system, allocate a
LOT of money to do the requirements right, then do your development
budget and schedule, and then decide whether or not to go ahead and
build the system.
- If you are doing an incremental or evolutionary development,
include some budget for further requirements development in the
budget for each increment. How much? Take your best shot--and
when that money is gone, the requirements part of that increment is
done :-)
Merlin Dorfman
DOR...@COMPUTER.ORG
m0nik3r
All these people wrote:
>>>>>
Merlin Dorfman wrote:
>
> Martin ELLISON (mar...@mpce.mq.edu.au) wrote:
> : John D Salt wrote:
> : >
> : > In article <dorfmanE...@netcom.com>,
> : > Merlin Dorfman <dor...@netcom.com> wrote:
> : > >John D Salt (John...@brunel.ac.uk) wrote:
> : > >
> : > >: Something of an aside here, but I just can't bring myself to see design
> : > >: and budgeting as the same thing at all.
> : > >
sanityCheck() == TRUE; // Expression has no effect
> : > > They are not the same thing...but good requirements are needed
> : > >before either is started!
function missing prototype!
> : > Okay... now where do I get my budget for the requirements phase, please?
>
> : ??? From the same place that you get the budget for the rest of the
> : project, presumably.
>
budgetTotal = (float)thinAir;
> The question--a valid one--is how do I know what to budget for the
> requirements phase if I can't determine the budget until I have written
> the requirements?
fPrintfThis(void * this, otherArgs)
{
> There are several answers, none of them overwhelmingly good:
}
> - If somebody is paying you to write the requirements, make your best
> estimate based on previous experience, but don't sign a contract to
> develop the system until after the requirements are completed and
> factored into the development estimates. You may lose some money if
> you have underestimated the requirements phase, but you may go
> bankrupt if you underestimated the entire development.
(money == success);
> - If you are deciding whether or not to build the system, allocate a
> LOT of money to do the requirements right, then do your development
> budget and schedule, and then decide whether or not to go ahead and
> build the system.
if (aLotof(money) == more(success)); // Comparision is meaningless
> - If you are doing an incremental or evolutionary development,
> include some budget for further requirements development in the
> budget for each increment. How much? Take your best shot--and
> when that money is gone, the requirements part of that increment is
> done :-)
success == (money - (squandering * stupidity) - lack_of_Planning); //
Formula too complex
attempt = (success | aLotof(money)()); // Bit-wise is word foolish
if (attempt = success)
aLotof(money) == success; // Expression has no meaning
return 0;
if (success == TRUE) // Code is unreachable
miracle = YES;
else typical();
> Merlin Dorfman
> DOR...@COMPUTER.ORG