3.1. Phân tích và đặc tả yêu cầu phần mềm:
+ Phân tích và đặc tả yêu cầu là bản đặc tả các dịch vụ mà hệ thống cung cấp và các ràng buộc để xây dựng và vận hành hệ thống.
+ Quá trình tìm kiếm, phân tích, tư liệu hoá, và kiểm tra các dịch vụ và các ràng buộc của hệ thống được gọi là kỹ thuật xác định yêu cầu
(Requirements Engineering - RE).
+ Chúng ta cần phải viết các yêu cầu ở các mức chi tiết khác nhau vì có nhiều người sử dụng khác nhau sử dụng chúng theo những cách khác nhau.
+ Phân tích yêu cầu là khâu kỹ thuật đầu tiên trong quá trình xây dựng phần mềm. Bên phát triển và khách hàng cần phối hợp thực hiện, tìm hiểu xem
hệ thống cần làm gì.
___________
3.1.1. Đặc tả yêu cầu phần mềm
+Yêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm do khách hàng - người sử dụng phần mềm - nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác.
+ Thông thường các yêu cầu phần mềm được phân loại theo
4 thành phần của phần mềm:
– Các yêu cầu về phần mềm (Software)
– Các yêu cầu về phần cứng (Hardware)
– Các yêu cầu về dữ liệu (Data)
– Các yêu cầu về con người (People, Users)
+ Mục đích: mục đích của yêu cầu phần mềm là xác định được phần mềm đáp ứng được các yêu cầu và mong muốn của khách hàng - người sử dụng phần mềm.
+ Lý do: Khách hàng chỉ có những ý tưởng còn mơ hồ về phần mềm cần phải xây dựng để phục vụ công việc của họ, người phát triển phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng cần thiết”.
–Khách hàng rất hay thay đổi các đòi hỏi của mình, người phát triển cần nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý
+ Mục tiêu của quy trình xác định yêu cầu là đưa ra các tài liệu yêu cầu của hệ thống.
+ Quy trình xác định yêu cầu biến đổi phụ thuộc vào miền ứng dụng, con người và tổ chức xây dựng yêu cầu. Tuy nhiên, những quy trình này vẫn có chung một số hoạt động sau: phát hiện yêu cầu, phân tích yêu cầu, đánh giá yêu cầu và quản
lý yêu cầu.
+ Nội dung
–Phát hiện các yêu cầu phần mềm (Requirements elicitation)
–Phân tích các yêu cầu phần mềm và thương lượng với khách hàng (Requirements analysis and negotiation
–Mô tả các yêu cầu phần mềm(Requirements–specification)
Mô hình hóa hệ thống (System modeling)
– Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements validation)
–Quản trị các yêu cầu phần mềm(Requirements management)
+ Tuy nhiên, trong thực tế, các yêu cầu luôn luôn thay đổi, thậm chí ngay cả khi đang xây dựng hệ thống. Vì vậy, người ta thường sử dụng mô hình xoắn ốc để xác định các yêu cầu. Mô hình này cho phép việc xác định yêu cầu và cài đặt hệ
thống được thực hiện cùng lúc.
*Mô hình xắn ốct rong quy trình xác định yêu cầu
*Phân tích và phát hiện yêu cầu PM:
+ Xác định các phương pháp sử dụng phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.v.
+ Tìm kiếm các nhân sự (chuyên gia, người sử dụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp người phát triển xác định yêu cầu phần mềm.
+ Xác định “môi trường kỹ thuật” (technical environment)
+ Xác định các “ràng buộc lĩnh vực” (domain constraints)
+ Thu hút sự tham gia của nhiều chuyên gia, khách hàng để người phát triển có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàng
+ Thiết kế các kịch bản sử dụng của phần mềm
+ Phân tích dựa trên khung nhìn cho phép phát hiện nhiều khía cạnh khác nhau của một vấn đề và giúp
phát hiện ra sự xung đột giữa các yêu cầu.
+ Khung nhìn được chia thành 3 loại chính và mỗi loại sẽ cung cấp các yêu cầu khác nhau.
–Khung nhìn tương tác: là những người hoặc hệ thống khác tương tác với hệ thống. Trong hệ thống ATM, khách hàng và CSDL tài khoản là những khung nhìn tương tác
–Khung nhìn gián tiếp: là những stakeholder không sử dụng hệ thống trực tiếp nhưng có ảnh hưởng tới hệ thống. Trong hệ thống ATM, nhân viên quản lý và bảo mật là những khung nhìn gián tiếp.
–Khung nhìn miền ứng dụng: là những đặc điểm và ràng buộc của miền ứng dụng, có ảnh hưởng tới các yêu cầu. Trong hệ thống ATM, các chuẩn để giao tiếp giữa nhiều ngân hàng là một ví dụ.
+ Ta có thể phát hiện khung nhìn dựa trên:
–Người cung cấp và người nhận các dịch vụ của hệ thống
–Các hệ thống tương tác trực tiếp với hệ thống cần xây dựng.
–Các chuẩn và các quy tắc
–Tài nguyên và các yêu cầu phi chức năng
–Marketing và các khung nhìn nghiệp vụ khác.
+ Phỏng vấn hình thức hoặc phi hình thức là một trong những phần quan trọng nhất của quy trình xác định yêu cầu. Trong quá trình phỏng vấn, những người xác định yêu cầu sẽ đặt ra các câu hỏi cho các bên liên quan về hệ thống hiện tại họ đang sử dụng và hệ thống sẽ được xây dựng. Và các yêu cầu sẽ được lấy ra từ những câu trả lời
của người sử dụng.
+ Phỏng vấn được chia thành hai loại:
–Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa trước và có nhiều đáp án để người sử dụng lựa chọn trả lời.
–Phỏng vấn mở: tất cả các vấn đề không được xác định trước và người sử dụng phải tự giải thích và phát biểu theo quan điểm của mình.
+ Kết quả của giai đoạn đặc tả yêu cầu phần mềm chúng ta thu được các tài liệu sau:
–Bảng kê (statement) các đòi hỏi và chức năng khả thi của phần mềm
– Bảng kê phạm vi ứng dụng của phần mềm
– Mô tả môi trường kỹ thuật của phần mềm
– Bảng kê tập hợp các kịch bản sử dụng của phần mềm
–Các nguyên mẫu xây dựng, phát triển hay sử dụng trong phần mềm (nếu có)
–Danh sách nhân sự tham gia vào quá trình phát hiện các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng
+ Các thành phần của hồ sơ đặc tả
–Đặc tả phi hình thức (Informal specifications) được viết bằng ngôn ngữ tự nhiên
–Đặc tả hình thức (Formal specifications) được viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽ
–Đặc tả vận hành chức năng (Operational specifications) mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng
– Đặc tả mô tả (Descriptive specifications) – đặc tả các
đặc tính đặc trưng của phần mềm.
+ Đặc tả các yêu cầu phần mềm là công việc xây dựng các tài liệu đặc tả, trong đó có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học hình thức (a formal mathematical model), tập hợp các kịch bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên
+ Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức
– Tính rõ ràng, chính xác
– Tính phù hợp
– Tính đầy đủ, hoàn thiện
+ Các yêu cầu của hệ thống phần mềm thường được chia thành ba loại: yêu cầu chức năng, yêu cầu phi chức năng và yêu cầu miền ứng dụng. Tuy nhiên, trong thực tế chúng ta rất khó phân biết ba loại yêu cầu này một cách rõ ràng.
+ Trong phần này chúng ta tìm hiểu:
– a. Các loại đặc tả
– b. Phương pháp xác định các yêu cầu hệ thống
– c. Đặc tả miềm ứng dụng
– d. Một số kỹ thuật đặc tả yêu cầu HT
a. Đặc tả chức năng
+ Đặc tả chức năng (Operational Specifications): Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức năng hoặc các dịch vụ của hệ thống một cách chi tiết.
+ Đặc điểm của yêu cầu chức năng:
–Tính mập mờ, không rõ ràng của các yêu cầu: Vấn đề này xảy ra khi các yêu cầu không được xác định một cách cẩn thận. Các yêu cầu mập mờ có thể được người xây dựng và người sử dụng hiểu theo nhiều cách khác nhau.
–Tính hoàn thiện và nhất quán: Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết và không có sự xung đột hoặc đối ngược giữa các yêu cầu. Tuy nhiên, trong thực tế rất khó có thể đạt được điều này.
+ Thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sau
– Biểu đồ luồng dữ liệu (Data Flow Diagrams)
– Máy trạng thái hữu hạn (Finite State Machines)
– Mạng Petri (Petri nets)
+ Ví dụ xác định các yêu cầu chức năng của
HTQLTV
–Người sử dụng có thể tìm kiếm tất cả CSDL hoặc một tập con của CSDL.
– Hệ thống sẽ cung cấp những giao diện thích hợp để
người sử dụng đọc tài liệu.
–Tất cả những hoá đơn mà người sử dụng đăng ký để in sao tài liệu có một mã duy nhất
b. Đặc tả phi chức năng:
+ Đặc tả phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. Yêu cầu phi chức năng thường định nghĩa các thuộc tính như: độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ …và các ràng buộc của hệ thống như: khả năng của thiết bị vào/ra, giao diện …
+ Một số đặc tả phi chức năng còn có liên quan đến quy trình xây dựng hệ thống. Ví dụ: các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình …
+ Các đặc tả phi chức năng có thể là hạn chế hơn những đặc tả chức năng. Nhưng nếu nó không được thoả mãn thì hệ thống sẽ không sử dụng được.
+ Các đặc tả phi chức năng xuất hiện là do yêu cầu của người sử dụng, ràng buộc về ngân sách, 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 và đặc tả phi chức năng như sau:
–Các đặc tả về sản phẩm xác định ứng xử của sản phẩm như: hiệu năng, khả năng sử dụng, độ tin cậy … của sản phẩm.
–Các đặc tả về tổ chức: các đặc tả này được lấy từ những chính sách và quy tắc của khách hàng hoặc tổ chức sử dụng hệ thống.
–Các đặc tả ngoài: được xác định từ các tác nhân ngoài của hệ thống.
+ Khó xác định chính xác và rất khó thẩm tra những
yêu cầu phi chức năng mập mờ. Do đó, trong tài liệu đặc tả yêu cầu, người ta thường bổ sung các mục tiêu. Mục tiêu rất hữu ích đối với người phát triển hệ thống khi nó truyền tải được những mong muốn của người sử dụng hệ thống. Còn với những đặc tả phi chức năng có thể thẩm định được là những yêu cầu có thể kiểm thử một cách khách quan.
+ Tuy nhiên, trong nhiều trường hợp thường xảy ra xung đột giữa các đặc tả phi chức năng đối với những hệ thống phức tạp.
+ Ví dụ xác định các đặc tả phi chức năng của
HTQLTV
– Đặc tả về sản phẩm: HTQLTV phải được cài đặt bằng
HTML mà không có frame hoặc Java applets.
–Đặc tả về mặt tổ chức: Quy trình xây dựng hệ thống và các tài liệu chuyển giao phải thoả mãn các quy tắc đã được định nghĩa trong phần phụ lục của tài liệu HTQLTV.
–Yêu cầu ngoài: Hệ thống không được để lộ các thông tin cá nhân của khách hàng.
+ Các đặc tả phi chức năng có thể thẩm định được
của HTQLTV
–Mục tiêu của hệ thống là dễ sử dụng đối với những người sử dụng có kinh nghiệm và được tổ chức để sao cho tối thiểu hoá được lỗi.
–Các đặc tả phi chức năng có thể thẩm định được: Những người sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi người sử dụng là không quá hai lỗi một ngày.
c. Đặc tả miền ứng dụng:
+ Đặc tả miền ứng dụng được xác định từ miền ứng dụng của hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng dụng. Nó có thể là yêu
cầu chức năng hoặc phi chức năng.
+ Nếu đặc tả miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được. Một số vấn đề liên quan:
–Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng.
–Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật.
+ Ví dụ về đặc tả miền ứng dụng của HTQLTV:
–Giao diện người dùng chuẩn cho tất cả các CSDL đều dựa trên chuẩn phù hợp với mô hình mạng Client- Server.
–Vì vấn đề bản quyền nên một số tài liệu phải xoá ngay khi vừa chuyển đến.
–Phụ thuộc vào yêu cầu của người sử dụng, những tài liệu đó có thể được in ngay trên server và chuyển đến
cho người sử dụng hoặc gửi đến cho máy in mạng.
d. Một số kỹ thuật đặc tả yêu cầu HT:
1. Đặc tả bằng ngôn ngữ hướng cấu trúc:
–Sử dụng ngôn ngữ hướng cấu trúc sẽ yêu cầu người viết đặc tả tuân theo những mẫu được định nghĩa trước. Tất cả các yêu cầu đều được viết theo chuẩn và các thuật ngữ được sử dụng có thể bị hạn chế.
– Ưu điểm của phương pháp này là đạt được mức độ
diễn tả cao nhất của ngôn ngữ tự nhiên nhưng mức độ đồng nhất lại bị lạm dụng trong các đặc tả.
2. Đặc tả dựa biểu mẫu (Form-based):
–Đặc tả dựa biểu mẫu định nghĩa các chức năng hoặc thực thể, mô tả đầu vào và nơi xuất phát của nó, mô tả đầu ra và nơi nó sẽ đến. Đặc tả dựa biểu mẫu chỉ rõ những thực thể cần thiết, các điều kiện trước và sau (nếu thích hợp), các ảnh hưởng của chức năng.
3. Biểu đồ trình tự:
–Biểu đồ trình tự biểu diễn trình tự các sự kiện xảy ra khi người sử dụng tương tác với hệ thống. Nếu ta đọc biểu đồ này từ đầu đến cuối thì ta sẽ thấy được thứ tự của các hành động được thực hiện.
+Đặc tả mô tả (Descriptive Specifications)
– Biểu đồ thực thể liên kết (Entity-Relationship
Diagrams)
– Đặc tả Logic (Logic Specifications)
– Đặc tả đại số (Algebraic Specifications)
Tài liệu đặc tả yêu cầu:
+ Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực hiện bởi đội phát triển hệ thống.
+ Tài liệu đặc tả yêu cầu nên bao gồm cả các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu hệ thống.
+ Tài liệu đặc tả yêu cầu không phải là tài liệu thiết kế hệ thống. Nó chỉ thiết lập những gì hệ thống phải làm, chứ không phải mô tả rõ làm như thế nào.
Các yêu cầu của một đặc tả tốt
+ Dễ hiểu với người dùng
+ Có ít điều nhập nhằng
+ Có ít quy ước khi mô tả, có thể tạo đơn giản
+ Với phong cách từ trên xuống (topdown)
+ Dễ triển khai cho những pha sau của vòng đời: thiết kế hệ thống và thiết kế chương trình và giao diện dễ làm, đảm bảo tính nhất quán, . . .
+ Ví dụ tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE:
– 1. Giới thiệu
1.1. Mục đích của tài liệu yêu cầu
1.2. Phạm vi của sản phẩm
1.3. Các định nghĩa, từ viết tắt
1.4. Các tham chiếu
1.5. Tổng quan về tài liệu yêu cầu
– 2. Mô tả chung
2.1. Giới thiệu chung về sản phẩm
2.2. Các chức năng của sản phẩm • 2.3. Đặc điểm của người sử dụng • 2.4. Các ràng buộc
2.5. Giả thiết và các phụ thuộc
– 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền
ứng dụng và giao diện.
– 4. Phụ lục
– 5. Chỉ mục
___________
3.1.2. Phân tích hệ thống
+ Xác định khách hàng, cùng khách hàng phát triển các yêu cầu
+ Xây dựng mô hình phân tích (hiểu bài toán):
– dữ liệu
– chức năng
– trạng thái
+ Làm bản mẫu đối với các chức năng chưa rõ ràng
+ Tạo đặc tả yêu cầu phần mềm
+ Thẩm định đặc tả yêu cầu
+Các nguyên lý phân tích
+Các phương pháp mô hình hóa
Nguyên lý 1:
+Nội dung: Mô hình hóa miền thông tin
Phải hiểu và biểu diễn được miền thông tin (problem domain)
– định danh dữ liệu (đối tượng, thực thể)
– định nghĩa các thuộc tính
– thiết lập các mối quan hệ giữa các dữ liệu
Từ điển dữ liệu, mô hình thực thể mối quan hệ, mô hình khái niệm
Nguyên lý 2:
+ Nội dung: Mô hình hóa chức năng
Bản chất của phần mềm là biến đổi thông tin
– định danh các chức năng (biến đổi thông tin)
– xác định cách thức dữ liệu (thông tin) di chuyển trong hệ thống
– xác định các tác nhân tạo dữ liệu và tác nhân tiêu thụ dữ liệu
Mô hình phân rã chức năng, mô hình luồng dữ liệu
Nguyên lý 3:
Nội dung: Mô hình hóa hành vi
Phần mềm (hệ thống) có trạng thái (hành vi)
-xác định các trạng thái của hệ thống
-xác định các dữ kiện làm thay đổi hành vi hệ thống
ví dụ: bàn phím, chuột, các cổng thông tin...
Nguyên lý 4 Nội dung: Phân hoạch các mô hình
Làm mịn, phân hoạch và biểu diễn các mô hình ở
các mức khác nhau
– làm mịn các mô hình dữ liệu
– tạo cây (mô hình) phân rã chức năng
– biểu diễn hành vi ở các mức chi tiết khác nhau
=>Mô hình luồng dữ liệu các mức 1,2,3,..
__________________
Mô hình hóa:
+ Biểu đồ phân rã chức năng (FDD)
+ Biểu đồ luồng dữ liệu (DFD)
+ Biểu đồ thực thể mối quan hệ (ER)
Mô hình hóa với FDD:
Biểu đồ phân rã chức năng
(Function Decomposition Diagram)
• Xác định phạm vi của hệ thống
• Phân hoạch chức năng
• Tạo nền tảng cho thiết kế kiến trúc hệ t
bán hàng
nhận đơn hàng ---- xử lý đơn hàng ------ gửi hàng hống
chức năng--liên kết
Ví dụ mô hình phân cấp chức năng đối với HTQLTV
Mô hình hóa với DFD
Biểu đồ luồng dữ liệu - Data Flow Diagram
• Cách thức dữ liệu được xử lý trong hệ thống
• Có nhiều mức chi tiết khác nhau (có cấu trúc)
• Có nhiều biến thể và mở rộng khác nhau
• Các đối tượng trong DFD
Tác nhân ngoài:
- đối t−ợng bên ngoài hệ thống
- phát sinh hoặc tiếp nhận thông tin
Tiến trình
- thao tác đối với thông tin (biến đổi)
Luồng dữ liệu
- luồng thông tin di chuyển trong hệ thống
Kho dữ liệu
- nơi lưu trữ dữ liệu
• Các bước để xây dựng:
Phân rã chức năng hệ thống
Liệt kê các tác nhân, các khoản mục dữ liệu
Vẽ DFD cho các mức
•Một số nguyên tắc:
o Các tiến trình phải có luồng vào và luồng ra
o Không có luồng dữ liệu trực tiếp giữa tác nhân với tác nhân hay kho dữ liệu
o Luồng dữ liệu không quay lại nơi xuất phát
Mô hình hóa với ER
+ Mô hình dữ liệu được sử dụng để mô tả cấu trúc logic của dữ liệu được xử lý bởi hệ thống.
+ Thông thường, chúng ta hay sử dụng mô hình quan hệ -thực thể (ER) nhằm thiết lập mối quan hệ giữa các thực thể và thuộc tính của các thực thể. Mô hình này được sử dụng trong thiết kế CSDL và thường được cài đặt trong các CSDL quan hệ.
Biểu đồ thực thể mối quan hệ
(Entity Relationship Diagram)
• Mô tả mối quan hệ vốn có của thế giới thực
o Thực thể
o Mối quan hệ
Phân tích dữ liệu độc lập với xử lý
=>Tạo ra mô hình trừu tượng hướng khách hàng
•Các đối tượng:
Thực thể
- là các đối t−ợng thế giới thực mà chúng ta muốn xử lý
- có thể là đối t−ợng thực hoặc trừu t−ợng
Thuộc tính
-đặc điểm của thực thể Cỏc đối tượng
Mối quan hệ
- mối liên hệ giữa các thực thể
- là thông tin cần l−u trữ/xử lý
Kế thừa
- quan hệ kế thừa giữa các thực thể
• Lực lượng tham gia mối quan hệ
object1(0, m)---relationship----(1, 1)object2
Xõy dựng cỏc thực thể và mối quan hệ
Thực thể
- là các danh từ (trong câu mô tả yêu cầu)
- có các thuộc tính khóa (xác định duy nhất
Mối quan hệ
- hoạt động xẩy ra giữa các thực thể
- có nghĩa với hoạt động của hệ thống
- là động từ
• Các bước mô hình hóa với ER:
o Xác định các thực thể và các thuộc tính của các thực thể
o Xác định các mối quan hệ giữa các thực thể
o Mô tả các thực thể, mối quan hệ và các thuộc tính
Từ điển dữ liệu:
+ Trên thực tế, mô hình dữ liệu thường không chi
tiết. Người phát triển có thể sử dụng từ điển dữ liệu làm công cụ bổ trợ. Từ điển dữ liệu là danh sách tất cả các tên gọi được sử dụng trong các mô hình hệ thống. Đó có thể là các thực thể, quan hệ và các thuộc tính …
+ Ưu điểm của từ điển dữ liệu là:
– hỗ trợ quản lý tên và tránh trùng lặp tên,
–lưu trữ kiến thức một cách có tổ chức kết nối pha phân tích, thiết kế và cài đặt.
Bạn đang đọc truyện trên: Truyen2U.Pro