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.

Data‐Driven Elicitation, Assessment and Documentation of Quality Requirements in Agile Software Development

3 views

Published on

An Exploratory Paper on quality requirements management presented in CAiSe 2018 conference.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Data‐Driven Elicitation, Assessment and Documentation of Quality Requirements in Agile Software Development

  1. 1. Data‐Driven Elicitation, Assessment and  Documentation of Quality Requirements  in Agile Software Development An Exploratory Paper
  2. 2. 2 Motivation Steady increase in budget spent on dealing  with software quality Quality Requirements (QR): Representation of  quality conditions and compliance The software service shall provide optimal response time Once the user completes the request, logging into the system  should not take more than 3 seconds 95% of the time
  3. 3. 3 Motivation Steady increase in budget spent on dealing  with software quality Quality Requirements (QR): Representation of  quality conditions and compliance The support that software development  methodologies provide to QR management is  still limited (specially in rapid development)
  4. 4. 4 Research goal To formulate a tooled method  supporting the effective management  of QRs in rapid software development
  5. 5. 5 QR management in ASD: The Q‐Rapids approach
  6. 6. 6 Research Questions • RQ1. When is it necessary to improve some quality  concern of a software system? • RQ2. How can this need be expressed as a quality  requirement? • RQ3. How can the consequences of undertaking such  quality requirement be assessed? • RQ4. In case that a quality requirement is accepted,  how can it be added to the backlog? RQ1 RQ2 RQ3 RQ4
  7. 7. 7 Q‐Rapids Conceptual Architecture
  8. 8. 8 RQ1. Raising Alarms
  9. 9. 9 RQ2. Identifying Candidate QRs Pattern Keep Availability Level Goal To determine which is the appropriate availability  level for a given component of the system Bound to Reliability::Availability Template The <entity> shall have a minimal  availability rate of <availabilityLevel> Parameter functions cost(<availabilityLevel>)
  10. 10. 10 RQ3. Assessment  of QRs
  11. 11. 11 RQ4. Representation  of QRs  Generic Detailed Local User story Acceptance criteria Group‐wide Epic • User story • Acceptance criteria System‐wide Epic User story Behutiye, W. et al.: Non‐functional Requirements Documentation in Agile Software  Development: Challenges and Solution Proposal. QUASD@PROFES 2017.
  12. 12. 12 Example scenarios
  13. 13. 13 Scenario 1: Test Coverage • Addresses internal quality • Trigger: change of release time (from 4 to 3 weeks) • How does this change impact indicators as On‐time delivery and Product Quality? • It illustrates that expert knowledge is key in  generating new QRs
  14. 14. 14 Scenario 1: Test Coverage ACME changes release time from 4 to 3 weeks QR1 +  additional knowledge as QRs + prioritize test cases  with greater coverage QR1: The system shall have a test  coverage not lower than 70%
  15. 15. 15 Scenario 3: Usability • Addresses external quality • Trigger: new release in the market • How does this change impact indicators as Revenue? • It illustrates that correlations may be needed to find  candidate QRs
  16. 16. 16 Scenario 3: Usability ACME released a major update on the UI of their e‐commerce platform Runtime monitoring detects users getting stuck in a particular  step and quitting 90%  80% The ACME e‐commerce platform shall be supported by smartphone devices Correlation found with use of browser from smartphone
  17. 17. 17 Scenario 3: Usability ACME released a major update on the UI of their e‐commerce platform The ACME e‐ commerce platform shall be supported by smartphone devices US737: As a user, I want to be  able to use the e‐commerce  platform using my smartphone  in order to ensure user’s  experience for this kind of device Product backlog
  18. 18. 18 Preliminary Evaluation Use of the TAM evaluation questionnaire in one of the  Q‐Rapids consortium companies (Bittium Wireless Ltd.) In addition, qualitative feedback: • “when thinking about all possible scenario in real life,  quite a “machine” is needed!” • “digging deeper in the data manually” • “the third scenario is really genuine, if it works” Criteria R1 R2 R3 Perceived usefulness 6 5 7 Perceived ease of use 6 6 7 Output quality 7 6 7 Result demonstrability 5 6 7 Feasibility 7 5 6
  19. 19. 19 Discussion Data‐driven generation of quality requirements… a  vision… Data‐driven generation of quality requirements… a  vision… or a chimera? Current challenges: • How much automation is possible (cf. Scenario 1)? • How accurate can be:  The mappings from metrics to strategic indicators?  The cost functions in the requirement patterns? • What are the limits due to data privacy?
  20. 20. Data‐Driven Elicitation, Assessment and  Documentation of Quality Requirements  in Agile Software Development An Exploratory Paper

×