TY - GEN
T1 - How architects see non-functional requirements
T2 - 18th Working Conference on Requirements Engineering: Foundation for Software Quality, REFSQ 2012
AU - Poort, Eltjo R.
AU - Martens, Nick
AU - Van De Weerd, Inge
AU - Van Vliet, Hans
PY - 2012/3/21
Y1 - 2012/3/21
N2 - This paper presents the analysis and key findings of a survey about dealing with non-functional requirements (NFRs) among architects. We find that, as long as the architect is aware of the importance of NFRs, they do not adversely affect project success, with one exception: highly business critical modifiability tends to be detrimental to project success, even when the architect is aware of it. IT projects where modifiability is perceived to have low business criticality lead to consistently high customer satisfaction. Our conclusion is that modifiability deserves more attention than it is getting now, especially because in general it is quantified and verified considerably less than other NFRs. Furthermore, IT projects that applied NFR verification techniques relatively early in development were more successful on average than IT projects that did not apply verification techniques (or applied it relatively late in development).
AB - This paper presents the analysis and key findings of a survey about dealing with non-functional requirements (NFRs) among architects. We find that, as long as the architect is aware of the importance of NFRs, they do not adversely affect project success, with one exception: highly business critical modifiability tends to be detrimental to project success, even when the architect is aware of it. IT projects where modifiability is perceived to have low business criticality lead to consistently high customer satisfaction. Our conclusion is that modifiability deserves more attention than it is getting now, especially because in general it is quantified and verified considerably less than other NFRs. Furthermore, IT projects that applied NFR verification techniques relatively early in development were more successful on average than IT projects that did not apply verification techniques (or applied it relatively late in development).
KW - Empirical Software Engineering
KW - Modifiability
KW - NFR
KW - Requirements Management
KW - Software Architecture
KW - Software Project Management
UR - http://www.scopus.com/inward/record.url?scp=84858316750&partnerID=8YFLogxK
U2 - 10.1007/978-3-642-28714-5_4
DO - 10.1007/978-3-642-28714-5_4
M3 - Conference contribution
AN - SCOPUS:84858316750
SN - 9783642287138
T3 - Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)
SP - 37
EP - 51
BT - Requirements Engineering
Y2 - 19 March 2012 through 22 March 2012
ER -