2 thu thap va mo hinh yeu cau

  • 1,331 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,331
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
20
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • The Business Modeling discipline provides organizational context for the system. This is the context in which the requirements are defined and analyzed. The purpose of the Requirements discipline is: To establish and maintain agreement with the customers and other stakeholders on what the system should do. To provide system developers with a better understanding of the system requirements. To define the boundaries of (delimit) the system. To provide a basis for planning the technical contents of iterations. To provide a basis for estimating cost and time to develop the system. To define a user-interface for the system, focusing on the needs and goals of the users. The Analysis and Design discipline 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.
  • A requirement is defined as "a condition or capability to which a system must conform". User Requirements Need to understand how the organization operates at present What are the problems with the current system? What are the requirements users have of a new system that are not in the current system?
  • Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration. These are often best described in a use-case model and in use cases . Functional requirements thus specify the input and output behavior of a system. Requirements that are not functional, such as the ones listed below, are sometimes called non-functional requirements . Many requirements are non-functional, and describe only attributes of the system or attributes of the system environment. Although some of these may be captured in use cases , those that cannot may be specified in Supplementary Specifications . Nonfunctional requirements are those that address issues such as those described below. A complete definition of the software requirements , use cases , and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature" or other subsystem grouping.
  • Purpose To understand who are the stakeholders of the project. To collect requests on what needs the system should fulfill. To prioritize stakeholder requests. Steps Determine Sources for Requirements Gather Information Conduct Requirements Workshops Evaluate Your Results
  • Determine Sources for Requirements To identify individuals who will act as stakeholders in your "extended project team". To determine and prioritize sources for requirements For an existing system, the first set of input to this activity will be the set of postponed enhancement requests , which have been gathered throughout the product lifecycle as part of the formal change request management process. This will provide a valuable starting point from which to gather data and further refine your set of stakeholder requests . After this initial information has been gathered, look for partners, users, customers, domain experts, and industry analysts who can represent your stakeholders . Determine which individuals you would work with to collect information, considering their knowledge, communication skills, availability, and "importance". These individuals will act as stakeholders of your project—in effect, an "extended project team". In general, it is better to have a small (2–5) group of people that can stay with you for the duration of the project. Also, the more people there are in your extended team, the more time it will take to manage them and make sure that you use their time effectively. These people do not work fulltime on the project—they typically participate in one or a few requirements gathering workshops in the inception and elaboration phases, and later on in review sessions. Find a way to learn how others do what you are trying to do. If you are developing a software product, this would mean to gather competitive information. If you are developing a new version of an in-house information system, you need to schedule site visits to see how people are using the current system and find out what can be improved. An important source is any existing descriptions of the organization in which the system is to be used. These could either be business models produced as described in the business modeling discipline, or any other form of business definition.
  • Gather Information Formulate which questions that need to be answered. Gather and document information. Interviews One of the most useful methods of gathering information is to conduct interviews with a select group of key stakeholders. Some sample questions and techniques that may be used are found in the Work Guidelines: Interviews .  See the supplied template for Artifact: Stakeholder Requests for a sample script for conducting an effective interview. Questionnaires This is a widely used technique. After conducting several interview, you may realize that the same information is appearing over and over again. This type of information may be collected into a set of questions with typical answers from which to choose and send to a larger set of stakeholders. This method allows you to better gather formal statistics on the answers that are given to the included questions. They key, however, is to be able to formulate questions in such a way that these statistics give realistic results of what your stakeholders actually need. The stakeholders may be able to answer and send the results back to you via the internet. This allows you to reach a much wider range of people than if you do direct interviews, but you have less control of the results. You are not there to directly communicate with the person answering the questions to clarify any issues or misunderstandings. Questionnaires can be a very powerful tool, but they do not replace a direct interview. Also, an assumption is that relevant questions can be determined in advance, and that you can phrase them so that the reader hears them in the intended way.
  • Interviews Aim is to get an in-depth understanding of the organization’s objectives, users’ requirements and people’s roles Includes: managers to understand objectives staff to understand roles and information needs customers and the public as potential users Advantages: personal contact allows the inetrviewer to respond adaptively to what is said it is possible to probe in greater depth if the interviewee has little or nothing to say, the interview can be terminated Disadvantages: can be time-consuming and costly notes must be written up or tapes transcribed after the interview can be subject to bias if interviewees provide conflicting information this can be difficult to resolve later Appropriate situations: most projects at the stage in fact finding when in-depth information is required Requires skill to carry out effectively (See Box 6.1 for guidelines) Questionnaires This is a widely used technique. After conducting several interview, you may realize that the same information is appearing over and over again. This type of information may be collected into a set of questions with typical answers from which to choose and send to a larger set of stakeholders. This method allows you to better gather formal statistics on the answers that are given to the included questions. They key, however, is to be able to formulate questions in such a way that these statistics give realistic results of what your stakeholders actually need. The stakeholders may be able to answer and send the results back to you via the internet. This allows you to reach a much wider range of people than if you do direct interviews, but you have less control of the results. You are not there to directly communicate with the person answering the questions to clarify any issues or misunderstandings. Questionnaires can be a very powerful tool, but they do not replace a direct interview. Also, an assumption is that relevant questions can be determined in advance, and that you can phrase them so that the reader hears them in the intended way.
  • Questionnaires Aims to obtain the views of a large number of people in a way that can be analysed statistically Includes: postal, web-based and email questionnaires open-ended and closed questions gathering opinion as well as facts Advantages: economical way of gathering information from a large number of people effective way of gathering information from people who are geographically dispersed a well designed questionnaire can be analysed by computer Disadvantages: good questionnaires are difficult to design no automatic way of following up or probing more deeply postal questionnaires suffer from low response rates Appropriate situations: when views of large numbers of people need to be obtained when staff of organization are geographically dispersed for systems that will be used by the general public and a profile of the users is required
  • Observation Aim is to see what really happens, not what people say happens Includes: seeing how people carry out processes seeing what happens to documents obtaining quantitative data as baseline for improvements provided by new system following a process through end-to-end Can be open-ended or based on a schedule Advantages: first-hand experience of how the system operates high level of validity of the data can be achieved verifies information from other sources allows the collection of baseline data Disadvantages: people don’t like being observed and may behave differently, distorting the findings requires training and skill logistical problems for the analyst with staff who work shifts or travel long distances ethical problems with personal data Appropriate situations: when quantitative data is required to verify information from other sources when conflicting information from other sources needs to be resolved when a process needs to be understood from start to finish
  • Background Reading Aim is to understand the organization and its business objectives Includes: reports organization charts policy manuals job descriptions documentation of existing systems Advantages: helps to understand the organization before meeting the people who work there helps to prepare for other types of fact finding documentation of existing system may help to identify requirements for functionality of new system Disadvantages: written documents may be out of date or not match the way the organization really operates Appropriate situations: analyst is not familiar with organization initial stages of fact finding
  • Conduct Requirements Workshops To make the project team meet the stakeholders of the project. To gather a comprehensive "wish list" from stakeholders of the project. To prioritize the collected requirements based on stakeholders attending the workshop
  • 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.
  • A Use-Case Model describes a system’s functional requirements in terms of use cases. It is a model of the system's intended functionality and its environment. The Use-Case Model serves as a contract between the customer and the developers. Because it is a very powerful planning instrument, the Use-Case Model is generally used in all phases of the development cycle. When the customer approves the Use-Case Model, you know the system is what the customer wants. You can also use the model to discuss the system with the customer during development. Potential users use the Use-Case Model to better understand the system. Designers use it as a basis for their work and to get a system overview. Testers use it to plan testing activities (use case and integration testing) as early as possible. Those developing the next version of the system use it to understand how the existing version works. Documentation writers use the use cases as a basis for writing the system user guides. The architect uses the Use-Case Model to identify architecturally significant functionality. The manager uses it to plan and follow up on use-case modeling and subsequent design. Introduce the students to use-case models. Remember, this is probably the first time that they have seen a use-case model. Actors and use cases are discussed on the next several slides. Use this slide to set the context for that discussion. You might describe a use-case model as a menu. People can place themselves in a role (actor) and see the options available to them on this system. A use-case model does NOT imply the order that use cases execute.
  • An actor represents a coherent set of roles that users of the system play when interacting with these use cases. Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system.
  • A use case is a sequence of actions a system performs to yield an observable result that is of value to a particular actor. A use case describes what a system does, but it does not specify how it does it.
  • 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. 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.
  • 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.
  • The workflow of a use case describes what needs to be done by the system to provide the value that the served actor is looking for. It consists of a sequence of activities that, together, produce something for the actor. The workflow often consists of a basic flow and one or several alternative flows. The structure of the workflow can be described graphically with the help of an activity diagram.
  • An activity diagram may include the following elements: Activity states represent the performance of an activity or step within the workflow. Transitions show what activity state follows after another. Decisions evaluate conditions defined by guard conditions. These guard conditions determine which of the alternative transitions will be made and, thus, which activities are performed. You may also use the decision icon to show where the threads merge again. Decisions and guard conditions allow you to show alternative threads in the workflow of a use case. Synchronization bars show parallel sub-flows. They allow you to show concurrent threads in the workflow of a use case.
  • 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 developed primarily during the Inception and Elaboration phases, because it is important to agree on a common terminology early in the project. In Inception and Elaboration, it is used by domain experts (for example, business analysts) to explain all the domain-specific terminology used in their use cases. In Elaboration and 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 it 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. Not all of these elements need to be in it. A project needs to establish the template to be used on that particular project. Introduction : Provides 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.
  • The nonfunctional requirements and functional requirements not captured by the use cases are included in the Supplementary Specifications. The Supplementary Specifications include constraints on the implementation. Functionality : List of the functional requirements that are general to many use cases. Usability : 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. Supplementary Specifications go hand-in-hand with the Use-Case Model, implying that: They are initially considered in the Inception phase as a complement to defining the scope of the system. They are refined in an incremental fashion during the Elaboration and Construction phases.
  • 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.

Transcript

  • 1. Chương 2: THU THẬP và MÔ HÌNH YÊU CẦU THU THẬP YÊU CẦU (Requirement Capture) 10/03/11
  • 2. Nội dung
    • Mục đích của thu thập và mô hình yêu cầu
    • Định nghĩa yêu cầu
    • Phát hiện yêu cầu (Requirements Elicitation)
    • Đàm phám và phê chuẩn yêu cầu (Requirements Negotiation and Validation)
    10/03/11
  • 3. Requirements in Context
    • The purpose of Requirements is to:
    • Establish and maintain agreement with the customers and other stakeholders on what the system should do.
    • Give system developers a better understanding of the requirements of the system.
    • To define the boundaries of (delimit) the system.
    • Provide a basis for planning the technical contents of the iterations.
    • Provide a basis for estimating cost and time to develop the system.
    • Define a user interface of the system.
    10/03/11
  • 4. Định nghĩa yêu cầu
    • "A requirement is a condition or capability to which a system must conform".
    • Yêu cầu là các dịch vụ (services) được mong đợi của hệ thống và các ràng buộc (constraints) mà hệ thông phải tuân theo.
    10/03/11
  • 5. Phân loại yêu cầu
    • Yêu cầu chức năng (Function requirements): các hành động gì mà hệ thống có thể thực hiện mà không xem xét các ràng buộc vật lý.
      • Các dịch vụ hệ thống (System services): các chức năng mà hệ thống cung cấp
      • Yêu cầu về dữ liệu (Data requirements): các dữ liệu mà hệ thống phải xử lý
    • Yêu cầu phi chức năng (Non-Function Requirements): các ràng buộc hệ thống, các thuộc tính và môi trường của hệ thống.
      • Yêu cầu về giao diện (Look and Feel), Yêu cầu về thực hiện (Performance), Yêu cầu về bảo mật (Security), …
    10/03/11
  • 6. C ác kỹ thuật
    • Requirements Elicitation: Phát hiện yêu cầu
    • Use Case Modelling: Lập mô hình usecase
    • Prototyping: Tạo mô hình phác thảo ban đầu cho các chức năng và giao diện người dùng của hệ thống
    10/03/11
  • 7. Phát hiện yêu cầu
    • Mục đích:
      • Nhận diện các cá nhân liên quan (stakeholders) tới dự án
      • Tập hợp các yêu cầu mà hệ thông phải thực hiện.
      • Sắp thứ tự ưu tiên các yêu cầu.
    • Các bước thực hiện:
      • Xác định nguồn của các yêu cầu
      • Thu thập thông tin
      • Hội thảo để phát hiện yêu cầu (Conduct Requirements Workshops)
      • Prototyping
      • Đánh giá kết quả.
    10/03/11
  • 8. Xác định nguồn yêu cầu
    • Stakeholder
      • là các cá nhân có ảnh hưởng tới kết quả của dự án, và là các đối tượng chúng ta sẽ làm việc để thu thập thông tin.
    • Một nguồn thông tin quan trọng khác là các tài liệu đang tồn tại của tổ chức mô tả hoạt động của hệ thống đang sử dụng
      • Có thể là các mô hình nghiệp vụ (business models)
      • Hoặc các biểu mẫu thương mại khác.
    • Xác định và sắp thứ tự ưu tiên các nguồn thông tin yêu cầu.
    10/03/11
  • 9. Thu thập thông tin
    • Mục đích:
      • Xác định các câu hỏi nào cần được trả lời.
      • Thu thập và viết tài liệu cho thông tin thu thập được.
    • Phương pháp truyền thống để thu thập thông tin
      • Interviewing: Phỏng vấn khách hàng và chuyên gia về lĩnh vực liên quan.
      • Questionnaires: Bảng câu hỏi.
      • Observation: Quan sát.
      • Background reading: Nghiên cứu tài liệu tổ chức và tài liệu hệ thống phần mềm đang tồn tại.
    10/03/11
  • 10. Interviewing – Phỏng vấn
    • Phỏng vấn nhằm đạt được hiểu biết sâu về mục tiêu của tổ chức, vai trò và yêu cầu người dùng
    • Phỏng vấn cấu trúc (Structured interview)
      • Các câu hỏi xác định trước và có lịch phỏng vấn rõ ràng.
    • Phỏng vấn không cấu trúc (Unstructured interview)
      • Gặp mặt không chính thức; câu hỏi, mục tiêu không định trước.
    • Các loại câu hỏi nên tránh:
      • Opinionated: Người được phỏng vấn cho ý kiến của mình.
      • Biased: Câu hỏi định hướng để tìm câu trả lời cụ thể
      • Imposing: Giả định câu trả lời cho câu hỏi.
    10/03/11
  • 11. Questionnaires - Bảng câu hỏi
    • Nhằm đạt được thông tin từ nhiều người và kết quả có thể phân tích thống kê.
    • Đặc điểm:
      • Bảng câu hỏi có thể được gởi qua thư, email, hoặc dựa web
      • Dùng thu thập ý kiến hoặc dữ kiện.
      • Bảng câu hỏi phải được thiết kế tốt và dễ trả lời
    • Các loại câu hỏi
      • Câu hỏi mở: câu trả lời có thể không đoán trước được.
      • Câu hỏi đóng: Câu trả lời được chọn từ danh sách cung cấp trước.
      • Có thể dùng câu hỏi đóng và hạn chế câu hỏi mở
      • Các câu hỏi đóng có thể:
        • Multi-choice questions: Câu hỏi nhiều chọn lựa
        • Rating questions: Câu hỏi đánh giá từ yếu tới mạnh
        • Ranking questions: Câu hỏi xếp hạng. từ 1 – 10 hoặc tỉ lệ %
    10/03/11
  • 12. Observation - Quan sát
    • Nhằm tìm kiếm điều thực sự xảy ra, không phải điều người ta nói.
    • Bao gồm:
      • Quan sát người ta thực hiện xử lý công việc như thế nào và điều gì xảy ra.
        • Quan sát thụ động: Quan sát các hoạt động mà không bị dừng ngang hoặc không tham gia trực tiếp  dùng camera
        • Quan sát chủ động: Tham gia trực tiếp vào các hoạt động xử lý thương mại.
      • Đi theo một xử lý từ đầu đến cuối.
      • Đạt được các dữ liệu định lượng để làm cơ sở cho các cải tiến được cung cấp bởi hệ thống mới.
    10/03/11
  • 13. Background reading
    • Nhằm tìm hiểu về tổ chức và mục tiêu kinh doanh của nó.
    • Bao gồm:
      • Tài liệu của tổ chức
        • Các biểu mẫu thương mại, các thủ tục làm việc, miêu tả công việc, các kế hoạch thương mại, các hướng dẫn (manuals), các biểu đồ tổ chức …
      • Tài liệu của hệ thống đang tồn tại
        • Các biểu mẫu (forms) và các báo cáo (reports), tài liệu người dùng, tài liệu phân tích và thiết kế hệ thống, …
      • Các yêu cầu về tri thức của lĩnh vực liên quan
        • Tạp chí thương mại, sách tham khảo
    10/03/11
  • 14. Các phương pháp hiện đại để phát hiện yêu cầu
    • Được sử dụng khi rủi ro của dự án cao, các nhân tố rủi ro bao gồm:
      • Mục tiêu không rõ ràng
      • Các thủ tục làm việc không được tài liệu hóa
      • Các yêu cầu không ổn định
      • Người phát triển không có kinh nghiệm.
      • Sư hợp tác củas người dùng không đầy đủ.
    • Các phương pháp:
      • Conduct Requirements Workshops
        • Hội thảo phát hiện yêu cầu
      • Prototyping
        • Một GUI, mà mô phỏng ứng xử hệ thống
    10/03/11
  • 15. Hội thảo phát hiện yêu cầu
    • Mục đích
      • Tạo điều kiện cho nhóm dự án gặp các stakeholder của dự án
      • Để thu thập các yêu cầu tinh tế hơn từ các stakeholder.
      • Để sắp thứ tự các yêu cầu được tập hợp dựa trên các stakeholder tham dự hội thảo.
    • Có thể sử dụng một số kỹ thuật phát hiện thông tin
      • Brainstorming: Thảo luận tập thể
        • Trong một thời gian ngắn, cho phép mọi người trình bày ý kiến, hay cảm nhận quan trọng của mình về dự án.
      • Role playing: Đóng kịch
        • Từng thành viên được phân một vai trò đáng quan tâm của dự án. Thảo luận và ghi nhận trách nhiệm của từng vaui trò
        • Một kỷ thuật tổ hợp với Role playing là Class Responsibility Collaboration (CRC) cards
    10/03/11
  • 16. Prototyping – Tạo hệ thống phác thảo
    • Prototype là một hệ thống có tính trình diễn
      • Một mô hình làm việc “nhanh và thô” của giải pháp cho hệ thống, nhằm kiểm tra một số chức năng nào đó.
      • Có thể miêu tả GUI cho các ứng xử khác nhau của hệ thống.
      • Nột dung có thể mã cứng (hard-coded) hơn là truy cập động từ CSDL.
    • Không thể thiếu trong quy trình phát triển phần mềm
      • Tính khả thi và hữu dụng của hệ thống có thể ước lượng qua prototype trước khi thực sự được cài đặt.
    • Thường được dùng khi:
      • Hệ thống xây dựng cho các chức năng thương mại mới.
      • Dùng trong quá trình xây dựng kịch bản cho use case.
      • Các yêu cầu xung đột
      • Có vấn đề truyền thông giữa khách hàng và người phát triển
    10/03/11
  • 17. Các kiểu Prototyping
    • “ Throw-away” prototype
      • Bỏ đi khi tiến trình tìm kiếm yêu cầu hoàn tất.
      • Tập trung vào các yêu cầu ít hiểu biết nhất.
      • Thường thực hiện ở bước xác định yêu cầu.
    • Evolutionary prototype
      • Được giữ lại sau khi tiến trình tìm kiếm yêu cầu hoàn tất
      • Thường đưa ra cho sản phẩm cuối cùng.
      • Hướng đến việc phát triển nhanh hệ thống bằng cách tập trung vào các yêu cầu đã hiểu biết nhất (là chung cho nhiều hệ thống)
    10/03/11
  • 18. Đàm phám và phê chuẩn yêu cầu
    • Yêu cầu phát hiện từ khách hàng thường:
      • Chồng chéo và xung đột.
      • Mơ hồ hoặc không thực tế.
      • Một số yêu cầu chưa được khám phá.
      •  Cần đàm phán với khách hàng đẩ phê chuẩn yêu cầu trước khi viết tài liệu yêu cầu.
    • Các công việc thường phải thực hiện:
      • Xác định các yêu cầu ngoài phạm vi (Out of scope requirements)
      • Xác định các yêu cầu chồng chéo và xung đột.
      • Phân tích rủi ro và sắp thự tự quyền ưu tiên các yêu cầu.
    10/03/11
  • 19. Xác định các yêu cầu ngoài phạm vi
    • Là nhiệm vụ của bước phân tích yêu cầu nhằm xác định biên hệ thống (system boudary)
    • Các yêu cầu được phân loại ở ngoài phạm vi do:
      • Quy định ràng cuộc của tổ chức.
      • Giới hạn của ngân quỹ của dự án.
      • Quá khó cài đặt vào hệ thống máy tính.
      • Có quyền ưu tiên thấp và được loại ra khỏi phiên bản đầu tiên của hệ thống.
      • Được cài đặt trong các thiết bị phần cứng khác, nằm ngoài điều khiển của hệ thống phần mềm.
    10/03/11
  • 20. THU THẬP và MÔ HÌNH YÊU CẦU MÔ HÌNH YÊU CẦU HỆ THỐNG 10/03/11
  • 21. Tài liệu kết quả của bước yêu cầu 10/03/11 Các đặc tả bổ sung (Supplementary Specification) Bảng chú giải (Glossary) Các đặc tả Use Case (Use Case Specifications) ... Use-Case Model Actors Các Use Case
  • 22. What Is a Use-Case Model?
    • Là mô hình ứng xử hệ thống
      • System behavior is the outwardly visible and testable activity of a system and is captured in use cases.
    • A model that describes a system’s functional requirements in terms of use cases.
    • A model of the system’s intended functions (use cases) and its environment (actors).
    • Use cases describe the system, its environment, and the relationship (or interactions) between the system and its environment.
    10/03/11
  • 23. Lược đồ Use Case 10/03/11 Actor Use case Communication association Withdraw Client View Balance
  • 24. Actor
    • Actor là vai trò của con người, thiết bị hay hệ thống khác … mà tương tác trực tiếp với hệ thống qua các use case.
      • Ở bên ngoài hệ thống và cần các dịch vụ hệ thống.
      • Một vai trò không phải là một người cụ thể.
    • Nhận diện các Actor:
      • Ai cần đến một dịch vụ nào đó cung cấp bởi hệ thống?
      • Hệ thống được dùng ở đâu trong tổ chức?
      • Ai có lợi ích từ việc dùng hệ thống?
      • Ai sẽ cung cấp, dùng, hủy thông tin của hệ thống?
      • Ai hỗ trợ và bảo trì hệ thống?
      • Hệ thống có dùng các tài nguyên bên ngoài?
    10/03/11
  • 25. Use case
    • Use case là một dãy các hành động mà hệ thống thực hiện nhằm đạt được một kết quả về giá trị có thể nhận biết được cho một actor cụ thể .
      • Biểu diễn một đơn vị chức năng đầy đủ.
      • Một đơn vị chức năng có thể nhìn thấy từ bên ngoài
      • Mỗi use case có thể được kích hoạt bởi một actor
        • Một khi kích hoạt, nó có thể tương tác hay cung cấp kết quả cho actor khác.
    • Phát hiện từ
      • Các yêu cầu chức năng được diễn dịch thành các use case
      • Actor và mục đích của họ đối với hệ thống.
    10/03/11
  • 26. Quan hệ giữa actor và use case
    • Communication Association :
      • Biểu diễn sự truyền thông giữa actor và use case
      • Hướng mũi tên biểu diễn ai kích hoạt việc truyền thông.
    10/03/11 Client kích hoạt use case Withdraw Use case Withdraw truy cập thông tin tài khoản từ Bank System Withdraw Client Bank System
  • 27. Video Store case study
    • Cho khách hàng thuê băng và đĩa video
    • Tất cả các băng và đĩa đều được mã vạch (bar-coded) và dùng một thiết bị quét tích hợp với hệ thống để đọc.
    • Thẻ khách hàng thành viên cũng được mã vạch.
    • Các khách hàng có thẻ thành viên có thể đặt thuê trước các băng video nhận ở một ngày cụ thể nào đó.
    • Trả lời các câu hỏi của khách hàng, bao gồm cả các câu hỏi về các phim mà cửa hàng không có
    10/03/11
  • 28. Nhận diện actor
    • Người dùng:
      • Nhân viên (Employee)
    • Thiết bị:
      • Thiết bị quét (Scanning Device)
    10/03/11
  • 29. Nhận diện Use Case
    • Các chức năng kích hoạt gián tiếp bởi Employee thông qua Scanning Device:
      • Rent Video
      • Return Video
    • Chức năng Employee:
      • Reserve Video
      • Answer Inquiry
      • Maintain Customer Information
      • Maintain Video Information
    10/03/11
  • 30. Video Store - Use case diagram 10/03/11 Rent Video Return Video Reserve Video Scanning Device Maintain Customer Answer Enquiry Employee Maintain Video <<depends on>>
  • 31. Ví dụ: Hệ thống đăng ký học phần
    • Hệ thống mới cho phép sinh viên đăng ký học phần và xem phiếu điểm từ một máy tính cá nhân đượ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.
    • Trường sẽ giữ lại cơ sở dữ liệu sẵn có về danh mục học phần mà lưu trữ toàn bộ thông tin về học phần. Hệ thống mới sẽ đọc các thông tin học phần trong 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ì các thông tin 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, như tên giáo sư, khoa, và các học phần phần tiên quyết sẽ được cung cấp để giúp sinh viên chọn lựa.
    10/03/11
  • 32.
    • Sinh viên được chọn bốn học phần được mở trong học kỳ tới và có thể chọn thêm 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 để đăng ký các học phần muốn học. Sinh viên chỉ có thể thêm hoặc hủy các học phần đã đăng ký trong khoảng thời gian này. Khi quá trình đăng ký hòan tất, hệ thống sẽ gửi thông tin đăng ký của các sinh viên tới hệ thống thanh toán (billing system) để các 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 phải được thông báo về sự thay đổi trước khi xác nhận lịch các học phần đã đăng ký.
    • Ở cuối học kỳ, sinh viên có thể truy cập vào hệ thống để xem phiếu điểm. Vì điểm của sinh viên là thông tin nhạy cảm cần được giữ kín, nên hệ thống phải 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ũng có thể xem danh sách các sinh viên đã đăng ký vào lớp của họ, và cũng có thể nhập điểm sau mỗi khóa học.
  • 33. Nhận diện actor
    • Người dùng:
      • Sinh viên (Student)
      • Giáo sư (Professor)
      • Nhân viên giáo vụ (Registrar)
    • Hệ thống khác:
      • Danh mục học phần (Course Catalog)
      • Hệ thống thanh toán học phí (Billing System)
    10/03/11
  • 34. Nhận diện Use Case
    • Chức năng cho mọi actor:
      • Đăng nhập hệ thống (Login)
    • Các chức năng sử dụng bởi Student:
      • Đăng ký học phần (Register for Course)
      • Xem phiếu điểm (View Report Card)
    • Các chức năng sử dụng bởi Professor:
      • Đăng ký môn dạy (Select Courses to Teach)
      • Nộp điểm (Submit Grades)
    • Nhiệm vụ của Registrar:
      • Kết thúc đăng ký (Close Registration)
      • Cập nhật thông tin giáo sư (Maintain Professor Information)
      • Cập nhật thông tin sinh viên (Maintain Student Information)
    10/03/11
  • 35. 10/03/11 View Report Card Student Register for Courses Submit Grades Course Catalog Professor Select Courses to Teach Maintain Student Information Maintain Professor Information Billing System Registrar Close Registration User Login
  • 36. Quan hệ phụ thuộc giữa các use case
    • Quan hệ bao gồm (Include)
    • Quan hệ mở rộng (Extend)
    10/03/11
  • 37. Quan hệ Include
    • Một use case luôn luôn bao gồm dãy các ứng xử của một use case khác
    • Được dùng để tách một dãy các ứng xử giống nhau mà được dùng bởi nhiều use case
    10/03/11 Withdraw Client View Balance List Account <<include>> <<include>>
  • 38. Quan hệ Extend
    • Một use case cung cấp thêm chức năng cho một use case khác
      • Biểu diễn ứng xử tùy chọn, nhiều công việc khác nhau được thực hiện dựa vào việc chọn lựa của actor.
      • Chỉ được kích hoạt dưới một điều kiện nào đó.
      • Điểm mở rộng (extension points) trình bày điều kiện khi nào việc mở rộng xảy ra.
    10/03/11 View Balance Print Balance <<extend>>
  • 39. Actor Generalization
    • M ột actor c ó thể tham gia vào tất cả các truyền thông với các use case m à &quot;super actor&quot; có, ngoài các use case kh ác của nó.
    10/03/11 Login User Register for Courses Student Select Courses to Teach Professor Close Registration Registrar
  • 40. Use-Case Specifications
    • Name
    • Actors
    • Brief description
    • Flow of Events
    • Relationships
    • Activity diagrams
    • Use-Case diagrams
    • Special requirements
    • Pre-conditions
    • Post-conditions
    • Other diagrams
    10/03/11
  • 41. Use-Case Specifications
    • Brief description describes the role and purpose of the use case.
    • Actors
    • Flow of events are textual descriptions of what the system does with regard to the use case. There can be multiple flows of events — for example, a basic flow and alternative flows.
    • Pre-conditions define a constraint on the system regarding when the use case may start.
    • Post-conditions define a constraint on the system that applies after the use case has terminated.
    10/03/11
  • 42. Use-Case Specifications
    • Relationships are communicates-associations. The use case includes and extends relationships that the use case participates in.
    • Activity 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.
    • Special requirements is a textual description that collects all use-case requirement
    • Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen captures from an user-interface prototype .
    10/03/11
  • 43. Use-Case Flows of Events
    • Là dãy các hành động mà hệ thống phải thực hiện và tương tác với actor để thực hiện Use case
    • Has one normal, basic flow (Main Flow or Happy Path)
    • Several 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
    10/03/11 “ Happy Path”
  • 44.
    • Scenario là một thể hiện của use case, là một dòng sự kiện qua một use case
    • Mỗi use case có thể có nhiều kịch bản thực hiện.
      • Phải tìm ra một kịch bản tiêu biểu giải quyết chung cho hầu hết các trường hợp  Dòng sự kiện chính (Main Flow)
      • Các trường hợp thay đổi khác sẽ xử lý riêng  Dòng lựa chọn hay dòng ngoại lệ (Alternative Flow)
    Scenarios là gì ? 10/03/11
  • 45. Đặc tả use case: Rent Video
    • Brief Description
      • Use case này cho phép nhân viên cửa hàng xử lý yêu cầu thuê băng hoặc đĩa video của khách hàng.
    • Actors
      • Nhân viên (Employee), Thiết bị quét (Scanning Device)
    • Preconditions
      • Không
    • Postconditions
      • Videos được cho khách hàng thuê và cơ sở dữ liệu được cập nhật tương ứng.
    10/03/11
  • 46. Đặc tả use case: Rent Video (tt)
    • Main Flow
      • Use case bắt đầu khi khách hàng muốn thuê băng đĩa
      • Nhân viên dùng thiết bị quét thẻ thành viên của khách hàng.
      • Hệ thống kiểm tra băng đĩa video thuê quá hạn và mức độ đáng tin của khách hàng.
      • Nhân viên quét mã vạch của các video khách hàng muốn thuê. Số lượng băng đĩa khách hàng thuê tối đa là 8.
      • Nhân viên nhập ngày thuê và hạn trả cho từng bản ghi thuê video.
      • Hệ thống tính toán và hiển thị lệ phí thuê video.
      • Sau khi khách hàng thanh toán, nhân viên in biên nhận thuê video và chọn chức năng Save
      • Hệ thống cập nhật các bản ghi thuê video.
    10/03/11
  • 47. Đặc tả use case: Rent Video (tt)
    • Alternative Flows
      • Khách hàng có video quá hạn Hệ thống sẽ hiển thị nhắc nhở và ghi chú “quá hạn” tới khách hàng và use case kết thúc. Nếu video không được trả trong vòng 2 ngày kể từ hạn trả, một ghi chú khác được khởi tạo và khách hàng bị ghi nhận là “đã vi phạm” (không đáng tin)
      • Khách hàng không đáng tin Khách hàng sẽ được yêu cầu đóng tiền thế chấp cho từng video thuê
      • Khách hàng không có thẻ thành viên Nhân viên sẽ kích hoạt use case Maintain Customer để đăng ký và cấp thẻ cho khách hàng.
      • Nếu nhiều hơn 8 video được thuê, hệ thống sẽ hiển thị nhắc nhở.
      • Thẻ thành viên hoặc video bị hư, máy quét không thể nhận được, hệ thống sẽ hiển thị nhắc nhở.
    10/03/11
  • 48. Viết kịch bản use case dạng 2 cột 10/03/11 Actor: Employee Video Store System 1. Nhân viên dùng thiết bị quét thẻ thành viên của khách hàng. 2. Hệ thống kiểm tra băng đĩa video thuê quá hạn hoặc mức độ đáng tin của khách hàng 3. Nhân viên sẽ quét mã vạch của các video khách hàng muốn thuê. Số lượng băng đĩa khách hàng thuê phải nhỏ hơn 8 4. Nhân viên nhập ngày thuê và hạn trả cho từng bản ghi thuê video. 5. Hệ thống tính toán và hiển thị lệ phí thuê video 6. Sau khi khách hàng thanh toán, nhân viên in biên nhân thuê video và chọn chức năng Save 7. Hệ thống cập nhật các bản ghi thuê video.
  • 49. Đặc tả use case: Register for Courses
    • Tóm tắt
      • Use case này cho phép một sinh viên đăng ký các lớp học được mở trong học kỳ hiện tại. Sinh viên còn có thể cập nhật hoặc xóa các lớp học đã chọn nếu các thay đổi này diễn ra trong thời gian cho phép thay đổi đăng ký vào đầu học kỳ.
    • Actor
      • Student
    • Điều kiện tiên quyết
      • Student phải đăng nhập vào hệ thống trước khi use case bắt đầu.
    • Post-Conditions
      • Nếu use case thành công, các lớp mà sinh viên chọn học sẽ được cập nhật vào lịch học của sinh viên . Ngược lại, trạng thái của hệ thống vãn không đổi.
    10/03/11
  • 50. Đặc tả use case: Register for Courses
    • Dòng sự kiện chính
      • Use Case này bắt đầu khi một sinh viên muốn đăng ký học phần, hoặc thay đổi lịch học đã đăng ký.
      • Hệ thống yêu cầu sinh viên chọn chức năng muốn thực hiện : Create a Schedule, Update a Schedule, Delete a Schedule.
      • Nếu sinh viên chọn “Creat e a Schedule”, luồng phụ Creat e a Schedule được thực hiện. Nếu sinh viên chọn “Update a Schedule”, luồng phụ Update a Schedule được thực hiện. Nếu sinh viên chọn “Delete a Schedule”, luồng phụ Delete a Schedule được thực hiện.
    10/03/11
  • 51. Đặc tả use case: Register for Courses
    • Các d òng sự kiện phụ
      • Create a Schedule
        • Hệ thống lấy danh sách học phần có mở trong học kỳ từ hệ thống Course Catalog System và thể hiện dưới dạng danh sách cho sinh viên chọn.
        • Sinh viên chọn 4 học phần bắt buộc và hai học phần tự chọn từ danh sách trên.
        • Sau khi sinh viên chọn, hệ thống tạo một lịch học chứa những học phần sinh viên đã đăng ký.
        • Sinh viên kiểm tra và xác nhận lịch học, Submit Schedule được thực thi.
      • Update a Schedule
        • Hệ thống lấy và hiển thị lịc học mà sinh viên đã đăng ký (trong học kỳ hiện tại)
        • Hệ thống lấy danh sách học phần có mở trong học kỳ từ hệ thống Course Catalog System và thể hiện dưới dạng danh sách cho sinh viên chọn.
        • Sinh viên có thể cập nhật lại bằng cách xóa và tạo mới. Sinh viên có thể chọn thêm những học phần mới hoặc loại bỏ những học phần đã đăng ký.
        • Sau khi sinh viên lựa chọn xong, hệ thống cập nhật lại lịch học cho sinh viên.
        • Luồng sự kiệ n Submit Schedule được thực hiện.
    10/03/11
  • 52. Đặc tả use case: Register for Courses
    • Các d òng sự kiện phụ
      • Delete a Schedule
        • Hệ thống lấy và hiển thị lịch học mà sinh viên đã đăng ký (trong học kỳ hiện tại).
        • Hệ thống yêu cầu sinh viên xác nhận việc xóa.
        • Sinh viên xác nhận việc xóa.
        • Hệ thống xóa lịch học của sinh viên.
        • Hệ thống xóa lịch học của sv
      • Submit Schedule
        • Đối với mỗi học phần trong lịch học, chưa được đánh dấu là “enrolled in”,
        • H ệ thống sẽ kiểm tra sinh viên đã đủ những điều kiện tiên quyết chưa, học phần đó có mở và không có mâu thuẫn trong lịch học (như là trùng giờ...).
        • Hệ thống sẽ thêm sinh viên vào học phần đã chọn. Học phần được đánh dấu là “enrolled in” trong lịch học. Lịch học được lưu vào hệ thống.
    10/03/11
  • 53. Đặc tả use case: Register for Courses
    • Alternative Flows
      • Save a Schedule
        • Tại mọi thời điểm sinh viên có thể chọn lưu lịch học trước khi submit.
      • Unfulfilled Prerequisites, Course Full, or Schedule Conflicts
        • Nếu luồng sự kiện phụ Submit Schedule, nếu sinh viên chưa chọn đủ các học phần theo qui định, hoặc học phần đã đầy, hoặc trong lịch học bị xung đột giữa các học phần (trùng giờ...), thông báo lỗi sẽ được gửi đến sv.Sinh viên phải chọn học phần khác và use case tiếp tục hoặc sinh viên hủy việc đăng ký và use case khởi tạo lại từ đầu.
      • No Schedule Found
        • Khi trong hai luồng sự kiện Update a Schedule Delete a Schedule, hệ thống không nhận được lịch học của sinh viên, thông báo lỗi sẽ hiễn thị trên màn hình.
  • 54. Đặc tả use case: Register for Courses
    • Alternative Flows
      • Course Catalog System Unavailable
        • Nếu không kết nối được với hệ thống Course Catalog, hệ thống sẽ hiển thị thông báo cho sinh viên.
      • Course Registration Closed
        • Khi thời gian đăng ký cho học kỳ hiện tại đã kết thúc, sinh viên vào đăng ký sẽ nhận được thông báo và hệ thống không cho phép sinh viên tiếp tục.
      • Delete Cancelled
        • Nếu trong dòng sự kiện phụ Delete A Schedule, sinh viên quyết định không xóa lịch học, lệnh xóa bị huỷ bỏ và Dòng sự kiện chính được re-started lại từ đầu.
  • 55. What Is an Activity Diagram?
    • An activity diagram in the Use-Case Model can be used to capture the activities in a use case.
    • It is essentially a flow chart, showing flow of control from activity to activity.
    10/03/11 Flow of Events This use case starts when the Registrar requests that the system close registration. 1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress. 2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.
  • 56. Example: Activity Diagram of Register for Course Usecase 10/03/11
  • 57.
    • UI Prototype l à c á c ph á c thảo giao diện người d ù ng (User interface – UI) để hỗ trợ viết kịch bản use case một c á ch hiệu quả.
    UI Prototype 10/03/11 Ví dụ: Renting Video prototype
  • 58. Glossary 10/03/11 Bảng chú giải Giới thiệu Tài liệu này được dùng để định nghĩa các thuật ngữ đặc thù trong lĩnh vực của bài toán, giải thích các từ ngữ có thể không quen thuộc đối với người đọc trong các mô tả use case hoặc các tài liệu khác của dự án. Thường thì tài liệu này có thể được dùng như một từ điển dữ liệu không chính thức, ghi lại các định nghĩa dữ liệu để các mô tả use case và các tài liệu khác có thể tập trung vào những gì hệ thống phải thực hiện. Các định nghĩa Bảng chú giải này bao gồm các định nghĩa cho các khái niệm chính trong Hệ thống đăng ký học phần. 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 cụ thể được mở cho một học phần trong một học kỳ cụ thể – cùng một học phần có thể được mở song song nhiều lớp trong một học kỳ. Thông tin bao gồm cả ngày và giờ học trong tuần. 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.
  • 59. Supplementary Specification
    • Include the nonfunctional requirements and functional requirements not captured by the use cases.
    • Include constraints on the implementation.
      • Functionality (Chức năng)
      • Usability (Tính dễ dùng)
      • Reliability (Tính đáng tin)
      • Performance (Hiệu suất)
      • Supportability (Tính hỗ trợ)
      • Design constraints (Ràng buộc thiết kê)
    10/03/11
  • 60.
    • 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 dễ 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 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ợ
      • Không có.
    • Các ràng buộc thiết kế
      • Hệ thống tích hợp với Hệ thống danh mục học phần có sẵn, một CSDL RDBMS.
      • Hệ thống phải cung cấp giao diện dựa Web.
    Supplementary Specification 10/03/11