Xref: utzoo comp.edu:2681 comp.software-eng:2439
Path: utzoo!attcan!uunet!samsung!usc!apple!netcom!stratus!cloud9!banyan!gordon
From: gordon@banyan.UUCP (Gordon Lee@Eng@Banyan)
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <603@banyan.UUCP>
Date: 19 Nov 89 23:49:41 GMT
References: <7036@hubcap.clemson.edu> <7046@hubcap.clemson.edu> <1054@scotty.Atlanta.NCR.COM> <4992@ae.sei.cmu.edu>
Reply-To: gordon@banyan.com (Gordon Lee@Eng@Banyan)
Organization: Banyan Systems, Inc.
Lines: 128

First off, I'd like to apologize for the goof up on my last posting, 
I was having a problem with the posting software and didn't realize 
that every failed attempt to send was reappending the article to
dead.article.  I was trying to resend dead.article you see, but anyway...

In article <4992@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>In article <1054@scotty.Atlanta.NCR.COM> K. C. Yakemovic writes:
>
>>It is my opinion that one of the greatest weaknesses we have in industry is
>>in the *requirements analysis* [RA] area. ...
>>I was going to say that with the limited amount of time available, perhaps
>>the more difficult subject of requirements analysis should be taught in a
>>separate course.  
>
>There is still no real consensus in the industry for what requirements
>are and what requirements analysis is.  There are IEEE definitions, but they
>are as poor as most of the rest of the definitions of software terms.  They
>make very little distinction between requirements and specifications.
>

Given the absence of an industry consensus on the definition 
of Req Analysis, is there a well-known list
of proposed definitions that have been set forward as likely candidates ?

In article <4992@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>What do you mean by requirements, and what are examples of those things that
>you would like taught?  Is RA part of the design process?  Who does it?

I'm relatively new to the debate, but here's my 2 cent definition...

For me, Req Analysis is the process of defining the problem.  There are
two entities, be they two distinct people, two distinct groups of people, 
or maybe both entities are one person.  One entity has (or thinks he has)
a problem to be solved, call him the "user".  The other entity is 
called on or acts to solve the problem through some computational model,
call him the "engineer".  Req Analysis is the process that these two
entities go through to identify the domain of the problem, 
research the domain, define the bounds of the problem, and then finally
produce some form of document which itemizes knowledge collected, and 
presents some model of the problem.  It would also contain
references to supporting documents which were used during the research 
phase.

The reason I would guess that even IEEE has trouble seperating this 
process from the process of developing specifications is that in actual
practice most engineers do both at the same time.  That is they tend 
to model the problem in terms of a potential solution.  So what they 
end up with is not what anyone would call a model of the problem, 
but a specification of the solution.

I think it is instinctual to approach problem solving by:
  1. rapidly trying a variety of solutions "in one's head"
  2. choosing the one that is perceived to be the closest
  3. refining this solution to make it fit

So for most people, Req Analysis is reduced to a simple exercise 
in comparative judgement.  How many have been frustrated by 
or perhaps taken advantage of the fact that a bad Human Resource
Department will tend to match Job Req's and resumes by keying
off buzzwords.

But most people would agree that this is a very limited 
way of thinking.  It is limited by the thinker's knowledge of 
potential solutions and by how much of the problem domain's complexity
the thinker can "see" let alone comprehend.

Remember an earlier article:

In article <4969@ae.sei.cmu.edu> Richard S D'Ippolito writes:
>This is right on the mark!  From Tomas Maldonado, "The Aspen Papers":
>
>    "Therefore we must say that for the moment the most distinctive
>    characteristic of man is not his capactiy to solve problems but
>    more his capacity to set them."

That's a great quote.  I take "problem-solving" in Tomas' observation to
mean the exercise in comparative judgement I described above.  

I see one's capacity to "set the problem" as defined by:
  - one's ability to recognize the limits of one's knowledge 
     of the bounds of the problem domain and the range of potential solutions.
  - one's ability (and motivation) to expand one's knowledge 
     in those two areas.

In article <4992@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>In article <1054@scotty.Atlanta.NCR.COM> K. C. Yakemovic writes:
>>I'll agree you can teach most of the
>>other software engineering processes with "uncomplicated" domains.  But it
>>seems to me that learning to do requirements analysis requires a reasonably
>>complicated domain.
>
>What are all of the "software engineering processes", and what do you mean
>by a complicated domain?

In light of what I have said above, I'd like to suggest 
that "complicated domain" is a relative term.
I think all domains are complicated, the existing body of AI research
is a testimony to the complexity of even the most mundane of domains.

Instead of measuring the complexity of the domain, we should measure
an individual's knowledge of the domain and past experience with solutions
to problems presented by the domain.

Richard, you presented a couple of interesting quotes in an earlier article,
D. Schoen, "The Reflective Practicioner"
Tomas Maldonado, "The Aspen Papers"

I only first heard about the Software Engineering Institute last week
when I started reading a friend's back issues of CACM.  I was wondering
if you or the SEI as a whole have a recommended reading list of some form 
that you could share.  I'd like to do some reading on issues concerning
the state of SE as a discipline, starting with a general background on
who's who, what ideas are current, what ideas have fallen out of practice,
etc, etc...  If you could mail to me or perhaps post to the net, 
as you see fit.

For that matter, if anyone has any reading list recommendations they 
would like to suggest, I would be interested in hearing of them.
I am looking first for general background info, and then also
anything considered seminal, the "must-reads" which get the most attention.

thanks

-- 
=============================================================================
Gordon Lee                 gordon@banyan.com    or    gordon@bu-it.bu.edu
Banyan Systems, Inc.
Westboro, MA            "Pay no attention to that man behind the keyboard..."