2-Thu thap va mo hinh yeu cau.ppt

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 kỹ thuật Requirements Elicitation

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

hiện (Performance), Yêu cầu về bảo mật (Security), …

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

Phát hiện yêu cầu

 Các bước thực hiện:

Workshops)

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

 Stakeholder

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

 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

 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

tiêu của tổ chức, vai trò và yêu cầu người dùng

interview)

trước

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

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.

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

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

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

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

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

 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

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

Các kiểu Prototyping

 Evolutionary prototype

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:

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:

requirements)

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:

tiên của hệ thống

điều khiển của hệ thống phần mềm

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

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

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

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.

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

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

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

 Actor và mục đích của họ đối với hệ thống.

Quan hệ giữa actor và use case

 Communication Association :

Withdraw Client

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ó

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:

Video Store - Use case diagram

Rent Video

Return Video

Reserve Video Scanning Device

Employee

Maintain Video

<<depends on>>

Ví dụ: Hệ thống đăng ký học phần

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

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

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

 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 Ngoài ra mỗi sinh viên 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ý

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ệ

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

Nhận diện actor

 Người dùng:

 Hệ thống khác:

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

Billing System

Registrar

Close Registration User

Login

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ệ Include

của một use case khác

mà được dùng bởi nhiều use case

Withdraw Client

View Balance

List Account

<<include>>

<<include>>

Quan hệ Extend

use case khác

được thực hiện dựa vào việc chọn lựa của actor

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 Registrar

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

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

Scenarios là gì ?

Đặc tả use case: Rent Video

 Brief Description

thuê băng hoặc đĩa video của khách hàng

Đặc tả use case: Rent Video (tt)

 Main Flow

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 và mức độ đáng tin của khách hàng.

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

Đặc tả use case: Rent Video (tt)

1 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à

4 Nếu nhiều hơn 8 video được thuê, hệ thống sẽ hiển thị nhắc nhở.

5 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ở.

Viết kịch bản use case dạng 2 cột

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.

Đặc tả use case: Select Courses to Teach

giáo sư có thể dạy được và muốn dạy trong học kỳ sắp tới

 Điều kiện tiên quyết

đầu

 Post-Conditions

được cập nhật

Đặc tả use case: Select Courses to Teach

Use case này bắt đầu khi một giáo sư muốn đăng ký dạy một số lớp trong học kỳ sắp tới

sư có thể dạy trong học kỳ hiện tại Hệ thống cũng truy xuất và hiển thị các lớp mà giáo sư này đã đăng ký dạy

thuẫn với nhau không (ví dụ như có cùng ngày, giờ dạy) Nếu như không có mâu thuẫn, hệ thống cập nhật thông tin cho mỗi lớp học được giáo sư chọn (ví dụ như ghi nhận giáo sư là người giảng dạy cho lớp này)

Đặc tả use case: Select Courses to Teach

 Dòng sự kiện khác

1 Mâu thuẫn trong lịch dạy

Nếu hệ thống tìm thấy mâu thuẫn trong lịch dạy khi giáo sư đăng ký lớp dạy, hệ thống sẽ hiển thị một thông báo lỗi Hệ thống cũng chỉ ra các lớp học gây mâu thuẫn Giáo sư có thể hoặc giải quyết mâu thuẫn này (ví dụ như hủy dạy một số lớp) hoặc hủy thao tác Trong trường hợp này, chọn lựa của giáo sư sẽ bị mất và use case kết thúc.

2 Hệ thống Danh mục học phần không sẵn sàng

Nếu hệ thống không thể kết nối được với Hệ thống Danh mục học phần, hệ thống sẽ hiển thị một thông báo lỗi Giáo sư xác nhận thông báo lỗi và use case kết thúc.

3 Đăng ký học phần đã bị đóng

Nếu khi use case bắt đầu, nó xác đinh được quá trình đăng ký cho học

kỳ này đã bị đóng, một thông báo sẽ được hiển thị cho giáo sư và use case kết thúc Giáo sư không thể thay đổi lớp dạy sau khi quá trình đăng ký cho học kỳ này đã bị đóng Nếu một thay đổi giáo sư cần

thiết xảy ra sau khi quá trình đăng ký bị đóng, nó sẽ được xử lý bên ngoài phạm vi của hệ thống.

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.

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