Non-functional requirements elicitation from business process models

Evaluation category

Abstract: Non-Functional Requirements (NFRs) elicitation is a critical stage in software development. Currently there are incipient advances aimed to the NFRs systematic elicitation. This article presents a proposal for the NFRs elicitation from business process models existing in organizations. The main contribution of the approach is to assist the requirements engineer in the systematic NFRs elicitation process using heuristics and templates, designed for this purpose, and organizational knowledge existing in the form of business process models.

Section III describes the proposal and Section IV considers the conclusions and future work. II. RELATED WORK

Keywords: Requirements elicitation, non-functional requirements elicitation, software engineering, business models reuse. I. INTRODUCTION

Recent advances in Information and Communication Technologies (ICTs) generate important challenges to the software engineering domain. Specifically, increased development of e-commerce, social networks and internet based systems makes necessary to put more attention to the NFRs as a condition to assure the systems success. On the other hand, as a strategy to cope with demands of an increasingly competitive environment, companies seek the improvement and certification of their processes often adopting quality assurance standards among which ISO 9001 [1] and EFQM [2] stand out. These standards require the documentation of the processes using for it natural language and languages established for this purpose like UML [3] or BPMN [4] among others. Once specified, the models of organizational processes become knowledge assets that can be used for improving business competitiveness such as reengineering and processes management. Although this knowledge is widely used in business tasks such as the previously mentioned, according to the available information, the direct use of process models in software development activities is incipient. In particular, nowadays the requirements elicitation highly depends on the engineers experience and proposals to assist him are required. In this sense, we introduce an approach whose main contribution precisely consists in set out a guide to facilitate the early and systematic NFRs elicitation directly from business process. Another remarkable aspect of the proposal consists in the heuristics and templates that allow the use of organizational knowledge, represented in business process models, for achieving this goal. This paper is organized as follows: Section II presents the related work,

Requirements treatment in software engineering domain has been subject of multiple works in recent years. Most of them are dedicated to FRs while NFRs have received less attention in spite of their acknowledged impact in software quality [5], [6], [7], [8], [9], [10], [11], [12]. Some approaches, such as [13], discuss the NFRs nature. Other proposals emphasize in software development processes based on NFRs treatment; some of them are [11], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24]. Proposals like [3], [4], [14], [19], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [36], [37], [38], [39], [40] deal with NFRs modeling. Our main interest is the NFRs elicitation; in the sequel, in agreement with the available information, the most relevant works in this category are presented. NFRs describe important restrictions that must be considered in software development. They correspond to a wide set of attributes like security, performance, portability, among others. These attributes play a critical role in the design phase and therefore they must be considered and specified as soon as it is possible during analysis phase of the system [25], [41]. In general, approaches proposed for NFRs elicitation use particular frameworks to classify the requirements corresponding to their specific interests [11]. Frequently, these works are based in creative brainstorming or use checklists and NFRs templates to guide the stakeholders inputs. For example, win-win methods [42] provide generic checklists and require that stakeholders prioritize and negotiate the NFRs perceived as important to the system success. The Architectural Assessment Method (ATAM) models NFRs using utility trees in which stakeholders describe quality requirements in a high level hierarchy of goals [43]. The NFR framework provides categories to support the analyst in NFRs definition as quality goals [18]. Other studies start from business processes to elicitate the NFRs implicit in business process models [35]. Cysneiros [36], [44] uses the i* framework to model softgoals such as the response time. Observing that softgoals are qualitative in nature, the author argues some ideas about how to map i* models to BPMN with the purpose of elicit these restrictions. Urrego [11] proposes a NFRs taxonomy, which facilitates the systematic elicitation of NFRs. Cleland-Huang [41] makes a proposal to the automatical detection of NFRs named NFR-classifier using a classification algorithm, which establishes the NFRs candidates from structured and unstructured documents. NFRs candidates are evaluated by the

analyst to determine their correctness. The method assumes that the different types of NFRs are characterized by the use of distinct words called indicator terms. Thus, the algorithm look for these indicator terms in documents obtaining a list of NFRs candidates. Hepp [38] proposes an enterprise rules and constraints ontology to support the constraints identification which can lead to NFRs. Pavlovski [25] suggests a BPMN extension that allows modeling business constraints and operational qualities (NFRs), to be identified during the earlier requirements elicitation phase. In addition, the author proposes a high level NFRs classification called operating conditions and a process that aids to the NFRs identification establishing types of pertinent restrictions for a business process. This author also proposes BPMN extensions to model these high level NFRs as a sort of operation conditions and operation control mechanisms denominated control case. Although these approaches facilitate the NFRs elicitation, research in these requirements engineering (RE) task remains being a priority. Particularly, proposals dealing with the NFRs elicitation in early stages of the software development process are required [12]. III. NFRS ELICITATION FROM BUSINESS PROCESS MODELS

Integrity: Accuracy, completeness Availability [31]

Simplicity, precision, consistency, scalability, operability, productivity, robustness and conciseness [48]

The NFRs elicitation process meta-model, depicted in Fig. 1, provides the concepts that govern the approach.
Agent Task

Activity ASM Condition Input Output Business Rule Guides

NFRs elicitation process Guides NFRs taxonomy

The proposal takes business processes, represented as Abstract Service Models (ASMs) [45], and a NFRs taxonomy as inputs. The process is guided by the categories of elements that comprise the ASM (activities, tasks, business rules, conditions, inputs and outputs) and the ISO NFRs taxonomy [46]. The NFRs ISOs taxonomy attributes are: Functionality: Suitability, security, compliance. accuracy, interoperability,

Figure 1. NFRs elicitation process meta-model.

Efficiency: Time, resource, compliance. Reliability: Maturity, fault to tolerance, recoverability, compliance. Usability: Understandability, learnability, operability, attractiveness, compliance. Maintainability: Analyzability, changeability, stability, testability, compliance. Portability: Adaptability, installability, replaceability, compliance. co-existence,

The same models and methods used in Functional Requirements Elicitation explained in [45] are replicated for obtaining the NFRs. In this way, FRs and NFRs may be elicited systematically in the same requirements analysis process. On the other hand, in recent years the i* approach stands out as one of the most relevant proposals to assist the analyst in requirements elicitation. This framework offers models to support the answer to questions like why the system is needed? and how the intended system would meet organizational goals? through its Strategic Dependency Model and Strategic Rationale Model respectively [44]. Our proposal extends these questions introducing other ones of the type what?, why?, what for? and how?, which contribute to requirements elicitation and to establish their alignment with business goals. Introducing the what for? question imply, in agreement with Cambridge [49] and Oxford [50], recognition that it could means for what purpose or reason; meanwhile, the why? question means for what reason. Since reasons are obtained responding the why? question; when we will reference the what for? question it will be only in its for what purpose sense. Differentiation between the reasons (why?) and the purpose or intention (what for?) will allow the analyst to establish relations among causes or reasons and the purpose or intention. For instance, the verification of whether or not the purpose accomplishment satisfies the user needs. Aiming to discover NFRs, taking the ASM elements and NFRs taxonomy as inputs, the following templates of questions are proposed:

This taxonomy is suitable for our purpose due its categories; nevertheless, since their attributes are insufficient [47], we have improved its coverage with elements proposed by Yu [31] and Urrego [48] as follows: Performance Space: Main memory, secondary storage Cost User friendliness Security Confidentiality

- What business restrictions or operation conditions, in relation to the <NFRs taxonomy element> and the <ASM element>, needs the <Main agent> that must be accomplished by the system? - Why business restrictions or operation conditions of the system, in relation to the <NFRs taxonomy element> and the <ASM element>, are needed for the <Main agent>? - What for business restrictions or operation conditions of the system, in relation to the <NFRs taxonomy element> and the <ASM element>, are needed for the <Main agent>? - How business restrictions or operation conditions of the system, in relation to the <NFRs taxonomy element> and the <ASM element>, are needed for the <Main agent>? As an example, in Fig. 2 an ASM corresponding to the banking process to transfer money is introduced from the Functional Requirements elicitation proposal presented in [45]. From this model the system requirements will be elicited.
1. To validate account = {Enter(origin account),} 2. To verify balance = {Enter(amount), } + Condition (Is valid?) + Business Rule (Minimum balance must be >= 10,000)

Customer <Agent instance>

ASM <to transfer money process instance> Guides Guides NFRs elicitation process <Banking system instance>

To validate account <Activity instance>

Confidentiality <NFRs taxonomy instance> Figure 3. NFRs elicitation process meta-model instantiation for the Banking process: to transfer money example.

Templates used to elicit the systems NFRs from business processes are presented in Table I. First column corresponds to the Main Agent, responsible agent for actions expressed by the verb, of each process. Second one correspond to the elements taken from the NFRs taxonomy which along with the ASMs elements, located in column three, guide the analyst in the NFRs elicitation process. Column four contains the questions to be solved by analyst and verified with the Main Agent. These questions are based in ASM and NFRs taxonomy elements appearing in the previously described templates. The analyst must respond to the questions considered in column 4 of Table I. The answers to these questions, exposed in column 5, constitute the systems NFRs which must be assured by the ongoing system as responsible agent of them.
TABLE I. NFR ELICITATION PROCESS: TEMPLATES OF QUESTIONS FOR THE BANKING PROCESS TO TRANSFER MONEY EXAMPLE.

Customer

3. To verify destiny account = {Enter (destiny account), }

Cashier

Main Agent Customer

4. To credit destiny account (destiny account, amount) 5. To debit origin account (origin account, amount) 6. To make the receipt (origin account, destiny account, amount) 7. To verify transaction (receipt) Figure 2. ASM of the Banking process: to transfer money.

FR taxonomy element Confidentia lity

ASM element To validate account <Activity>

Question

Answers to the question The needs so that: - The destiny account must be registered in the authorized customer accounts. Only the can customer final results. - The system must be able to identify the customer the

What business restrictions conditions, in relation to tiality and validate account activity, needs the customer that must to the confidenor operation

system support

With the purpose to illustrate how the NFRs elicitation process is carried out, for sake of space, the questions will be solved only for to validate account and confidentiality elements belonging to the ASM and NFRs taxonomy respectively. Nevertheless, we must consider that this approach consists in the systematic use of all ASM and NFRs taxonomy elements in requirements discovering. In fig. 3 an instantiation of the metamodel corresponding to the NFRs elicitation process for the Banking system example is presented.

know partial or operation

be accompli shed the system? by

customer unequivocally. - The customer must be able to identify unequivocally the system (to know that it is not a fake site). - The customer must be able to access the system 24x7 (24 hours per day, seven days per week). - The customer must be able to access system matter geographical location. . profiles Multiple and the no his

Customer

Confidentia lity

To validate account <Activity>

What for business restrictions or operation conditions of the system, in relation to the confidentiality and to validate account activity, are needed for the customer?

The customer needs the system support for/to: - Save time and money. - Improve his business opportunities. - Have a better availability his resources. - Increase his confidence the electronic transactions. - Improve his service quality perception. in banks of

Customer

Confidentia lity

To validate account <Activity>

responsibility levels must be included customer Customer Confidentia lity To validate account <Activity> Why business restrictions or operation conditions of the system, in relation to the confidentiality and to validate account activity, are needed for the customer? operations. The customer needs the system support because: Requires ensuring his data privacy. Needs to orient his operations towards the web. Requires expanding and diversifying his operations. Needs to incorporate massively and opportunely the Information and Communication Technologies (ICTs) advances. in

How business restrictions or operation conditions of the system, in relation to the confidentiality and to validate account activity, are needed for the customer?

The customer needs that the system contribute through: - Its availability in different devices such as ATMs, computers, cell phones, television and all kind of mobile devices. - Its availability in different places like banks, homes and commerce places. - Incorporating reliable and proved communication technology. Making explicit security features and customer procedures. - Introducing an audit plan. - Satisfying on line customer claims.

The previous example shows an important set of pertinent NFRs obtained using the proposed template of questions instantiated from the ASM diagram, representing the business process, and the NFRs taxonomy. The quantity and pertinence of requirements obtained in all processes involved in bank

money operations satisfy the exigencies for constructing the system and let confirm the efficacy in discovering systems NFRs from business processes. IV. CONCLUSIONS AND FUTURE WORK

The presented approach guides for systematic requirements discovering from business processes, in early stages of system development. The proposal goes beyond questions what?, why?, and how?, used in other works such as i*, introducing the what for? question. The proposed treatment of these questions leads to more explicit and detailed answers. The systematic use of agent interactions and NFRs taxonomy guides for discovering pertinent requirements. The proposed questions template can be instantiated with other agent interactions, processes and quality features. The efficacy of the approach was proved in a case study related to banking processes. In one ongoing work the approach integrates functional and non-functional requirements elicitation. The extension of the approach for including business rules treatment and the alignment of requirements with organizational objectives, mission and vision, is considered. REFERENCES
[1] International Organization for Standardization (ISO), Quality Management Systems, 2001. [2] European Foundation for Quality Management (EFQM), The EFQM Excellence Model, In http://www.efqm.org, [November 21, 2010]. [3] Object Management Group (OMG), OMG Unified Modeling Language Specification, In: http://www.omg.org/UML/, [November 21, 2010]. [4] Object Management Group (OMG), Business Process Modeling Notation Specification, In: http://www.omg.org/spec/BPMN/, [November 21, 2010]. [5] F. P. Brooks Jr., "No Silver Bullet: Essences and Accidents of Software Engineering", IEEE Computer Apr. 1987, No. 4 pp:10-19, 1987. [6] A. Davis, "Software Requirements: Objects Functions and States", Prentice Hall, 1993. [7] K. Breitman, J. C. S. d. P. Leite and A. Finkelstein, The World's Stage: A Survey on Requirements Engineering Using a Real-Life Case Study, Journal of the Brazilian Computer Society, No. 1 Vol. 6 Jul. 1999 pp:13:37. [8] L. M. Cysneiros and J. C. S. d. P. Leite, Integrating Non-Functional Requirements into data model, 4th International Symposium on Requirements Engineering Ireland, June 1999. [9] L. M. Cysneiros and J. C. S. d. P. Leite, Using UML to Reflect NonFunctional Requirements, 2001, In: http://www.math.yorku.ca/~cysneiro/articles/Cascon.pdf, [November 21, 2010]. [10] A. Borg, Non-functional requirements: Real-world problems vs. Literature, International workshop on requirements engineering for software quality, (REFSQ 03), 2003. [11] G. Urrego, Reasoning non-functional goals and features in web systems, Universit Paris I Panthon-Sorbonne, Centre de Recherche en Informatique, Paris France, 2005. [12] C. Salinesi, Ch. Marhold, C. Rohleder and J. Doerr, Clarifying nonfunctional requirements to improve user acceptance experience at Siemens, Siemens PL (DE) GmbH, Lina-Ammon-Strasse 22, D-90471 Nuremberg, CRI - Universit Paris 1, 90, rue de Tolbiac, F-75013 Paris, Fraunhofer Institute Experimental Software Engineering, D-67663 Kaiserslautern, 2009, In: http://crinfo.univ-paris1.fr/php/administration/fichier/616REFSQ09.pdf, [November 21, 2010]. [13] M. Glinz, On Non-Functional Requirements, International Conference on RE, 2007. [14] J. Mylopoulos, L. Chung and A. Nixon, Representing and using NFR: A process-oriented approach, IEEE transactions on software engineering, Special issue on knowledge representation and reasoning in software development, Vol. 18, No. 6, June 1992, pp 483-497.

[15] A. Dardenne, A. V. Lamsweerde and S. Fickas, Goal directed requirements acquisition, Science of computer programming, 20, Elsevier, 1993, Pp 3-50. [16] L. Chung, Representing and using non-functional requirements: A process oriented approach, Ph. D. Thesis, Dept. of Comp. Sci. University of Toronto, June 1993. [17] E. Yu, Modeling strategic relationships for process re-engineering, Ph. D. Thesis, Dept. of Comp. Sci. University of Toronto, Dec. 1994. [18] L. Chung, A. Nixon, E. Yu and J. Mylopoulos, Non-functional requirements in software engineering, Kluwer academic publishers, Boston, 2000. [19] L. M. Cysneiros, J. C. S. d. P. Leite and J. d. M. S. Neto, A framework integrating non-functional requirements into conceptual models, Requirements engineering journal, Vol. 6 No. 2, April 2001, pp 97-115. [20] P. Donzelli and P. Bresciani, Improving requirements engineering by quality modelling, International workshop on requirements engineering for software quality (REFSQ 03), 2003. [21] A. I. ANTN AND J. B. EARP, REQUIREMENTS TAXONOMY TO REDUCE WEBSITE PRIVACY VULNERABILITIES, REQUIREMENTS ENGINEERING JOURNAL, SPRINGER-VERLAG, 2003. [22] D. Bolchini and P. Paolini, Goal driven requirements analysis for hypermedia-intensive web applications, 2003. [23] B. Pernici and M. Scannapieco, Data quality in web information-systems, 2003. [24] M. Scanapieco, V. Mirabella, M. Macella and C. Batini, Data quality in e-business applications, 2003. [25] Ch. Pavlovski and J. Zou, Non functional requirements in business process modeling, IBM Corporation, Australian Computer Society, 5th AsiaPacific Conference on Conceptual Modelling (APCCM), 2008, In: http://crpit.com/confpapers/CRPITV79Pavlovski.pdf, [November 21, 2010]. [26] L. Chung and A. Nixon, Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach, Proc. of IEEE 17th International Conference on Software Engineering,Seattle, USA, 25-37, 1995. [27] P. Bresciani and P. Giorgini, The TROPOS Analysis Process as Graph Transformation System, Proc. of the OOPSLA Workshop on Agent-Oriented Methodologies (AOM-2002), Seattle, USA, 1-12, 2002. [28] R. Lu, S. Sadiq, V. Padmanabhan and G. Governatori, Using a Temporal Constraint Network for Business Process Execution, Proc. of 17th Australasian Database Conference, Hobart, Australia, 49:157166, ACM Conference Series, 2006. [29] M. Rosemann, J. Recker, C. Flender and P. Ansell, Understanding Context-Awareness in Business Process Design, Proc. of the 17th Australasian Conference on Information Systems, Australia Association for Information, Adelaide, Australia, 2006. [30] L. Chung, A. Nixon and E. Yu, Dealing with Change: An approach Using Non-Functional Requirements, Proceedings of the Second International Symposium on Requirements Engineering, York, England, Springer Verlag London Limited, Requirements Engineering Journal, p. 238-260, 1996. [31] L. Chung, A. Nixon, E. Yu and J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, Boston, 2000. [32] J. Castro, M. Kolp and J. Mylopoulos, Towards Requirements-Driven Software Development Methodology: The Tropos Project, Information Systems, 2002. [33] B. Gonzlez-Baixauli, J. C. S. d. P. Leite and J. Mylopoulos, Visual Variability Analysis for Goal Models, Requirements Engineering Conference, 198-207, 2004. [34] B. Gonzlez-Baixauli, M. A. Laguna and J. C. S. d. P. Leite, A Metamodel to Support Visual Variability Analysis, First International Workshop on Variability Modelling of Software-intensive Systems, Limerick, Ireland, 2007. [35] O. Demirors, C. Gencel and A. Tarhan, Utilizing Business Process Models for Requirements Elicitation, Proc. of 29th Euromicro Conference: New Waves in Systems Architecture, 409-412, IEEE Computer Society, 2003. [36] L. M. Cysneiros and E. Yu, Addressing Agent Autonomy in Business Process Management with Case Studies on the Patient Discharge Process, Proc. Of the Information Resources Management Association Conference, New Orleans, USA, 2004. [37] S. Gorton and S. Reiff-Marganiec, Towards a Task-Oriented, PolicyDriven Business Requirements Specification for Web Services, Proc. of 4th

International Conference on Business Process Management, Vienna, Austria, 465-470, 2006. [38] M. Hepp and D. Roman, An Ontology Framework for Semantic Business Process Management, Proc. of International Conference on Wirtschaftsinformatik (Commercial Informatics), WI, Karlsruhe, Germany, 2007. [39] J. Recker, M. Indulska, M. Rosemann and P. Green, How Good is BPMN Really? Insights from Theory and Practice, Proc. of the 14th European Conference on Information Systems, Goeteborg, Sweden, pp. 1582-1593, 2006. [40] M. Pesic and W. M. P. van der Aalst, A Declarative Approach for Flexible Business Processes, In Workshop on Dynamic Process Management (DPM2006), LNCS, Vienna, Austria, 4103:169-180, Springer-Verlag, 2006. [41] J. Cleland-Huang, R. Settimi, X. Zou and P. Solc, The detection and classification of non-functional requirements with application to early aspects, Center for Requirements Engineering, School of Computer Science, Telecommunications and Information Systems, DePaul niversity, In 14th IEEE International Requirements Engineering Conference (RE06), 2006, In: http://promisedata.org/pdf/re2006ClelandHuang.pdf, [November 21, 2010]. [42] H. In and B. W. Boehm, Using Win-Win Quality Requirements Management Tools: A Case Study, Annals Software Eng. 11(1): 141-174, 2001. [43] R. Kazman, M. Klein and P. Clements, ATAM: Method for Architecture Evaluation, CMU/SEI Technical Report, CMU/SEI-2000-TR-004, ADA382629, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000, In: http://www.sei.cmu.edu/publications/documents/00.reports /00tr004.html, [November 21, 2010]. [44] E. Yu, Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering, Proc. of the 3rd IEEE International Symposium on Requirements Engineering, 226-235, 1997. [45] A. F. Jaramillo, G. Urrego and C. Rolland, Software requirements elicitation from business process models, Submitted to RCIS 2011, Fifth IEEE International Conference on Research Challenges in Information Science, May 19-21 2011, Guadeloupe - French West Indies, France, unpublished. [46] International Organization for Standardization (ISO), ISO/IEC 9126-1, Software engineering product quality part 1: Quality model, 2001. [47] H. Kaiya, A. Osada and K. Kaijiri, Identifying stakeholders and their preferences about NFR by comparing use case diagrams of several existing systems, Dept. of Computer Science, Shinshu University, Japan, In Proceedings of the 12th IEEE International Requirements Engineering Conference (RE04), 2004. [48] G. Urrego, ABC-Besoins: Une approche dingnierie de besoins fonctionnels et non-fonctionnels centre sur les Agents, les Buts, et les Contextes, Ph. D. Thse, Centre de Recherche en Informatique, Universit Paris I Panthon Sorbonne, 2005. [49] Cambridge International Dictionary of English, Cambridge University Press, University of Cambridge, London, 1995. [50] Oxford Essential Dictionary, Oxford University Press, 2009.