<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Elicitation of Information Needs in Precontract Requirements Engineering</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Christian Müller</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Matthias Koch</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Sebastian Adam</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Fraunhofer Institute for Experimental Software Engineering</institution>
          ,
          <addr-line>Kaiserslautern</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <fpage>77</fpage>
      <lpage>82</lpage>
      <abstract>
        <p>The precontract phase of a software project is of high importance for the employer as well as the contractor, because this phase yields the basis for a contract between the parties. The main interest of the contractor is to provide an offer which addresses the requirements of the employer in a convincing way and proposes a solution for a reasonable price. In order to decide about the acceptance of an offer, decision makers of the employer require certain information to be contained in the offer. In this paper the results of a survey about the information needs of decision makers are presented. It yields first indications about the relevance of certain information and where in a document decision makers would like to find it. The paper includes a description of the method that has been used to acquire the knowledge.</p>
      </abstract>
      <kwd-group>
        <kwd>Precontract</kwd>
        <kwd>offer</kwd>
        <kwd>information needs</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Before the implementation of a software project can start, there is the need to develop
solution ideas as well as to estimate their costs as precisely and reliably as possible.
These are to be packaged into an offer that a customer is able to understand, assess, and
finally accept. In the end of the so-called “precontract phase” a contract is created to
which all partners have to commit. Errors in this contract, for example, because of
wrong cost calculations, ambiguously formulated requirements, or unconsidered
functionalities, can lead to a failure of the project [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>Although the precontract phase precedes every project, many organizations are
facing difficulties in this phase [2] [3]. To increase the chances of acceptance of the offer,
the requirements of the customer towards the system have to be captured and
understood exactly in order to identify suitable solutions and to determine the costs of their
realizations precisely. This is hampered by the asymmetry of information, i.e. the
potential services provider does not know the employer’s requirements and budget [4].
Subsequently, the solutions have to be presented in an understandable and convincing
way such that decision makers can judge the offer appropriately. Despite having an
economical relevance for the competitiveness of organizations, the precontract phase is
hardly addressed in the literature and is not present in common process models [5].
However, there is a demand for suitable methods which support the generation of
appropriate offers [6].</p>
      <p>As basis for the development of such methods it is important to know the information
needs of decision makers. Because these form the foundation of the offers to be created,
methods have to be aligned with them. The main goal is to be able to create the offers
with limited effort in such a way, that they contain exactly the information that the
decision makers need – not more and not less.</p>
      <p>This paper summarizes the information needs which have been identified in a survey
with three partner organizations and three of their customers. Therefore, interviews
have been conducted and the insights about the participants’ information needs have
been aggregated.</p>
      <p>The remainder of the paper is structured as follows: In chapter 2 the method for the
elicitation of information needs is described. In chapter 3 the outcomes of the conducted
study are elucidated. Chapter 4 contains an explanation of the threats of validity that
have to be taken into account when considering the presented results. Finally, an
outlook to future research in this area is given in chapter 5.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Method for the Elicitation of Information Needs</title>
      <p>This chapter describes the method which has been applied to gather the information
needs of decision makers.</p>
      <p>The elicitation of information needs has been done in interviews following a fixed
agenda. During these interviews the participants have been asked, what motivates them
to read the offer completely from beginning to end, and what prevents them from
reading it completely. The answers have been collected in an unsorted list of indications.
Furthermore, the participants have been asked for information that is expected to be
included in the offer by all means. This can for instance include information about the
product, the vendor, or the project. All the mentioned elements have been noted on
cards.</p>
      <p>Next, the order in which the information should be present in the offer has been
elicited. For this purpose, the card-sorting technique [7] has been applied. The
participants ordered the cards with the information elements to express which information
they would like to have in the beginning, middle, or end of the document.</p>
      <p>As a last step, the participants were supposed to prioritize the information elements
with respect to their importance for a decision to accept or reject the offer. The
prioritization has been done using a five-point Likert-scale, whereas “1” stands for very
important and “5” for very unimportant.</p>
      <p>After the workshops, the gathered information has been consolidated, i.e. the
terminology has been unified, and the results have been aggregated.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Information Needs</title>
      <p>In this chapter, the results of the survey are presented. The method, which is
described in the previous chapter, has been applied with three partner organizations and
three of their customers. This means the results depicted in this chapter contain the
aggregated outcomes of six interviews.</p>
      <p>At first the identified positive and negative criteria is elaborated, afterwards the
information elements required by decision makers are depicted.
3.1</p>
      <sec id="sec-3-1">
        <title>Positive and negative criteria</title>
        <p>The organizations and their customers have been asked what motivates them to read
the offer from beginning to end. Table 1 shows these criteria sorted by the number of
indications by the interviewees. The most important criterion is that the offer has to
justify the price of the solution. In particular, the description of the individual modules
should convey their value and degree of innovation. Furthermore, a comprehensible
textual presentation of the concepts and a clear layout motivates half of the participants
to read the offer entirely.</p>
        <p>Besides the factors that motivate the customers reading the offer, the interviewees
have been asked for criteria which prevents them from reading the offer. Table 2 gives
an overview of the identified negative criteria. The first two criteria relate to a bad
readability of the textual descriptions of the concepts and too much content in the offer.
These fit to the identified motivation criteria that has been described before.</p>
        <p>Criterion
Price
Textual
presentation
Layout
Graphics
Requirements
Extent
Criterion
Readability
Extent</p>
        <p>Indications
67%
50%
50%
33%
33%
33%
Indications
33%
33%
Criterion
Textual
presentation
Layout
Price
Requirements
Technical
information
Reference
projects</p>
        <p>Description
Usage of generic standard text elements which do not react to
the requirements
Poor formatting, no loosening graphics
The price is way too high and exceeds the price limit
The previously defined requirements of the customer are not
addressed
No technical information of the proposed solutions is present
No description of successful similar projects with other
customers is given
17%
17%
17%
17%
17%
3.2</p>
      </sec>
      <sec id="sec-3-2">
        <title>Required information elements</title>
        <p>In addition to the criteria mentioned in the previous section, the interviewees have
been asked specifically about information elements that have to be present in the offer.
Table 3 shows an overview of all the identified information needs. They are sorted by
the average importance that has been assigned to the information. The values of the
importance have been transformed to labels according to the following scheme:
1.0 – 2.33: Important 2.34 – 3.66: Neither nor 3.67 – 5.0: Unimportant
Information
element
Initial
situation
Price
information
Modules
Visual
information
Technical
background
Milestones
Temporal
procedure
Contract
conditions
Information
element
Contact
persons
Optional
services
Resources
Contact data of the project responsible or
project management
Optional, but recommended services /
modules including their costs
Efforts to be made by the customers, such
as coaching or maintenance
End</p>
        <p>The results of the survey have to be regarded carefully because of several threats to
validity which are explained in this section. They are classified into the categories
conclusion, internal, construct, and external validity [8].</p>
        <p>The conclusion validity is concerned with the degree to which conclusions about
relationships in the data can be drawn. This validity is threatened by the small sample
size of only six participants. This means it has to be stated that the implications drawn
from the data most likely have a limited reliability.</p>
        <p>The internal validity is concerned with the causal relationships between a treatment
and the results. The internal validity is threatened by the way the information has been
gathered in interviews. There is a risk that participants are influenced by recent
occurrences and might have forgotten aspects that used to be important in the past.</p>
        <p>The construct validity is concerned with the relation between theory and observation.
In the scope of the survey, the construct validity is threatened by the fact, that the only
means for gathering the information has been interviews. In these interviews the
participants expressed what they think is important to them. Their perception might deviate
from reality.</p>
        <p>The external validity is concerned with the generalizability of the results. This
validity is seen as rather high, because all the participants of the survey were
representatives of real organizations who are involved in writing and reading offers in their
business.
5</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Conclusion</title>
      <p>The survey presented in this paper aims at gathering the information needs of
decisions makers who decide about the acceptance of offers that are created in the
precontract phase of software development projects. Additionally, the survey covers the
criteria which motivates them to read the offer completely, and the criteria which has
negative influence on the willingness to read the document. The identification of the
information needs is required in order to propose methods which help contractors to write
offers with reasonable effort in such a way that decision makers find exactly the
information they are looking for.</p>
      <p>A comparison of the information elements currently included in offers and the
identified information needs reveals that the information required to judge an offer is
already present in today’s “as-is-offers”. Deviations mainly arise in the order of the
presentation. An important indicator for decision makers is the price, which is currently
only present in conjunction with the list of modules and their descriptions. Another
important criterion is the temporal procedure. In the “as-is-offers” this information is
given after the description of modules. However, it should be presented more
prominently in the beginning of the document.</p>
      <p>The results of this study provide a first indication about the information which
decision makers expect to be present in offers. Because of the described threats to validity,
further studies need to be performed in order to increase the level of confidence. In
future research it is necessary to repeat the survey with more participants in order to
minimize the threats to conclusion validity. To counter the threats to construct validity,
i.e. the risk that the measured perception of the information needs deviates from the
actual needs, it is beneficial to acquire the information from participants during their
reading of such documents instead of purely relying on interviews. This could for
example be supported by the usage of observations or eye tracking.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <source>[1] [2] [3] [4] [5] [6] [7] [8] The Standish Group, "CHAOS Manifesto</source>
          <year>2013</year>
          ,"
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>A.</given-names>
            <surname>Tarhan</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Gencel</surname>
          </string-name>
          and
          <string-name>
            <given-names>O.</given-names>
            <surname>Demirors</surname>
          </string-name>
          ,
          <article-title>"Pre-Contract Challenges: Two Large System Acquisition Experiences," in Enterprise Architecture and Integration: Methods, Implementation</article-title>
          and Technologies,
          <year>2007</year>
          , pp.
          <fpage>75</fpage>
          -
          <lpage>91</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <given-names>B.</given-names>
            <surname>Paech</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Heinrich</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            <surname>Zorn-Pauli</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Jung</surname>
          </string-name>
          and
          <string-name>
            <given-names>S.</given-names>
            <surname>Tadjiky</surname>
          </string-name>
          ,
          <article-title>"Answering a Request for Proposal - Challenges and Proposed Solutions,"</article-title>
          <source>in REFSQ, Essen</source>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <given-names>R.</given-names>
            <surname>Weiber</surname>
          </string-name>
          and
          <string-name>
            <given-names>F.</given-names>
            <surname>Jacob</surname>
          </string-name>
          ,
          <article-title>"Kundenbezogene Informationsgewinnung,"</article-title>
          <source>in Technischer Vertrieb - Grundlagen</source>
          , Berlin, Springer,
          <year>2000</year>
          , pp.
          <fpage>523</fpage>
          -
          <lpage>612</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <string-name>
            <given-names>J.</given-names>
            <surname>Ludewig</surname>
          </string-name>
          and
          <string-name>
            <given-names>H.</given-names>
            <surname>Lichter</surname>
          </string-name>
          , Software Engineering: Grundlagen, Menschen, Prozesse, Techniken, dpunkt.verlag,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <string-name>
            <given-names>O.</given-names>
            <surname>Demirors</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            <surname>Demirors</surname>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Tarhan</surname>
          </string-name>
          ,
          <article-title>"Managing instructional software acquisition,"</article-title>
          <source>Software Process: Improvement and Practice</source>
          , vol.
          <volume>6</volume>
          , no.
          <issue>4</issue>
          , pp.
          <fpage>189</fpage>
          -
          <lpage>203</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <string-name>
            <given-names>D.</given-names>
            <surname>Spencer</surname>
          </string-name>
          ,
          <article-title>"Card sorting: a definitive guide," 7 4 2004</article-title>
          . [Online]. Available: http://boxesandarrows.com
          <article-title>/card-sorting-a-definitive-guide/.</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <string-name>
            <given-names>C.</given-names>
            <surname>Wohlin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Runeson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Höst</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M. C.</given-names>
            <surname>Ohlsson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Regnell</surname>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Wesslén</surname>
          </string-name>
          , Experimentation in Software Engineering: An Introduction, MA, USA: Kluwer Academic Publishers Norwell,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>