From: Andrew Gabb (agabb@tpgi.com.au)
Date: Wed Oct 08 2003 - 22:13:04 EST
Your question is difficult to answer, Daniel, mainly because there
really is no criteria for measuring 'hard' (ie perfectly clear,
verifiable, etc.), ie it is not a single goal which we can aim for,
then meet.
Instead, we trade off time and effort to reach a level of 'hardness' which is appropriate to the risk (and budget, and schedule).
So, for example, safety critical systems may need harder requirements. Extreme Programming, which tends to be used on apps needed in 'internet time' (and to some extent 'internet quality'), tends to use softer requirements. The fact that the customer is (should be) closely involved in XP, and the apps are usually relatively small, also means that softer requirements may be acceptable.
How expensive is it harden requirements? It can be very, very expensive depending on how far you want to go. For example, formal methods may increase the development cost by 5-10 times (I read somewhere).
OTOH, many projects would have benefited by an extra few percent of effort at the requirements stage. Determining how far to go (how hard) and when to start the next stage is not at all easy. Remember that the additional effort usually costs in both schedule time and money.
Andrew
Daniel Gross wrote:
> Perhaps I can ask a question to the practitioners on the list:
>
> Based on your experience, how expensive (both in cost/time/risk) is it to
> formulate hard requirements for a software system, and how often does it
> occur that it's too expensive (and to risky) to do so? Also, I am also
> wondering, how much do uncertainties of the market place play a role in
> making it costly/risky to develop hard requirements, due to the need to drop
> them when the need arises to adopt alternative business strategies, which in
> turn lead to alternative system requirements.
>
> I am also wondering whether there exist types (or kinds) of systems for
> which dealing with soft requirements and the decision to not develop too
> many hard requirements is of advantage.
>
> In general, it seems to me that a balance needs to be found between telling
> designers exactly what the requirements are, and the cost/risk/time factor
> of developing such requirements. From another point of view a balance need
> to be found to ensure that designers create the right system vs. the
> cost/risk/time it takes to describe to a designer the "right" system by
> developing hard requirements.
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Wed Oct 15 2003 - 14:23:04 EST