ÔN TẬP GIỮA KỲ
NỘI DUNG
1. Phát biểu vấn đề 2. Tầm nhìn và Phạm vi (Vision and
Scope)
3. Xác định mục tiêu 4. Xác định yêu cầu 5. Xác định StackHolder, lớp người dùng 6. Các kỹ thuật thu nhận yêu cầu 7. Các kỹ thuật phân tích yêu cầu 8. Bài tập
Product Vision và Project Scope
Vision (hay mission) mô tả thực chất sản phẩm
sẽ là cái gì.
Project scope xác định một phần của mục đích lâu dài (long-term product vision) của sản phẩm mà dự án hiện hành đang thực thi.
Vision dùng để chỉ đến cả hệ thống phần mềm, nó phản ánh mục tiêu nghiệp vụ (business objectives) của hệ thống, còn scope chỉ liên quan đến từng dự án riêng lẻ hay một lần lặp trong quá trình phát triển tăng tiến các chức năng của hệ thống.
BM HTTT - Khoa CNTT - HUI 3
Product Vision và Project Scope
Vision thay đổi tương đối chậm, scope thay đổi linh động theo mỗi dự án tùy thuộc vào các ràng thời gian (schedule), ngân sách buộc về (budget), tài nguyên (resource) và chất lượng (quality) của dự án.
Các tài liệu nên có của mỗi dự án mới
Vision and scope document Software Requirement Specification (SRS)
BM HTTT - Khoa CNTT - HUI 4
Product vision và project scope
BM HTTT - Khoa CNTT - HUI 5
Vision và Scope Document
Tài liệu bao gồm một mô tả về cơ hội kinh doanh của sản phẩm, tầm nhìn và các mục tiêu của sản phẩm, báo cáo phạm vi và các giới hạn của sản phẩm, mô tả đặc tính của khách hàng (characterization of customers), các ưu tiên của dự án, mô tả các tiêu chuẩn đánh giá sự thành công của dự án.
Tài liệu cần tương đối ngắn, chỉ nên từ 3 tới 8 trang, phụ thuộc chủ yếu vào bản chất và kích thước của dự án.
BM HTTT - Khoa CNTT - HUI 6
Vision và Scope Document
Các vấn đề thuộc tầm nhìn và phạm vi (vision and scope) của dự án cần được phân giải rõ trước khi các yêu cầu chức năng (functional requirements) chi tiết được đặc tả đầy đủ.
Một tài liệu tầm nhìn và phạm vi (vision and scope) tốt sẽ cung cấp các tham chiếu cần thiết cho việc thêm, xoá bỏ, chỉnh sửa các yêu cầu trong tiến trình phát triển của dự án.
BM HTTT - Khoa CNTT - HUI 7
Tài liệu về vision và scope
Chủ nhân của tài liệu vision and scope là:
Người tài trợ chính (executive sponsor) của
dự án
Người chi tiền (funding authority) Người phân tích yêu cầu (requirements
analyst) có thể làm việc với owner để viết tài liệu vision and scope.
BM HTTT - Khoa CNTT - HUI 8
Tài liệu về vision và scope
Yêu cầu nghiệp vụ nên thu thập từ những ai hiểu rõ vì
Khách hàng Người có trách nhiệm trong bô phận quản lý Người hình dung của dự án Quản lý sản phẩm Các chuyên gia lãnh vục Thành viên của bộ phận marketing
sao họ quan tâm đến dự án. Họ là: Customer Senior management Project visionary Product manager Subject matter expert Members of the marketing department.
BM HTTT - Khoa CNTT - HUI 9
Scope of a project
Cần phải xác định scope (=boundary) của
phần mềm.
Một trong các rủi ro lớn nhất của hệ thống là để cho scope “phình ra” (‘creep’), không ai biết chính xác hệ thống bao gồm những gì, mất bao lâu và chi phí bao nhiêu để hoàn tất.
BM HTTT - Khoa CNTT - HUI 10
Scope of a project
BM HTTT - Khoa CNTT - HUI 11
Scope of a project
BM HTTT - Khoa CNTT - HUI 12
Xác định những người liên quan
Stakeholder:
Bao gồm những người, tổ chức mà là một phần của môi trường hệ thống. Hệ thống cung cấp cho họ những lợi ích và họ có tầm quan trọng trong hệ thống
BM HTTT - Khoa CNTT - HUI 13
Stakeholder
• Customers
• Users
• Requirements analysts
• Developers
• Testers
• Documentation writers
• Project managers
• Legal staff – nhóm người làm việc hợp pháp
• Manufacturing people – người sản xuất
• Sales, marketing, field support, help desk, …
14
Stakeholder của hệ thống ATM
Khách hàng của ngân hàng Đại diện của các ngân hàng khác Người quản lý ngân hàng Nhân viên thu tiền Người quản trị CSDL Người quản lý bảo mật Kỹ sư bảo trì phần cứng và phần mềm Những người điều phối ngân hàng…
BM HTTT - Khoa CNTT - HUI 15
Stakeholder
Stakeholder không rõ những gì họ thật sự muốn Stakeholder diễn đạt yêu cầu theo những thuật ngữ
riêng của họ
Những stakeholder có thể có những yêu cầu tranh
chấp
Nhân tố quyền lực và tổ chức ảnh hưởng tới yêu cầu
hệ thống
Những yêu cầu có thể thay đổi trong quá trình phân
tích, có thể xuất hiện những nhân tố mới, những thay đổi về môi trường nghiệp vụ
BM HTTT - Khoa CNTT - HUI 16
Thực hành
Bạn là người quản lý sản phẩm cho một công ty công cụ máy. Giám đốc yêu cầu bạn phát triển một máy cắt mới quần áo để may váy thời trang theo các kích cỡ và mẫu. Máy được bán cho những người làm quần áo khắp thế giới 1. Các stakeholder? 2. Phân tích và đánh giá các stakeholder?
BM HTTT - Khoa CNTT - HUI 17
Answer #1
Key stakeholders are:
Giám đốc và các cổ đông trong công ty Nhân viên bán hàng và tiếp thị của công ty Khách hàng (những người vận hành máy cắt và chủ
của họ)
Quan chức chính quyền phụ trách về sức khỏe và an toàn trong mỗi quốc gia mà ta dự định bán máy cho họ.
Các đối thủ cạnh tranh (negative stakeholders). Nếu công ty có ý định đảm nhận thêm khâu bảo trì
máy móc thì đội bảo hành cũng là stakeholder chính.
Answer #1
How will you analyse and validate your
stakeholder list? Kiểm tra (check) và cập nhật (update) danh
sách một cách thường xuyên; duyệt lại (review) và theo dõi (follow) thông qua các cuộc tiếp xúc gặp gỡ với stakeholder chính
Trang 34
Phân loại người dùng
Dựa vào các yếu tố sau:
Mức độ thường xuyên người dùng sử dụng
sản phẩm
Kinh nghiệm về miền ứng dụng của họ, sự
thành thạo về hệ thống máy tính
Các tính năng mà người dùng sử dụng Các tác vụ để hỗ trợ xử lý nghiệp vụ Quyền truy xuất và cấp độ bảo mật
BM HTTT - Khoa CNTT - HUI 20
Phân cấp người dùng
BM HTTT - Khoa CNTT - HUI 21
Kinh nghiệm phân loại người dùng
Nên phân loại người dùng sớm để có thể thu thập yêu cầu từ đại diện của mỗi lớp người dùng.
Không nên e ngại nếu lúc đầu có quá nhiều lớp
người dùng
Không nên bỏ qua bất kỳ lớp người dùng nào vì
sau này có thể sẽ phải rework
Ghép chung các lớp người dùng nào có yêu cầu tương tự nhau. Nên giảm xuống sao cho không quá 15 lớp người dùng khác nhau.
BM HTTT Khoa CNTT - HUI 22
Tài liệu người dùng
Ghi chép các lớp người dùng, tính cách, trách nhiệm, và địa điểm làm việc vào tài liệu SRS
Giúp đội phát triển xếp loại độ ưu tiên các yêu cầu Giúp các tester xây dựng cách sử dụng hệ thống (usage profile for the system) và có thể lập kế hoạch cho việc kiểm thử
BM HTTT Khoa CNTT - HUI 23
Tìm đại diện người dùng
Mỗi loại dự án đều cần có đại diện người dùng thích hợp để cung cấp tiếng nói chung cho nhóm người dùng đó.
Người đại diện không chỉ tham gia trong giai đoạn thu thập yêu cầu mà trong suốt chu kỳ phát triển dự án
BM HTTT Khoa CNTT - HUI 24
Đại diện lớp người dùng (user representatives)
Đối với ứng dụng của công ty: dễ dàng xác định
người dùng thực sự cho mỗi lớp người dùng. Ví dụ: chọn Fred là kỹ sư hóa cho lớp chelmistt
Đối với phần mềm
thương mại (commericial software): chỉ có thể có được người dùng thực sự sau khi phát hành phiên bản chạy thử (beta-testing) hay đầu tiên Nên thiết lập nhóm người tình nguyện (focus group) từ những người dùng phần mềm của mình hay phần mềm của đối thủ
BM HTTT Khoa CNTT - HUI 25
Người dùng tiêu biểu PC
PC (Product champion) dùng để chỉ những thành viên chính trong cộng đồng người dùng cung cấp cho dự án các yêu cầu.
Cs (Champions) là các người dùng thực sự, không phải là người đại diện như nhà tài trợ, nhân viên tiếp thị, người quản lý …
BM HTTT - Khoa CNTT - HUI 26
Vai trò của Product Champiom
PC (Product champion) thu thập yêu cầu từ các thành viên khác thuộc lớp người dùng mà họ đại diện và hợp nhất lại yêu cầu không giống nhau.
Phát triển yêu cầu là trách nhiệm chung
của nhà phân tích và khách hàng đã được chọn, mặc dù nhà phân tích sẽ là người viết yêu cầu.
BM HTTT - Khoa CNTT - HUI 27
Một PC tốt
Có cái nhìn rõ ràng về hệ thống mới và ủng hộ hệ thống vì họ thấy được lợi ích dành cho họ từ hệ thống mới này.
Là người cởi mở và được đồng nghiệp tín
nhiệm.
Là người hiểu biết thấu đáo về nghiệp vụ và
môi trường hoạt động của hệ thống.
Nhận thức được tầm quan trọng của họ đối
với sự thành công của dự án.
BM HTTT - Khoa CNTT - HUI 28
PC bên ngoài
Khi phát triển phần mềm thương mại, rất khó tìm
PC từ bên ngoài.
Nếu có quan hệ công việc gần gũi với 1 số công ty, một số người thể sẵn lòng tham gia vào quá trình thu thập yêu cầu.
Nên khích lệ bằng kinh tế cho các PC bên ngoài như giảm giá sản phẩm hay trả tiền theo giờ khi họ tham gia công việc
BM HTTT - Khoa CNTT - HUI 29
Quyền hạn của product champion
Phương pháp dùng PC chỉ tốt khi mỗi champion có quyền đưa ra các quyết định đại diện cho lớp của minh
Nếu quyết định của champion luôn bị gạt bỏ bởi managers hay SW group thì thời gian và thiện chí của họ sẽ bị lãng phí.
Nhưng champion cũng nên nhớ rằng họ
không phải là khách hàng duy nhất
BM HTTT - Khoa CNTT - HUI 30
Hạn chế tử PC
Làm thế nào để tránh chỉ nghe yêu cầu từ CP mà bỏ qua các nhu cầu từ các khách hàng khác.
Nếu khách hàng đa dạng thì trước tiên cần nhận biết yêu cầu cơ bản chung cho mọi khách hàng, sau đó xác định các yêu cầu khác từ các loại người dùng khác, từ bộ phận tiếp thị, từ khách hàng riêng lẻ,…
BM HTTT - Khoa CNTT - HUI 31
Goal và requirement
Goals là cái mà stakeholders muốn thực thi. Goals có thể có nhiều mức độ khác nhau:
Mức cao nhất (highest level): phát biểu về nhiệm vụ và mục tiêu, chính là mission statements and objectives.
(Có thể dùng Mission = vision = objective)
Mục tiêu lâu dài thì được gọi là policies. Mức thấp nhất (lowest level): gọi là chức năng
cơ bản riêng biệt (individual functions)
BM HTTT - Khoa CNTT - HUI 32
Goal và requirement
Mục tiêu chi tiết sẽ trở thành requirement khi: Có thể kiểm chứng được (fully verifiable) Được xếp loại ưu tiên trong 1 dự án cụ thể
BM HTTT - Khoa CNTT - HUI 33
Question 2
You are a product manager for a machine tool company. The directors have asked you to develop a new cutting machine to cut cloth for fashionable dresses of all sizes and patterns. The machine will be sold to clothing makers around the world.
a. What are the major goals for this project? b. Using the list of stakeholders for this project, identify the likely sources of tension (possible conflict) between stakeholders’ goals.
Answer #2
Major goals: - Đưa máy cắt ra thị trường đúng lúc và trong ngân sách
dự tính
- Phát triển 1 dòng sản phẩm mới. - Đạt được chứng nhận an toàn (safety certificate) ở tất
cả các quốc gia dư định bán máy.
- Hiểu được yêu cầu trong từng quốc gia mà ta dự định
bán máy,
- Chuẩn bị tài liệu cho người dùng và người bán hàng
bằng nhiều thứ tiếng tương ứng với các quốc gia mà ta dự định bán máy.
- Bảo đảm là bộ phận bảo hành phải sẵn sàng - Bảo đảm là bộ phận phân phối tiếp thị đã sẵn sàng - Hiểu rõ các đối thủ cạnh tranh và có chiến lược đối phó
Yêu cầu (requirement)
Một yêu cầu là một đặc trưng của hệ thống, hay là sự mô tả những việc, mà hệ thống có khả năng thực hiện để hoàn thành mục tiêu của hệ thống
Yêu câù cũng có thê ̉là các ràng buộc trong quá trình
phát triển hệ thống.
Yêu cầu có thể được ràng buộc bởi hợp đồng hay văn
bản
Có những yêu cầu ngầm định (implicit) Một yêu cầu có thể được nhận biết (known, spoken)/
không nhận biết (forgotten, unspoken…)
Requirements described the “what” of a system, not the
“how”
36
36
Vai trò của yêu cầu
Yêu cầu quan trọng vì nó cung cấp các cơ sở cho tất cả công việc phát triển hệ thống sau đó. Ngay khi yêu cầu được xác định, nhà phát triển khởi đầu các công việc kỹ thuật khác như: thiết kế hệ thống, phát triển, kiểm thử, thực thi và vận hành.
37
Phân loại yêu cầu
Yêu cầu được phát biểu (stated requirement) Yêu cầu thực (real requirement)
38
Stated Requirements
Là các yêu cầu được cung cấp bởi khách
hàng khi bắt đầu phát triển hệ thống.
Các dạng yêu cầu:
Yêu cầu về thông tin Dự toán Bảng báo giá Phát biểu công việc (statement of work –
SOW)
39
Real Requirements
Là các yêu cầu phản ánh nhu cầu xác thực của
người dùng.
Thường khác nhau rất lớn giữa yêu cầu phát
biểu và yêu cầu thực.
Việc phân tích các yêu cầu khách hàng (stated requirements) được dùng để xác định và tinh chỉnh các nhu cầu thực sự của khách hàng.
40
Requirements Engineering
Là hệ thống các phương thức có liên quan với nhau chỉ định cái mà khách hàng muốn hệ thống làm gì.
There are two majors tasks in the requirements
engineering: Analysis Modeling
41
Requirements Engineering
Analysis is the process of determining
what the customer wishes the system to do and formally creating a list of requirements that the customer can understand and agree to do.
Modeling is a process of interpreting the customer requirements into something that software engineers can understand.
42
Phân loại yêu cầu trong quá trình phân tích yêu cầu
Gồm hai loại chính: • Yêu cầu chức năng (Function requirements) • Yêu cầu phi chức năng (Non Functional Requirements)
43
Yêu cầu chức năng (Functional requirements)
Yêu cầu chức năng (Functional requirements):
chức năng dịch vụ hệ thống cung cấp.
Xác định chức năng của phần mềm mà các nhà phát triển phải xây dựng để giúp người dùng hoàn thành nhiệm vụ của họ, thỏa mãn được yêu cầu nghiệp vụ.
Đôi khi còn được gọi là behavioral requirements. Ví dụ: “The system shall e-mail a reservation
confrimation the user”
44
Yêu cầu chức năng (Functional requirements)
Yêu cầu chức năng (Functional requirements): Yêu cầu chức năng chỉ ra những gì hệ thống làm, chúng thường quan hệ các use-case hay những qui tắc nghiệp vụ (business rule) • Một số yêu cầu chức năng • Chức năng tính toán • Chức năng lưu trữ • Chức năng tìm kiếm • Chức năng kết xuất • Chức năng backup, restore • Chức năng đa người dùng • Chức năng đa phương tiện…
45
Yêu cầu chức năng (Functional requirements)
Thí dụ: Trong hệ thống quản lý thư viện • Người dùng có thể tìm kiếm, download, in những bài
báo
• Người dùng được cấp một vùng lưu trữ riêng để có
thể copy để lưu trữ tài liệu lâu dài…
46
Yêu cầu phi chức năng (Non-functional requirements
Yêu cầu phi chức năng (Non-functional requirements): Không tập trung vào các chức năng của hệ thống mà chỉ tập trung vào các ràng buộc của hệ thống. Những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển…, chủ yếu là những yêu cầu về chất lượng.
Sáu loại chính của yêu cầu phi chức năng: security, privacy,
usability, reliability, availability, and performance.
Ràng buộc: phản ảnh những đặc trưng của miền ứng dụng. Chúng có thể là những yêu cầu chức năng hay yêu cầu phi chức năng.
47
Yêu cầu phi chức năng (Non-functional requirements
Một số yêu cầu phi chức năng • Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu
trữ…
• Các chuẩn được sử dụng, các công cụ CASE, ngôn
ngữ lập trình…
• Yêu cầu của người sử dụng: dễ sử dụng, thân thiện • Ràng buộc về ngân sách • Phù hợp với các chính sách của tổ chức sử dụng hệ
thống
• Yêu cầu tương thích giữa phần cứng và phần mềm • Các yêu cầu từ các tác nhân ngoài khác…
48
Yêu cầu phi chức năng (Non-functional requirements
Ví dụ Trong hệ thống quản lý thư viện • Yêu cầu sản phẩm: giao diện người dùng không chứa
frame và applet java
• Yêu cầu tổ chức: qui trình phát triển hệ thống và tài liệu phân phối phải phù hợp theo tiêu chuẩn “STAN- 07” (sử dụng ngôn ngữ, phương pháp thiết kế…)
• Yêu cầu ngoài: hệ thống không được lộ thông tin của
khách hàng (tên, số tham chiếu…)
49
Phân loại yêu cầu
50
Đặc trưng của yêu cầu
Khả thi - Feasible Có giá trị - Valid Không nhập nhằng - Unambiguous Dễ kiểm chứng - Verifiable Dễ biến đổi - Modifiable Toàn vẹn - Consistent Đầy đủ - Complete Lần vết được - Traceable
51
Các mức yêu cầu
Software Requirement bao gồm 3 mức phân biệt: Yêu cầu nghiệp vụ (Business requirements) Yêu cầu người dùng (User requirements) Yêu cầu chức năng (Functional requirements)
52
Yêu cầu nghiệp vụ (Business requirements)
Biễu diễn các mục tiêu của tổ chức hay khách hàng yêu
cầu hệ thống phải có
Yêu cầu nghiệp vụ thường do người tài trợ cho dự án, khách mua phần mềm, người quản lý các người dùng, bộ phận tiếp thị (maketing)…cung cấp
Thường được ghi nhận trong phần đặc tả (vision) và phạm vi (scope) của tài liệu, đôi khi còn được gọi là tuyên bố dự án (project charter) hay tài liệu yêu cầu thị trường (market requirements document)
53
Yêu cầu người dùng (User requirements)
Mô tả mục tiêu (goal) hay tác vụ (task) của người
dùng đối với hệ thống.
Các cách để biểu diễn yêu cầu người dùng:
Use cases, scenario Bảng event-response.
Yêu cầu người dùng mô tả cái (what) mà người dùng
có thể làm đối với hệ thống.
Ví dụ: use case "Make a Reservation" dùng trong các website của hàng không, thuê xe, hay khách sạn.
54
Yêu cầu chức năng (Functional requirements)
Xác định chức năng của phần mềm mà các nhà phát triển phải xây dựng để giúp người dùng hoàn thành nhiệm vụ của họ, thỏa mãn được yêu cầu nghiệp vụ.
Đôi khi còn được gọi là yêu cầu về hành vi
(behavioral requirements)
Ví dụ: Hệ thống sẽ gởi một xác nhận giữ chỗ
cho khách hàng…
55
Các kỹ thuật thu nhận yêu cầu
Document Sampling Interviewing Survey and observation Questionaires Workshop and Brainstorming JAD (Joint Application Development)
sessions
Document Sampling
Document Sampling Interviewing Survey and observation Questionaires Workshop and Brainstorming JAD (Joint Application Development)
sessions
Interviewing
• Là kỹ thuật trực tiếp và đơn giản • Nếu bạn cần biết một số điều, bạn hỏi
một vài người
Có 5 bước cơ bản để phỏng vấn
Chọn người được phỏng vấn Thiết kế câu hỏi phỏng vấn Chuẩn bị cho phỏng vấn Hướng dẫn phỏng vấn Thực hiện phỏng vấn tiếp
Interviewing
Chọn người phỏng vấn Cần một kế hoạch phỏng vấn
Danh sách tất cả những người để phỏng vấn Khi nào mỗi người sẽ được phỏng vấn Mục đích gì ở họ sẽ được phỏng vấn
Danh sách có thể là không chính thức … hoặc nó có
thể là một phần của phân tích dự án Danh sách được dựa vào thông tin cần Tốt để tạo ra các phối cảnh khác nhau
Người quản lý (Managers) Người dùng (Users)
Chọn những người cho các lý do chung Phỏng vấn được lặp đi lặp lại
Interviewing
Thiết kế câu hỏi Đừng hỏi thông tin mà có thể đạt được tại nơi khác Muốn chỉ ra khía cạnh người phỏng vấn Mong muồn tạo nên thông tin tốt hơn.
Interviewing
Câu hỏi đóng
* Có bao nhiêu cuộc điện thoại được nhận trên một ngày? * Có bao nhiêu loại khách hàng? * Bạn muốn hệ thống mới cung cấp thông tin gì?
• Yêu cầu câu trả lời cụ thể • Có nhiều lựa chọn. • Có bao nhiêu yêu cầu • Người phân tích sẽ điều khiển • Thông tin rõ ràng
Câu hỏi mở
• Không yêu cầu câu trả lời cụ thể • Để thu thập thông tin và dữ liệu • Người phân tích có thể sửa đổi • Tạo một hệ thống hiệu quả
Câu hỏi tìm kiếm
Tiếp tục câu hỏi Có gạn lọc Khuyến khích mở rộng câu trả lời Chỉ ra những gì bạn nghe và thích thú
* Bạn nghĩ gì về hệ thống hiện tại? * Những vấn đề cơ bản nào bạn đối mặt hàng ngày? * Bạn quyết định chiến dịch quảng cáo thực hiện như thế nào? * Tại sao? * Bạn có thể đưa cho tôi một số ví dụ? * Bạn có thể giải thích chi tiết hơn?
Interviewing
Thiết kế câu hỏi Đừng hỏi thông tin mà có thể đạt được tại nơi khác Muốn chỉ ra khía cạnh người phỏng vấn Mong muồn tạo nên thông tin tốt hơn.
Interviewing
Chiến lược phỏng vấn
EXAMPLES?
TOP DOWN
High Level Very General Mức cao rất chung Medium-Level Moderately Specific Mức trung gian Xác định ở mức độ vừa phải Low-Level Very Specific
BOTTOM UP
Mức thấp rất chi tiết
Interviewing
Hướng dẫn phỏng vấn Trình diễn chuyên nghiệp và không thiên vị Xây dựng quan hệ (và trung thực) với người được phỏng vấn Ghi chép tất cả thông tin Kiểm tra tổ chức cách giải quyết theo băng thu âm Đảm bảo bạn hiểu tất cả các kết quả và ngôn ngữ Chia ra các sự kiện từ các quan điểm Đưa ra cho người được phỏng vấn thời gian để hỏi câu hỏi Đảm bảo để cảm ơn người được phỏng vấn Kết thúc thời gian
Interviews
Interviews
Exercise - Part 1
Find a partner for this exercise Think e-commerce system (hệ thống thương mại). You will now serve as “customer” for that project and your partner will act as “project lead – cố vấn” (of requirements consultant) for you.
Create an interview outline (be sure to include your name, customer name,
system name) that addresses at least 2 high-priority or high-risk items.
Conduct the interview Translate the responses into possible requirements. For each possible
requirement, answer the following: a. What kind of requirement is it? b. How does it (can it) meet the necessary condition for a requirement? Switch roles, you become the project lead and you partner the customer for
their project. Repeat the above with the new roles and project
Questionnaires
Được sử dụng thêm vào trong quá trình phỏng vấn. Mục tiêu là chứa đựng thông tin từ bộ phận tiêu biểu của nhiều khách hàng.
Bản câu hỏi hữu dụng khi người phân tích cần thu thập thông tin từ nhiều người. Nếu có ít thời gian thì bản câu hỏi rất hữu dụng.
Bản câu hỏi có thể không cho kết quả như ý từ những câu trả lời vì họ rất bận rộn và họ có thể cho rằng nó không quan trọng.
Có thể bao gồm những câu hỏi đóng và câu hỏi mở.
Questionnaires
Có những loại câu hỏi đóng sau:
1. Fill-in-the-blanks – Điền vào khoảng trống. 2. Dichotomous(Yes or No type) – Loại Yes hay No. 3. Ranking scale questions – Câu hỏi xếp loại. 4. Multiple-choice questions – Câu hỏi nhiều lựa chọn. 5. Rating scale questions are an extension of the multiple- choice questions – Câu hỏi phân loại là mở rộng của câu hỏi nhiều lựa chọn .
Workshop and Brainstorming
Có thể là kỹ thuật năng động nhất để thu thập
yêu cầu.
Tập hợp tất cả các stakeholder chính cùng với nhau trong 1 giai đoạn tuy ngắn nhưng rất tập trung.
Sử dụng facilitator có kinh nghiệm từ bên ngoài trong quản lý yêu cầu có thể bảo đảm cho sự thành công của workshop.
Brainstorming là phần quan trọng nhất của
workshop.
Brainstorming
Ý tưởng then chốt JAD
Cho phép người quản lý dự án, người dùng và
người phát triển làm việc với nhau
Có thể giảm phạm vi đến 50% Tránh đòi hỏi quá chi tiết hoặc quá mơ hồ JAD được như 1 kỹ thuật để phát triển yêu
cầu của 1 hệ thống và trong các giai đoạn đầu của dự án phần mềm.
Mục đích: tập hợp MIS và người dùng cuối
trong cơ chế của 1 workshop, để cùng thống nhất (consensus) với nhau các yêu cầu của hệ thống.
Quản lý các vấn đề trong phiên JAD
Giảm sự thống trị Khuyến khích việc không liên quan của người
đóng góp
Bên ngoài cuộc thảo luận Chương trình nghị sự một chiều Sự đồng ý mạnh mẽ Xung đột không được giải quyết Xung đột đúng Sử dụng sự hài hước
JAD Team Members
Session leader coordinator – Người lãnh đạo User information source – Thông tin người dùng Manager information source – Thông tin người quản lý Sponsor champion – Người bảo trợ System analyst listener – Nhà phân tích hệ thống Scribe recorder – Máy ghi âm, người ghi chép IS staff listener – Người nghe
Việc dùng bảng có thể giúp nắm bắt được yêu cầu của stakeholder rõ ràng và chặt chẽ hơn. Bảng quyết định
Condition Stub
Condition Entry
1
2
3
4
5
6
Customer is individual ?
Y Y
.
.
.
.
Customer shopkeeper or retailer ?
. Y Y Y Y
.
Order-size 85 copies or more ?
.
. Y
.
.
.
Order-size 49-84 sarees ?
.
. Y
.
.
.
Order-size 13-48 copies ?
.
.
.
.
. Y
Order-size 12 or more ?
. Y
.
.
.
.
Order-size less than 12?
Y
.
.
.
. Y
Allow 50% discount
. X X
.
.
Allow 40% discount
.
. X
.
.
.
Allow 30% discount
X
.
.
.
. X
Allow 15% discount
.
.
.
.
. X
Bảng quyết định (Decision Tables)
Example: Consider the recruitment policy of ABC Software Ltd. • •
•
•
It the applicant is a BE then recruit otherwise not. If the person is from Computer Science, put him/her in the software development department and if the person is from non-computer science background put him/her in HR department. If the Person is from Computer Science and having experience equal to or greater than three years, take him/her as Team leader and if the experience is less than that then take the person as Team member. If the person recruited is from non Computer Science background, having experience less than three years, make him/her Management Trainee otherwise Manager
Bảng quyết định (Decision Tables)
Định nghĩa phân tích yêu cầu
I
Là quá trình suy luận các yêu cầu hệ thống thông qua quan sát hệ thống hiện tại, thảo luận với các người sử dụng, phân tích công việc.
U H
- T T N C a o h K
Việc này có thể liên quan với việc tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống.
Các mẫu hệ thống cũng có thể được phát triển để
- T T T H n ô M ộ B
mô tả các yêu cầu.
79
HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)
QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý 1. Định nghĩa tầm nhìn và phạm vi của dự án 2. Xác định các lớp người dùng 3. Xác định các đại diện thích hợp của mỗi lớp người
dùng
4. Xác định người ra quyết định về yêu cầu và quy
trình ra quyết định của họ
5. Chọn các kỹ thuật suy luận mà bạn sẽ dùng 6. Ứng dụng các kỹ thuật suy luận để phát triển các use cases và xếp thứ tự ưu tiên các use cases đó cho từng phần của hệ thống
BM HTTT Khoa CNTT - HUI 80
HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)
QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý 7. Thu thập thông tin về các thuộc tính chất lượng và các yêu cầu phi chức năng khác từ người dùng.
I
U H
8. Phác thảo các use cases từ các yêu cầu chức
năng cần thiết
9. Rà xét các mô tả use-case và các yêu cầu chức
- T T N C a o h K
năng
- T T T H n ô M ộ B
10. Phát triển các mô hình phân tích, nếu cần thiết, để làm sáng tỏ hiểu biết của những người tham gia suy luận về các phần của yêu cầu
81
HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)
QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý 11. Phát triển và đánh giá các nguyên mẫu giao diện người dùng nhằm trực quan hoá các yêu cầu chưa được hiểu kỹ
12. Phát triển các test cases dưới dạng ý tưởng từ các
use cases
13. Sử dụng các test cases để kiểm tra các use cases, các yêu cầu chức năng, các mô hình phân tích, các nguyên mẫu
14. Lặp lại các bước từ 6 đến 13 trước khi thực hiện
thiết kế và xây dựng từng phần của hệ thống
BM HTTT Khoa CNTT - HUI 82
Ma trận CRUD
I
U H
- T T N C a o h K
Là 1 cách để tìm yêu cầu bị thiếu. Viết tắt của Create, Read, Update, and Delete. Ma trận CRUD cho sự tương quan giữa các action của hệ thống với các thực thể dữ liệu giúp ta biết được mỗi data item được tạo, đọc, cập nhật, xóa ở đâu và như thế nào.
- T T T H n ô M ộ B
83
Ma trận CRUDL cho hệ thống theo dõi hóa chất
CRUDL (Create, Read, Update, Delete, List) Có thể rút ra các suy luận gì từ ma trận trên khi nói đến thực thể Requester ???
84 Bộ Môn HTTT - Khoa CNTT - HUI
Process Modeling Technique
Kỹ thuật mô hình hóa quy trình (model driven) phù hợp cho cả elicitation và analysis. Data flow diagrams (DFDs) Use case analysis (use case = business
process)
Data flow diagrams (DFDs)
Được sử dụng trong 1 thời gian dài Tập trung vào dòng dữ liệu và cấu trúc dữ liệu hơn là vào dịch vụ (services). DFD chi ra luồng dữ liệu của hệ thống thông tin, mối qua hệ giữa những luồng dữ liệu và làm thế nào dữ liệu được lưu trữ tại vị trí cụ thể
Data flow diagrams (DFDs)
Elements of Data Flow Diagrams(Những thành phần của
DFD) The External Entity - Tác nhân ngoài: nằm bên ngoài hệ thống, mô tả dữ liệu nguồn và dữ liệu đích của hệ thống
The Data Flow - Luồng dữ liệu: mô tả sự di chuyển của
dữ liệu.
The Data Store - Kho lưu trữ: mô tả dữ liệu mà nó
không di chuyển.
The Process - Quá trình: mô tả một hoạt động mà thay
đổi hay duy trì dữ liệu.
Data flow diagrams (DFDs)
Process
Data flow
Data store
External entity
Sơ đồ ngữ cảnh
Mức ngữ cảnh mô tả toàn bộ hệ thống ở mức tổng quá và hoạt động môi trường bên ngoài của nó và chỉ toàn bộ hệ thống như một quá trình. Diễn tả toàn bộ hệ thống bằng một ô xử lý DFD ngữ cảnh là sơ đồ ở mức tổng quát nhất DFD ngữ cảnh xác định phạm vi của hệ thống DFD ngữ cảnh không có kho dữ liệu
Sơ đồ ngữ cảnh
Vẽ một chức năng biểu diễn thực thể hệ thống
(process 0)
Xem hệ thống như là một hộp đen Nhận dạng ranh giới hệ thống Ranh giới giữa hệ thống đích và môi trường bên
ngoài
Tìm tất cả danh sách các đầu vào và đầu ra tại đỉnh đến hoặc đi từ thực thể ngoài, vẽ như các luồng dữ liệu
Vẽ các thực thể ngoài như nguồn hoặc đích của các
luồng dữ liệu
Sơ đồ ngữ cảnh
Hệ thống được mong đợi tự động hoá hoạt động của
thư viện Hai người dùng bên ngoài (terminators) 3 mục dữ liệu vào 1 mục dữ liệu ra
Một chức năng mức đỉnh (transform) -- Issue library
item
Thẻ thư viện
Yêu cầu
Thư viện
Độc giả
Đưa ra ngày
Nhân viên thư viện
Kết quả
Sơ đồ ngữ cảnh
Example: Student result management system (Hệ thống quản lý điểm cho sinh viên)
Administrator
Student information Reports generated
Subject
Marksheet generated
Student result Management System
Student
Marks
Student performance reports generated
The context diagram
Sơ đồ ngữ cảnh
Example: Student result management system (Hệ thống quản lý điểm cho sinh viên)
Administrator
User account maintenance
Student information Reports generated
0
Subject
Subject info entry
Marksheet generated
Student result Management System
Student
Student info entry
Student performance reports generated
Marks
Marks entry
0 – Level DFD of result management system
Sơ đồ DFD mức 0
Sơ đồ ngữ cảnh
Exercise : Railway Reservation System Railway caters to the need of passenger. Tickets can be booked for different classes. Some concessions are available for categories like students, old people, etc. there is a special category for reserving tickets for handicapped people, military, MPs. There is a certain surcharge levied for special trains. Fare computation depends on the class, category, train, and distance. The passenger is issued a confirmed ticket if seat is available. She/he gets a waitlisted/RAC ticket if she/he so desires. Vẽ sơ đồ ngữ cảnh
Phương pháp Use Case
Use Case: Mô tả những chức năng của hệ
thống từ hướng nhìn của người sử dụng.
Use case diagram:
Là một mô hình trong UML (Unified Modeling
Language)
Mô tả các chức năng mà hệ thống cung cấp Cho biết người dùng nào có thể tương tác với
chức năng nào
Phương pháp Use Case
Use Case: chức năng Actor: Tác Nhân Association: mối kết hợp
System
Actor
Use Case
Relationship
Phương pháp Use Case
Actor (Tác Nhân): là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống. Một tác nhân sẽ có một tên, và cái tên này cần phải phản ánh lại vai trò của tác nhân. Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp
GiangVien
Sinhvien
Hệ thống thanh toán Hệ thống Bảo mật
Xác định tác nhân
Ai sử dụng chức năng chính của hệ thống? Ai sẽ duy trì, quản lý và giữ cho hệ thống
làm việc?
Những phần mềm/hệ thống khác mà hệ
thống cần tương tác? Những hệ thống máy tính khác Những ứng dụng khác chạy trên cùng một máy
tính (i.e. X client/server)
Chú ý: tránh nhầm lẫn giữa sự tương tác
(interaction) với đầu vào (input)
99 Use Case Modeling
Xác định tác nhân
Là ai
Sử dụng hệ thống? Cài đặt hệ thống? Khởi động hệ thống? Duy trì hệ thống? Thoát hệ thống? Thu thập thông tin từ hệ thống? Cung cấp thông tin cho hệ thống?
Chuyện gì xảy ra tại một thời điểm định trước?
100 Use Case Modeling
Thời gian?
Xem thời gian như là một tác nhân Tác nhân thời gian có thể kích hoạt một
Use Case
101 Use Case Modeling
Phương pháp Use Case
Use Case (chức năng): Use Case là sự mô hình hoá những chức năng của hệ thống từ hướng nhìn của người sử dụng
Mỗi Use Case là một tập hợp của các hành động được thực hiện bởi một tác nhân tác động vào hệ thống để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể.
Nhậpđiểm
Xem điểm
Đăng ký học phần
Đặc tính của use case
Phải luôn được bắt đầu bởi một actor. Use case cung cấp giá trị cho một actor. Giá trị này
không đòi hỏi phải luôn luôn nổi bật nhưng nó phải có thể nhận thấy được.
Use case phải là một đơn vị đầy đủ. Thường hay sai lầm chia use case thành các use case nhỏ hơn và khi thực thi 1 use case này thì cần dùng đến các use case khác. Một use case sẽ không đầy đủ nếu không tạo ra được giá trị cuối dù cho để có giá trị cuối này phải xảy ra nhiều giao tiếp.
103 PTTKHT bang UML - BM HTTT
Tìm kiếm Use Case
Với mỗi tác nhân, ta xác định:
Những dịch vụ nào tác nhân yêu cầu từ hệ
thống?
Hệ thống có lưu trữ thông tin không?
Đọc, tạo, hủy, hiệu chỉnh, lưu trữ thông tin
Liệu tác nhân cần được thông báo về các sự kiện trong hệ thống, hay tác nhân cần thông báo cho hệ thống về việc gì đó không?
Công việc thường ngày của tác nhân có đơn
giản không?
Không nên chỉ tập trung vào hệ thống hiện tại
104 Use Case Modeling
Mối quan hệ giữa các Use Case
Association (mối kết hợp): Là sự kết hợp giữa những
Actor và Use case. Type of relationship
Uses Relationship – Quan hệ sử dụng Extends Use Case Relationship – Quan hệ mở rộng Generalization relationship – Quan hệ tạo nhóm
Relationship
Khi một nhóm các Use Case cùng chung một hành vi nào đó thì hành vi này có thể được tách riêng ra thành một Use Case riêng biệt và nó có thể được sử dụng bởi các Use Case kia.
«include»
OpenIncident
HelpDispatcher
«include»
AllocateResources
Quan hệ sử dụng giữa các Use Case
Generalization
<> & <>
Là 2 mối quan hệ giữa 2 use case với nhau Include: Nếu trong quá trình thực hiện use case A Người dùng luôn luôn/hầu như đều phải thực hiện use case B.
A <
include
A
B
<> & <>
Extend: nếu trong quá trình thực hiện use case A người
dùng có thể /lâu lâu phải thực hiện use case B
B<
extend
A
B
Example: Using <>
Lược đồ UC của hệ thống đặt chỗ trước
111 PTTKHT bang UML - BM HTTT
Đóng gói UC
112 PTTKHT bang UML - BM HTTT
Exercise
Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. Browse catalog and select items. Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson.
Exercise
USE CASES VÀ KỊCH BẢN SỬ DỤNG (USE CASES AND USAGE SCENARIOS)
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
Use case là một tập hợp các kịch bản (scenario) thông thường có liên quan nhau. Một kịch bản được gọi là một tiến trình chuẩn (normal course) của các sự kiện nối tiếp nhau tạo nên use case, nó cũng được gọi là tiến trình chính (main course), tiến trình cơ sở (basic course), luồng chuẩn (normal flow), hay là “đường yên lành” (happy path). Tiến trình chuẩn được mô tả bằng cách liệt kê
một dãy đối thoại (dialogue elements) hoặc dãy tương tác giữa actor và hệ thống.
115
Mẫu mô tả UC
Tên (Name)
Tên của UC, có nghĩa gần với mục đích người sử
dụng
Các tác nhân (Actors) Mục đích (Goals) Các yêu cầu (Requirements) (tùy chọn)
Cung cấp khả năng lần vết
Điều kiện tiên quyết (Pre-Conditions)
Các điều kiện cần thiết cần phải có trước khi thực
hiện mộ UC
Có thể là một UC khác (không giống với quan hệ
<
116 Use Case Modeling
Biểu mẫu mô tả UC
Mô tả (Description)
Mô tả các tiến trình cơ bản hoặc bình thường của hệ thống nếu hệ
thống hoạt động như dự định (mọi thứ điều đúng)
Điều kiện sau (Post-conditions)
Trạng thái của hệ thống sau khi UC được thực thi Các giá trị đưa ra cho các tác nhân Phân biệt giữa biến thể và các ngoại lệ
Các biến thể (Variations)
Các điều kiện dẫn tới việc phân nhánh Mô tả các tiến trình thay thế hoặc là tên mở rộng của UC
Các ngoại lệ (Exceptions)
Những điều kiện không mong đợi dẫn tới việc phân nhánh (xung đột
với điều kiện sau)
Mô tả các tiến trình thay thế Ví dụ
117 Use Case Modeling
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
118
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
119
Use case của hệ thống theo dõi hóa chất
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
120
Mô tả Use case “request a chemical”
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
121
Mô tả Use case “request a chemical”
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
122
Mô tả Use case “request a chemical”
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
123
Mô tả Use case “request a chemical”
I
U H
- T T N C a o h K
- T T T H n ô M ộ B
124
Bài tập
Phát biểu vấn đề Dẫn nhập (Background) Xác định mục tiêu Xác định yêu cầu Xác định StackHolder Các kỹ thuật thu nhận yêu cầu Các kỹ thuật phân tích yêu cầu Bài tập
