Re: [re-online] Bottom-up RE methods

From: Andrew Gabb (agabb@tpgi.com.au)
Date: Tue Apr 27 2004 - 12:38:26 EST


Good stuff, Ian.

There are at least two very good reasons why some form of top-down approach is normally seen in successful projects, regardless of how the actual process happened in practice. What I was suggesting tends to be something like: working upwards from middle/bottom fragments (including scenarios), then working top-down, then validating (partial) against the fragments.

The two reasons are closely related although they seem quite different.

  1. Requirements are best assimilated if presented in some form of logical structure. This tends to result in requirements being presented, documented, etc. in a top-down fashion. It aids in understanding and maintenance, not to mention use by the designers.
  2. As I previously indicated, it's very difficult to find omissions and errors unless you have a structured model for the requirements (in any form - a good statement of requirements is normally a well-structured model). One reason for this is that missing *branches* are easier to detect. Another is that it assists in determining the boundaries and scope of your system, and scope errors tend to be very expensive.

Andrew

Ian F Alexander wrote:
> I have a feeling that any approach that gathers stakeholder
> goals, viewpoints and stories in a people-centred way is going to
> be mixed: perhaps only purely analyst-devised (and hence, not
> surprisingly, analytic) methods will ever be top-down.
>
> Actual meetings with stakeholders tend to be chaotic from the
> point of view of neat and tidy top-down analysis! --- but quite
> orderly and logical from the point of view of people who are
> experiencing the pain of a problematic work process.
>
> Stories/scenarios/use cases may seem to offer a top-down
> approach, but people can offer stories at any level. I suggest
> that, rather as mathematicians do with published proofs,
> engineers tend to try to impose top-down order on sets of
> stories, but this is post-hoc explanation rather than a method of
> gathering. There is a natural small-scale way in which use case
> work is top down: from any story, you ask what can go wrong and
> elicit exception sub-stories from that. But these mini-trees have
> to be assembled into a model bit by bit. So I see stories as
> end-to-end interaction sequences; you work both up and down from
> them.
>
> I note that I and the other people who've replied to your
> question have written mostly about "user requirements".
> Specifications are more likely to work in a relatively top-down
> way simply because it's safer to do so once the user reqts are
> reasonably well-known. However I concur with Suzanne Robertson's
> view that you have to work "top-down, bottom-up, and
> middle-every-which-way".

-- 
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 : Mon May 03 2004 - 09:00:18 EST