From: Andrew Gabb (agabb@tpgi.com.au)
Date: Sun May 30 2004 - 17:35:53 EST
Hi Uday
I suggest you look at a paper I wrote some time ago called "Denying
Requirements--Twelve Excuses", at
http://systems-engineering.larc.nasa.gov/incose/insight/vol-2-issue-4a.pdf
(or an earlier paper called "Requirements Denial - Examining the
Excuses" - the later paper is an extension of this - at
http://www1.tpgi.com.au/users/agabb/)
which answers some of your questions.
May I also suggest some issues that will (should) affect your work:
# Often the participants in the project will not really know why the project failed, or will not be honest in their assessment (consciously or unconsciously). For example, according to their owners, how many small businesses fail due to their own incompetence?
# Some factors are often seen as subsets of others. For example, poor RE means that the wrong people were involved, or were not given the right tasks, or were not permitted sufficient time. This can also be viewed as a management failure.
# I postulate that for a complex system, you can never be sure that the requirements you have are correct and complete (part of my Impurity Principle). The skill is in knowing when they are *sufficiently* correct and complete, and this is more of a value judgment, based on experience.
Andrew
Uday.B.Goud wrote:
> Hi Friends,
>
>
>
> I am an International Masters Student from Blekinge Institute of
> Technology in Sweden. Having completed my courses I am interested
> in taking up a Masters Thesis. The area of Requirements
> engineering interest me the most, hence have decided to take up a
> topic in this area.
>
> In this regard, I would like to share a thought of mine which I
> would like to consider for my Masters Thesis. I am struck with
> this aspect of RE since the very beginning.
>
>
>
> Most of the text books, articles, conference presentations which
> I have read so far during my course and for the assignments state
> one thing in common
>
>
>
> Conveying :
>
>
>
> "Most of the software product failures are attributed to
> unsatisfactory requirements engineering process". This is has
> been mentioned in most of the literature published in this
> decade. (at least to the best of my knowledge)
>
>
>
> I have also come across a document by the Standish group (which I
> feel has some good worth)
>
> http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf
>
>
> Who have conducted a survey, which shows that projects are
> impaired and ultimately cancelled ranked incomplete requirements
> and lack of user involvement in the top of the list.
>
>
>
> If so:
>
>
>
> 1.. Having known this fact since a considerable amount of
> research time, why is that the software engineers not able to
> come over this issue? 2.. Aren't the Software professionals
> (specifically people involved in Requirements elicitation phase),
> sufficiently educated / aware of the fact? Assuming that they
> must have gone through the phase of learning/training in
> Requirements Engineering practices. I think that most of the
> contemporary Software Engineers are well qualified. 3.. I somehow
> feel that this talk about "unsatisfactory requirements
> engineering process" will for sure continue even in the forth
> coming literature. Are all the Software Engineering Students
> bound to read "this fact", in the forthcoming years also? Will
> this be a potential area to investigate constantly? 4.. Actually
> how practical is it to say "yes! we have perfect requirements to
> go ahead" ." Can the requirements RE process" come to a stage
> where one can say " Now we have the Stakeholders Requirements ,
> perfect" 5.. For the moment I am of the impression that the
> theories behind the RE process makes more sense to the Academic
> community rather than the industry. 6.. Finally , what could be
> the possible bottom line for "Good requirements elicitation"
>
>
> I want to address this issue in my Masters Thesis.
>
>
>
> How I propose to do it :
>
>
>
> 1) Find out what the literature has to say about the
> question "A", and come out with a conclusion.
>
> 2) Conduct a survey in the industry to find out.
>
> a. Who are the people involved in RE, and how are they
> different from the rest of the employees in the organization.
>
> b. Are they aware of the theories behind RE process?
>
> c. What are the most obvious problems they find in
> requirements elicitation from the stake-holders?
>
> d. What do they have to say about "Why do the projects fail
> "
>
> ( We should probably able to answer question B)
>
> 3) Based on literature Survey and the outcome of the
> industry survey, we should probably be able to answer question C.
>
>
> 4) Map 2(d) with the literature (may be we can contribute in
> answering A).
>
> 5) Discuss the issue in "E", based on conclusions we draw.
>
> 6) Question "D" is the Main Goal of the Thesis.
>
>
>
>
>
> Hence , I would like to request your opinion and suggestion(more
> aspects that I could consider) , so that I can improve on the
> existing idea , and carve a Thesis proposal which holds good
> academic value.
>
>
>
> I shall look forward to hear from you.
>
>
>
> Thank you.
>
>
>
> Kind regards
>
> Uday
>
>
>
>
>
>
>
>
>
-- 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 Jun 07 2004 - 09:00:19 EST