How do Software Architects consider Non-Functional Requirements - An exploratory study
Upcoming SlideShare
Loading in...5
×
 

How do Software Architects consider Non-Functional Requirements - An exploratory study

on

  • 4,294 views

 

Statistics

Views

Total Views
4,294
Views on SlideShare
2,362
Embed Views
1,932

Actions

Likes
0
Downloads
53
Comments
0

8 Embeds 1,932

http://modeling-languages.com 1756
http://vu.paktutorial.com 157
http://www.twylah.com 10
http://translate.googleusercontent.com 3
http://131.253.14.66 2
http://www.vufacebook.com 2
http://www.linkedin.com 1
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    How do Software Architects consider Non-Functional Requirements - An exploratory study How do Software Architects consider Non-Functional Requirements - An exploratory study Presentation Transcript

    • How do Software Architects consider Non-Functional Requirements
    • Outline• Motivation and objective• Background• The study• Observations• Conclusions and related work 2
    • Motivation NFRs SA“the rationale behind each architecture decision ismostly about achieving certain NFRs” “[NFRs] play a critical role during system development, serving as selection criteria for choosing among myriads of alternative designs”“quality attribute requirements strongly influence asystem’s architecture” Little evidence from empirical studies support these statements 3
    • ObjectiveTo conduct an exploratory study to investigatethe following research question: How do software architects deal with NFRs in practice? 4
    • BackgroundReqs. structure Prd. managers Sw. architects + SLR in [Svensson ProgrammersArch. designRE activities Prj. leadesNFR types et al. 2010] Users Analysis Companies Interviews 5 Interviews 11 Interviews 2 e-Survey 25 e-Survey ? Questionnaire 15 Questionnaire ? Group discus. 10 Interviews 12 5
    • BackgroundObservations:• No clear view in NFR elicitation• Cost-driven NFR quantification• Role-dependent view on NFR type’s importance• Lack of knowledge about NFR management• Vagueness of NFRs• Difficulty to test NFRs• FRs still prevale• Need for more empirical studies 6
    • The Study• Type:  Exploratory study using qualitative research  Seven RQs• Target population:  Software architects (or practitioners with that role)  We invited 21 software organizations (Spain)  We recruited 12 of them 13 interviews made 7
    • The StudySCC: Software Consulting Company; SH: Software House; ITD: IT Department 8
    • The Study• Data collection:  Semi-structured interviews  Focus: one single project  Duration: ~1 hour • 7 questions about architect profile and development methodology used in the project • 10 questions about decision-making and NFRs  Audio-taped  Transcribed  Checked 9
    • The Study• Analysis:  Two authors coded data independently tabulation  Categories generation NVivo Software  Consolidation Group meetings  Presentation Counting technique 10
    • The Study• Limitations and mitigations:  Evaluation apprehension  Confidentiality  Understandability  Piloting (4)  Influential factors  Single project  Bad memory  Questionnaire sent in advance  The best project  Ask for the most familiar  Omitting data  Results overviewed by respondants  Researcher bias  Two separated interpretations  Generalize the findings  We do not attempt to make universal generalizations 11
    • Observations• RQ1: What is the role of the software architect?  Nobody had the “software architect” position  Nomination: (experience, tec. knowledge) > architect skills  12 played other roles played in the project: Project 3 Manager 4 Both 5 Developer 12
    • Observations• RQ2: Are there terminological confusions on NFRs?  Inability. “availability”, “accuracy”, “sustainability”  Confusion. “ergonomic” instead of “easy to use”  Incorrectness. “Maintainability is very important, because when something is working, we can’t make changes”  Worsened by the Spanish translation 13
    • Observations• RQ3: What types of NFRs are relevant to software architects? 10 9 8 49 Software qualities 7 6 5 4 Domain 3 Tacit 2 1 0 14
    • Observations• RQ3: What types of NFRs are relevant to software architects? 10 9 8 33 Non-technical reqts. 7 6 5 4 3 2 1 0 15
    • Observations• RQ4: How are NFRs elicited? User and Mainly 3 architect architect 10 Outsourced Projects  All architects considered elicitation as a gradual process… also never-ending 16
    • Observations• RQ5: How are NFRs documented? Plain text 1 No documentationSome kind 3 9of strategy “I rarely documentVolere my projects becauseISO/IEC 9126-based it costs money”Ad-hoc  Documentation not always evolved! 17
    • Observations• RQ6: How are NFRs validated?  NFRs had been met by the end of the project? Not “yes” 2 Yes 11“We wait for the Very vagueclient to complain” justifications 18
    • Observations• RQ6: How are NFRs validated?  What NFRs were validated? None Efficiency 1 Accuracy Usability Unknown 4 Reliability 8 19
    • Observations• RQ7: What type of tool support for NFRs is used?  Architects did not use any specific tool support for NFR management 20
    • Observations• RQ7: What type of tool support for NFRs is used?  What about NFR-driven MDD (cf. [Ameller RE’10]) Not answer 2 Not at allJust support 2 5 “I would not trust” 4 Not viable 21
    • Conclusions• Contributions  Corroborating previous evidences Architects… performed other activities simultaneously did not share a common vocabulary showed some misunderstandings and lack of knowledge considered performance and usability as most important mainly elicited NFRs iteratively more often than not, didn’t document validated just a few types were not enthusiastic about advanced tool support 22
    • Conclusions• Contributions  Finding previously unreported observations Architects… considered NTRs almost as important as quality reqts. mainly elicited NFRs by themselves claimed that NFRs were satisfied at the end of project did not use any specific tool for NFR management 23
    • Conclusions• Contributions  Finding some misalignments or even contradictions with previous studies Architects… did not exist as a differentiated role quantification of NFRs was poor 24
    • Conclusions• Future work  Replication; consolidation with other studies • E.g., study on OSS domain [REFSQ’12]  Changing the conditions • E.g., influence of an starting architecture (Ferrari et al, REJ10)• More research needed on:  Cost-benefit analysis (e.g., documentation)  Highly customizable NFR management (e.g., existence of architect role)  Exploring other communication channels (e.g., blogs) 25
    • Hope you liked it!