Page 43 - Software and Systems Requirements Engineering in Practice

16 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

Function Point Metrics as Leading Indicators
A function point is used to estimate the complexity and effort
necessary to build a software product. Capers Jones has published
extensively on this topic [Jones 2007, 2008]. Function point metrics
are an excellent way of identifying potential problems with
requirements prior to the implementation of a project. Furthermore,
there is a clear correlation between function points and requirements;
that is, function points can be used as an indicator of requirements
creep and quality. Furthermore, it has been shown that function point
analysis (FPA) can be effective in determining requirements
completeness [Dekkers et al. 2001].

1.10 How to Read This Book
We suggest that you start by reading Chapters 1 and 2 before looking
at any of the other chapters. They lay the groundwork for the
remaining chapters by defining basic terminology that is used
throughout the book.
Chapters 3 and 5 describe techniques for eliciting requirements. If
you are interested in gathering requirements for software platforms
or middleware, we also suggest that you read Chapter 6.
Chapter 4 describes modeling techniques that can be used for
business or use case analysis. One specific method that has been used
successfully at Siemens on several projects, the hierarchical
decomposition of use cases, is described in detail.
Chapter 9 is devoted to rapid prototyping and describes a simple
technique that has been found useful in the development of systems
that are categorized by workflow and graphical user interfaces.
Chapter 7 describes techniques and best practices for requirements
management. If you are interested in managing environments where
the work may be distributed, then read Chapter 10 as well.
Chapter 8 describes advanced techniques for transforming
requirements into test cases. It will be of interest to project and quality
assurance staff. However, as Chapter 8 uses model-based methods,
be sure to read Chapter 4 before reading Chapter 8.
Finally, Chapter 11 describes hazard and threat analysis and
management in the context of a requirements engineering process. If
you are an analyst working in a domain that is regulated or where
there is the potential for physical or financial harm to an end user of
a product, we recommend reading this chapter.

1.11 Summary
We’ve introduced some of the key challenges for requirements
engineering and some of the success factors to achieve good RE.
We’ve provided a definition of requirements engineering, and we’ve