Deriving Use Cases from Business Processes

Where do goals come from: the underlying principles of goal-oriented requirements engineering

“…Shishkov et al [16] in particular have proposed a method for deriving use cases and goals through a semiotic-based norm analysis. However, Organizational Semiotics has not been further linked to GORE methods.…”

Regulation, the Invisible Part of the Goal Oriented Requirements Engineering Iceberg

“…(Weinberg, 1975), (Weinberg and Weinberg, 1988), (Ashby, 1956). Organizational Semiotics can also be useful because it is the study of norms in organizations (Chong and Liu, 2002), (Shishkov, Xie, Liu, Dietz, 2002).…”

Analysis of Interactive Information Systems Using Goals

“…These techniques are: UML (Object Management Group, 2003) that provides the modeling notation; Wisdom (Nunes, 2001) that provides the basic concepts for the RE process, by means of the "Requiremens Workflow"; the High-Level Concept (Kreitzberg, 1999) a concept used in PUC without changes; the Business Process Model (Eriksson & Pencker, 2001) that provides the (adapted) notation used in PUC for modeling BPs and their interaction with users and information, and Usage-centered design (Constantine, 2006) that provides the definition of (essential) use case and the basis for the definition of actor. The following RE related works also identify use cases as a result of the analysis of business processes: (González & Díaz, 2007) proposes an extensive approach which defines business strategy, business and IT infrastructure to produce a Business Process Goal Tree from which the goals that need automation (use cases) are derived; (Shishkov & Dietz, 2005) that derives use cases from the description of business processes based on the construction of norm sentences; Usage-centered design (Constantive, 2006) that represents the relevant activities (BPs) and interrelationships among them (Activity Map), caracterizes each activity (Activity Profiles) and identifies each participant (Participation Map) and their relationships with each other and with the various artifacts involved in the activity, and then extracts (ActivityTask Map) the task cases (essential use cases) from the activities previously identified; (Dijkman & Joosten, 2002) that proposes a detailed procedure to transform business process models into use case diagrams by mapping roles to actors, steps to use cases, and tasks to interactions; Wisdom (Nunes, 2001) that comprehends the steps of "Interiorize Project" producing an High-Level Concept, "Understand System Context" producing a Domain Model and/or a Business Model, "User Profiling" producing a Role Model and "Requirements Discovery" that encompasses finding actors and essential use cases; and (Štolfa & Vondrák, 2006) that proposes that business processes are designed using Activity Diagrams and that a mapping is made between the activities of the business process and use cases, which can be "one-to-one" or "mapping several actions to use cases" by applying the Sequential pattern or the Optional pattern respectively. For a more comprehensive analysis and comparision of the related works on RE please refer to (Valente, 2009).…”