Catching the worm

Requirements in early phases

While methods for requirements engineering have greatly advanced over the last years, these techniques mainly focus on engineering tasks that need to be carried out after a project is already started.

However, before starting a project, standards like PRINCE2 ^{[OGC 2009]} demand for a project mandate and a business case, to evaluate if the project should be carried out or not. Usually the business case should estimate the benefits of the project as well as the costs. To do so, it is first of all necessary to determine the scope of the projects requirements.

However, it is within the very nature of a project that the scope is not a fixed size throughout the course of the project. Barry Boehm was one of the first to describe this behavior with what is now commonly called the Cone of Uncertainty. The notion this image conveys it that the scope of a project is much more prone to fluctuations in early phases than it is in later phases. This is shown by the tapering of the cone to the right.

Thus, the problems a requirements engineer faces in early phases are:

1. An unclear project scope due to early stage of problem definition.
2. Limited time and means to create the first requirements documentation.
3. Capturing the functional scope necessary for cost estimation.

Though the first problem can’t be solved by any methodology – it is due to the very nature of the Cone of Uncertainty - we will provide useful tools to deal with the last two issues in this article.

To determine the solution scope, use case diagrams will mostly be the method of choice in early project phases. The advantages are: They offer a good first overview of functional requirements from a user point of view and can be captured, structured and documented easily. Therefore use case diagrams are often used as a basis for discussion and communication with stakeholders ^{[Rupp et al. 2009]}. Nevertheless, as we will describe later, a plain use case diagram is insufficient for both an adequate presentation of functional requirements and as a basis for an effort and cost estimation.

Understanding the business use case

For a reliable size measurement it is necessary to understand how business use cases (what) translate into system use cases (how). However, usually it already takes a long time to describe the business use cases, so we cannot expect to have enough time to describe the system use cases as well in pre-project phases. Therefore, we propose to address this conversion in short stakeholder interviews.

It is our experience that stakeholders who define the business use case often have limited technical knowledge concerning the actual implementation of their requirements. However, they very often possess a very in-depth understanding about what systems and interfaces are involved in the new application. That’s because they often have a coarse overview of the IT landscape of their company and know where to draw the needed information from, e.g. customer data, or what applications will provide services for the new IT product. Also they understand when input data needs to be manipulated or processed to generate the desired output data.

In our experience sufficient information can often be gathered even in early or pre-project phases if the requirements engineer has access to the right stakeholders and poses the right questions. Here are some simple steps that we think can be carried out in any project no matter how tight the schedule is:

• Document the preliminary business use cases (what).
• Hold a workshop together with business people and technical staff.
• Clarify for every use case the rough details of its implementation (how) by asking:
  • Which actors are interacting with the system?
  • How many other systems are involved?
  • What interfaces need to be defined?
  • How many steps does it take to process the raw data?
  • How many steps does it take to process the output data for displaying?
  • How many alternative scenarios are there and of how many steps will they be comprised?
  • How many error scenarios are there?

If all stakeholders work together, a workshop like this can yield enough information about the functional size of the application. As can also be seen, the time needed to gather all necessary information for the functional size measurement is only a short workshop. Compared to effort and cost estimates based on expert judgments the time needed for an estimate can thus be significantly reduced. As might have been noticed, some of the questions posed are rather unspecific in nature. This is to facilitate an open discussion that allows all stakeholders to take part and provide the requirements engineer with useful input. What is important, however, is that the information is captured in the right way so that is becomes quantifiable and can be used for functional size measurement. ####Measuring functional size Stakeholder interviews or pre-project workshops such as described above will usually not yield a detailed description of single sequences or specific system behavior. However, they will provide the number of steps and transactions necessary for a use case to be completed. Basically a use case diagram displays system functionality, all relationships, and the interactions of actors from outside the system boundary as shown in the following diagram.

However, the plain UML specification only provides a mere description of how the diagram should look like. It contains no recommendation about what information should actually be included in the diagram. This poses the risk that the diagram will only describe the use case from a business standpoint (what) while lacking information about the implementation (how), which is necessary for a functional size measurement. To add this information it is necessary to also capture the steps that comprise a use case. We will define a step as an elementary process for achieving a use case’s goal. This step is either executed completely or not at all and is described from a system user’s point of view. A step covers the following possibilities: * An interaction between an actor and the subject (the system which is considered). * A data validation. * An internal change of state. This definition is important, because it will be the requirements engineer’s responsibility to transfer the information provided in workshops and interviews into the appropriate Use Case Metric based on the number of steps. The idea to equate the functional size of a use case with its numbers of steps was originally proposed by Gustav Karner ^{[Karner 1993]}. The Use Case Points Metrics assign a weighting to every use case based on the number of steps. The metrics are defined as follows: * 1-3 steps: Simple Use Case (weight: 5) * 4-7 steps: Average Use Case (weight: 10) * 7 steps or more: Complex Use Case (weight: 15). In addition to use cases, actors are evaluated by means of their interaction with the system: * via APIs: Simple Actor (weight: 1) * via protocols or the command line: Average Actor (weight: 2) * through graphical user interfaces: Complex Actor (weight: 3). This information usually cannot be captured using plain use case diagrams; when it comes to chronological relations or detailed descriptions of steps or scenarios use case diagrams are rather limited ^{[Cockburn 2000]}. We therefore strongly recommended extending the diagrams with a textual or tabular description as described by ^{[Fowler 2012]} and ^{[Pohl et al. 2011]} as shown in the following table.

ID	UC2
Name	Car booking
Short description	A customer wants to book a rental car via the webpage of a car rental service
Actors	Customer, payment processor
Pre-conditions	None
Trigger	Customer starts the booking process by entering his preferred pickup and return station and rental dates
Main scenario		No. of steps:
	1. The customer enters his data (preferred car, dates etc.), his personal data as well as his payment information	Step 1
	2. The system has to check the availability of the selected cars	Step 2
	3. The system has to check the payment information with the payment processors (i.e. credit card institute)	Step 3
	4. At the end the customer should receive a booking confirmation	Step 4
Post-condition	The customer has received a booking confirmation and his booking has been saved in the system.

If every use case is documented in this way, it is easy to calculate the Functional Size Measurement (FSM) as the sum of the weighting of all use cases metrics. The FSM is then given in so-called Unadjusted Use Case Points (UUCP). In this example we can count 15 Unadjusted Use Case Points (1 Actor Complex, 1 Actor Average and a Use Case Average). ####Creating a cost estimate Using the functional size measurement of the application it is possible to estimate the overall project effort and thus the project cost. We will describe two methods that can be used by the project manager. The first method can be used by organizations that already use function-point-driven estimation methods in later project phases but are having problems to come up with early estimates. These problems usually arise because function points counting cannot be done in early phases due to the technical nature of the function point metrics. However, using the use case point counting practice described above, it is easy to transform the UUCP size measurement into function points. Transforming Function Points (FP) requires using a normalization factor that equates Unadjusted Use Case Points and Function Points. This factor can either be provided by estimation companies, or can be determined by the organization over the course of several projects. As a starting point we suggest a factor of 2.27 implicitly provided by ^{[Schofield et al. 2013]}. After the transformation the company can use its productivity benchmarks to generate an effort and cost estimate. Suppose, for example, an application has a FSM of 300 UUCP and the company has a productivity of 34 person hours per FP. A course estimate would yield:

300 UUCP ∗ 2.27 FP per UUCP ∗ 34 PH X 34 PH per FP = 23154 PH

However, this method is only based on the functional size of the application not on non-functional requirements. It therefore only works when firstly enough historic data has been gathered to come up with a stable productivity factor (e.g., person month per function point) and secondly the non-functional requirements for the new application do not differ too much from projects in the historical database. The second method makes up for these problems. It is based on a combination of the COnstructive COst MOdel - II (COCOMO II) and function points described by ^{[Boehm 2000]}. One of the advantages of COCOMO II is that it can be used to estimate projects that take place in unfamiliar environments with a lot of non-functional requirements. However, this requires a few more calculations: The idea behind COCOMO is to provide a sufficient number of parameters to adjust for the specific situation of any project. The formula used, the parameters and how to rate these parameters can be found in ^{[Boehm 2000]}. Before using COCOMO it is necessary to transform the function points into kilo Source Lines Of Code (kSLOC). This means that depending on the programming language used, the productivity of the project is adjusted using a table of backfiring values (provided by ^{[Boehm 2000]}). Backfiring values thus describe how many lines of code are necessary to implement one function point. The kSLOC value can then be used as input to the COCOMO formula. To sum these steps up, let’s assume we have an application with a FSM of 300 UUCP that will be implemented in Java (with a backfiring value of 53). We can calculate the kSLOC as:

300 UUCP ∗ 2.27 FP per UCP ∗ 53 SLOC per FP ≈ 36000 SLOC = 36 kSLOC

This value can now be used to generate a cost estimate using the COCOMO II framework. #### Refining the estimation The preliminary requirements documentation from the pre-project phase can be updated and used throughout the rest of the actual project. This is important because our approach aims to minimize the effort necessary for cost estimation by going along with requirements engineering tasks that will usually take place anyway sooner or later in the project. As an example, we’ll show how the use case description above can be transformed into a sequence diagram that satisfies standards for requirement documentation.

In this example we assume a medium complexity for every function point component, resulting in 31 function points. Usually after describing sequence diagrams the estimation can be conducted using function point analysis (and either COOCMO or the company’s productivity factor). We recommend conducting both steps: that is, the use case counting and the function point counting over the course of a few projects to build up historical data concerning the relation between both sizing methods. This will help to further strengthen the reliability of the estimation while aligning perfectly well with the described requirements engineering techniques. ###References

• [Boehm 2000] Barry Boehm: Software Cost Estimation with COCOMO II. Upper Saddle River 2000
• [Cockburn 2000] Alistair Cockburn: Writing Effective Use Cases. Boston 2000
• [Fowler 2012] UML Distilled: A Brief Guide to the Standard Object Modeling Language. Boston 2012
• [Karner 1993] Gustav Karner: Metrics for Objectory. Diploma thesis, Linköping University 1993
• [Pohl et al. 2011] Klaus Pohl und Chris Rupp: Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam. Santa Barbara 2011
• [Rupp et al. 2009] Chris Rupp & die SOPHISTen: Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis. München 2009
• [OGC 2009] Office of Government Commerce: Managing successful projects with PRINCE2, London 2009
• [Schofield et al. 2013] Joe Schofield, Alan W. Armentrout, Regina M. Trujillo: Function Points, Use Case Points, Story Points: Observations from a Case Study. In: CrossTalk, May/June 2013 URL: http://goo.gl/il44Kw (last accessed: December 2013)