1. Tổng quan về xác định yêu cầu người dùng
Giáo trình Phân tích và thiết kế hướng đối tượng bằng UML
Tổng quan về xác định yêu cầu người dùng

2. Mục tiêu
Tìm hiểu các khái niệm cơ bản về xác định yêu cầu người dùng và tác dụng của chúng lên Phân tích và Thiết kế
Tìm hiểu cách ghi nhận và diễn dịch các yêu cầu của nguời dùng, là những thông tin được dùng để bắt đầu việc phân tích và thiết kế
The Requirements Overview module provides an overview of the activities that immediately precede Analysis and Design. It is meant to describe the interface between the Requirements and the Analysis and Design workflows.
The Requirements Overview module will provide enough information so that you will have an appreciation for the Requirements workflow, and will be able to read/interpret the Requirements artifacts that serve as the starting point for the Analysis and Design activities.

3. Các chủ đề Giới thiệu Các khái niệm chính Phát biểu bài toán
Bảng chú giải
Use-Case Model
Các đặc tả bổ sung
Checkpoints
We will start with an introduction to the Requirements workflow, followed by a review of the key concepts in use-case modeling. Then we will look briefly at each of the Requirements’ artifacts and discuss how to read and interpret their contents. We will close by reviewing a series of checklists that will assist you in assessing the quality and completeness of the requirements artifacts.

4. Các yêu cầu người dùng trong ngữ cảnh
Test
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
Requirements
Elaboration
Transition
Inception
Construction
Mục đích của buớc xác dịnh yêu cầu nguời dùng là:
Ði đến thỏa thuận với khách hàng và nguời dùng về các chức năng của hệ thống (những gì hệ thống phải thực hiện).
Cho phép các nhà phát triển hệ thống (system developer) hiểu rõ hơn các yêu cầu đối với hệ thống.
Phân định các ranh giới của hệ thống.
Cung cấp cơ sở để hoạch định nội dung kỹ thuật của các vòng lặp.
Xác định giao diện nguời dùng cho hệ thống.
Configuration & Change Mgmt
Environment
Management
Analysis & Design
This is the hump back chart that was first introduced in the Introduction to RUP module.
The Business Modeling workflow provides a organizational context for the system. This is the context in which the requirements are defined and analyzed.
The purpose of Requirements is:
To come to an agreement with the customer and the users on what the system should do.
To give system developers a better understanding of the requirements on the system.
To delimit the system.
To provide a basis for planning the technical contents of iterations.
To define a user-interface for the system.
The Analysis and Design workflow gets its primary input (the use-case model and the Glossary) from Requirements. Flaws in the use-case model can be discovered during analysis and design; change requests are then generated, and applied to the use-case model.

5. Các dạng thông tin về yêu cầu người dùng
Các đặc tả bổ sung
Bảng chú giải
Use-Case Reports
...
Use-Case Model
Actors
Các Use Case
These are the artifacts that drive the analysis and design of the system, and each will be discussed, in detail, later in this module.
Emphasize that the Use-Case Model not only contains the actors and use cases and their relationships, but also contains the detailed information for each use case (documented in Use-Case Reports).
The other artifacts produced during Requirements do not have as much of an impact on the Analysis and Design activities, so they are not listed here and will not be covered in this course. For more information on the Requirements workflow, suggest the Requirements Management with Use Cases (RMUC) course.
Though not explicitly listed as a Requirements artifact, the Use-Case Modeling Guidelines document is very important, as it is where the conventions for how to write use cases are described (e.g., how to reference actors, glossary terms; use of caps, italics, bold-face, etc.)
Templates for these artifacts are delivered with the Rational Unified Process.
The Use-Case Model describes what the system will do. The Use-Case Model serves as a contract between the customer, the users, and the system developers, which allows customers and users to validate that the system will become what they expected and System developers to build what is expected. The Use-Case Model consists of use cases and actors. Each use-case in the model is described in detail, showing step-by-step how the system interacts with the actors, and what the system does in the use case. The Use-Case Report is the document where all of the use-case properties are documented (e.g., brief description, use-case flows of events, etc.). Note: The OOAD course requirements documentation includes use-case specifications rather than use-case reports because it is the textual descriptions that will drive our analysis and design activities (use-case specifications only include the textual use-case properties).
The Supplementary Specification contains those requirements that don’t map to a specific use case (e.g., non-functional requirements). The Supplementary Specification is an important complement to the use-case model, because together they capture all requirements (functional and nonfunctional) that need to be described to serve as a complete system requirements specification.
The Glossary defines a common terminology for all models and contains textual descriptions of the required system.

6. Các chủ đề Giới thiệu Các khái niệm chính Phát biểu bài toán
Bảng chú giải
Use-Case Model
Các đặc tả bổ sung
Checkpoints
In this section, we will discuss the key concepts of use-case modeling -- the actor and the use case, as well as what relationships can exist between them. We will also see how packages can be used to organize these modeling elements.

7. Khái niệm trong Use-Case Modeling: Actor
Actor (Tác nhân)
An actor represents anything that interacts with the system. An actor is EXTERNAL!
Actors are not part of the system, they represent roles a user of the system can play.
An actor may actively interchange information with the system.
An actor may be a passive recipient of information.
An actor can represent a human, a machine or another system.
Các Actor nằm BÊN NGOÀI hệ thống

8. Actor Generalization (Tổng quát hóa)
Generalization can be used between actors to model those cases where several actors can play the same role in a particular use case. For example, for the Course Registration System, there are full-time and part-time students, both of whom can register for courses, and both are seen as the same external entity by the use-case that does the registering. The shared role can be modeled as an actor, Student, inherited by the two original actors.
Generalization between actors is considered an advanced use-case modeling technique. However, it is presented here because it appears in the Payroll System solution.
For more information on these use-case modeling concepts, see the Requirements Management with Use Cases (RMUC) course or the Rational Unified Process (RUP).
This actor inheritance may seem somewhat contrived, but we could not think of a better example for the registration system.
Student
Full-Time
Part-Time
Several actors can play the same role in a particular use case
In the above example, there are full-time and part-time students, both of whom can register for courses, and are seen as the same external entity by the use-case that does the registering. The shared role is modeled as an actor, Student, inherited by the two original actors. This relationship is shown with actor-generalizations.

9. Một User có thể có nhiều Vai trò (Role)
Charlie có vai trò như
một sinh viên
Charlie
Student
Charlie có vai trò như
một giáo su
In the above example, Charlie is a professor that also happens to be enrolled in a course as a student. Thus Charlie plays both a professor and a student role in the system.
Professor

10. Actors và giới hạn hệ thống (System Boundary)
Customer
Bank System
System
boundary?
ATM System
Bank Teller
Nguời thu ngân
The choice of actors scopes the system.
If the inner circle is the system boundary, the there are three actors: Customer, Bank Teller, and Bank System.
If the outer circle is the system boundary, then there is only one actor, Customer.
The system to be built depends on who the actors are (i..e who will use the system and how).

11. Khái niệm trong Use-Case Modeling: Use-Case
Use cases focus on WHAT the system does, not HOW it does it.
A use-case has a
set of properties - brief description, flow of events, special
requirements, activity diagrams, … (these are discussed in more detail later in this module).
Use cases are enclosed in the use-case
model artifact (i.e., is use-cases are properties of
the use-case model).
Uses and extends relationships between use cases are considered advanced use-case modeling techniques, and thus are not discussed in this course. However, if students ask, you can tell them the following:
If two or more use cases contain the same behavior, you can extract the common behavior to create a new use case. The original use cases can then use this extracted behavior, which is indicated by a uses-relationship between the new and original use cases.
Extends can be used to extract optional or complicated subflows into a separate use case that extends specific use cases. The extended use case is unaware that it is extended.
For more information on these use-case modeling concepts, see the Requirements Management with Use Cases (RMUC) course or the Rational Unified Process (RUP).
Use-Case
A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor.
Use cases are the conduit between the end users and the developers. One of their primary purposes is to serve as a communication vehicle, so that end users and developers can clearly understand the requirements.
A use-case models a dialogue between actors and the system.
A use-case is initiated by an actor to invoke a certain functionality in the system.
A use-case is a complete and meaningful flow of events.
In order to "scope" the size of a use case, consider that a use case represents a major system usage goal for one or more of the actors that interact with the use case.
Taken together, all use cases constitute all possible ways of using the system.

12. Các Package trong Use-Case Model
Packages are just a general grouping mechanism for grouping elements into semantically related groups.
Packages can be used in the Use-Case Model to reflect order, configuration, or delivery units in the finished system.
Allocation of resources and the competence of different development teams may require that the project be divided among different groups at different sites
You can use use-case packages to:
Structure the use-case model in a way that reflects the user types
Preserve secrecy in areas where it is needed.
In the UML, a package is represented as a tabbed folder.

13. Các chủ đề
Giới thiệu
Các khái niệm chính
Phát biểu bài toán (Problem Statement)
Bảng chú giải
Use-Case Model
Các đặc tả bổ sung
Checkpoints

14. Ví dụ: Course Registration Problem Statement
Là người phụ trách Tin học của trường Đại học KHTN, bạn được yêu cầu phát triển một hệ thống đăng ký học phần mới. Hệ thống mới cho phép sinh viên đăng ký học phần và xem phiếu điểm từ bất kì máy tính cá nhân nào được kết nối vào mạng nội bộ của trường. Các giáo sư cũng có thể truy cập hệ thống này để đăng ký lớp dạy và nhập điểm cho các môn học.
Do kinh phí bị giảm nên trường không đủ khả năng thay đổi toàn bộ hệ thống trong cùng một lúc. Trường sẽ giữ lại cơ sở dữ liệu (CSDL) sẵn có về danh mục học phần mà trong đó lưu trữ toàn bộ thông tin về các học phần. Đây là một CSDL quan hệ và có thể truy cập bằng các câu lệnh SQL thông qua các server của trường. Hiệu suất của hệ thống cũ này rất kém nên hệ thống mới phải bảo đảm truy cập dữ liệu trên hệ thống cũ một cách hợp lý hơn. Hệ thống mới sẽ đọc các thông tin học phần trên CSDL cũ nhưng sẽ không cập nhật chúng. Phòng Đào tạo sẽ tiếp tục duy trì thông tin các học phần thông qua một hệ thống khác.
Ở đầu mỗi học kỳ, sinh viên có thể yêu cầu danh sách các học phần được mở trong học kì đó. Thông tin về mỗi học phần, ví dụ như tên giáo sư, khoa,các học phần tiên quyết sẽ được cung cấp để giúp sinh viên chọn lựa.
Direct the Students to the Course Registration Problem Statement in the Course Registration Requirements document. Give them an opportunity to read the problem statement themselves and discuss any questions, comments, issues.
If the students should question the length of the problem statement, tell them that every project is different with respect to the level of detail that is included in the Problem Statement. A Problem Statement can range from a few sentences to a multi-page formal requirements document. The standards for these documents must be established and documented for each project.
Do not spend too much time here. The goal is for them to have an understanding of the problem to be solved in the Course Registration System.
Before we discuss the details of the artifacts which drive the analysis and design workflow. It is important that you understand the problem domain that all of the course exercises will be based on.
With regards to the formal Requirements artifacts, the Problem Statement is part of the Vision document. The other sections have been omitted for scoping reasons. For more information on the Vision document, see the Requirements workflow of the Rational Unified Process.

15. Ví dụ: Course Registration Problem Statement
Hệ thống mới cho phép sinh viên chọn bốn học phần được mở trong học kỳ tới. Thêm vào đó mỗi sinh viên có thể đưa ra hai môn học thay thế trong trường hợp không thể đăng ký theo nguyện vọng chính. Các học phần được mở có tối đa là là 100 và tối thiểu là 30 sinh viên. Các học phần có ít hơn 30 sinh viên sẽ bị hủy. Đầu mỗi học kỳ, sinh viên có một khoảng thời gian để thay đổi các học phần đã đăng ký. Sinh viên chỉ có thể thêm hoặc hủy học phần đã đăng ký trong khoảng thời gian này. Khi quá trình đăng ký hoàn tất cho một sinh viên, hệ thống đăng ký sẽ gửi thông tin tới hệ thống thanh toán (billing system) để sinh viên có thể đóng học phí. Nếu một lớp bị hết chỗ trong quá trình đăng ký, sinh viên sẽ được thông báo về sự thay đổi trước khi xác nhận việc đăng ký học phần.
Ở cuối học kỳ, sinh viên có thể truy cập vào hệ thống để xem phiếu điểm. Bởi vì thông tin về điểm của mỗi sinh viên cần được giữ kín, nên hệ thống cần có cơ chế bảo mật để ngăn chặn những truy cập không hợp lệ.
Các giáo sư có thể truy cập vào hệ thống để đăng ký những học phần mà họ sẽ dạy. Họ có thể xem danh sách các sinh viên đã đăng ký vào lớp của họ, cũng như nhập điểm sau mỗi khóa học.
Direct the Students to the Course Registration Problem Statement in the Course Registration Requirements document. Give them an opportunity to read the problem statement themselves and discuss any questions, comments, issues.
If the students should question the length of the problem statement, tell them that every project is different with respect to the level of detail that is included in the Problem Statement. A Problem Statement can range from a few sentences to a multi-page formal requirements document. The standards for these documents must be established and documented for each project.
Do not spend too much time here. The goal is for them to have an understanding of the problem to be solved in the Course Registration System.
Before we discuss the details of the artifacts which drive the analysis and design workflow. It is important that you understand the problem domain that all of the course exercises will be based on.
With regards to the formal Requirements artifacts, the Problem Statement is part of the Vision document. The other sections have been omitted for scoping reasons. For more information on the Vision document, see the Requirements workflow of the Rational Unified Process.

16. Các chủ đề
Giới thiệu
Các khái niệm chính
Phát biểu bài toán
Bảng chú giải
Use-Case Model
Các đặc tả bổ sung
Checkpoints

17. Từ điển thuật ngữ (Glossary)
Giới thiệu
Bảng chú giải
The Glossary does not document things purely in the solution space, such as mechanisms, key abstractions related only to the solution space, architectural patterns being used, and the like. Do not overload the Glossary with those sorts of things - it’s primarily a ‘user-oriented’ document. The SAD is better at communicating the common architectural “house rules”.
The Rational Unified Process ships with a template for the Glossary.
Glossary
The Glossary defines important terms used in the project.
There is one Glossary for the system. This document is important to many developers, especially when they need to understand and use the terms that are specific to the project. The glossary is used to facilitate communications between domain experts and developers.
The Glossary is primarily developed during the inception and elaboration phases, because it is important to agree on a common terminology early in the project. In Inception/Elaboration it is used by domain experts (e.g., business analysts) to explain all the domain-specific terminology used in their use cases. In Elaboration/Construction, developers use the Glossary to explain technical terms used in the other four models.
A system analyst is responsible for the integrity of the Glossary, ensuring that the Glossary is produced in a timely manner and is continuously kept consistent with the results of development.
The above is just a sample outline for the Glossary. All of these elements do not have to exist in the Glossary. A project needs to establish the template to be used on that particular project.
Introduction: A brief description of the glossary and its purpose.
Terms: Define the term in as much detail as necessary to completely and unambiguously characterize it.

18. Ví dụ: Glossary Bảng chú giải của ứng dụng “Course Registration”:
Course (Học phần): Một môn học được dạy trong trường.
Course Offering (Lớp): Một lớp học cụ thể được mở trong một học kỳ cụ thể – cùng một học phần có thể đuợc mở song song nhiều lớp trong một học kỳ. Thông tin gồm cảc ngày học trong tuần và giờ học.
Course Catalog (Danh mục học phần): Danh mục đầy đủ của tất cả các học phần được dạy trong trường.
Faculty: Toàn bộ cán bộ giảng dạy của trường..
Finance System (Hệ thống thanh toán): Hệ thống dùng để xử lý các thông tin thanh toán học phí.
Grade (Ðiểm số): Sự đánh giá cho một sinh viên cụ thể trong một lớp cụ thể.
Professor (Giáo sư): Người giảng dạy trong truờng.
Report Card (Phiếu diểm): Toàn bộ điểm số cho tất cả học phần một sinh viên đã học trong một học kỳ xác dịnh.
Roster (Danh sách sinh viên đăng ký): Tất cả sinh viên đăng ký vào một lớp học cụ thể.
Student (Sinh viên): Người đăng ký vào học các lớp của trường.
Schedule (Lịch học): Các học phần mà một sinh viên đã chọn học trong học kỳ hiện tại.
Transcript (Bản sao học bạ): Bản sao tất cả điểm số cho tất cả các học phần của một sinh viên cụ thể đuợc chuyển cho hệ thống thanh toán để hệ thống này lập hóa đơn cho sinh viên.
Direct the Students to the Glossary in the Course Registration Requirements document. Give them an opportunity to read it themselves and discuss any questions, comments, issues.
The idea is not to go over the Glossary in vivid detail, but to demonstrate how to read it, where to look for information you’ll need during the analysis and design activities, as well as how to detect if it is insufficient.

19. Các chủ đề Giới thiệu Các khái niệm chính Phát biểu bài toán
Bảng chú giải
Use-Case Model
Các đặc tả bổ sung
Checkpoints
Now, let’s discuss how use cases are documented.

20. Use-Case Model Giới thiệu Survey Description Use-Case Packages
Use-Case Reports
...
Use-Case Model
Actors
Use Cases
Giới thiệu
Survey Description
Use-Case Packages
Use Cases
Actors
Relationships
Diagrams
Use-Case View
The use-case model is used as an essential input to activities in analysis, design, and test.
Use cases are enclosed in the use-case model artifact, which is stated by saying that use cases are properties of the use-case model.
Remind the students that the OOAD course requirements documentation includes use-case specifications rather than use-case reports because it is the textual descriptions that will drive our analysis and design activities (use-case specifications only include the textual use-case properties).
The Use-Case Model is a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers. The above slide lists the properties of a use case, which are described below.
Introduction: A textual description that serves as a brief introduction to the model.
Survey Description: A textual description that contains information not reflected by the rest of the use-case model, including: typical sequences in which the use cases are employed by users, functionality not handled by the use-case model.
Use-Case Packages: The packages in the model, representing a hierarchy.
Use Cases: The use cases in the model, owned by the packages. The use cases have their own properties, which may be documented in Use-Case Reports.
Actors: The actors in the model, owned by the packages.
Relationships: The relationships in the model, owned by the packages.
Diagrams: The diagrams in the model, owned by the packages.
Use-Case View: An architectural view showing the significant use-cases and/or scenarios.

21. Use-Case Model
Các Use Case lái công việc từ giai đoạn phân tích đến kiểm chứng
Use-Case Model
Emphasize that the focus of this course will be on how the Use-Case Model affects the development of the Design Model.
Remember, use-case-driven is a key characteristic (and benefit) of the Rational Unified Process.
Use-Case Driven: The Use cases serve as a unifying thread throughout system development
The same use-case model is used in requirements, analysis & design, implementation and test.
Kiểm tra bởi
Hiện thực bởi
Cài đặt bởi
Design Model
Implementation Model
Test Model
Use cases defined for a system are the basis for the entire development process. They provide the unifying thread through the system and define the behavior performed by a system. Use cases play a role in each of the core process workflows:
The use-case model is a result of the requirements workflow. In this early process you need the use cases to model what the system should do from the user's point of view.
In analysis and design use-cases are realized in a design model. You create use-case realizations which describe how the use-case is performed in terms of interacting objects in the design model. This model describes, in terms of design objects, the different parts of the implemented system, and how the parts should interact to perform the use cases.
During implementation the design model is the implementation specification. Because use cases are the basis for the design model, they are implemented in terms of design classes.
During test the use cases constitute basis for identifying test cases and test procedures. The system is verified by performing each use case.
Use cases have other roles as well:
Basis for planning an iterative development.
Foundation for what is described in user manuals.
Definition of ordering units. For example, a customer can get a system configured with a particular mix of use cases.

22. Ví dụ: Use-Case Model: Use-Case Diagram
Walk through the use-case diagram, showing the students how to read and interpret it’s contents.
An interaction between actor and use-case also means that there exist an interface between the actor and the system.
The idea is not to go over the above use-case diagram in vivid detail, but to demonstrate how to read the use-case diagram, where to look for information you’ll need during the analysis and design activities, as well as how to detect if the use-case model is insufficient.
Note: You don’t have to draw arrows on the communication-associations. Remember, the default value of navigability is true.
The direction of the arrow defines the actor that initiated the use case and any return messages are assumed.
Some students may question having Login as a separate use case. See the Instructor’s Best Practices document for the rationale.
Login
Maintain Professor Information
Registrar
View Report Card
Student
Maintain Student Information
Register for Courses
Course Catalog
Close Registration
Billing System
Select Courses to Teach
A use-case diagram is drawn to illustrate that use-cases and actors interact by sending stimuli to one another An association (communicates-association) between an actor and an use-case implies that there is interaction between the two.
Each role of a communicates-association has a navigability property, indicating the direction of the communication. It is indicated by an open arrow, which is placed on the end of the association line next to the target type (the one being communicated with). For a communication that involves a response (return of values) from the receiving instance, you need a communicates-association only in the direction of the transmission. You do not need navigability in the opposite direction. The default value of the navigability property is true. Arrows are usually suppressed for communicates-associations with navigability in both directions, because this is the default; instead, arrows are shown only for associations with one-way navigability. In summary, the direction of the arrows is used by convention to indicate the direction of initial communication between a use case and each actor with which it interacts.
The above is the main use case diagram for a Course Registration System. The complete use-case model (including all use cases) is provided in the Course Registration Requirements Document.
Professor
Submit Grades

23. Use Case Tên Brief description Luồng các sự kiện Relationships
Use-Case Reports
...
Use-Case Model
Actors
Use Cases
Tên
Brief description
Luồng các sự kiện
Relationships
Activity và State diagrams
Use-Case diagrams
Special requirements
Preconditions
Postconditions
Các diagram khác
The flows of events should be understandable by the customer. The flow of events should describe: how and when the use-case starts and ends, when the use-case interacts with the actors, and what information is exchanged between an actor and the use case. The flows of events should not describe user interface details.
A use-case specification contains all textual information for a use case. A use-case report contains the properties of a use case, including diagrams (a use-case report is a use-case specification plus diagrams). RUP ships with templates for use-case specifications and reports. Remind the students that the OOAD course requirements documentation includes use-case specifications rather than use-case reports because it is the textual descriptions that will drive our analysis and design activities.
In Rose, the use-case name and brief description can be entered into the use-case specification. The other properties can be documented in a separate file that can be “attached” to the use-case. SoDA can then be used to generate use-case reports, including the information you entered into Rose and any other supporting information.
The use-case has a set of properties which are listed above. The use-case properties may be documented in Use-Case Reports.
The brief description should describe the role and purpose of the use case in a few lines
The flows of events are textual descriptions of what the system does in regard to the use case. There may be multiple flows of events (e.g, a basic flow, alternative flows).
Relationships: The relationships, such as communicates-associations, uses-and extends-relationships, in which the use-case participates.
Activity and State diagrams can be used to illustrate the structure of the flow of events. Use-case diagrams can be used to show the relationships involving the use case.
The special requirements section is a textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation.
Preconditions define a constraint on the system for when the use-case may start. Postconditions define a constraint on the system for after the use-case has terminated.
Other diagrams can be used to illustrate the use case, such as hand-drawn sketches or screen-dumps from an user-interface prototype.

24. Luồng các sự kiện (Use-Case Flows of Events)
Của một basic flow (“Happy Path”)
Một số alternative flows
Các biến thể thường gặp (Regular variants)
Các trường hợp bất thường (Odd cases)
Exceptional flows xử lý các tình huống lỗi
For example, in a Maintain Employee Information use case, there may be separate subflows for adding, deleting and modifying employee information.
Don’t be too concerned with the exact definition of what is “basic” versus what is “alternate” (or “exception”). Readability and understandability are the key.
Note: The colors are not distinguishable in the black and white books. That’s OK, the picture still provides value as the alternate flows are visible.
“Happy Path”
The basic flow describes what happens “most of the time” when the use-case is executed. It has been referred to as “the happy path” or “the happy day scenario”.
A use case's flow of events can be divided into several subflows. Extracting parts of the flow of events and describing these parts separately, can often increase the readability of the basic flow of events and improve the structure of the use-case model. Separating out the subflows helps the use case's basic flow to stand out more clearly. If a subflow involves only a minor part of the complete flow of events, it is better to describe it in the body of the text.
The use-case should cover all the flows, the normal as well as the alternative and exceptional ones. Structure the use-case flows of events in such a way that it is easy to follow the different flows and understand what happens when.
It is recommended that you describe each subflow in a separate supplement to the Flow of Events section.
Some examples of potential subflows include flows of events that:
Occupy a large segment of a given flow of events
Are variants, or exceptions, of the basic flow of events
Can be executed at several intervals in the same flow of events.
Subflows may be performed at the same time and in optional sequences.

25. Scenarios là gì ? Scenario là một thể hiện của use case
A scenario is an instance of a use case. It is one flow through a use case.
Each use-case will have a web of flows of events with a scenario being an instance of a particular flow of events. The scenario may involve the basic flow and any number of alternative flows in any number of combinations.
In the above example, the bold lines highlight some possible scenarios for the basic and alternative flows previously described.
How many scenarios are needed?
Simple answer: As many as one needs to understand the system being developed. You should elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be used to understand, as well as to validate the use-case flows of events. Some people write scenarios first and extract use cases, while others find use cases first and validate those use cases by writing scenarios.
Scenarios make excellent test cases.

26. Ví dụ: Activity Diagram
initial state
Chọn
Activity diagrams model the flow of control from activity to activity, whereas a statechart diagram models the flow of control from state to state.
In this example, the concurrent join is followed immediately by a concurrent fork because a synchronization point (a concurrent join or a concurrent fork) can only have one incoming and several outgoing transitions, or several incoming and one outgoing transitions.
Course
Phân nhánh các tác vụ đồng hành
action state
Check
Check
Schedule
Pre-requisites
Kết hợp các tác vụ đồng hành
[ checks completed ]
[ checks failed ]
biểu thức kiểm tra (guard expression)
The flow of events of a use-case can be described graphically with the help of an activity diagram. Such a diagram is used for capturing workflow in an organiztion and shows:
Action states, which represent the execution of an activity or step within the flow of events.
Transitions between those action states.
Decisions for which a set of guard conditions are defined. These guard conditions control which transition follows once the activity an action state represents has been completed.
A fork is where a single flow of control is split into two or more concurrent flows of control. A join is where two or more concurrent flows of control are synchronized.
The above activity diagram shows the steps of the Register for Courses use case. The student first selects a course. Once the course has been selected, the student’s schedule must be checked for conflicts and it must be verified that the student has taken all of the pre-requisites of the selected course. If these validation steps complete successfully, the student is added to the course and his/her schedule can be updated. If the checks fail, the conflicts must be resolved before the student can be registered for the course.
Note: An activity diagram is a special case of a state diagram, so a state diagram could also be used. State diagrams are discussed in the Class Design module.
Ghi tên vào
Giải quyết các
course
conflict
[Sinh viên đã được thêm vào course ]
Cập nhật
lịch học

27. Ví dụ: Đặc tả Use-Case
Ðiểm lại đặc tả của một use-case hoàn chỉnh được cung cấp trong tài liệu, mô tả các yêu cầu của ứng dụng “Course Registration”
Walk the students through the Register for Courses use case, as the registration functionality is the heart of the Course Registration System.
Direct the Students to the Register for Courses use-case specification in the Course Registration Requirements document. Give them an opportunity to read the use case themselves, and then discuss any questions, comments, issues.
Also take the time to point out the overall structure of the use case - how there are separate subflows, how alternative subflows are written as “deltas” off the basic flow.
A long, several page use case can be a bit boring to go over in detail. Make this exciting.
The idea is not to go over the use case in vivid detail, but to demonstrate how to read the use case, where to look for information you’ll need during the analysis and design activities, as well as how to detect if the use case is insufficient.
Note: The requirements documentation includes use-case specifications rather than use-case reports because it is the textual descriptions that will drive our analysis and design activities (use-case specifications only include the textual use-case properties).

28. Các chủ đề
Giới thiệu
Các khái niệm chính
Phát biểu bài toán
Bảng chú giải
Use-Case Model
Các đặc tả bổ sung
Checkpoints

29. Các đặc tả bổ sung Functionality Tính khả dụng (Usability)
Tính tinh cậy (Reliability)
Tính hiệu nang(Performance)
Tính hỗ trợ (Supportability)
Các ràng buộc thiết kế
Those non-functional requirements that can be tied to a particular use case should be documented in the use case “special requirements” property.
The Rational Unified Process ships with templates for the supplementary specification.
Supplementary
Specification
The non functional requirements and the functional requirements not captured by the use cases are included in supplementary specifications. The Supplementary Specifications include constraints on the implementation
The above is just a sample outline for a supplementary specification. For a more detailed outline, see the IEEE recommended practice for software requirements specifications [IEEE Std ]. All of these elements do not have to exist in the supplementary specifications. A project needs to establish the template to be used on that particular project.
Functionality: List of the functional requirements that are general to many use cases.
Usability: Those requirements that relate to, or affect, the usability of the system. Examples include ease-of-use requirements or training requirements that specify how readily the system can be used by its actors.
Reliability: Any requirements concerning the reliability of the system. Quantitative measures such as mean time between failure or defects per thousand lines of code should be stated.
Performance: The performance characteristics of the system. Include specific response times. Reference related use cases by name.
Supportability: Any requirements that will enhance the supportability or maintainability of the system being built.
Design Constraints: Any design constraints on the system being built.

30. Ví dụ: Các đặc tả bổ sung Tài liệu tham khảo Không có. Chức năng
Hỗ trợ nhiều người dùng làm việc đồng thời.
Nếu một lớp bị hết chỗ khi một sinh viên đang đăng ký học của lớp đó thì sinh viên này phải được thông báo.
Tính khả dụng
Giao diện nguời dùng tương thích Windows 95/98.
Tính ổn định
Hệ thống phải hoạt động liên tục 24 giờ/ngày, 7 ngày/tuần, với thời gian ngừng hoạt động không quá 10%.
Hiệu suất
Hệ thống phải hỗ trợ đến 2000 người dùng truy xuất CSDL trung tâm đồng thời bất kỳ lúc nào, và đến 500 người dùng truy xuất các server cục bộ.
Hệ thống phải cho phép truy xuất đến CSDL danh mục học phần cũ với độ trễ không quá 10 giây.
Hệ thống phải có khả năng hoàn tất 80% giao dịch trong vòng 2 phút.
Sự hỗ trợ
Tính bảo mật
Hệ thống phải ngăn chặn sinh viên thay đổi lịch học của người khác, và ngăn các giáo sư thay đổi lớp dạy của giáo sư khác.
Chỉ có giáo sư mới có thể nhập điểm cho sinh viên.
Chỉ có cán bộ đào tạo mới được phép thay dổi thông tin của sinh viên.
Các ràng buộc thiết kế
Hệ thống phải tích hợp với hệ thống có sẵn, Hệ thống danh mục học phần, một CSDL RDBMS.
Hệ thống phải cung cấp giao diện dựa trên Windows.
Direct the Students to the Supplementary Specification in the Course Registration Requirements document. Give them an opportunity to read the it themselves and discuss any questions, comments, issues. Highlight the different sections and stress that your project may include their own specific sections.
Emphasize those non-functional requirements that will end up being modeled on interaction diagrams.
The idea is not to go over the Supplementary Specification in vivid detail, but to demonstrate how to read it, where to look for information you’ll need during the analysis and design activities, as well as how to detect if it is insufficient.

31. Các chủ đề Giới thiệu Các khái niệm chính Phát biểu bài toán
Bảng chú giải
Use-Case Model
Các đặc tả bổ sung
Checkpoints
Now lets look at some review criteria for establishing the quality and completeness of the Requirements artifacts. The idea behind including these checklists in this course even though we are not generating these artifacts is because the requirements artifacts are input to the analysis and design activities, so the people that perform the analysis and design activities will be (or should be) participating in the review of the of requirements artifacts.
You need to be able to read the requirements artifacts, to know where to look for the information you need, and to know how to detect if the artifacts are insufficient.

32. Checkpoints: Requirements: Use-Case Model
Use-case model có dễ hiểu không?
Sau khi nghiên cứu use-case model, bạn có hình thành được một ý tuởng rõ ràng về các chức năng của hệ thống và cách thức mà chúng liên hệ với nhau ?
Ðã xác định hết tất cả các actor? Tất cả các yêu cầu chức năng được thỏa hay chưa?
Use-case model có chứa các hành vi vô dụng nào không?
Việc chia model thành các use-case package có xác đáng?
Complete checklists are provided in the online Rational Unified Process.
A normal system has 20 to 50 use cases. A very large system has no more than 100 use cases.
The number of use cases is more a measure of the complexity of the interaction between the system and actors. A big, but simple, system may have a few use cases, but a small system (that may be complex to build) may have lots of use cases.
The number of use cases a project may initially identify may be large (because they are doing functional decomposition) The idea of fewer use cases helps to push them towards the real usage of use cases - thinking of functionality rather than algorithms when doing functional requirements analysis.
The above, as well as the remaining checklists in this section, are a sample of the kinds of things to look for when reviewing the use-case model. Explicit, detailed checklists should be established for the project to support the review of the use-case model.
Verify that there are no open questions. The use cases you have found must be able to perform all system behaviors; if not, some use cases are missing. If you have intentionally left any requirements to be dealt with in the object models, such as nonfunctional requirements, you must mention this somewhere, probably in the Supplementary Specification(s). If a requirement of this type concerns a specific use case, state this in the Special Requirements section of the use case. The use-case model should not present more functions than were called for in the requirements.
Traceability from the original requirements to the use cases and the Supplementary Specification is critical for project management, impact assessment and to make sure nothing has been missed
The packaging should make the use-case model more simple and intuitive to understand and maintain.

33. Checkpoints: Requirements: Actors
Ðã xác định hết tất cả các actor?
Mỗi actor có tham gia vào ít nhất một use case?
Mỗi actor thật sự có một vai trò (role)? Có cần ghép hoặc tách các actor không?
Có tồn tại 2 actor dùng cùng một vai trò đối với 1 use case không?
Tên của các actor có gợi nhớ không? Users và customers có hiểu tên của chúng?
Make sure that all the roles in the system's environment have been accounted for and modeled. You can check this at this point, but you cannot be sure until you have found and described all the use cases.
Remove any actors not mentioned in the use-case descriptions, or any actors without communicates-associations with a use case. However, an actor mentioned in a use-case description is likely to have a communicates-association with that particular use case.
You should be able to name at least two people who would be able to perform as a particular actor. If not, check if the role the actor models is part of another role. If so, you should merge the actor with another actor. If any actors play similar roles in relation to the system, they should be merged into into a single actor. If a particular actor will use the system in several completely different ways, or has several completely different purposes for using the use case, then there should probably be more than one actor.
If two actors play the same role in relation to a use case, then actor-generalizations should be used to model their shared behavior.
It is important that actor names correspond to their roles.

34. Checkpoints: Requirements: Use-Cases
Mỗi use case có ít nhất một actor tương tác?
Các use case có độc lập với nhau?
Tồn tại các use case có các luồng sự kiện và các hành vi tương tự nhau không?
Liệu các use case có tên duy nhất, gợi nhớ, và dễ hiểu để chúng không bị nhầm lẫm trong các giai đoạn sau?
Các khách hàng và người dùng có hiểu tên và mô tả của các use case không?
Note: These checkpoints really only apply to concrete use cases, not use cases that extend other use cases or are used by other use cases, but use-case uses and extends were not covered in this course for scoping reasons.
A use-case that does not interact with an actor is superfluous, and you should remove it.
If two use cases are always activated in the same sequence, you should probably merge them into one use case.
Use cases that have very similar behaviors or flows of events, or if you wish their behavior to be similar in the future, should be merged into a single use case. This makes it easier to introduce future changes.
Note: you must involve the users if you decide to merge use cases, because the users, who interact with the new, merged use-case will probably be affected.
If some part of the flow of events already part of another use case, the subflow should be extracted and be used by the use cases in question.
Note: you must involve the users if you decide to "reuse" the subflow, because the users of the existing use-case will probably be affected.
Each use-case name must describe the behavior the use-case supports. The names and descriptions must be understood be the users and customers.

35. Checkpoints: Requirements:Các đặc tả Use-Case
Use case có đủ rõ ràng đối với những người muốn hiên thực?
Mục đích của use-case có rõ ràng?
Mô tả sơ lược (Brief description) có cho ta hình ảnh trung thực của use-case?
Có xác định rõ luồng sự kiện của use-case như thế nào và khi nào bắt đầu và kết thúc?
Chuỗi các giao tiếp giữa actor và use-case có tiện nghi không (từ góc nhìn của người dùng)?
Các tương tác và các thông tin trao đổi của actor có rõ ràng?
Có use-case nào quá phức tạp không?
Các luồng sự kiện (basic và alternative) được mô hình đúng đắn?
Include any (nonfunctional) requirements to be handled in the object models in the use-case Special Requirements.
Behavior might exist that is activated only when a certain condition is not met. There should be a description of what will happen if a given condition is not met.
If you want your use-case model to be easy to understand, you might have to split up complex use cases. A use-case that contains disparate flows of events will be very difficult to understand and to maintain. It is best to divide such use cases into two or more separate use cases.

36. Checkpoints: Requirements: Glossary
Các thuật ngữ có định nghĩa rõ ràng và súc tích?
Mỗi thuật ngữ có dùng đâu đó trong các mô tả use-case?
Các thuật ngữ có được sử dụng hợp lý trong các mô tả ngắn về các actor và use case?
If each glossary term is not included somewhere in the use-case descriptions, that may imply that a use-case is missing or that the existing use cases are not complete. It is more likely, though, that the term is not included because it is not needed, and it should be removed.
A term should represent the same thing in all use-case descriptions.

37. Review: Các thành phần chính của Đặc tả yêu cầu (Requirements)?
Các thành phần của đặc tả yêu cầu được dùng để làm gì?
Use-case model là gì?
Actor là gì?
Use case là gì? Liệt kê một số thuộc tính của use case.
Sự khác nhau giữa use-case và scenario?
Supplementary specification là gì và nó chứa những gì?
Glossary là gì và nó chứa những gì?

38. Bài tập: Mơ tả các thành phần chính của Requirements:
Problem statement
Use-case model main diagram
Supplementary specification
Glossary
Ðiểm lại các thông tin về yêu cầu người dùng được sử dụng trong mô hình, ghi chú tất cả các câu hỏi, các vấn dề còn tranh cãi, mâu thuẫn
Have the students review each of the artifacts and note any questions, comments, and/or concerns. Then discuss the comments as a group.
During the artifact discussion, I recommend that you display the Use-case model main diagram from the Payroll System Rose model, and then walk through with the students to make sure that they understand the system they will be working with in the exercises throughout the course.
Some students may question why Printer is included as an actor. See the Instructor Best Practices document for a discussion of the rationale.
These artifacts will be used as the basis for the remainder of the examples and exercises in this course, so you need to have a good foundation for moving forward. All questions, issues, etc. regarding the Requirements artifacts will be recorded and addressed here.
We will not be reviewing the use case flows of events at this point, as these will be reviewed in detail later in the course.
The requirements artifacts can be found in the Payroll Requirements Document. See the table of contents of that document for specific page numbers.