Xref: utzoo comp.edu:2674 comp.software-eng:2430
Path: utzoo!attcan!uunet!samsung!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd
From: rsd@sei.cmu.edu (Richard S D'Ippolito)
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <4992@ae.sei.cmu.edu>
Date: 17 Nov 89 14:10:35 GMT
References: <7036@hubcap.clemson.edu> <7046@hubcap.clemson.edu> <1054@scotty.Atlanta.NCR.COM>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 32

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.

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'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?


Rich
-- 
When you can measure what you are speaking about, and express it in numbers,
you know something about it.
Lord Kelvin						      rsd@sei.cmu.edu
-----------------------------------------------------------------------------