Academia.eduAcademia.edu

Outline

Title
Abstract
Figures
Chapter 3 Use Case Modeling and Analysis Overview
Use Case Modeling for Requirements Elicitation
Use Case Modeling Techniques
What is Use Case Model?
Use Cases
Summary of Uml Notation for Use Case Modeling
Usecasename Actorname
Structuring Use Cases with Relationships
Base Use Case Versus Abstract Use Case
Documenting Use Cases
Developing Base Use Case Descriptions
Use Case Template
Use Case Id Id of the Use Case
Prioritizing Use Cases
Factors to Consider for Prioritizing Use Cases
Use Case Modeling and Analysis Process Overview
Developing Use Case Models
Developing Initial Use Case Model
Guidelines for Naming Use Cases
Step 3: Identify Use Cases
Step 6: Perform Textual Analysis
Use Case
Use Case Id UC-300
Expand Initial Use Case Model
Super Use Case
Use Case Name
Use Case Id UC-10
Parent Use Case Name
Parent Use Case Id UC-100
Finding the Right Use Cases
Correct Focus of Base Use Case
Good Use Cases Should Be Observable
Use Cases Versus Process Charts
Apply Textual Analysis in Different Contexts
Structure Use Case Models
Specify Use Cases in Detail ... But Not Too Much
Fit Use Cases Into System Architecture
Use Case Modeling and Analysis with VP-Uml

Object-Oriented Technology

Profile image of shashank nawatheshashank nawathe

2005

Abstract
sparkles

AI

The paper explores the significance of use case modeling in the requirements elicitation process within object-oriented technology. It outlines the definition of requirements, common problems in defining them, and emphasizes the importance of capturing user interactions through use cases to ensure the system meets actual user needs. Furthermore, it provides insights into prioritizing use cases and techniques for developing effective use case descriptions.

Figures (73)
Actors versus Roles modeling, allowing models to be simplified and made more expressive. The fact that actors are classes means that actors can be generalized. Through the generalization process, similarities between different actors can be identified. The UML icon for generalization is a small hollow arrowhead pointing at the superclass of the actor. For instance, a generic actor, such as System Designer, can be inherited by other actors, such as System Analyst and Project Manager. Figure 3.2 shows that the inheriting actors (System Analyst and Project Manager) also inherit the Use Cases associated with the inherited Actor (System Designer).
Actors versus Roles modeling, allowing models to be simplified and made more expressive. The fact that actors are classes means that actors can be generalized. Through the generalization process, similarities between different actors can be identified. The UML icon for generalization is a small hollow arrowhead pointing at the superclass of the actor. For instance, a generic actor, such as System Designer, can be inherited by other actors, such as System Analyst and Project Manager. Figure 3.2 shows that the inheriting actors (System Analyst and Project Manager) also inherit the Use Cases associated with the inherited Actor (System Designer).
Figure 3.4. A use case model for an ATM system Example 2: A Hotel Information System In this example, consider a simple hotel information system for two groups of customers: Tour Group customers and Individual customers. Tour Group customers are those who have made advanced reservations through a tour operator, while Individual customers make their reservations directly with the hotel. Both groups of customers can book, cancel, check-in and check-out of a room by phone or via the Internet. TTY ...4y 2... )0h 6g On eg ey ee r,s is They operate the ATM to withdraw and deposit money, check the account
Figure 3.4. A use case model for an ATM system Example 2: A Hotel Information System In this example, consider a simple hotel information system for two groups of customers: Tour Group customers and Individual customers. Tour Group customers are those who have made advanced reservations through a tour operator, while Individual customers make their reservations directly with the hotel. Both groups of customers can book, cancel, check-in and check-out of a room by phone or via the Internet. TTY ...4y 2... )0h 6g On eg ey ee r,s is They operate the ATM to withdraw and deposit money, check the account
Use Case Analysis Techniques
Use Case Analysis Techniques
Figure 3.6. Two use cases with a common behavior
Figure 3.6. Two use cases with a common behavior
Base Use Case versus Abstract Use Case Once a set of use cases of the system has been identified, common behaviors may be found. By extracting their common behaviors, we can form a base case concrete use case) and an abstract use case. The former is basically the main use case which may be instantiated directly by an actor as it can achieve an observable user goal by itself. The latter can only be instantiated by a base use case as it only contains a portion of the common behaviors shared among two yr more use cases. Therefore, it is not a complete goal from the user’s perspective. For example, in Figure 3.8, a use case such as Login Account is not a4 use case but an abstract use case (or an <<include>> use case), because logging into the system does not achieve a complete user goal. A goal is not achieved if a user goes to an ATM, logs in to the system and then leaves without making a transaction. Typical operations a user may want to carry out through an ATM could be Check Balance, Request Check Book or Deposit Money, etc. A use case may also exhibit several scenarios: the normal scenario and possible several alternative scenarios. Similarly, the base use case can be used ~~ noenencant tha narmal ereoanarin wihiloa ahetrant weo pacoac Aacevihoa tha A child use case can inherit the behaviors, relationships and communication links of a parent use case. In other words, it is valid to put the child use case wherever a parent use case appears. The relationship between the child use case and the parent use case is the generalization relationship. For example, suppose the ATM system can be used to pay bills. Pay Bill has two child use cases: Pay Credit Card Bill and Pay Utility Bill (see Figure 3.10).
Base Use Case versus Abstract Use Case Once a set of use cases of the system has been identified, common behaviors may be found. By extracting their common behaviors, we can form a base case concrete use case) and an abstract use case. The former is basically the main use case which may be instantiated directly by an actor as it can achieve an observable user goal by itself. The latter can only be instantiated by a base use case as it only contains a portion of the common behaviors shared among two yr more use cases. Therefore, it is not a complete goal from the user’s perspective. For example, in Figure 3.8, a use case such as Login Account is not a4 use case but an abstract use case (or an <<include>> use case), because logging into the system does not achieve a complete user goal. A goal is not achieved if a user goes to an ATM, logs in to the system and then leaves without making a transaction. Typical operations a user may want to carry out through an ATM could be Check Balance, Request Check Book or Deposit Money, etc. A use case may also exhibit several scenarios: the normal scenario and possible several alternative scenarios. Similarly, the base use case can be used ~~ noenencant tha narmal ereoanarin wihiloa ahetrant weo pacoac Aacevihoa tha A child use case can inherit the behaviors, relationships and communication links of a parent use case. In other words, it is valid to put the child use case wherever a parent use case appears. The relationship between the child use case and the parent use case is the generalization relationship. For example, suppose the ATM system can be used to pay bills. Pay Bill has two child use cases: Pay Credit Card Bill and Pay Utility Bill (see Figure 3.10).
Figure 3.12. Use case diagram showing <<include>> and <<extend>> relationships Documenting Use Cases
Figure 3.12. Use case diagram showing <<include>> and <<extend>> relationships Documenting Use Cases
For example, the ATM system may provide the Withdraw Money service to customers in many different scenarios. A typical scenario may involve the customer withdrawing money from the machine from which he/she has requested the transaction. In another scenario, the system may report that the password keyed in by the customer is incorrect, requiring the customer to re-enter the password. Figure 3.13 conceptualizes that a use case can be elaborated by a use case description in a more detailed form in that a use case description is explained and elaborated through scenarios (a sequence of actions). Each of these scenarios is simply an instance of the use case. In other words, a use case instance is only a particular example of a use case (a particular system service). As defined by Booch, a use case not only consists of a normal scenario, but possibly its variant scenarios. In such cases, they need to be represented in <<extend>> use cases, where each should be elaborated by a separate use case description.
For example, the ATM system may provide the Withdraw Money service to customers in many different scenarios. A typical scenario may involve the customer withdrawing money from the machine from which he/she has requested the transaction. In another scenario, the system may report that the password keyed in by the customer is incorrect, requiring the customer to re-enter the password. Figure 3.13 conceptualizes that a use case can be elaborated by a use case description in a more detailed form in that a use case description is explained and elaborated through scenarios (a sequence of actions). Each of these scenarios is simply an instance of the use case. In other words, a use case instance is only a particular example of a use case (a particular system service). As defined by Booch, a use case not only consists of a normal scenario, but possibly its variant scenarios. In such cases, they need to be represented in <<extend>> use cases, where each should be elaborated by a separate use case description.
Table 3.2. Components of a use case template
Table 3.2. Components of a use case template
Step 4: Create Initial Use Case Diagram
Step 4: Create Initial Use Case Diagram
Identify/Refine Candidate Business (Domain) Classes
Identify/Refine Candidate Business (Domain) Classes
Note: Recall that a use case model often consists of several use cases. Each of the use cases has its own corresponding use case description, including its brief description and the flow of events, providing more details. As progress is made in the development of the project, more and more use cases will be developed according to the use case schedule. Iteratively and incrementally refine and enrich the initial class model (Figure 3.17) by performing the textual analysis for each of the use cases that have been developed. Table 3.6. Textual analysis on the Schedule Delivery use case is made in the development of the project, more and more use cases will be
Note: Recall that a use case model often consists of several use cases. Each of the use cases has its own corresponding use case description, including its brief description and the flow of events, providing more details. As progress is made in the development of the project, more and more use cases will be developed according to the use case schedule. Iteratively and incrementally refine and enrich the initial class model (Figure 3.17) by performing the textual analysis for each of the use cases that have been developed. Table 3.6. Textual analysis on the Schedule Delivery use case is made in the development of the project, more and more use cases will be
Chapter 3: Use Case Modeling and Analysis 108 The initial use case model is expanded incrementally in subsequent phases of the system development life cycle. In each phase, some use cases are selected and analyzed to produce detailed specifications of the necessary behavioral and functional requirements. Common behaviors and alternative behaviors of use cases are identified when the use cases are expanded and analyzed. These behaviors are extracted to become inclusion, extension and generalization use cases. These, in turn, help to make the use case model easier to maintain. The classes identified in the analysis of the use cases are used to update and refine the class model.
Chapter 3: Use Case Modeling and Analysis 108 The initial use case model is expanded incrementally in subsequent phases of the system development life cycle. In each phase, some use cases are selected and analyzed to produce detailed specifications of the necessary behavioral and functional requirements. Common behaviors and alternative behaviors of use cases are identified when the use cases are expanded and analyzed. These behaviors are extracted to become inclusion, extension and generalization use cases. These, in turn, help to make the use case model easier to maintain. The classes identified in the analysis of the use cases are used to update and refine the class model.
The revised descriptions of the Place Order and Find Member Record use ases are shown in Tables 3.8 and 3.9 respectively.
The revised descriptions of the Place Order and Find Member Record use ases are shown in Tables 3.8 and 3.9 respectively.
No member record is found for the customer. Table 3.9. Description of the Find Member Record use case
No member record is found for the customer. Table 3.9. Description of the Find Member Record use case
Table 3.10. Instance Scenario of Place Order
Table 3.10. Instance Scenario of Place Order
Tricks and Tips in Using Use Case Analysis Chapter 3: Use Case Modeling and Analysis 108
Tricks and Tips in Using Use Case Analysis Chapter 3: Use Case Modeling and Analysis 108
externally observable behaviors of an ATM system, but no customer would ever set his/her goal as inputting the password, selecting a transaction and then leaving the ATM. Furthermore, both Input Password and Select Transaction use cases do not yield an observable value to the user and, therefore, cannot achieve a user goal.
externally observable behaviors of an ATM system, but no customer would ever set his/her goal as inputting the password, selecting a transaction and then leaving the ATM. Furthermore, both Input Password and Select Transaction use cases do not yield an observable value to the user and, therefore, cannot achieve a user goal.
Apply Textual Analysis in Different Contexts
Apply Textual Analysis in Different Contexts
Structure Use Case Models
Structure Use Case Models
Figure 3.26. Identifying major actors
Figure 3.26. Identifying major actors
Figure 3.30. Creating an Actor in model repository
Figure 3.30. Creating an Actor in model repository
Figure 3.29. Entering actor description in Class Description
Figure 3.29. Entering actor description in Class Description
Figure 3.32. Actor models in Model Repository Tree
Figure 3.32. Actor models in Model Repository Tree
Figure 3.33. Hiding Actors in Candidate Class Container Step 3: Identify Use Cases
Figure 3.33. Hiding Actors in Candidate Class Container Step 3: Identify Use Cases
Figure 3.34. Creating a candidate use case in Candidate Class Container 3.3. An input dialog will appear. Enter Place Order in the input dialog (see Figure 3.35).
Figure 3.34. Creating a candidate use case in Candidate Class Container 3.3. An input dialog will appear. Enter Place Order in the input dialog (see Figure 3.35).
Figure 3.35. Naming a new candidate use case
Figure 3.35. Naming a new candidate use case
Figure 3.37. Creating a brief use case description
Figure 3.37. Creating a brief use case description
Figure 3.38. Adding a candidate use case to Model Repository 3.7. Anew use case is added to the Model Repository Tree (see Figure 3.39). Figure 3.39. A new use case in Model Repository Tree
Figure 3.38. Adding a candidate use case to Model Repository 3.7. Anew use case is added to the Model Repository Tree (see Figure 3.39). Figure 3.39. A new use case in Model Repository Tree
Figure 3.40. Use cases in Model Repository Tree
Figure 3.40. Use cases in Model Repository Tree
© C:\VP-UML Projects\MailOrderSystem.vpp * - Visual Paradigm for
© C:\VP-UML Projects\MailOrderSystem.vpp * - Visual Paradigm for
Figure 3.45. Creating an association relationship using resource-centric icon
Figure 3.45. Creating an association relationship using resource-centric icon
Figure 3.44. Creating an Actor with Model Repository Tree
Figure 3.44. Creating an Actor with Model Repository Tree
Step 5: Describe Use Cases The use cases created require further elaboration so that the next phase of the
Step 5: Describe Use Cases The use cases created require further elaboration so that the next phase of the
Figure 3.47. Use case right click pop-up menu 5.2. Select the Description tab (see Figure 3.48). A Specification Dialog about the files associated to the element will be displayed.
Figure 3.47. Use case right click pop-up menu 5.2. Select the Description tab (see Figure 3.48). A Specification Dialog about the files associated to the element will be displayed.
Figure 3.48. Use case specification setup
Figure 3.48. Use case specification setup
Figure 3.49. Use case specification and template
Figure 3.49. Use case specification and template
Figure 3.50. Launching textual analysis function with a use case
Figure 3.50. Launching textual analysis function with a use case
Figure 3.52. Identifying candidate classes
Figure 3.52. Identifying candidate classes
Figure 3.54. Inputting class description for Order class
Figure 3.54. Inputting class description for Order class
Figure 3.53. All occurrences of candidate class are highlighted
Figure 3.53. All occurrences of candidate class are highlighted
Figure 3.55. Candidate classes in Candidate Class Container
Figure 3.55. Candidate classes in Candidate Class Container
Figure 3.56. Adding new items to Use Case Template Note: The Add Item option appends an item at the end of the Use Case Template, while the Insert Item option creates an element after the current highlighted position of the Use Case Description.
Figure 3.56. Adding new items to Use Case Template Note: The Add Item option appends an item at the end of the Use Case Template, while the Insert Item option creates an element after the current highlighted position of the Use Case Description.
Figure 3.57. Renaming items in Use Case Template
Figure 3.57. Renaming items in Use Case Template
Figure 3.58. The completed use case description
Figure 3.58. The completed use case description
Figure 3.59. Creating a new package
Figure 3.59. Creating a new package
Figure 3.61. Structuring use cases into a package within a package at multiple levels. When a package is moved around the
Figure 3.61. Structuring use cases into a package within a package at multiple levels. When a package is moved around the
Figure 3.62. Structuring the use cases into packages
Figure 3.62. Structuring the use cases into packages
Figure 3.64. Complete use case model structured into packages Having grouped the use cases into packages according to the actors’ roles and responsibilities, further structure the use cases according to their common pattern as well as their interactive flow pattern. If some common behaviors are found in two or more use cases, we can factor them out by creating an <<include>> use case. On the other hand, if some alternative scenarios arise due to some special condition(s), we can handle these by introducing the <<extend>> use case(s). Now, let us structure the use case model for the Find Member Record <<include>> use case. If a system boundary will eventually be placed in the use case model, it is better to create the boundary at the beginning before the first use case is created. This way, use cases are created inside the boundary without having to move the use cases and actors around to place them in the right position (see Figure 3.64).
Figure 3.64. Complete use case model structured into packages Having grouped the use cases into packages according to the actors’ roles and responsibilities, further structure the use cases according to their common pattern as well as their interactive flow pattern. If some common behaviors are found in two or more use cases, we can factor them out by creating an <<include>> use case. On the other hand, if some alternative scenarios arise due to some special condition(s), we can handle these by introducing the <<extend>> use case(s). Now, let us structure the use case model for the Find Member Record <<include>> use case. If a system boundary will eventually be placed in the use case model, it is better to create the boundary at the beginning before the first use case is created. This way, use cases are created inside the boundary without having to move the use cases and actors around to place them in the right position (see Figure 3.64).
Chapter 3: Use Case Modeling and Analysis 14 Note: If the <<include>> use case has already been created and you simply want to connect the base use case with the existing <<include>> use case, then drop the <<include>> use case into the existing Find Member Record <<include>> use case. A dependency link between the base use case Register New Member and the <<include>> Find Member Record use case will then be created.
Chapter 3: Use Case Modeling and Analysis 14 Note: If the <<include>> use case has already been created and you simply want to connect the base use case with the existing <<include>> use case, then drop the <<include>> use case into the existing Find Member Record <<include>> use case. A dependency link between the base use case Register New Member and the <<include>> Find Member Record use case will then be created.
Step 9: Prioritize Use Cases We shall prioritize the use cases using the use case schedule.
Step 9: Prioritize Use Cases We shall prioritize the use cases using the use case schedule.
Figure 3.70. Use Case Schedule for the Mail Order System
Figure 3.70. Use Case Schedule for the Mail Order System

Related papers

The Engineering Roles of Requirements and Specification
matteo rossi

The distinction between requirements and specification is often confused in practice. This obstructs the system validation process, because it is unclear what exactly should be validated, and against what it should be validated. The reference model of Gunter et al. addresses this difficulty by providing a framework within which requirements can be distinguished from specification. It separates world phenomena from machine phenomena. However, it does not explain how the characterization can be used to help assure system validity.

View PDFchevron_right
Language for Use Case Specification
Dusan Savic

2011 IEEE 34th Software Engineering Workshop, 2011

The software requirements engineering (RE) process is one of the key processes in software development. The aim of requirements engineering process is capturing, understanding and analyzing customer requirements. Today, use cases are widely used as a technique for specification of the functional requirements of the system. Even through use cases are widely used for specification of the functional requirements, their semantics are unclear that it is difficult to apply them to complex problems. In this paper we have proposed SilabReq language for use cases specification for a standard information system. It is developed under XText framework. The benefits of using SilabReq for use cases specification are reflected in the fact that software requirements are considered as a model. Thereafter, the use cases can be used for automatic processing and analyzing. (Abstract)

View PDFchevron_right
Actor and Use Case Extraction from Text-Based Requirement Specification
Andry Hutagaol

International Conference Image Processing, Computers and Industrial Engineering (ICICIE'2014) Jan. 15-16, 2014 Kuala Lumpur (Malaysia), 2014

Initial stage in software development lifecycle is requirements gathering steps which results a text-based requirements specification document. Common problem in analyzing those requirements is the difficulty of identifying the functionality of the software, especially when there are so many descriptions elicited from the gathering activities. The objective of this research is analyzing the process to identify actor and use case of the system to be built. Since the requirements were described in the form of natural language, therefore it needs natural language processing. The proposed solution is simplification form by only doing the syntax analysis to provide a quick response. The tool is built in Java by accept active sentences in English. The evaluation result proves that the tool is able to list actor and use cases from a given system description. Possible future work is able to process passive sentence with complex structure not only in the Subject-Predicate-Object form.

View PDFchevron_right
Role is an , a Foundation for the Concept of Role
Guy Genilloud

2000

Standardization experts in object modelling are having difficulties with defining the concept of role; for example, they are not sure of whether role is a type or an instance concept. This issue is a source of confusion in the UML standard, and prevents ISO experts to reach consensus and finalize a language for ODP enterprise modelling. In this paper, we make an in-depth analysis of the problem, find its likely causes, and come up with a proposal for a new ODP definition of role, as well as with definitions of related concepts. We expect our definitions and our results not only to achieve consensus among ISO delegates, but also to be a basis for improving the UML standard and related software engineering processes.

View PDFchevron_right
Use Case Specification at Different Levels of Abstraction
Alberto Silva

Use cases are narrative description of interactions between users and a software system. They are primary used to specify functional system requirements. Despite the fact that use cases are narrative, there is no standard that specifies what textual specification of use case should like. However, the integration of use cases in a Model Driven Engineering process requires more rigorous specifications. The specification of use cases at different levels of abstraction is needed because of the large number of stakeholders involved in the software development process. We propose use cases specification at different levels of abstraction to promote better integration, communication and understanding among the involved stakeholders. We still discuss that base on this approach different software development artifacts such as domain model, system operations, user interface design can be automatically generated or validated.

View PDFchevron_right
Requirements Engineering
Donald Firesmith

The Journal of Object Technology, 2002

Because all other activities are influenced or driven by it, requirements engineering is arguably the most important activity performed during the development of softwareintensive systems. Yet, there has been remarkably little standardization on what requirements engineering is and how it should be done beyond the growing de facto standard of using some kind of use case modeling for functional requirements. The first two articles of this column lay the foundation for my future columns on requirements engineering by defining the reusable requirements related process components of the OPEN Process Framework (OPF) and by providing you with an industry-standard terminology for organizing and communicating requirements engineering concepts.

View PDFchevron_right
Role on Requirements Engineering Process Model
Henda Ben Ghezala

MCIS 2008 Proceedings, 2008

The contribution of the requirements engineering in the success of projects is incontestable and it has been proved, through studies and statistics that succeed or fail a project depends generally on requirements engineering. This domain became the centre of interest of a big number of researchers to present the most adequate model and process to succeed the requirements engineering and so succeed the project. Requirements engineering is done according to a process spread all along the life cycle of the system and that aims to provide methods, technologies and tools allow developing and implanting some computing systems providing the services and the information expected by their users, demanded by their acquirers, and compatible with their functioning environment. Requirements engineering process is executed on three principals steps: First, the requirements elicitation to identify future system needs .Then, the specification and the requirements documentation validated or modified following a discussion between the different actors of the process. The end product which is an outfit of models that allows to take into account the actors' point of view, represent not only the final specifications but also the intermediate results. This permits having coherent and well structured documents. The validation and verification of the requirement specification is the final step. On this article, after a presentation of principal challenges that requirements engineering face and notably in specification step, we will define the fundamental notion of a role that will allow us to surround a system in all his perspectives : the organizational, the functional and even the intentional, etc. Then, after a study of some models of requirements engineering we will propose a model of process of requirements engineering with focusing on role notation and its participation in the different process steps.

View PDFchevron_right
Execution of a requirement model in software development
James Huggins

2004

Latest research results have shown that requirements errors have a prolonged impact on software development and that they are more expensive to fix during later stages than early stages in software development. Use case diagrams in UML are used to give requirements for a software system, but all descriptions for each use case are written in informal language. In this paper, we propose a new language HCL (High-Level Constraint Language) to which any requirement model given by use case diagrams can be mapped. Not only is the language HCL based on a formal language but also the requirement model written in HCL can be executed. Many errors occurring during requirements analysis and design can be detected by means of execution.

View PDFchevron_right
The use of object-oriented models in requirements engineering: a field study
Linda Dawson

1999

In many organizations, there has been a move toward the use of object-oriented methods for the development of information systems. Little is understood, or reported on the basis of research, of the use of object-oriented methods by practicing professionals in the production of requirements specifications for commercial or industrial sized projects. In this paper, we outline a conceptual framework of "what might be happening" in professional object-oriented requirements engineering based on the common characteristics of published, well known object-oriented methods. We then describe a research project and the findings from a set of six case studies that have been undertaken that examine professional practice from the standpoint of the epistemology contained in the conceptual model. In these studies, it was found that the more formal models of objectorientation were rarely used to validate, or even clarify, the specification with clients or users. Rather, analysts tended to use informal models, such as use cases or ad hoc diagrams, to communicate the specification to users. Formal models are more often used internally within the analysis team and for communicating the specification to the design team.

View PDFchevron_right
ID2. 5 Elaborated Use Cases & Domain Model
Christian Glahn

2007

View PDFchevron_right

Related papers

The Role of “Roles” in Use Case Diagrams
Guy Genilloud

Lecture Notes in Computer Science, 2000

Use cases are the modeling technique of UML for formalizing the functional requirements placed on systems. This technique has limitations in modeling the context of a system, in relating systems involved in a same business process, in reusing use cases, and in specifying various constraints such as execution constraints between use case occurrences. These limitations can be overcome to some extent by the realization of multiple diagrams of various types, but with unclear relationships between them. Thus, the specification activity becomes complex and error prone. In this paper, we show how to overcome the limitations of use cases by making the roles of actors explicit. Interestingly, our contributions not only make UML a more expressive specification language, they also make it simpler to use and more consistent.

View PDFchevron_right
Use Cases, Actions, and Roles
Guy Genilloud, Gonzalo Génova

Lecture Notes in Computer Science, 2006

Use Cases are widely used for specifying systems, but their semantics are unclear in ways that make it difficult to apply use cases to complex problems. In this paper, we suggest clarifications to use case semantics so that use case modeling can be applied to relate automated systems to business processes and process specifications, particularly in situations where we need to integrate multiple systems in support of a business process. We discuss the original intentions of Ivar Jacobson and UML and we find out that use case specifications, whether written in natural language or as interaction diagrams, are misleading as to what is a use case (instance). We consider then a more natural modeling technique, and establish a relation between a use case, a joint action, and a role.

View PDFchevron_right
Actor Perception in Business Use Case Modeling
Sergio de Cesare

Mainstream literature recognizes the validity and effectiveness of use cases as a technique for gathering and capturing system requirements. Use cases represent the driver of various modern development methods, mainly of object-oriented extraction, such as the Unified Process. Although the adoption of use cases proliferated in the context of software systems development, they are not as extensively employed in business modeling . The concept of business use case is not a novelty, but only recently did it begin to re-circulate in the literature and in case tools. This paper examines the issues involved in adopting business use cases for capturing the functionality of an organization and proposes guidelines for their identification, packaging, and mapping to system use cases. The proposed guidelines are based on the principle of actor perception described in the paper.

View PDFchevron_right
Software Requirements Engineering
Abreham Menker
View PDFchevron_right
Requirements Engineering: An Integrated View of Representation, Process, and Domain
Yannis Vassiliou

1993

Reuse, system integration, and interoperability create a growing need for capturing, representing, and using application-level information about software-intensive systems and their evolution. In ESPRIT Basic Research Project NATURE, we are developing an integrative approach to requirements management based on a three-dimensional framework which addresses formalism as well as cognitive and social aspects. This leads to a new requirements process model which integrates human freedoms through allowing relatively free decisions in given situations. Classes of situations and decisions are defined with respect to the three-dimensional framework through the integration of informal and formal representations, theories of domain modeling, and the explicit consideration of nonfunctional requirements in teamwork. Technical support is provided by a conceptual modeling environment with knowledge acquisition through interactive as well as reverse modeling, and with similarity-based querying.

View PDFchevron_right
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved