[Context] The requirements baseline is an agreed-upon set of desired product features committed to a specific release. It determines intra- and interproject planning and involved performance assessment. [Problem] To establish a credible baseline, one which fits into the limits e.g. time box of the project and which satisfies user expectations, a reasonable choice of requirements must be made. This demands commensurable units of measure for requirements that are meaningful to most decision makers in a project team. [Principle Idea] This work proposes the use of functional size measurement patterns as a reusable point of reference to classify requirements consistently and to estimate their functional size in a reproducible way. It develops measurable requirements patterns out of problem frames and a counting procedure, that facilitates determining function points for requirements in accordance with ISO/IEC 20926:2009. [Contribution] These patterns provide the project team with a bias-free anchor regarding the functional size of requirements with which they can correlate their requirements estimates and anticipated work plan. Establishing the requirements baseline with respect to these patterns eases the comparability of project outcomes and thus contributes to the predictability of project planning.
Implementing software projects the agile way is all the rage. It is deemed to
be the fast track to deliver software features at low cost due to self-organizing
project controls. An agile development iteration follows a Plan-Do-Check-Adjust
(PDCA) cycle [10, page 88]. Each completed cycle brings an improvement of
the software increment i.e. of the product towards desired functionality. Sprint
events of the Scrum project process framework [
Copying permitted for private and academic purposes. 216]. To this end, ’Requirements First’ is still the name of the game. Before any development starts, the team needs to reach consensus on the work plan to be done during the upcoming iteration, which depends on the agreed-upon requirements baseline. In order to decide on it, a gamified decision-making process known as Planning Poker [5, page 56] is played by the team to estimate requirements. It is a modern adaption of the Wideband-Delphi estimation technique [4, Page 335ff] originated in the 1980s.
desired Kde4si2reDdr.
~ |}
I.
Scrum Planning II. (Daily) Work
DO dfealitvuerreable committed
fedaotnuere scored
X X III.
Reviewq
feature
credible Baseline iteration b
B IV.
Retrospective events
Estimating by Planning Poker starts with User Stories [
The key benefits of requirements estimating in points are (i.) that they make “the unit of estimation abstract, which makes it easier to commit to, and easier to adjust your commitments to” [27, page 161], and (ii.) their self-correcting nature [27, page 160]. “Even if a team is bad at estimating, as long as they’re consistently bad, this makes a team’s commitments self-correcting” [27, page 159], which helps “to meet expectations more consistently” [27, page 161].
A common criticism is that this consistency of estimates depends on the team,
since (the meaning of) points assigned to requirements or a user story relates to
an estimator’s “experience and good feel rather than on formal criteria” [9, page
1343]. Team virtualization, membership turnover, silo mentality, etc. impacts the
team’s capability to establish a common respectively shared understanding on
their requirements estimates. In each iteration they suffer from a bootstrapping
problem [
Establishing consistency of estimates from one iteration to another is
obtainable by finding comparable requirements that require “a similar amount of
work” [
With the bootstrapping problem in mind, it cannot be assumed that historical data about requirements estimates exist nor that these compare to the team estimates i.e. that the same principles and methods have been followed to establish them. Commensurable units of measure for requirements reusable in any project are needed to keep the baseline consistent. These units must be meaningful to most decision makers in a project team to “bridge any gaps in understanding [. . . ] between clients and developers” [9, page 1343].
This work proposes to unify consideration of requirements and their respective amount of work expressed as a point value by means of patterns. Therefore, it joins the use of problem frames as best practices to classify requirements consistently, which are introduced in Section 1.1, and ISO/IEC 20926 as a standard for functional size measurement to determine the requirements’ size in a reproducible way, which is introduced in Section 1.2. 1.1
Requirements Classification by Problem Frames
Problem Frames are patterns, which characterize classes of recurring problem
situations [
Using Problem Frames to classify requirements helps to identify the kind of functionality that is of relevance to the problem. They allow to find a proper machine behavior, i.e. specification, which can be created by the developer and that will make what is required by the user [19, Page 106]. Therefore, the machine to be built i.e. the software application has to control a specific part of the problem in a way as the requirement demands [19, Page 107]. A problem frame indicates this part by a requirement constraint on the respective problem domain.
In general, each problem frame is a unique combination of problem domains
and their respective shared phenomena, which differ in their type, quantity, and
correlation. The functionality of a software as describable by problem frames
establishes one of the following three kinds of machine control: a constrained
X L99 Le(X)ical domain “is a physical representation of data” [
D L99 (D)isplay domain is “an output device for the machine” [
CD!Y2
CDM!E1 machine domain
interface CA!E2 developer view e.g. functional specification problem domain
X requirements FUR02
B domain type client or user view e.g. user story Legend for interfaces and their {shared phenomena}: E1{store40FormData}, E2{fillIn40FormData,FormData1..40}, E3{fillInCandidateData}, Y2{FormData1..40}, Y4{collectCandidateData}
For example, in Figure 2 a set of requirements named FUR02 builds a
subproblem for a Student Recruitment Web Portal [
This technology-agnostic approach makes use of logical so-called base functional components to classify functional, user-recognizable requirements (FUR) into an “elementary unit of FUR defined by and used by an FSM Method for measurement purposes” [17, page 2, section 3.8]. Their size is determined within the counting process and expressed by a number in function points.
Functional size measurement introduces a means for quantifying
requirements specifications. However, it is no Requirements Engineering method, since
its prime purpose is not to result in a comprehensive requirements specification.
Actually, its quality depends on a good requirements specification [
In this connection, identification of the application boundary, which is a “conceptual interface between the software under study and its users” [17, page 3, section 3.9] is crucial. The base functional components are counted with respect to the application boundary as illustrated in Figure 3. In order to determine the functional size of some requirements consistently, they need to be decomposed to fit the base functional components in a reproducible way. ILF
EI boundary application EQ / EO EQ / EO user
EIF application other
The measurement process according to ISO/IEC 20926 [17, page 8]
distinguishes data functions and transactional functions. Data functions such as
Internal Logical File (ILF), and External Interface File (EIF) relate to requirements
that are concerned with data storage needs. An ILF is some ”information
maintained within the boundary of the application being measured” [17, page 6,
section 3.39], in contrast to an EIF, which is some ”information, which is
referenced by the application being measured, but which is maintained within the
boundary of another application” [17, page 5, section 3.29]. Requirements that
are concerned with different kinds of data processing are considered by
transactional functions. These are synonyms for the following elementary processes:
EI External Input (EI) is an “elementary process that processes [. . . ]
information sent from outside the boundary” [17, page 4, section 3.27], its
primary intent is to “maintain an ILF [. . . ]” [
EQ ! External Inquiry (EQ) is an “elementary process that sends [. . . ]
information outside the boundary” [17, page 5, section 3.28], its primary
intent is to “present information to a user. It presents only data that is
retrieved [. . . ]” [
EO ! External Output (EO) is an “elementary process that sends [. . . ]
information outside the boundary and includes additional processing logic
beyond that of an external inquiry” [17, page 5, section 3.30], its
primary intent is to “present information to a user. It presents data that is
calculated or derived [. . . ]” [
Given that an elementary process is the “smallest unit of activity that is meaningful to the user” [17, page 4, section 3.21], it specifies what the software shall do in terms of different kinds of processing and functionality, respectively. This drives decomposition of FUR comparable to problem frames. 2
“At the start of each development iteration, [. . . ] Groups of user stories are
associated with a generic ’feature’. The complexity of each feature is then
estimated” [9, page 1343]. Thus, the challenge is to set up commensurable units
of requirements, i.e. requirements work packages [
On the one hand, they allow for classifying requirements into self-contained
subproblems, which maintain requirements description at a consistent level of
detail, as long as their underlying frames belong to the same hierarchy of
patterns. Each Problem Frame in Table 1 belongs to the set of Basic FSM Patterns
“that apply to a complete yet single functional process” as defined in [
On the other hand, each set of requirements grouped by a problem frame is concerned with a particular kind of functionality, which is indicated by the constrained problem domain as discussed in Section 1.1. It can be compared and mapped to the primary intent of an elementary process as discussed in Section 1.2, which indicates similarly the kind of functionality or respective processing to be sized in a function point count. Table 1 provides for this relation by a bullet point.
As a result, Table 1 lists 17 Basic FSM patterns, which allow to set up requirements work packages. These patterns provide for a grouping of requirements, which relate to measurable base functional components. They can be sized according to the rules of functional size measurement. A respective requirements sizing method is presented in Section 3.
Table 1 makes use of a short cut representation for problem frames introduced
in prior work [
This work proposes to use a customized requirements sizing method to provide
for consistent and reproducible requirements estimates. It is applicable within
planning of a project iteration as supplementary method to Planning Poker and
given in detail in the Frame Counting Agenda [
Figure 4 depicts the requirements work package “Collect Candidate Data” in
a stereotype notation as applied in the UML4PF [
«subProblem» FUR02 Collect Candidate Data
CDM!{store40FormData}, CD!{FormData1..40 } «machine» Collect Data transactional function (EI) «lexicalDomain» Candidate Data data function (ILF) {collectCandidateData}
«constrains» «requirements» FUR02 CA!{fillIn40FormData, FormData1..40} «refersTo» {fillInCandidateData} «biddableDomain» Candidate data function (EIF)
Establishing requirements work packages based on functional size
measurement patterns also prevents a malpositioned application boundary [
To give an example of the outcome produced by the requirements sizing method
as introduced in Section 3, it is applied to a Student Recruitment Web Portal [
The list in Table 2 can be used by the project team to set up the requirements baseline for a project iteration. These requirement estimates allow to organize the Sprint Backlog, i.e. to commit to a set of requirements work packages, which are then to be done in the time box of a project iteration. A requirement work package, for which the team successfully delivers desired product features after completing the iteration, can be scored for the requirements baseline respectively.
Statistics on these baseline scores can be used to adjust iteration planning [27, page 170]. A credible baseline is established depending on measurable project outcome (scored points), which demonstrably fits into the time box of a project project outcome (points scored) iteration, e.g. credibilitybaseline = requirements baseline (points planned) . Thus, a requirements baseline, which is established by means of functional size measurement patterns, relates to fulfilled requirements, i.e. satisfied user expectations, rather than to individual team estimates.
In [
The contribution of this work is twofold: As discussed in Section 2, it takes the
problem frames approach to obtain recognizable classes of requirements, which
are capable of relating user requirements with more measurable, technical
specifications. They allow to transfer requirements into self-contained subproblems
i.e. work packages, that are meaningful as units of work that the team can
commit to and score for the baseline of a project iteration, and as units of measure
for requirement’s functional size. As discussed in Section 3, this work proposes
to use a counting procedure for the functional size measurement patterns in
Table 1, that is based on a match of the problem frame concept with that of base
functional components. These contributions serve the estimator to obtain
reproducible results, i.e. function point estimates for requirements, that comply with
a standard for functional size measurement, i.e. ISO/IEC 20926 [
This work implements an Integrated Requirements Engineering approach [
With regard to the client, it is intended to investigate how tender preparation and mockup creation relate to requirements work packages. With regard to the developer, it is planed to investigate how an appropriate design or reusable software components can be chosen with respect to a requirements work packages, that fit the project time box.