Bài giảng Chương 2: Thu thập và mô hình yêu cầu

Bài giảng Chương 2: Thu thập và mô hình yêu cầu nêu lên 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án và phê chuẩn yêu cầu (Requirements Negotiation and Validation).

Chương 2:

THU THẬP và MÔ HÌNH YÊU CẦU

THU THẬP YÊU CẦU (Requirement Capture)

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)

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.

Đị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.

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), …

Các hành động bước yêu cầu

Use Case Model

Project Initiation

Document

Select requirements

Develop use cases

Requirements discipline

Glossary

C ác kỹ thuật và kết quả

 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

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ả.

Xác định nguồn yêu cầu

 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.

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

 Cá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.

 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.

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ê.

 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ệ %

 Đ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.

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

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 đủ

 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

Hội thảo phát hiện yêu cầu

 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.

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 thông tin của GUI 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

 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

Các kiểu Prototyping

 “Throw-away” prototype – hệ thống phác thảo bỏ đi

 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 – hệ thống phác thảo tiến hóa

 Đượ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)

Đà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.

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)

 Dùng lược đồ ngữ cảnh (context diagram) để định nghĩa phạm vi hệ thống

 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

Chương 2:

THU THẬP và MÔ HÌNH YÊU CẦU

MÔ HÌNH YÊU CẦU HỆ THỐNG

Nhắc lại: Các hành động bước yêu cầu

Use Case Model

Project Initiation

Document

Select requirements

Develop use cases

Requirements discipline

Glossary

Tài liệu kết quả của bước yêu cầu

Các đặc tả bổ sung (Supplementary Specification)

Bảng chú giải (Glossary)

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.

Lược đồ Use Case

Actor Communication Use case

association

Withdraw

Client

View Balance

 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?

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.

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.

Withdraw Client

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 môn học phần tiên

quyết sẽ được cung cấp để giúp sinh viên chọn lựa.

 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 lịch 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 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 Bởi 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

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)

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)

View Report Card

Student

Register for Courses

Submit Grades

Course Catalog System

Billing System

Registrar

Close Registration User

Login

Video Store

 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ó

Nhận diện Use Case

 Chức năng Employee:

 Reserve Video

 Order Video

 Answer Inquiry

 Maintain Customer Information

 Maintain Video Information

 Các chức năng kích họat bởi Scanning Device:

 Rent Video

 Return Video

Video Store - Use case diagram

Rent Video

Return Video

Reserve Video Scanning Device

Maintain Customer Answer Enquiry

Employee

Order Video

<<depends on>>

Quan hệ phụ thuộc giữa các use case

 Quan hệ bao gồm (Include) giữa các use case.

 Quan hệ mở rộng (Extend)

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.

View Balance Print Balance

<<extend>>

Register for Courses Student

Select Courses to Teach Professor

Close Registration

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.

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.

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

“Happy Path”

 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ì ?