From: Andrew Gabb (agabb@tpgi.com.au)
Date: Tue Apr 27 2004 - 12:43:20 EST
Er ... where's the System domain, Jim?
IMNSHO, considering the software to *be* the system is a common and serious failing - it means that system issues must be mixed in with the software issues (or the business issues). More often they're overlooked until they jump out and bite you.
Andrew
Jim_Archer@or.blm.gov wrote:
> I find the following scheme useful. Requirements are divided into two
> domains (Business and Software), four hierarchies, and three types
> (Concrete, Abstract, and Typed):
>
>
> I. Business domain
> A. Business Function hierarchy
> 1. Concrete Business Requirements
> 2. Abstract Business Requirements
> B. Typed Business hierarchy
> 1. Typed Business Requirements
> II. Software domain
> A. Software Function hierarchy
> 1. Concrete Software Requirements
> 2. Abstract Software Requirements
> B. Typed Software hierarchy
> 1. Typed Software Requirements
>
> Very briefly, Concrete Software Requirements are attached to deliverables
> and have clear completion criteria; they are mapped to scheduled tasks.
> Abstract Software Requirements apply to multiple deliverables all of which
> inherit the requirement. Similar comments apply to Business Requirements.
> All Concrete Software Requirements must have a link to a Concrete
> Business requirement that justifies its inclusion. Finally, requirements
> that are neither Concrete nor Abstract are assigned a Type as required.
>
> Concrete Software Requirement: The Payroll Summary Report will have a
> grand total of payroll costs for the last pay period.
>
> Abstract Software Requirement: All Payroll reports will show dates in
> dd-mmm-yyyy format.
>
> Typed Software Requirement: Type = Availability, Requirement = the Payroll
> system will be available for use in all district offices.
>
>
>
>
>
> Debbie Lawther <dlrl@onetel.com>
> Sent by: owner-re-online@it.uts.edu.au
> 04/18/2004 02:21 AM
> Please respond to re-online
>
> To: re-online@it.uts.edu.au
> cc:
> Subject: [re-online] Requirements taxonomy; Soft Systems
> Methodology
>
>
> Hello -
>
> I'm in the middle of a diploma project, and have a couple of
> questions: Has anyone developed a taxonomy of 'requirement' as the
> notion is used in IT? And, what use have people made of Soft Systems
> Methodology to identify and/or work with requirements?
>
> The 'taxonomy' question comes from trying to find different words for
> 'requirements' at the level of business need, as opposed to those
> related to developing a specific system. The difference would be, say,
> 'PC users want to be able to send emails and do calculations and store
> pictures', vs. 'a calculator implemented on a PC needs to take input
> from both numeric keys and the key-pad'. Another dimension might be
> requirement states at different points in the development life-cycle.
>
> Soft Systems Methodology, developed by Peter Checkland at Lancaster
> Business School, seems to be a set of ideas that various people stumble
> onto, as I have, and use formally for a while until it becomes
> integrated into their work and they drop the label. It's applicable in
> a huge range of ways. Is there work with it directly as a requirements
> tool?
>
>
> Debbie Lawther
> -------------------------------------------------------------------------------
> 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.
>
>
-- 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