<!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>Towards automated requirements checking throughout development processes of interactive systems</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Thiago R. Silva</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Marco A. A. Winckler</string-name>
          <email>winckler@irit.fr</email>
        </contrib>
        <contrib contrib-type="author">
          <string-name>ICS-IRIT</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Université Paul Sabatier Toulouse</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>France</string-name>
        </contrib>
      </contrib-group>
      <abstract>
        <p>The user-centered development process of interactive systems is iterative and, during multiple iterations, users have the opportunity to bring new requirements that are very likely to have an impact, not only in future development, but also affect previously developed artifacts. Manual testing of all artifacts when new requirements are introduced can be cumbersome and time consuming. For that, we need flexible methods to ensure continuous consistency and accuracy among the various artifacts employed to build interactive systems. The ultimate goal of this position paper is to briefly present our vision on an approach for automating the requirements assessment using a Behavior-Driven Development perspective. Thereby, automated tests can run early in the design process, providing a continuous quality assurance of requirements, and helping clients and teams to identify potential problems and inconsistencies before commitments with software implementation.</p>
      </abstract>
      <kwd-group>
        <kwd>Automated Requirements Checking</kwd>
        <kwd>Behavior-Driven Development</kwd>
        <kwd>Multi-Artifact Testing</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        The activities of Requirements Engineering encompass cycles of meetings and
interviews with clients, users and other stakeholders. The outcomes of these meetings
are documented and modeled in several requirements artifacts which are
crosschecked at the end of the process, when the system is functional and ready to be
tested. When User-Centered Design (UCD) approaches are employed, intermediate tests
can be conducted earlier in Prototypes. However, UCD practice has shown that users
are keen to introduce new requirements along the process which might raise problems
for the correspondence with artifacts already produced, demanding activities
supported by Continuous Requirements Engineering. Currently, there are many solutions for
tracing requirements specification artifacts such as Use Cases, Business Rules etc.,
but there is still room for investigating automated solutions for tracking and testing
other types of artifacts such as Task Models, Prototypes etc. [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ].
      </p>
      <p>
        In this context, Behavior-Driven Development (BDD) [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] has aroused interest from
both academic and industrial community in the last years. User Stories allow us to
specify executable requirements in a natural language format, leading to a testable
requirements specification and conducting to a “live” documentation, making easier
for clients receive feedback early and conduct their acceptance tests. For this reason,
we are investigating some directions for using User Stories in a multi-artifact testing
spectrum as follows.
      </p>
      <p>From Ontologies to User Stories: Ontologies are useful to describe concepts used
by platforms, models and artifacts that compose the design of interactive systems. We
are studying ontologies for Web and Mobile platforms and associating the most
common behaviors that each User Interface (UI) element can answer. These behaviors
are being described using a natural language convention, useful later to specify steps
of Scenarios in User Stories, in order to set actions on interaction elements.</p>
      <p>From User Stories to Task Models: In Task Modeling, Scenarios represent
instances of specific tasks described in the model. In User Stories, Scenarios describe
examples of behaviors that users can perform in an interactive system. Ultimately,
these behaviors can be viewed as examples of tasks being executed by users.
Therefore, we are working on the use of User Stories as a mean to run Task Models,
crosschecking them since early in the design process.</p>
      <p>From User Stories to Prototypes: In a Requirements Engineering perspective,
Prototypes are used to address opportunities for UI design in the early phases of
development. This kind of artifact is highly evolutionary and can be useful until the last
stages of development, when the Final UI is defined. Scenarios in the User Stories
may support prototyping activities, giving them details and concrete examples of how
performing tasks on the proposed interface. Considering this, we are using User
Stories to run test scenarios in different stages of prototyping.</p>
      <p>From User Stories to Final UIs: User Stories described in BDD are a powerful
source of testing on the Final UI. Using external frameworks for specific
environments, Scenarios can be directly executed, acting at the same time as executable
requirements and test cases. We are writing User Stories from behaviors previously
extracted from our ontologies. These behaviors are being tested by executable actions
on the Final UI, using tools like JBehave and Selenium WebDriver.</p>
      <p>These four directions highlight possible solutions to automate the requirements
assessment, assuring VV&amp;T1 activities in a wider set of artifacts. In our approach, User
Stories are central pieces for guiding multi-artifact testing. Moreover, the use of
ontologies as a knowledge base to describe behaviors for UI elements allows us to
provide multiple design solutions as well as promoting reuse when considering similar
business models. Ongoing and future works include developing and adapting tools to
visualize and run User Stories on the artifacts mentioned above, in addition to collect
feedback from stakeholders through studies in real cases of software development.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Chelimsky</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Astels</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Helmkamp</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>North</surname>
          </string-name>
          , D.,
          <string-name>
            <surname>Dennis</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          , &amp;
          <string-name>
            <surname>Hellesoy</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          (
          <year>2010</year>
          ).
          <article-title>The RSpec book: Behaviour driven development with Rspec, Cucumber, and friends</article-title>
          . Pragmatic Bookshelf.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Nair</surname>
            , S., de la Vara,
            <given-names>J. L.</given-names>
          </string-name>
          , &amp;
          <string-name>
            <surname>Sen</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          (
          <year>2013</year>
          ,
          <article-title>July). A review of traceability research at the requirements engineering conference re@ 21</article-title>
          . In Requirements Engineering Conference (RE),
          <year>2013</year>
          21st IEEE International (pp.
          <fpage>222</fpage>
          -
          <lpage>229</lpage>
          ). IEEE.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>