Bài giảng Công nghệ phần mềm: Bài 2 - TS. Lê Nguyễn Tuấn Thành

Công nghệ Phần mềm

Xác định Yêu cầu

Giảng viên: Lê Nguyễn Tuấn Thành

Email: thanhlnt@tlu.edu.vn

Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT

Trường Đại Học Thủy Lợi

Nội dung  Yêu cầu Phần mềm  Quy trình Kỹ thuật tạo Yêu cầu

Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007”

1. Yêu cầu Phần mềm

(Software Requirements)

Mục tiêu  Giới thiệu khái niệm về Yêu cầu người dùng và Yêu cầu

hệ thống

 Miêu tả Yêu cầu chức năng và Yêu cầu phi chức năng  Giải thích cách những yêu cầu phần mềm được tổ chức

trong một tài liệu yêu cầu

Những chủ đề được đề cập (Topics covered)

 Yêu cầu người dùng và Yêu cầu hệ thống  Yêu cầu chức năng và Yêu cầu phi chức năng  Tài liệu yêu cầu phần mềm

Yêu cầu là gì? (Requirement?)

 Yêu cầu có thể là:

 phát biểu trừu tượng ở mức cao về một dịch vụ

hoặc

 một rằng buộc hệ thống đến một đặc tả chức

năng toán học cụ thể

Phân biệt: Yêu cầu và Thiết kế (Requirements and Design)

 Về nguyên tắc, yêu cầu nên phát biểu về CÁI (what) mà hệ thống nên làm, còn thiết kế nên miêu tả CÁCH (how) hệ thống làm điều đó

 Trong thực tế, yêu cầu và thiết kế là không thể tách rời

Sự đầy đủ và nhất quán của yêu cầu (Requirements completeness & consistency)

 Về nguyên tắc, những yêu cầu nên phải hoàn thiện và

nhất quán  Hoàn thiện

 Yêu cầu nên bao gồm miêu tả về tất cả các phương tiện, khía

cạnh cần thiết

 Nhất quán

 Không nên có xung đột (conflicts) hoặc mâu thuẫn

(contradictions) trong những yêu cầu

 Trên thực tế, không thể tạo ra một tài liệu yêu cầu hoàn

thiện và nhất quán

Case study: Hệ thống LIBSYS  Một hệ thống quản lý thư viện cung cấp một giao diện đơn cho một số lượng cơ sở dữ liệu bài báo trong những thư viện khác nhau,

 Người dùng có thể tìm kiếm, tải về hoặc in những bài

báo này cho mục đích học tập cá nhân

Phân loại Yêu cầu •Yêu cầu người dùng •Yêu cầu hệ thống

•Yêu cầu chức năng •Yêu cầu phi chức năng

Yêu cầu Người dùng vs Hệ thống  Yêu cầu người dùng

 Những phát biểu bằng ngôn ngữ tự nhiên cộng với sơ đồ (diagram) về những dịch vụ hệ thống sẽ cung cấp và những rằng buộc vận hành của nó.  Được viết cho/bởi khách hàng.

 Yêu cầu hệ thống

 Một tài liệu có cấu trúc đưa ra những mô tả chi tiết về

chức năng hệ thống, dịch vụ và rằng buộc vận hành.  Được dự định là một cơ sở để thiết kế hệ thống  Có thể được định nghĩa hoặc minh hoạ sử dụng mô hình

hệ thống (system models)

VD: Yêu cầu Người dùng và Hệ thống  Yêu cầu người dùng



Phần mềm phải cung cấp một cách thức để biểu diễn và truy cập những tệp bên ngoài được tạo bởi những công cụ khác

 Đặc tả những yêu cầu hệ thống

1. Người dùng nên được cung cấp các phương tiện (facilities) để

định nghĩa kiểu của những tệp tin ngoài (external files)

2. Mỗi kiểu tệp tin ngoài nên có một công cụ đi kèm có thể áp dụng

cho kiểu tệp tin đó

3. Mỗi kiểu tệp tin ngoài nên được biểu diễn bằng một biểu tượng

cụ thể (specific icon) trên màn hình của người dùng

4. Các phương tiện nên được cung cấp cho biểu tượng biểu diễn

một kiểu tệp tin ngoài được định nghĩa bởi người dùng

5. Khi người dùng chọn một biểu tượng biểu diễn tệp tin ngoài, hiệu ứng của việc lựa chọn đó là sử dụng công cụ liên kết với kiểu tệp ngoài đó cho tệp tin được biểu diễn bởi công cụ lựa chọn

Insulin Pump / Phần mềm kiểm soát / SRS / 3.3.2

Chức năng

Tính liều insulin: Mức đường an toàn

Miêu tả

Tính toán lượng insulin được cung cấp khi mức đường đo được hiện tại nằm trong vùng an toàn giữa 3 và 7 đơn vị.

Đầu vào

Nguồn

Lượng đường đọc được hiện tại (r2), hai lượng đường ở lần đọc trước (r0 và r1) Lượng đường đọc từ cảm biến. Những lần đọc khác từ bộ nhớ.

Đầu ra

Compdose - liều lượng insulin được cung cấp

Miêu tả

Vòng điều khiển chính

Hành động

CompDose có giá trị 0 nếu mức đường ổn định hoặc giảm xuống hoặc nếu mức độ đang tăng lên nhưng tỷ lệ tăng đang giảm. Nếu mức độ đang tăng và tỷ lệ tăng lại đang tăng lên, thì CompDose được tính bằng cách chia sự khác biệt giữa mức đường hiện tại và mức trước đó cho 4 và làm tròn kết quả. Nếu kết quả, được làm tròn bằng 0, thì CompDose được đặt ở liều tối thiểu có thể được phân phối.

Yêu cầu

Hai lần đọc trước đó để có thể tính tỷ lệ thay đổi của mức đường.

Điều kiện trước

Túi insulin chứa ít nhất một liều đơn tối đa cho phép của insulin

Điều kiện sau

r0 được thay thế bởi r1 sau đó r1 được thay thế bằng r2

Ảnh hưởng phụ

Không có

Đối tượng của những kiểu yêu cầu

Yêu cầu người dùng (User requirements)

• Nhà quản lý phía khách hàng (Client managers) • Người dùng cuối của hệ thống (System end-users) • Kỹ sư phía khách hàng (Client engineers) • Nhà quản lý phía nhà thầu (Contractor managers) • Kỹ sư hệ thống (System architects)

Yêu cầu hệ thống (System requirements)

• Người dùng cuối của hệ thống (System end-users) • Kỹ sư phía khách hàng (Client engineers) • Kỹ sư hệ thống (System architects) • Lập trình viên phần mềm (Software developers)

• Kỹ sư phía khách hàng (Client engineers) [có thể] • Kỹ sư hệ thống (System architects) • Lập trình viên phần mềm (Software developers)

Đặc tả thiết kế phần mềm (Software design specification)

Yêu cầu Chức năng vs Phi chức năng (Functional and non-functional requirements)

 Yêu cầu chức năng

 Những tuyên bố (statements) về dịch vụ hệ thống nên cung cấp, cách hệ thống nên phản ứng với những đầu vào cụ thể và cách hệ thống nên hành xử trong những tình huống cụ thể

 Yêu cầu phi chức năng

 Những rằng buộc trên những dịch vụ hoặc chức năng được cung cấp bởi hệ thống như rằng buộc về thời gian, rằng buộc về tiến trình phát triển, về các chuẩn, …

Yêu cầu chức năng (Functional requirements)

 Mô tả chức năng hoặc dịch vụ hệ thống  Phụ thuộc vào kiểu phần mềm, mong muốn của người dùng và kiểu của hệ thống nơi mà phần mềm được sử dụng

 Những yêu cầu chức năng người dùng có thể là những tuyên bố (statements) ở mức cao về điều mà hệ thống nên làm

 Những yêu cầu chức năng hệ thống nên miêu tả chi tiết

dịch vụ hệ thống

Ví dụ: Yêu cầu chức năng của LIBSYS  Người dùng có thể tìm kiếm tất cả các bộ cơ sở dữ liệu

ban đầu hoặc chỉ chọn một tập con trong đó

 Hệ thống sẽ cung cấp chế độ hiển thị thích hợp cho

người dùng để đọc tài liệu trong kho tài liệu

 Mỗi đơn hàng sẽ được cấp một định danh duy nhất (ORDER_ID) mà người dùng sẽ sử dụng để sao chép vào khu vực lưu trữ dài hạn của tài khoản đó

Yêu cầu phi chức năng (Non-functional requirements)

 Định nghĩa những thuộc tính và rằng buộc, ví dụ: độ tin cậy, thời gian phản ứng, yêu cầu lưu trữ. Những rằng buộc là khả năng thiết bị vào/ra (I/O), những biểu diễn hệ thống, …

 Yêu cầu phi chức năng có thể quan trọng hơn yêu cầu chức năng. Nếu những yêu cầu này không được đáp ứng, hệ thống có thể sẽ vô dụng (useless)

Phân loại Yêu cầu phi chức năng (Non-functional classifications)

 Yêu cầu sản phẩm (product requirements)

 Những yêu cầu xác định rằng sản phẩm được phân phối phải hoạt động theo một cách cụ thể, ví dụ: tốc độ chạy (execution speed), độ tin cậy (reliability), v.v.

 Yêu cầu tổ chức (organizational requirements)

 Những yêu cầu là hệ quả của những chính sách (policies) và thủ tục (procedures) tổ chức, ví dụ: những tiêu chuẩn quy trình được sử dụng, phương pháp thiết kế, v.v.  Yêu cầu bên ngoài (external requirements)

 Những yêu cầu phát sinh từ những yếu tố bên ngoài tác động lên hệ thống, ví dụ: yêu cầu về khả năng tương tác (interoperability) với các hệ thống khác, yêu cầu pháp lý (legislative), tính văn hóa, đạo đức, v.v.

Ví dụ: Yêu cầu phi chức năng  Yêu cầu sản phẩm (product requirement)

 8.1 Giao diện người dùng cho LIBSYS sẽ được triển khai dưới dạng HTML đơn thuần mà không có frame hoặc Java applet

 Yêu cầu tổ chức (organizational requirement)

 9.3.2 Tiến trình phát triển hệ thống và những tài liệu chuyển giao (deliverable documents) phải phù hợp với tiến trình và sản phẩm được định nghĩa trong XYZCo-SP-STAN-95.

 Yêu cầu bên ngoài (external requirement)

 7.6.5 Hệ thống sẽ không tiết lộ bất kỳ thông tin về khách hàng ngoài tên và số tham chiếu của họ cho người vận hành hệ thống

Phân biệt: Yêu cầu và Mục tiêu  Yêu cầu là một cái gì đó có thể kiểm tra được  Mục tiêu là một đặc trưng khái quát hơn mà hệ thống

phải thể hiện  Một ý định chung của người dùng, ví dụ tính dễ sử dụng, thân thiện với người dùng (nhưng đây không phải là một thuộc tính khách quan)

 Mục tiêu hữu ích cho các nhà phát triển do chúng biểu đạt ý

định của người dùng hệ thống

Ví dụ: Mục tiêu và Yêu cầu  Mục tiêu hệ thống

 Hệ thống nên dễ sử dụng cho những người dùng kinh nghiệm và nên được tổ chức theo cách sao cho những lỗi người dùng được tối giản hóa

 Yêu cầu phi chức năng có thể xác thực

 Người dùng có kinh nghiệm có thể sử dụng tất cả chức năng

hệ thống sau 2 giờ huấn luyện.

 Sau thời gian huấn luyện này, số lượng trung bình lỗi được tạo ra bởi người dùng kinh nghiệm sẽ không quá 2 lỗi một ngày.

Những độ đo cho Yêu cầu (Requirements measures) Thuộc tính (property)

Số đo (measure)

Tốc độ (speed)

Số giao dịch được xử lý / giây Số người dùng / thời gian đáp ứng sự kiện Thời gian làm tươi màn hình

Kích thước (size)

Mbytes Số lượng ROM chips

Tính dễ sử dụng (ease of use)

Thời gian huấn luyện Số lượng khung trợ giúp

Độ tin cậy (reliability)

Thời gian trung bình mà hệ thống lỗi (failure) Xác suất của trạng thái không sẵn sàng (unavailability) Tỷ lệ xuất hiện lỗi (failure occurrence) Tính sẵn sàng (availability)

Độ vững mạnh (robustness)

Thời gian khởi động sau khi có lỗi Phần trăm sự kiện gây ra lỗi Xác suất hư hỏng dữ liệu (data corruption) khi có lỗi

Phần trăm những phát biểu phụ thuộc mục tiêu Số lượng hệ thống mục tiêu (target systems)

Tính di động (portability) 23

Xung đột yêu cầu  Xung đột giữa những yêu cầu phi chức năng là phổ biến

trong những hệ thống phức tạp

 Ví dụ: Hệ thống tàu vũ trụ

 Tối giản hóa trọng lượng, do đó số lượng vi xử lý (chip) trong

hệ thống nên được tối giản hóa,

 Tối giản hóa việc tiêu thụ điện năng (power consumption),

những vi xử lý tiêu thụ điện năng thấp nên được sử dụng

 Tuy nhiên, sử dụng vi xử lý điện năng thấp nghĩa là phải sử

dụng số lượng nhiều hơn.

 Đâu là yêu cầu quan trọng hơn?

Nhắc lại: Yêu cầu người dùng  Nên miêu tả những yêu cầu chức năng và phi chức năng theo cách mà chúng có thể được hiểu bởi người dùng hệ thống, những người không có kiến thức kỹ thuật chi tiết

 Yêu cầu người dùng được định nghĩa sử dụng ngôn ngữ tự nhiên, các bảng và biểu đồ mà có thể được hiểu bởi tất cả người dùng

Hướng dẫn viết yêu cầu (Guidelines for writing requirements)

 Tìm ra một định dạng chuẩn và sử dụng nó cho tất

cả các yêu cầu.

 Sử dụng ngôn ngữ một cách nhất quán. Sử dụng cho các yêu cầu bắt buộc, nên sử dụng cho các yêu cầu mong muốn.

 Sử dụng văn bản được làm nổi bật để xác định

những phần quan trọng của yêu cầu.

 Tránh sử dụng thuật ngữ máy tính

Vấn đề của Đặc tả Ngôn ngữ tự nhiên (Problems with NL specification)

 Sự mơ hồ (Ambiguity)

 Người đọc và người viết yêu cầu phải phiên dịch những

từ giống nhau theo cùng một cách.

 Ngôn ngữ tự nhiên là không rõ ràng vì vậy điều này rất

khó khăn.

 Quá linh hoạt (Over-flexibility)

 Những phát biểu tương tự có thể được nói bằng một số

cách khác nhau trong đặc tả.

 Thiếu tính mô-đun hóa

 Cơ cấu ngôn ngữ tự nhiên không phù hợp để cấu trúc

những yêu cầu hệ thống

Những thay thế cho Đặc tả bằng NNTN

Ký hiệu (notation)

Miêu tả (description)

Cách tiếp cận này phụ thuộc vào việc định nghĩa các hình thức hoặc khuôn mẫu chuẩn để diễn tả đặc tả yêu cầu.

Ngôn ngữ tự nhiên được cấu trúc

Ngôn ngữ mô tả thiết kế

Cách tiếp cận này sử dụng một ngôn ngữ như một ngôn ngữ lập trình nhưng với nhiều tính năng trừu tượng hơn để chỉ định các yêu cầu bằng cách định nghĩa một mô hình hoạt động của hệ thống. Cách tiếp cận này bây giờ không được sử dụng rộng rãi mặc dù nó có thể hữu ích cho các đặc tả giao diện.

Ký hiệu đồ hoạ

Một ngôn ngữ đồ họa, bổ sung bằng các chú thích văn bản, được sử dụng để định nghĩa các yêu cầu chức năng cho hệ thống. Một ví dụ ban đầu của một ngôn ngữ đồ họa như thế là SADT. Bây giờ, những mô tả use-case sử dụng và biểu đồ trình tự thường được sử dụng.

Đặc tả toán học

Đây là những ký hiệu dựa trên các khái niệm toán học như các máy hoặc tập hữu hạn trạng thái. Những đặc tả rõ ràng này làm giảm các tham số giữa khách hàng và nhà thầu về chức năng của hệ thống. Tuy nhiên, hầu hết khách hàng không hiểu những đặc tả hình thức và miễn cưỡng chấp nhận nó như một hợp đồng hệ thống.

Đặc tả ngôn ngữ được cấu trúc (Structured language specifications)

 Sự tự do của người viết yêu cầu bị giới hạn bởi một khuôn mẫu được định nghĩa trước cho các yêu cầu.  Tất cả các yêu cầu được viết theo một cách chuẩn.  Thuật ngữ (terminology) sử dụng trong mô tả có thể bị

hạn chế.

 Ưu điểm là hầu hết các biểu cảm của ngôn ngữ tự nhiên được duy trì nhưng một mức độ đồng nhất bị bắt buộc trong đặc tả.

Đặc tả dựa trên biểu mẫu (Form-based specifications)

 Sự định nghĩa của chức năng hoặc thực thể.  Sự mô tả về đầu vào và nguồn gốc của chúng.  Sự mô tả về đầu ra và nơi chúng đến.  Sự chỉ dẫn của các thực thể khác được yêu cầu.  Những điều kiện trước và sau (nếu thích hợp).  Những ảnh hưởng phụ (nếu có) của chức năng.

Đặc tả nút dựa trên biểu mẫu (Form-based node specification) Insulin Pump / Phần mềm kiểm soát / SRS / 3.3.2

Chức năng Tính liều insulin: Mức đường an toàn

Miêu tả

Tính toán lượng insulin được cung cấp khi mức đường đo được hiện tại nằm trong vùng an toàn giữa 3 và 7 đơn vị.

Đầu vào

Lượng đường đọc được hiện tại (r2), hai lượng đường ở lần đọc trước (r0 và r1)

Nguồn

Lượng đường đọc từ cảm biến. Những lần đọc khác từ bộ nhớ.

Đầu ra

Compdose - liều lượng insulin được cung cấp

Miêu tả

Vòng điều khiển chính

Hành động

Yêu cầu

Hai lần đọc trước đó để có thể tính tỷ lệ thay đổi của mức đường.

Điều kiện trước Túi insulin chứa ít nhất một liều đơn tối đa cho phép của insulin

Điều kiện sau

r0 được thay thế bởi r1 sau đó r1 được thay thế bằng r2

Ảnh hưởng phụ Không có

Đặc tả dạng bảng (Tabular specification)

 Được sử dụng để bổ sung cho ngôn ngữ tự nhiên.  Đặc biệt hữu ích khi phải định nghĩa một số các

phương án thay thế có thể cho hành động

Ví dụ: Đặc tả dạng bảng

Điều kiện

Hành động

CompDose = 0

CompDose = round((r2-r1) / 4) Nếu kết quả làm tròn = 0 thì CompDose = MinimumDose

Mức đường đang rơi xuống (r2

Mô hình đồ họa (Graphical models)

 Được sử dụng để bổ sung cho ngôn ngữ tự nhiên.  Hữu ích nhất khi chúng ta cần hiển thị các trạng thái

thay đổi hoặc mô tả một chuỗi hành động.

VD: Sơ đồ trình tự rút tiền ATM (Sequence diagram of ATM withdrawal)

Đặc tả giao diện (Interface specification)

 Hầu hết hệ thống phải hoạt động với các hệ thống

khác

 Các giao diện hoạt động phải được xác định như là

một phần của yêu cầu.

 Ba loại giao diện có thể được định nghĩa:

 Giao diện thủ tục (Procedural interfaces)  Cấu trúc dữ liệu được trao đổi (Exchanged data structures)  Biểu diễn dữ liệu (Data representations)

 Những ký hiệu hình thức là một kỹ thuật hiệu quả

cho đặc tả giao diện.

VD: Miêu tả giao diện

Tài liệu đặc tả Yêu cầu (Requirements document)

 Tài liệu yêu cầu là tuyên bố chính thức về những gì

được yêu cầu của các nhà phát triển hệ thống.

 Nên bao gồm cả định nghĩa về các yêu cầu người

dùng và đặc tả của yêu cầu hệ thống.

 Nó KHÔNG PHẢI là một tài liệu thiết kế.

 Càng nhiều càng tốt, nó nên thiết lập về CÁI hệ thống nên

làm hơn là CÁCH hệ thống nên làm

Đối tượng của Tài liệu yêu cầu

Chuẩn Tài liệu Yêu cầu IEEE (IEEE requirements standard)

 Định nghĩa một cấu trúc chung cho một tài liệu yêu

cầu phải được khởi tạo cho mỗi hệ thống cụ thể.  Giới thiệu (introduction)  Miêu tả chung (general description)  Những đặc tả cụ thể (specific requirements)  Phụ lục (appendices)  Mục lục (index)

Cấu trúc Tài liệu Yêu cầu (Requirements document structure)

Lời nói đầu (Preface) 1. 2. Giới thiệu (Introduction) 3. Bảng chú giải (Glossary) 4. Định nghĩa yêu cầu người dùng (User requirements

definition)

5. Kiến trúc hệ thống (System architecture) 6. Đặc tả yêu cầu hệ thống (System requirements

specification)

Sự tiến hóa hệ thống (System evolution)

7. Mô hình hệ thống (System models) 8. 9. Phụ lục (Appendices) 10. Mục lục (Index)

Tóm tắt những điểm chính (1/2) (Key points)

 Yêu cầu chỉ ra CÁI hệ thống nên làm và định nghĩa những rằng buộc về sự hoạt động và thực hiện của nó.

 Các yêu cầu chức năng đưa ra các dịch vụ mà hệ

thống cần cung cấp.

 Các yêu cầu phi chức năng giới hạn hệ thống

đang được phát triển hoặc quá trình phát triển.

Tóm tắt những điểm chính (2/2) (Key points)

 Yêu cầu người dùng là những phát biểu ở mức cao

về cái hệ thống nên làm.  Yêu cầu người dùng nên được viết bằng ngôn ngữ tự

nhiên, những bảng biểu và sơ đồ.

 Yêu cầu hệ thống nhằm mục đích truyền đạt các

chức năng mà hệ thống cần cung cấp.

 Một tài liệu yêu cầu phần mềm là một tuyên bố đồng

thuận về các yêu cầu hệ thống.

 Tiêu chuẩn IEEE là một điểm khởi đầu hữu ích để định nghĩa các tiêu chuẩn yêu cầu cụ thể chi tiết hơn.

2. Quy trình Kỹ thuật tạo Yêu cầu

(Requirements Engineering Processes)

Mục tiêu  Miêu tả các hoạt động kỹ thuật chủ yếu tạo yêu cầu

và các mối quan hệ của chúng

 Giới thiệu các kỹ thuật cho việc khai phá và phân tích

yêu cầu

 Mô tả việc xác nhận yêu cầu và vai trò của duyệt lại yêu

cầu

 Thảo luận về vai trò của quản lý yêu cầu trong việc hỗ

trợ các quy trình kỹ thuật yêu cầu khác

Chủ đề được đề cập (Topics covered)

 Nghiên cứu tính khả thi (Feasibility studies)  Khai phá và phân tích yêu cầu (Requirements elicitation

and analysis)

 Xác thực yêu cầu (Requirements validation)  Quản lý yêu cầu (Requirements management)

Quy trình kỹ thuật tạo yêu cầu (1/2) (Requirements engineering processes)

 Các quy trình sử dụng cho việc tạo yêu cầu rất rộng lớn tùy thuộc vào lĩnh vực ứng dụng, những người liên quan và tổ chức phát triển các yêu cầu.

 Tuy nhiên, có một số hoạt động chung cho tất cả quy

trình  Khai phá yêu cầu (Requirements elicitation)  Phân tích yêu cầu (Requirements analysis)  Xác thực yêu cầu (Requirements validation)  Quản lý yêu cầu (Requirements management)

Quy trình kỹ thuật tạo yêu cầu (2/2) (Requirements engineering processes)

Kỹ thuật tạo yêu cầu (Requirements engineering)

1. Nghiên cứu tính khả thi (Feasibility studies)

 Một nghiên cứu khả thi quyết định xem hệ thống

được đề xuất có đáng giá hay không

 Đây là một nghiên cứu ngắn để tập trung kiểm tra:

 Liệu hệ thống đóng góp vào các mục tiêu của công ty?  Liệu hệ thống có thể được kỹ nghệ hóa sử dụng công

nghệ hiện tại và trong phạm vi ngân sách?

 Liệu hệ thống có thể được tích hợp với các hệ thống khác

đang được sử dụng?

Thực hiện nghiên cứu khả thi (Feasibility study implementation)

 Dựa trên đánh giá thông tin (những gì được yêu

cầu), thu thập thông tin và viết báo cáo  Đặt câu hỏi cho những người trong công ty

 Điều gì xảy ra nếu hệ thống này không được thực thi?  Những vấn đề của quy trình hiện tại là gì?  Hệ thống được đề xuất sẽ giúp đỡ như thế nào?  Những vấn đề của tích hợp là gì?  Công nghệ mới có cần thiết không? Những kỹ năng nào?  Các phương tiện gì phải được hỗ trợ bởi hệ thống đề

xuất?

2. Khai phá và phân tích yêu cầu (Requirements elicitation and analysis)

 Liên quan đến nhân viên kỹ thuật làm việc với khách hàng để tìm hiểu về các lĩnh vực ứng dụng, các dịch vụ mà hệ thống nên cung cấp và những rằng buộc hoạt động của hệ thống.

 Có thể liên quan đến người dùng cuối, nhà quản lý, kỹ sư tham gia bảo trì, chuyên gia về lĩnh vực đó, tổ chức công đoàn, v.v. Đây là gọi các bên liên quan (stakeholders)

Khai phá yêu cầu (Requirements discovery)

 Là quá trình thu thập thông tin về những hệ thống đề xuất và hiện có, sau đó đưa ra các yêu cầu người dùng và yêu cầu hệ thống từ các thông tin này.

 Nguồn thông tin bao gồm tài liệu, các bên liên quan đến hệ thống và các đặc tả của các hệ thống tương tự.

Bên liên quan trong hệ thống ATM (ATM stakeholders)

 Khách hàng ngân hàng (Bank customers)  Đại diện của các ngân hàng khác (Representatives of

other banks)

 Quản lý ngân hàng (Bank managers)  Nhân viên tính toán (Counter staff)  Quản trị viên cơ sở dữ liệu (Database administrators)  Quản lý an ninh (Security managers)  Bộ phận quảng cáo (Marketing department)  Kỹ sư bảo trì phần cứng và phần mềm (Hardware and

software maintenance engineers)

 Người điều hành ngân hàng (Banking regulators)

Khó khăn trong phân tích yêu cầu (Problems of requirements analysis)

 Các bên liên quan không biết mình thực sự muốn gì  Các bên liên quan phát biểu yêu cầu theo thuật ngữ

riêng của họ

 Các bên liên quan khác nhau có thể có các yêu cầu

xung đột.

 Các yếu tố về tổ chức và chính trị có thể ảnh hưởng

đến yêu cầu hệ thống.

 Các yêu cầu thay đổi trong quá trình phân tích. Các bên liên quan mới có thể xuất hiện và môi trường kinh doanh thay đổi.

2.1. Quan điểm (Viewpoints)

 Quan điểm là một cách cấu trúc các yêu cầu để biểu diễn những khía cạnh khác nhau của các bên liên quan.

 Các bên liên quan có thể được phân loại dựa trên

các quan điểm khác nhau.

 Sự phân tích đa góc độ này rất quan trọng khi không có cách nào chính xác để phân tích các yêu cầu hệ thống.

Các kiểu quan điểm (Types of viewpoint)  Quan điểm tương tác (Interactor viewpoints)

 Con người hoặc các hệ thống khác tương tác trực tiếp với hệ

thống.

 Trong máy ATM, cơ sở dữ liệu khách hàng và tài khoản là

những quan điểm tương tác.

 Quan điểm gián tiếp (Indirect viewpoints)

 Các bên liên quan tự họ không sử dụng hệ thống nhưng

ảnh hưởng đến các yêu cầu.

 Trong máy ATM, nhân viên quản lý và an ninh là những quan

điểm gián tiếp.

 Quan điểm miền (Domain viewpoints)

 Đặc điểm và rằng buộc về miền ảnh hưởng đến những yêu

cầu.

 Trong máy ATM, một ví dụ là tiêu chuẩn cho truyền thông liên

ngân hàng.

Nhận dạng quan điểm (Viewpoint identification)

 Nhận dạng quan điểm sử dụng

 Nhà cung cấp và người nhận của dịch vụ hệ thống;  Các hệ thống tương tác trực tiếp với hệ thống đang cần

xác định;

 Các quy định và tiêu chuẩn (regulations and standards);  Nguồn của các yêu cầu kinh doanh và phi chức năng;  Các kỹ sư phải phát triển và bảo trì hệ thống;  Quảng cáo và quan điểm kinh doanh khác.

Phân cấp quan điểm của LIBSYS (LIBSYS viewpoint hierarchy)

2.2. Chất vấn (Interviewing)

 Trong cuộc chất vấn chính thức hoặc không chính thức, nhóm tạo yêu cầu sẽ đặt câu hỏi cho các bên liên quan về hệ thống mà họ sử dụng và hệ thống sẽ được phát triển.  Có hai kiểu chất vấn

 Chất vấn kín, khi mà một tập các câu hỏi định nghĩa trước

sẽ được trả lời.

 Chất vấn mở khi không có chương trình nghị sự được xác định trước và một loạt vấn đề được đề cập với các bên liên quan.

Thực hành Chất vấn (Interviews in practice)

 Thông thường kết hợp giữa chất vấn đóng và

chất vấn mở.

 Chất vấn là tốt để có được sự hiểu biết tổng thể về những gì các bên liên quan làm và cách mà họ có thể tương tác với hệ thống.

Người chất vấn hiệu quả (Effective interviewers)

 Người chất vấn nên có một đầu óc cởi mở, sẵn sàng lắng nghe các bên liên quan và không nên có những ý tưởng ban đầu về các yêu cầu.

 Người chất vấn nên nhắc người được chất vấn bằng một câu hỏi hay một đề nghị và không nên chỉ đơn giản là mong đợi họ phản hồi một câu hỏi kiểu như 'Bạn muốn điều gì'.

2.3. Kịch bản (Scenarios)

 Kịch bản là những ví dụ thực tế trong cuộc sống về

cách một hệ thống có thể được sử dụng.

 Kịch bản nên bao gồm:

 Một mô tả về tình trạng ban đầu;  Một mô tả về luồng bình thường của các sự kiện;  Một mô tả về điều gì có thể khiến sai sót xảy ra;  Thông tin về các hoạt động đồng thời khác;  Một mô tả về trạng thái khi kịch bản kết thúc.

Kịch bản của LIBSYS (1/2) (LIBSYS scenario)

Giả định ban đầu: Người dùng đã đăng nhập vào hệ thống LIBSYS và đã

tìm thấy tạp chí chứa bản sao của bài báo.

Bình thường: Người dùng chọn bài báo để sao chép. Sau đó, anh/chị ấy sẽ được hệ thống nhắc để cung cấp thông tin đăng ký cho tạp chí hoặc chỉ ra cách họ sẽ trả tiền cho bài báo. Những phương thức thanh toán thay thế là bằng thẻ tín dụng hoặc bằng cách trích dẫn số tài khoản của tổ chức.

Sau đó, người dùng sẽ được yêu cầu điền vào một mẫu bản quyền để lưu giữ chi tiết của giao dịch và sau đó họ gửi mẫu này vào hệ thống LIBSYS.

Mẫu bản quyền được kiểm tra, và nếu OK, phiên bản PDF của bài báo sẽ được tải xuống khu vực làm việc LIBSYS trên máy tính của người dùng và người dùng được thông báo rằng bài báo đã có sẵn. Người dùng được yêu cầu chọn một máy in và một bản sao của bài báo sẽ được in ra. Nếu bài báo đã được gắn cờ 'chỉ in' thì nó sẽ bị xóa khỏi hệ thống của người dùng khi người dùng đã xác nhận rằng việc in đã hoàn tất.

Kịch bản của LIBSYS (2/2) (LIBSYS scenario)

Điều có thể khiến sai sót xảy ra: Người dùng có thể không điền đúng trong mẫu bản quyền. Trong trường hợp này, mẫu đó phải được đưa lại cho người dùng để chỉnh sửa. Nếu mẫu đó được gửi lại mà vẫn không chính xác thì yêu cầu của người dùng về bài báo bị từ chối.

Việc thanh toán có thể bị hệ thống từ chối. Yêu cầu của người dùng về bài báo bị từ chối. Bài báo có thể tải xuống không thành công. Hãy thử lại cho đến khi thành công hoặc khi người dùng chấm dứt phiên làm việc. Có thể không in được bài báo. Nếu bài báo không được gắn cờ 'chỉ in' thì nó sẽ được giữ trong không gian làm việc của LIBSYS. Nếu không, bài báo sẽ bị xóa và tài khoản của người dùng được cộng thêm chi phí của bài báo.

Các hoạt động khác: Tải đồng thời các bài báo khác.

Trạng thái hệ thống khi hoàn thành: Người dùng đăng nhập. Bài báo tải về đã bị xóa khỏi không gian làm việc của LIBSYS nếu nó đã được gán cờ là chỉ in (print-only)

Những trường hợp sử dụng (Use cases)

 Use-case là một kỹ thuật dựa trên kịch bản trong UML giúp xác định các tác nhân trong một tương tác và mô tả chính tương tác đó.

 Một tập hợp các use-case nên mô tả tất cả các

tương tác có thể với hệ thống.

 Sơ đồ trình tự (sequence diagram) có thể được sử dụng để thêm chi tiết cho use-case bằng cách hiển thị trình tự xử lý sự kiện trong hệ thống.

Use-case cho việc in bài báo (Article printing use-case)

Các use-case của LIBSYS (LIBSYS use cases)

Sơ đồ trình tự cho in bài báo (Sequence diagram for article printing)

4. Xác thực yêu cầu (Requirements validation)

 Liên quan đến việc chứng minh rằng các yêu cầu sẽ định nghĩa một hệ thống mà khách hàng thực sự muốn.

 Chi phí của một lỗi yêu cầu là cao vì thế xác thực yêu

cầu là rất quan trọng  Sửa một lỗi yêu cầu sau khi phát hành có thể mất chi phí

lên đến 100 lần so với sửa một lỗi cài đặt.

Kiểm tra yêu cầu (Requirements checking)

 Tính hiệu lực (validity).

 Hệ thống có cung cấp các chức năng hỗ trợ tốt nhất nhu cầu

của khách hàng không?  Tính nhất quán (consistency).

 Có bất kỳ yêu cầu xung đột nào không?

 Tính hoàn thiện (completeness).

 Có phải tất cả các chức năng mà khách hàng yêu cầu đã được

cài đặt?

 Tính hiện thực (realism).

 Các yêu cầu có thể được thực hiện với ngân sách và công

nghệ sẵn có không?

 Khả năng kiểm chứng (verifiability).

 Các yêu cầu có thể được kiểm tra không?

Những kỹ thuật xác thực yêu cầu (Requirements validation techniques)

 Đánh giá lại yêu cầu (Requirements reviews)  Phân tích thủ công có hệ thống của các yêu cầu

 Tạo nguyên mẫu (Prototyping)

 Sử dụng một mô hình có thể thực thi của hệ thống để

kiểm tra các yêu cầu

 Tạo các trường hợp thử nghiệm (Test-case generation)

 Phát triển những bài kiểm tra cho các yêu cầu

Đánh giá lại yêu cầu (Requirements reviews)

 Việc đánh giá lại thường xuyên nên được tổ chức trong lúc định nghĩa các yêu cầu đang được xây dựng

 Cả nhân viên khách hàng và nhà thầu đều nên tham

gia vào việc đánh giá lại

 Việc đánh giá lại có thể chính thức (với những tài liệu đã hoàn thành) hoặc không chính thức. Viêc giao tiếp tốt giữa các nhà phát triển, khách hàng và người dùng có thể giải quyết các vấn đề ở giai đoạn đầu

Kiểm tra việc đánh giá lại (Review checks)

 Khả năng kiểm chứng (Verifiability).

 Liệu yêu cầu có thể kiểm thử được trong thực tế không?

 Tính hiểu (Comprehensibility).

 Liệu yêu cầu có được hiểu đúng không?

 Khả năng truy vết (Traceability).

 Liệu nguồn gốc của yêu cầu có được phát biểu rõ ràng?

 Khả năng thích nghi (Adaptability).

 Liệu yêu cầu có thể được thay đổi mà không ảnh hưởng

lớn tới các yêu cầu khác không?

Quản lý yêu cầu (Requirements management)

 Quản lý yêu cầu là quá trình quản lý sự thay đổi yêu cầu trong quá trình kỹ thuật tạo yêu cầu và phát triển hệ thống.

 Yêu cầu khó tránh khỏi việc không đầy đủ và không

nhất quán  Các yêu cầu mới xuất hiện trong quá trình khi nhu cầu kinh doanh thay đổi và sự hiểu biết tốt hơn về hệ thống được phát triển;

 Các quan điểm khác nhau có những yêu cầu khác nhau

và điều này thường mâu thuẫn (contradictory).

Thay đổi yêu cầu (Requirements change)

 Mức độ ưu tiên của các yêu cầu từ các quan điểm

khác nhau thay đổi trong quá trình phát triển.

 Khách hàng hệ thống có thể xác định các yêu cầu từ quan điểm kinh doanh mà mâu thuẫn với những yêu cầu người dùng cuối.

 Môi trường kinh doanh và kỹ thuật của hệ thống thay

đổi trong quá trình phát triển.

Tiến hóa yêu cầu (Requirements evolution)

Yêu cầu ổn định và không ổn định (Enduring and volatile requirements)

 Yêu cầu ổn định (Enduring requirements).

 Yêu cầu ổn định bắt nguồn từ hoạt động cốt lõi của tổ

chức khách hàng.

 VD: Một bệnh viện sẽ luôn luôn có bác sĩ, y tá, v.v. Có thể

được bắt nguồn từ các mô hình miền.

 Yêu cầu không ổn định (Volatile requirements).

 Yêu cầu thay đổi trong quá trình phát triển hoặc khi hệ

thống đi vào sử dụng.

 VD: Trong một bệnh viện, yêu cầu bắt nguồn từ chính

sách chăm sóc sức khoẻ

Phân loại yêu cầu (Requirements classification)

Kiểu yêu cầu

Miêu tả

Yêu cầu có thể thay đổi (Mutable requirements)

Những yêu cầu thay đổi do sự thay đổi của môi trường mà công ty đang hoạt động. Ví dụ, trong các hệ thống bệnh viện, quỹ kinh phí chăm sóc bệnh nhân có thể thay đổi và do đó cần phải thu thập thông tin điều trị khác nhau.

Yêu cầu khẩn cấp (Emergent requirements)

Những yêu cầu nổi lên khi sự hiểu biết của khách hàng về hệ thống phát triển trong quá trình phát triển hệ thống. Quá trình thiết kế có thể bộc lộ các yêu cầu khẩn cấp mới.

Yêu cầu hệ quả (Consequential requirements)

Những yêu cầu là kết quả từ sự giới thiệu của hệ thống máy tính. Giới thiệu hệ thống máy tính có thể thay đổi quy trình của tổ chức và mở ra những cách làm việc mới để tạo ra các yêu cầu hệ thống mới

Yêu cầu tương thích (Compatibility requirements)

Những yêu cầu phụ thuộc vào các hệ thống hoặc quá trình kinh doanh cụ thể trong một công ty. Khi điều này thay đổi này, những yêu cầu tương thích trên hệ thống được ủy thác hoặc phân phối cũng có thể phải tiến hóa theo.

Lập kế hoạch quản lý yêu cầu (Requirements management planning)

 Trong quá trình kỹ thuật tạo yêu cầu, bạn phải lên kế

hoạch cho những việc sau:  Nhận dạng yêu cầu (Requirements identification)  Cách những yêu cầu được nhận dạng riêng biệt;

 Quy trình quản lý thay đổi

 Quá trình tiếp theo khi phân tích yêu cầu thay đổi;  Chính sách truy xuất nguồn gốc (Traceability policies)

 Số lượng thông tin về các mối quan hệ yêu cầu được duy trì;

 Công cụ hỗ trợ CASE

 Công cụ hỗ trợ cần thiết để giúp quản lý sự thay đổi yêu cầu;

Khả năng truy vết (Traceability)

 Khả năng truy vết liên quan đến các mối quan hệ giữa các yêu cầu, nguồn gốc của chúng và thiết kế hệ thống

 Khả năng truy vết nguồn (Source traceability)

 Liên kết những yêu cầu với các bên liên quan đã đề xuất

các yêu cầu này;

 Khả năng truy vết yêu cầu (Requirements traceability)

 Liên kết giữa các yêu cầu phụ thuộc;

 Khả năng truy vết thiết kế (Design traceability)

 Liên kết những yêu cầu với thiết kế;

Ma trận truy vết (Traceability matrix)

Tóm tắt những điểm chính (1/2) (Key points)

 Quy trình kỹ thuật tạo yêu cầu bao gồm: nghiên cứu khả thi, khai phá và phân tích yêu cầu, đặc tả yêu cầu và quản lý yêu cầu.

 Khai phá và phân tích yêu cầu là quá trình lặp liên quan đến hiểu biết miền, thu thập yêu cầu, phân loại, cấu trúc, ưu tiên và xác thực.

 Hệ thống có nhiều bên liên quan với các yêu cầu khác

nhau.

Tóm tắt những điểm chính (2/2) (Key points)

 Các yếu tố xã hội và tổ chức ảnh hưởng đến các

yêu cầu hệ thống.

 Xác thực yêu cầu liên quan đến việc kiểm tra: tính hợp lệ, tính nhất quán, tính đầy đủ, tính hiện thực và khả năng kiểm chứng.

 Những thay đổi kinh doanh chắc chắn dẫn đến thay

đổi yêu cầu.

 Quản lý yêu cầu bao gồm lập kế hoạch và quản lý

thay đổi.

Tài liệu Tham khảo  Giáo

trình chính: Software Engineering,

Ian

Sommerville, 8th Edition, 2007

 Tham khảo:

Practical

Software

Engineering and

UML

Software Lloseng.com,

Java,

using

 Object-Oriented Development Lethbridge/Laganièr, 2001

 Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm,

Phạm Thị Quỳnh