Reliability Measurement: From Theory to Practice
IEEE Software
The Top Risks of Requirements Engineering
IEEE Software
Representing and Using Nonfunctional Requirements: A Process-Oriented Approach
IEEE Transactions on Software Engineering - Special issue on knowledge representation and reasoning in software development
The cost of errors in software development: evidence from industry
Journal of Systems and Software
Software Architecture in Practice
Software Architecture in Practice
The Importance of Quality Requirements in Software Platform Development - A Survey
HICSS '01 Proceedings of the 34th Annual Hawaii International Conference on System Sciences ( HICSS-34)-Volume 9 - Volume 9
Goal-Oriented Requirements Engineering, Part II
RE '06 Proceedings of the 14th IEEE International Requirements Engineering Conference
IEEE Transactions on Software Engineering
Software architects' experiences of quality requirements: what we know and what we do not know?
REFSQ'13 Proceedings of the 19th international conference on Requirements Engineering: Foundation for Software Quality
The role of quality attributes in service-based systems architecting: a survey
ECSA'13 Proceedings of the 7th European conference on Software Architecture
| Hi-index | 0.00 |
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).