Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Non functional requirements documentation in agile software development profes

75 views

Published on

Conference presentation

Published in: Software
  • Be the first to comment

  • Be the first to like this

Non functional requirements documentation in agile software development profes

  1. 1. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 732253. Non-functional Requirements Documentation in Agile Software Development: Challenges and Solution Proposal Woubshet Behutiye1, Pertti Karhapää1, Dolors Costal2 Markku Oivo1, Xavier Franch2 1University of Oulu (Finland) 2 Universitat Politècnica de Catalunya (Spain)
  2. 2. Motivation Purpose Research approach Findings o Non-functional requirements documentation practices and challenges in ASD projects Guidelines o Guidelines Proposal for documenting NFRs in ASD Conclusion Outline
  3. 3. Why do we study Non-functional requirements (NFRs) Documentation in Agile software development (ASD)? o NFRs • Determinant for the success of software projects • Characterized as hard to define and vague • Often not documented or are underspecified o ASD • Focus on quick delivery of working software • Short iterations, minimal documentation Limitations of requirements engineering practices in ASD Significance of NFRs documentation in ASD Motivation
  4. 4. Purpose o Identify state of the practice of NFRs documentation practices and challenges in ASD o Propose guidelines for documentation of NFRs in ASD Purpose
  5. 5. NFRs documentation practices and challenges in ASD: state of the practice o Case studies o Qualitative analysis Research approach Use case Company size (based on number of employees) Software development methodology of the UC Role of interviewees (subjects) in the UC UC1 > 900 Agile Software architect /developer, project manager, project researcher UC2 > 600 Scrum Devops specialist, quality assurance engineer, software developer UC3 >100,000 Scrum Agile coach, product owner, project manager, requirements manager UC4 < 100 Scrum Scrum master/ Product owner, Software architect
  6. 6. UC NFRs documentation practice NFRs documentation challenge UC1 not formally documented, communicated through white board and when necessary documented in word documents NFRs not documented properly and resulted in the lack of traceability of NFRs, difficulty for new developers joining team UC2 Epics, features, and user stories, acceptance criteria and Definition of Done (DoD), wiki pages, word docs Lower-level details are lost in documentation, word and power point documents disconnected from actual software Results
  7. 7. UC NFRs documentation practice NFRs documentation challenge UC3 Features, acceptance criteria and DoDs in complex backlogs Complexity of backlogs makes it hard to identify dependent NFRs, internally generated NFRs are not documented UC4 Epics, user stories, in DoD and acceptance criteria (at user story, task and ticket levels), in product and sprint backlogs. Mockups, wireframes, word, spreadsheet are also used for documenting NFRs while Whiteboards and flip charts facilitate communication of NFRs. Not reported Results
  8. 8. Assumptions: 1. Functional requirements are specified using both epics and user stories 2. User stories may include one or more acceptance criteria 3. User stories will be derived from epics and this link will be recorded NFRs variation o Scope: quality properties for a particular service, function or system component • Local: NFRs applying to a single user story (or functionality) • group-wide: NFRs applying to a set of user stories (or a group of functionalities) • system-wide: NFRs applying to the entire system o Level of detail: • generic NFRs specified at a high level of abstraction • detailed NFRs concrete feature or tied to a concrete solution. Guidelines proposal for Documenting NFRs in ASD: approach
  9. 9. Scope Detail Representation artefact Observation Local Generic User story (NFR user story) With a link to the functional user story to which it applies Detailed Acceptance criteria Appearing in the functional user story to which it applies Group wide Generic Epic The description of the epic must clarify to which group of functionalities it applies (e.g. “critical functions of the system”) Detailed (1) User story or (2) Acceptance criteria (1) The description of the user story must clarify to which group of functionalities it applies or include links to the user stories it applies (2) Appearing in the functional user stories to which it applies System wide Generic Epic The description of the epic must clarify it is system-wide (e.g. by referring to “the system”) Detailed User story The description of the epic must clarify to which group of functionalities it applies (e.g. “critical functions of the system”) Guidelines proposal for Documenting NFRs in ASD
  10. 10. Local and generic NFR: o “The functionality for checking the account balance must have a good response time” Group-wide and detailed o “The critical functions of the system must take less than 0.25 s, 90% of the times” Guidelines example
  11. 11. NFRs documentation practices in ASD projects • NFRs are documented together with functional requirements • UCs applied epics, features, user stories, acceptance criteria and DoD of user stories, and backlogs to document NFRs • Whiteboard and flip charts are used to facilitate the communication of NFRs in cases where they are not documented o Challenges • difficulty in the traceability of NFRs • problems in identifying interdependent NFRs • Detached documentation from actual software, were among the challenges of NFRs identified in the UCs Conclusions
  12. 12. Guidelines proposal • Diversity of NFRs: Scope and detail • ASD artefacts such as epics, user stories and acceptance criteria for documenting NFRs Future work o Implementation and empirical evaluation of the guidelines Conclusions
  13. 13. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 732253. Thank you!!!

×