Hello,

Here some starting points on requirements and benchmarks / measurement
to get started. All include rich scientific literature.

Business impact of requirements engineering in industry. Results of this
longitudinal study are summarized in: Understanding the Product Life
Cycle: Four Key Requirements Engineering Techniques. IEEE Software,
ISSN: 07407459, Vol. 23, No. 3, pp. 19-25, May 2006.
http://doi.ieeecomputersociety.org/10.1109/MS.2006.88
http://www.computer.org/portal/cms_docs_software/software/homepage/2006/
019-025.pdf

Our book Software Measurement (Springer, ISBN 9783540716488, Heidelberg,
New York, 2007.
http://www.amazon.com/gp/product/3540716483)
is a good starting point with necessary measurement foundations, best
practices, many industry case studies, hands-on measurement examples,
and benchmarks both for IT and engineering organizations. It has an
explicit chapter on requirements.

A few hints:

1) Only half of all requirements that are agreed upon before project
start are finally delivered to the client.

2) Half of all functionality in a software system is never or very
rarely used in prac-tice. This means that the list of value-add
functionality which can be effectively sold is smaller than the list of
requirements. Knowing this factor and eliminating unnecessary
requirements allows to save effort and shorten cycle time.

3) 80% of all defects found during test result from missing (30%) or
wrong (50%) requirements.

4) 40% of all software defects in embedded systems result from
insufficient require-ments and analysis activities.

5) The typical effort allocated to requirements engineering is 3-7% of
total project cost. It is 5-10% for all requirements management related
activities during the life-cycle which includes for instance change
management during the project. Doubling this effort has the potential to
reduce life-cycle cost by 20%, thus yielding an immediate ROI of 4. The
cost reduction mostly stems from reduced error rate during elicitation
and analysis, earlier defect removal during specification and
requirements verification, and improved consistency across work
products.

6) Requirements change at 1-3% per month normalized to the effort
originally estimated. For instance if the requirements are estimated
with 1 person year, you would expect an additional effort or change
impact of 1-2 person weeks per month. This is not peanuts and needs to
be considered in building change review boards and clear rules for
change management. Target a freeze point of your requirements in due
time by backward planning from project (or task) end.

7) Requirements changes beyond 20% (normalized to project effort) after
the start of the project typically impact productivity (and other
project parameters) dramatically. Up to 20% change rate which translates
into 3% per month in a six month project, can be digested without
negative impacts.


best regards
-Christof Ebert
Vector Consulting Services
http://www.vector-consulting-services.com


________________________________

From: Requirements-Engineering@yahoogroups.com
[mailto:Requirements-Engineering@yahoogroups.com] On Behalf Of Florencio
Garay
Sent: Wednesday, July 01, 2009 8:36 PM
To: Requirements-Engineering@yahoogroups.com; Donald Firesmith
Subject: {Requirements-Engineering} Urgent - Academic papers -
Requirements





Dear : colleages

I am doing my dissertation about Importance of Systems/Software
requirements ( Requirement Engineering) to delivery quality products .

Do you know where can I found academic papers related to Requirement
Engineering ?

I will appreciate your support

Florencio Garay