Business Modeling with the Support of Multiple Notations in Requirements Engineering

Requirements specification should not be concerned only with the software specification, but should also be able to integrate with the organizational models describing the environment in which the system will function. Agent–oriented conceptual modeling notations such as i* represents an interesting approach for modeling early phase requirements which includes organizational contexts, stakeholder intentions and rationale. Business Process Modeling notations such as BPMN are used to effectively conceptualize and communicate important process characteristics to relevant stakeholders. On the other hand, Unified Modeling Language (UML) is suitable for later phases of requirement capture which usually focus on completeness, consistency, and automated verification of functional requirements for the new system. In this paper, we illustrate the use of a methodology that facilitate and support the combined use of notation for modeling requirement engineering process in a synergistic fashion in a complex project for a large government Department. The notations we used were i*, BPMN and UML Use Case

Embedding Requirements within the Model Driven Architecture

The Model Driven Architecture (MDA) brings benefits to software development, among them the potential for connecting software models with the business domain. This paper focuses on the upstream or Computation Independent Model (CIM) phase of the MDA. Our contention is that, whilst there are many models and notations available within the CIM Phase, those that are currently popular and supported by the Object Management Group (OMG), may not be the most useful notations for business analysts nor sufficient to fully support software requirements and specification. Therefore, with specific emphasis on the value of the Business Process Modelling Notation (BPMN) for business analysts, this paper provides an example of a typical CIM approach before describing an approach which incorporates specific requirements techniques. A framework extension to the MDA is then introduced; which embeds requirements and specification within the CIM, thus further enhancing the utility of MDA by providing a more complete method for business analysis

Do Process Modelling Techniques Get Better? A Comparative Ontological Analysis of BPMN

Current initiatives in the field of Business Process Management (BPM) strive for the development of a BPM standard notation by pushing the Business Process Modeling Notation (BPMN). However, such a proposed standard notation needs to be carefully examined. Ontological analysis is an established theoretical approach to evaluating modelling techniques. This paper reports on the outcomes of an ontological analysis of BPMN and explores identified issues by reporting on interviews conducted with BPMN users in Australia. Complementing this analysis we consolidate our findings with previous ontological analyses of process modelling notations to deliver a comprehensive assessment of BPMN

Requirements Engineering as Creative Problem Solving: A Research Agenda for Idea Finding

This vision paper frames requirements engineering as a creative problem solving process. Its purpose is to enable requirements researchers and practitioners to recruit relevant theories, models, techniques and tools from creative problem solving to understand and support requirements processes more effectively. It uses 4 drivers to motivate the case for requirements engineering as a creative problem solving process. It then maps established requirements activities onto one of the longest-established creative problem solving processes, and uses these mappings to locate opportunities for the application of creative problem solving in requirements engineering. The second half of the paper describes selected creativity theories, techniques, software tools and training that can be adopted to improve requirements engineering research and practice. The focus is on support for problem and idea finding - two creative problem solving processes that our investigation revealed are poorly supported in requirements engineering. The paper ends with a research agenda to incorporate creative processes, techniques, training and tools in requirements projects