ORIGINAL ARTICLE Automated classification of non-functional requirements Jane Cleland-Huang Æ Raffaella Settimi Æ Xuchang Zou Æ Peter Solc Received: 3 November 2006 / Accepted: 22 February 2007 / Published online: 23 March 2007 Ó Springer-Verlag London Limited 2007 Abstract This paper describes a technique for automat- ing the detection and classification of non-functional requirements related to properties such as security, per- formance, and usability. Early detection of non-functional requirements enables them to be incorporated into the initial architectural design instead of being refactored in at a later date. The approach is used to detect and classify stakeholders’ quality concerns across requirements speci- fications containing scattered and non-categorized requirements, and also across freeform documents such as meeting minutes, interview notes, and memos. This paper first describes the classification algorithm and then evalu- ates its effectiveness through reporting a series of experi- ments based on 30 requirements specifications developed as term projects by MS students at DePaul University. A new and iterative approach is then introduced for training or retraining a classifier to detect and classify non-func- tional requirements (NFR) in datasets dissimilar to the initial training sets. This approach is evaluated against a large free-form requirements document obtained from Siemens Logistics and Automotive Organization. Although to the NFR classifier is unable to detect all of the NFRs, it is useful for supporting an analyst in the error-prone task of manually discovering NFRs, and furthermore can be used to quickly analyse large and complex documents in order to search for NFRs. Keywords Non-functional requirements  Quality requirements  Classification  Early aspects 1 Introduction Non-functional requirements (NFR) describe important constraints upon the development and behaviour of a software system. They specify a broad range of qualities such as security, performance, availability, extensibility, and portability. As these qualities play a critical role in driving architectural design [1] they should be considered and specified as early as possible during system analysis. Unfortunately NFRs are often discovered in an ad-hoc fashion relatively late in the development process. In a recent review we conducted of 15 publicly available soft- ware requirements specifications (SRS) [2], we found an almost universal lack of any requirements describing non- functional qualities. This suggests that developers may fail to appreciate the importance of specifying NFRs or may falsely assume them to be implicitly understood and agreed upon by all stakeholders. Despite a lack of emphasis on NFRs, stakeholders’ quality concerns are often collected as a by-product of the requirements elicitation process and documented across a range of artefacts including memos, interview notes, and meeting minutes. Resulting requirements specifications tend to be organized by functionality, with non-functional requirements scattered widely across multiple documents. J. Cleland-Huang (&)  R. Settimi  X. Zou  P. Solc Center for Requirements Engineering, School of Computer Science, Telecommunications, and Information Systems, DePaul University, 243 S. Wabash Avenue, Chicago, IL 60604, USA e-mail: jhuang@cs.depaul.edu R. Settimi e-mail: rsettimi@cs.depaul.edu X. Zou e-mail: xzou@cs.depaul.edu P. Solc e-mail: petersolc@hotmail.com 123 Requirements Eng (2007) 12:103–120 DOI 10.1007/s00766-007-0045-1