When specifying user requirements, not only it is critical to ensure correct and unambiguous specification of functional requirements, but also that of non-functional requirements (NFRs). In fact, resolving ambiguities from user specified natural language NFRs and specifying the correct ones in a formal language have attracted significant attention. Our current research focuses on the issues pertaining the same. We observe that it is a usual practice for a user to narrate the NFRs in natural language and the requirement engineers manually try to express the same, using some semi-formal or formal language notations. However, inaccurate and the laborious manual approach may fail to detect all the NFRs and correctly remove the ambiguities in those detected. Hence, current research attempts have focused on automating the conversion of natural language NFRs to formal notations. In literature, there exist numerous approaches that take requirements as input and output the extended UML counterpart including NFRs. However, majority of the approaches do not support ambiguity resolution and verification of the extracted NFRs that are fairly essential. In this paper, we propose and discuss a hybrid approach viz. NFRs-Specifier, that attempts to resolve ambiguities, extract NFR's, perform verification and generate NFRs specification by means of the extended UML model.
Requirements Engineering (RE) is one of the most vital activities in the entire
software development life cycle [
The NFRs [
As per our literature survey, numerous approaches exist, that deal with NFRs
activities viz. elicitation, classification, verification and specification. Typically, users
and requirements engineers informally (manually) identify the NFRs from the
requirements documents using their experience and expertise [
Many researchers [
Models)
In support of the claims 1 and 2, authors [
We reiterate that it is error-prone to analyze a large set of software requirements and identify relationships amongst them - especially when using inaccurate, time consuming and laborious manual approach is employed. Obviously, expecting a user to specify the requirements in a formal language that is cryptic and that requires sophisticated skills is idealistic.
On the other hand, semi-formal approach (viz. natural language processing, machine learning, etc) helps to reduce human efforts in identifying and classifying NFRs from requirements documents accurately. The machine learning approaches viz. supervised/ semi-supervised and unsupervised provide an ease by classifying requirements without human expert. As compared to informal approaches, this approach is cheap, flexible and less labor intensive.
However, it is usually impossible to achieve accuracy and high performance
without a lot of training labeled data set. Again, the manual annotation process is time
consuming and error prone. Moreover, changes are inevitable in real world and hence
when there are changes in the domain, words/terms used in the requirements or the
writing style, there is an imminent need to retrain the machine [
After analyzing existing approaches/tools, we classify them in three categories viz. formal, informal and semi-formal. We observe that these approaches (viz. informal, semi-formal and formal) are not competitive, instead complementary. Furthermore, we observe that the informal approach mainly focuses on elicitation and specification of the NFRs. The semi-formal approach, focus on the classification of the NFRs and the formal methods (viz. Z notations [50], UML-B [51]) help for formal specification of the NFRs.
Our proposed approach viz. NFR-Specifier, mainly focuses on extracting all possible NFRs from requirements documents and provides specification after resolving ambiguity. To achieve this, we use a hybrid approach – combination of NLP, machine learning and ontology. 2
We propose a semi-automated approach called NFR-Specifier, aims to generate accurate specification from informal requirements including NFRs as shown in figure 1. The approach consists of five modules viz. preprocessing, ambiguity resolving, SRS ontology formation, UML diagram generation and NFRs classification. Initially, requirements engineer gathers domain knowledge from users by means of various communication approaches viz. questionnaires, interviews, checklist, prototyping, meetings, among others. Once the communication phase is over, the requirements engineer represents the collected information by means of a text files, documents, graphs or UML models (viz. use-case, class, sequence diagram). These initial requirements are ambiguous in nature.
The preprocessing module takes input as natural language requirements and
produces normalized natural language requirements. The module performs three tasks
viz. sentence splitting, Part-Of-Speech (POS) tagging and normalizing. It performs
syntactic reconstruction to split a complex sentence into simple sentences to extract
all possible information from the requirements document. We use the Stanford parser,
for lexical-syntactic analysis and WordNet [52] to determine context knowledge.
Each token is analyzed and classified into its respective POS (Part-Of-Speech)
classification viz. noun, verb, pronoun, adverb, helping-verb, adjective, prepositions,
etc. Furthermore, we use dependencies [53] (binary relations that give a grammatical
relation between a head and a dependent relative in a sentence) generated by the
Stanford parser to identify the semantic relationships between words. The normalizing
process also performs spelling and grammar checking. We perform a comparative
analysis of ambiguity (having more than one meaning to a word/sentence) resolving
approaches/tools [
Stanford Dependencies csubjpass (clausal passive subject); nsubj (nominal subject) nsubjpass (passive nominal subject); xsubj (controlling subject); dobj (direct object); iobj (indirect object), pobj (object of a preposition); acomp; advmod (adverbial modifier); amod (adjectival modifier), (String/number) (numeric modifier), npadvmod: noun phrase as adverbial modifier; aux: auxiliary; auxpass: passive auxiliary, complm: complementizer, rcmod: relative clause modifier; xcomp: openclausal complement).
Relationships between classes are extracted using the rules listed in table 2. requirements clustering based on noun. Here, we use hierarchical clustering [55]. In literature, we have identified various promising machine learning algorithms used for requirements classification [56-58]. We observe that the accuracy of machine learning algorithm depends on various factors such as feature selection, distance/similarity measures, dataset, among others [55, 57]. We provide flexibility to adjust classification parameters and to add/update/delete irrelevant requirement classes. Once we have functional grouping of the requirements based on nouns, we verify these requirements with the system generated use-case model as shown in fig. 1. The approach then extracts possible NFRs using pre-developed quality ontology based on specific parts of standard quality models using protégé tool. We apply classification to identify NFRs related requirements. The module takes normalized unambiguous requirements as an input and produces the NFRs classification using ontology and machine learning approach. The extracted NFRs are integrated with UML models viz. use-case diagram. We provide a generalized algorithm in figure 2 and a brief summary of each module in table 3.
A. Initial informal requirements B. Apply POS Tagging //Natural language processing C. Resolve coordination ambiguity (and, or, as well as, but not) D. Resolve Anaphora Ambiguity //Rule based a. Identify Anaphora ambiguity b. Identify Antecedent c. Avoid Non-anaphoric anaphora d. Generate suitable antecedent for anaphora//user input E. Create Software Requirements Specification Ontology a. Extract nouns from the requirements b. Group similar nouns based semantics and give generic name to them and create a hierarchy F. Apply requirements clustering//Machine learning a. Apply stop word removing and stemming b. Select feature (viz. noun, verb, adjective)//user input c. Generate distance/similarity measure matrix d. Group similar requirements in to a cluster G. Create UML Diagram a. Extract Class, Attributes and Methods b. Extract relationship among Classes c. Extract cardinalities d. Extract class diagram e. Extract actors and use-cases// //using Stanford Dependencies f. Generate Use-case Diagram H. NFRs Classification//using Ontology a. Identify NFRs using Quality Ontology b. Refine NFRs related requirements I. Integrate NFRs to the UML diagram
Fig. 2. Procedure: NFRs-Specifier
tagging, Normalizing Anaphora ambiguity (viz. -Stanford Parse event, verb, personal pronoun, -WordNet possessive pronouns, Wh- -NLP pronoun, Wh-adverb), -Heuristic Rules Coordination ambiguity and Attachment ambiguity rooBennaqttsooueilldrooeggmyyoennctsreparetebusiapldecsiofdifoctamwtiaaoirnne --APRrpuoplteréogbaéacstheodol ----pdIEEEeodxxxpsestttenrrrinaaabtidccclfeetttynRaOcsceyutvOloabeTrtajrsiebgocentn,sthpiohptobrajesicedtsenatinftdyo ---ADSRWtpeuaopplnererdfonobNadracdeeshtendcies identify possible use-cases -Stemming words -Extract nouns -Apply distance/similarity measures -Apply clustering algorithm
To generate the SRS ontology automatically we have used the pre-developed domain ontology as shown in figure 3. The partial output of the generated SRS ontology is shown in figure 4. We apply the hierarchical clustering and get the cluster as follows: 1. Cluster1 : R1, R2, R3 2. Cluster2 : R4, R6 3. Cluster3 : R5, R7, R8 Once the requirements are clustered, we verify these requirements with the generated use-case model as shown in figure 5.
Available 24 hours a day
Provide maximal security ATM_network
Using pre-developed quality ontology based on standard quality model, we extract the NFRs from the requirements viz. security, availability, performance and the relationship to the requirements as shown in table 5.
Execution time Response Time Usability Availability Security Authenticity Integrity Availability
Finally, the extended use-case model generated as shown in figure 6. ATM_network
Available 24 hours a day
Provide maximal security Provide Integrity
Provide
Authentication Fig. 6. Extended Use-Case Model Provide Confidentiality 4
The presented approach seems easy if human intelligence applies, but to make the process automated, requires a lot of training dataset and domain knowledge. Furthermore, the machine learning algorithms may not perform well if NFRs occur that are not relevant to the predefined category. In order to adapt the change in the application domain, the algorithms need to be re-trained and re-evaluated that again require manual efforts. On the other hand, to provide a complete and precise NFRs specification, we need to identify all possible NFRs conflicts as it may happen that one NFR affect (positively or negatively) other NFRs. To provide the conceptualization, it is required to identify the dependencies exist between NFRs. The NFRs provides constraints on FRs, thus the change in NFRs may cause the change in FRs. Though, we investigate the positive impact of combining rule based and machine learning approaches on classification of NFRs using quality ontology, we need to investigate the impact of hybrid clustering algorithms for classification of NFRs.
The correct and precise software requirements specification is required for the success of the software. If the requirements are not extracted and analyzed using an engineering approach, the errors that creep into the software are detected in the later stages of the software development, leads to higher costs for changes. In this paper, we present a hybrid approach that provides a specification of NFRs. It addresses the problems viz. normalizing, ambiguity resolving, requirements clustering, NFRs classification and verification using efficient natural language processing, a set of rules, ontology and machine learning approaches. After analyzing feasibility of the approach of case study, we conclude that the deployment of the approach in the RE practice would have a positive impact. 46. Lee, S.W., Muthurajan, D., Gandhi, R.A., Yavagal, D. and Ahn, G.J., ―Building decision support problem domain ontology from natural language requirements for software assurance,‖ International Journal of Software Engineering and Knowledge Engineering, vol. 16(06), pp.851-884, 2006. 47. Li, F.L., Horkoff, J., Mylopoulos, J., Liu, L. and Borgida, A., ―Non-Functional
Requirements Revisited,‖ In iStar, pp. 109-114, 2013. 48. Rashwan, A., Ormandjieva, O. and Witte, R., ―Ontology-based classification of nonfunctional requirements in software specifications: a new corpus and svm-based classifier,‖ In Computer Software and Applications Conference (COMPSAC), IEEE 37th Annual, pp. 381-386, 2013. 49. Jingbai, T., Keqing, H., Chong, W. and Wei, L., ―A context awareness non-functional requirements metamodel based on domain ontology,‖ In Semantic Computing and Systems, WSCS'08, IEEE International Workshop on, pp. 1-7, 2008. 50. Ledru, Yves, et al., "An attempt to combine UML and formal methods to model airport security," CAiSE Forum, 2006. 51. Snook, C. and Butler, M., ―UML-B: Formal modeling and design aided by UML,‖ ACM Transactions on Software Engineering and Methodology (TOSEM), vol.15(1), pp.92-122, 2006. 52. WordNet (2010) Princeton University [online] http://wordnet.princeton.edu/wordnet (accessed 27 November 2015). 53. De Marneffe, M.C., MacCartney, B. and Manning, C.D., ―Generating typed dependency parses from phrase structure parses,‖ InProceedings of LREC (Vol. 6, No. 2006, pp. 449454, 2006. 54. Unnati Shah and Devesh Jinwala (in Press), ―Resolving ambiguity in natural language specification to generate UML diagrams for requirements specification‖, In International Journal of Software Engineering, Technology and Applications, Inderscience. 55. Borgatti, Stephen P., "How to explain hierarchical clustering," pp.78-80, 1994. 56. Duan, Chuan, and Jane Cleland-Huang, "A clustering technique for early detection of dominant and recessive cross-cutting concerns," In Proceedings of the Early Aspects at ICSE: Workshops in Aspect-Oriented Requirements Engineering and Architecture Design, p. 1. IEEE Computer Society, 2007. 57. Li, Z., Rahman, Q.A. and Madhavji, N.H., ―An Approach to Requirements Encapsulation with Clustering,‖ In WER, pp. 92-96, 2007. 58. Belsis, P., Koutoumanos, A. and Sgouropoulou, C., ―PBURC: a patterns-based, unsupervised requirements clustering framework for distributed agile software development,‖ Requirements Engineering, vol. 19(2), pp.213-225, 2014.