How Artifacts Support and Impede Requirements Communication

Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 9013)


[Context & motivation] Requirements artifacts, like specifications, diagrams, or user stories, are often used to support various activities related to requirements. How well an artifact can support a specific activity depends on the artifact’s nature. For example, a plain text document can be adequate to provide contextual information, but is not well suited in terms of documenting changes. [Questions / problem] We wanted to understand how practitioners in various roles use requirements artifacts, how they manage to work with multiple artifacts at a time, and whether they use current practices for linking related artifacts. [Principal ideas / results] We have conducted an interview study with 21 practitioners from 6 companies. The interviews indicate that often a variety of artifact types is needed to successfully conduct a project. At the same time, using multiple artifacts causes problems like manual translation effort and inconsistencies. Mapping mechanisms that explicitly relate different artifacts are needed. However, existing methods are often not used. We investigate why these methods challenge developers in practice. [Contribution] We show challenges and chances of requirements artifacts. Our findings are grounded on true experiences from the industry. These experiences can support software developers in planning and improving their processes with regard to better requirements communication and researchers in making mapping methods more applicable in industry.


Requirements artifacts Requirements communication User stories 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Cockburn, A.: Agile Software Development. Addison Wesley (2002)Google Scholar
  2. 2.
    Bjarnason, E., Wnuk, K., Regnell, B.: Requirements are slipping through the 
gaps - a case study on causes & effects of communication gaps in large-scale software development. In: Requirements Engineering Conference (RE) (2011)Google Scholar
  3. 3.
    Bjarnason, E., Wnuk, K., Regnell, B.: Are you biting off more than you can chew? a case study on causes and effects of overscoping in large-scale software engineering. Information and Software Technology 54(10), 1107–1124 (2012)CrossRefGoogle Scholar
  4. 4.
    Abelein, U., Paech, B.: State of practice of user-developer communication in large-scale IT projects. In: Salinesi, C., van de Weerd, I. (eds.) REFSQ 2014. LNCS, vol. 8396, pp. 95–111. Springer, Heidelberg (2014)CrossRefGoogle Scholar
  5. 5.
    Marczak, S., Damian, D., Stege, U., Schroter, A.: Information brokers in requirement-dependency social networks. In: Requirements Engineering Conference (RE) (2008)Google Scholar
  6. 6.
    Knauss, E., Damian, D., Cleland-Huang, J., Helms, R.: Patterns of continuous requirements clarification. Requirements Engineering Journal (2014)Google Scholar
  7. 7.
    Kumar, S., Wallace, C.: A tale of two projects: a pattern based comparison of communication strategies in student software development. In: Frontiers in Education Conference. IEEE (2013)Google Scholar
  8. 8.
    Fernandez, D.M., Penzenstadler, B.: Artefact-based requirements engineering: the AMDiRE approach. Requirements Engineering Journal (2014)Google Scholar
  9. 9.
    Gross, A., Doerr, J.: What you need is what you get!: the vision of view-based requirements specifications. In: Requirements Engineering Conference (RE) (2012)Google Scholar
  10. 10.
    Sharp, H., Robinson, H., Petre, M.: The role of physical artefacts in agile software development: Two complementary perspectives. Interacting with Computers 21(12), 108–116 (2009)CrossRefGoogle Scholar
  11. 11.
    Gallardo-Valencia, R.E., Olivera, V., Sim, S.E.: Are use cases beneficial for developers using agile requirements?. In: Fifth International Workshop on Comparative Evaluation in Requirements Engineering (CERE) (2007)Google Scholar
  12. 12.
    Patton, J.: User Story Mapping. O’Reilly Media (2014)Google Scholar
  13. 13.
    Imaz, M., Benyon, D.: How stories capture interaction. In: INTERACT 1999, pp. 321–328. IOS Press (1999)Google Scholar
  14. 14.
    Antonino, P.O., Keuler, T., Germann, N., Cronauer, B.: A non-invasive approach to trace architecture design, requirements specification and agile artifacts. In: 23rd Australian Software Engineering Conference (ASWEC), pp. 220–229 (2014)Google Scholar
  15. 15.
    Abelein, U., Paech, B.: A proposal for enhancing user-developer communication 
in large IT projects. In: 5th International Workshop on Cooperative and Human Aspects of Software Engineering 
(CHASE), pp. 1–3 (2012)Google Scholar
  16. 16.
    Rashid, A., Sawyer, P., Moreira, A., Araujo, J.: Early aspects: a model for aspect-oriented requirements engineering. In: Requirements Engineering Conference (RE) (2002)Google Scholar
  17. 17.
    Gotel, O.C.Z., Marchese, F.T., Morris, S.J.: On requirements visualization. In: 2nd International Workshop on 
Requirements Engineering Visualization (REV) (2007)Google Scholar
  18. 18.
    Creighton, O., Ott, M., Bruegge, B.: Software cinema – video-based requirements engineering. In: Requirements Engineering Conference (RE) (2006)Google Scholar
  19. 19.
    Bouillon, E., Mäder, P., Philippow, I.: A survey on usage scenarios for requirements traceability in practice. In: Doerr, J., Opdahl, A.L. (eds.) REFSQ 2013. LNCS, vol. 7830, pp. 158–173. Springer, Heidelberg (2013)CrossRefGoogle Scholar
  20. 20.
    Ben Charrada, E., Koziolek, A., Glinz, M.: Identifying outdated requirements based on source code changes. In: Requirements Engineering Conference (RE) (2012)Google Scholar
  21. 21.
    Anderson, K.M., Sherba, S.A.: Using open hypermedia to support information integration. In: Reich, S., Tzagarakis, M.M., De Bra, P.M.E. (eds.) AH-WS 2001, SC 2001, and OHS 2001. LNCS, vol. 2266, pp. 8–16. Springer, Heidelberg (2002)CrossRefGoogle Scholar
  22. 22.
    Hayes, J.H., Dekhtyar, A., Osborne, J.: Improving requirements tracing via information retrieval. In: Requirements Engineering Conference (RE) (2003)Google Scholar
  23. 23.
    Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering 14(2), 131–164 (2009)CrossRefGoogle Scholar
  24. 24.
    Glaser, B.G., Strauss, A.L.: The Discovery of Grounded Theory: Strategies for Qualitative Research. Observations (Chicago, Ill.). Aldine de Gruyter (1967)Google Scholar

Copyright information

© Springer International Publishing Switzerland 2015

Authors and Affiliations

  1. 1.Leibniz University HannoverHannoverGermany

Personalised recommendations