<!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>The notion of Stakeholder in Requirements Engineering community</article-title>
      </title-group>
      <contrib-group>
        <aff id="aff0">
          <label>0</label>
          <institution>Facultad de Ingeniería y Ciencias Exactas-UADE y UNTREF</institution>
        </aff>
      </contrib-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Stakeholders play an important role in software process to meet the goals of the
development project. The software development process requires understanding the
stakeholders and assuring their involvement. Stakeholders are a key source of
information about the system under construction and are relevant protagonists in
validation and prioritization processes. Independently of these characteristics we
found inconsistences and contradictions in the use of the notion of stakeholders.</p>
      <p>Some authors consider stakeholders as individuals; others considerer they groups
or individuals and others think stakeholders are individuals or organizations. Some
authors consider individuals, groups or organizations as stakeholders; others admit as
stakeholder a “thing” or an interface..</p>
      <p>In the literature the stakeholder notion includes different relationships with
different entities of Software Product Life Cycle. A software project is a set of
activities to produce a software system with certain constraints. It involves three key
entities: project, product of the project and requirements of the software under
construction. We found instances of the stakeholder notion related with one, two or all
entities. A no structured review of text of Requirements Engineering or related with,
shows great differences between these entities and their relationships (for example
[1][2][3][4], a version with all the references can be requested to the author )
.Stakeholders have an interest in the new system; they will be involved by the system
and who have an influence on the system requirements; they influence the
requirements; they have an interest in the system or are affected by the development
and implementation of the system; they are person whose opinions, needs, or
preferences could be relevant to the Project; they determine requirements; they are
affected by or are accountable for some output of the project; they have an interest in
the product or knowledge about to the product; they obtain benefits from the system
under construction; they have indirect influence on the system requirements; they are
actively involved in the Project, or are affected by the end product; they are interested
in the behavior of the use case or the system; they have a "stake" in the success of the
system; they are affected by the system and are critical for its success; they are
1 This research is funded by project P13T06 (Web Requirements) of Instituto de Tecnología de
la Universidad Argentina de la Empresa (UADE)
affected by the implementation of the system; have a stake in the operation of the
system.</p>
      <p>In the requirements engineering community we found different contents of the
notion de “stakeholder”. This first approach suggest that there is no a clear concept in
the requirements community of stakeholder. The research is organized in three
dimensions: 1) Stakeholder notion definition; 2) Types of roles of stakeholders; 3)
Relationship of the definition an typology with the application domains, 4)
Stakeholder identification process. The largest question of this project is: What is a
stakeholder? From that question we derive several second level questions, for
example: How the RE community defines (explicitly or implicitly) stakeholder? What
kinds of roles are present in the literature? Does the notion of stakeholders include
relationships with the three entities of a project? Which type of relationship has the
stakeholder with these entities? Is stakeholder notion application domain dependent?</p>
      <p>The methodology considers analyzing scientific results of de Requirements
Engineering scientific community. The first step of the investigation will be
conducted from the proceedings of the International Requirements Engineering
Conference (RE) since 1993 to the last digital version available on line. This
Conference is a relevant component of the RE scientific community and there is not a
special reason to begin with it. After this first step we will extend the research to
others conferences and journals. The rationale of this approach is to analyze the
concept associated with the concept of “scientific community” as a key actor in
science progress. The analysis of the proceedings will begin identifying the use of the
word “stakeholder” trough the title, abstract, text (including tables and figures) and
references. Then we will do direct inspection of the papers.
2</p>
      <p>Contribution
Identification how this scientific community considers the notion and taxonomy of
stakeholders and the relationship of this notion with application domains. Major
characteristics of stakeholders identification processes. Based on these results we will
build the strategy to extend the analysis to other communities and corpus within
software engineering community.
3</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <surname>I. Sommerville</surname>
          </string-name>
          , Software Engineering, 5th ed. Harlew, Essex: Addison-Wesley,
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>S.</given-names>
            <surname>Robertson</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Robertson</surname>
          </string-name>
          ,
          <source>Mastering the Requirements Process Second Edition</source>
          , 2nd ed.
          <source>Addison Wesley Professional</source>
          ,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <given-names>D.</given-names>
            <surname>Leffingwell</surname>
          </string-name>
          and
          <string-name>
            <given-names>D.</given-names>
            <surname>Widrig</surname>
          </string-name>
          .,
          <source>Managing Software Requirements. A Unified Approach</source>
          , 1st ed.
          <source>Addison Wesley</source>
          ,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <given-names>S.</given-names>
            <surname>Lauesen</surname>
          </string-name>
          ,
          <article-title>Software requirements</article-title>
          .
          <source>Styles and techniques. London: AddisonWesley</source>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>