Phần 3: Yêu cầu người dùng

C1. Định nghĩa yêu cầu người dùng: các quan điểm định nghĩa, các định nghĩa chuẩn theo IEEE.

TL: Trong CNPM, phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một phần mềm (mới hoặc được sửa đổi), dựa trên cơ sở là các 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ần 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.

Việc phân tích yêu cầu nhằm xây dựng một cách hệ thống các yêu cầu cần thiết đối với phần mềm dựa trên những yêu cầu mơ hồ ban đầu do khách hàng (người sử dụng đưa ra).

C2. Những vấn đề trong định nghĩa yêu cầu: phát hiện yêu cầu, mô tả yêu cầu, mô hình hóa yêu cầu.

TL:

• Phát hiện yêu cầu phần mềm:

- Vấn đề: phạm vi của phần mềm, hiểu rõ phần mềm, các thay đổi của hệ thống.

- Phương pháp phát hiện:

o Phỏng vấn, làm việc nhóm, gặp gỡ đối tác...

o Tìm kiếm chuyên gia giúp xác định YCPM

o Xác định môi trường kỹ thuật

o Xác định ràng buộc lĩnh vực

o Thiết kế kịch bản sử dụng PM

- Sản phẩm đầu ra của p/hiện YCPM:

o Bảng kê đòi hỏi + chức năng

o Bảng kê phạm vi ứng dụng

o Mô tả môi trường kỹ thuật

o Bảng kê tập hợp các kịch bản

o Các nguyên mẫu xây dựng hoặc sử dụng trong phần mềm

o Danh sách nhân sự kể cả khách hàng

• Mô tả (đặc tả) yêu cầu: là công việc xây dựng các tài liệu đặc tả có thể sử dụng các công cụ.

- Các thành phần hồ sơ đặc tả:

o Đặc tả phi hình thức được viết bằng ngôn ngữ tự nhiên.

o Đặc tả hình thức được viết bằng tập các ký pháp có quy định chặt chẽ về cú pháp và ý nghĩa.

o Đặc tả chức năng: miêu tả các chức năng của hệ thống.

o Đặc tả phi chức năng: miêu tả các đặc tính, đặc trưng của phần mềm: các ràng buộc về dịch vụ, ràng buộc về quá trình phát triển, các chuẩn...

o Đặc tả vận hành chức năng mô tả các hoạt động của phần mềm sẽ xây dựng: các dịch vụ mà PM cung cấp, phản ứng cụ thể với từng đầu vào, hành vi trong các tình huống đặc biệt...

• Mô hình hóa yêu cầu: sử dụng các công cụ để xây dựng mô hình cho yêu cầu.

C3. Các kỹ thuật mô hình hóa yêu cầu phần mềm: các kỹ thuật cơ bản.

TL:

• Biểu đồ luồng dữ liệu (DFD): hệ thống là tập hợp các dữ liệu được xử lý bằng các chức năng tương ứng.

- Các ký pháp sử dụng:

- Đặc điểm:

o Có thể sử dụng để xây dựng mô hình vật lý hoặc logic, xây dựng cho hệ thống hiện tại hoặc hệ thống mới.

o Không thể hiện được yêu cầu cần thiết và thứ tự thực hiện chức năng.

o Đòi hỏi hiểu sâu yêu cầu để có thể sửa được DFD.

o Quyết định lúc nào dừng việc phân rã chức năng khá khó khăn.

• Máy trạng thái hữu hạn (FSM)

- FSM chứa:

o Tập hữu hạn các trạng thái Q

o Tập hữu hạn các đầu vào I

o Các chức năng chuyển tiếp

• Mô hình thực thể liên kết: mô hình khái niệm cho phép đặc tả các yêu cầu của hệ thống, thường sử dụng trong các hệ thống dữ liệu lớn

- Thực thể: tập hợp các thông tin liên quan được xử lý trong phần mềm.

o Thuộc tính: tính chất của một thực thể hoặc một đối tượng dữ liệu.

- Quan hệ: chỉ ra mối quan hệ giữa các đối tượng dữ liệu.

o Định lượng của mối quan hệ: 1:1, 1: n, m : n

o Có hoặc không quan hệ: 0 - có thể có có thể không, 1- bắt buộc phải có quan hệ

C4. Các kỹ thuật mô hình hóa yêu cầu phần mềm: các kỹ thuật nâng cao.

TL:

Ngôn ngữ mô hình hóa thống nhất (UML) là một ngôn ngữ mô hình gồm các ký hiệu đồ họa mà các phương pháp hướng đối tượng sử dụng để thiết kế các hệ thống thông tin một cách nhanh chóng. Các mô hình hướng đối tượng được lập cũng là cơ sở cho việc ứng dụng các chương trình tự động sinh mã trong các ngôn ngữ lập trình hướng đối tượng, chẳng hạn như ngôn ngữ C++, Java, ... Phương pháp mô hình này rất hữu dụng trong lập trình hướng đối tượng. Các mô hình được sử dụng bao gồm Mô hình đối tượng (mô hình tĩnh) và Mô hình động.

UML sử dụng một hệ thống ký hiệu thống nhất biểu diễn các Phần tử mô hình (model elements). Tập hợp các phần tử mô hình tạo thành các Sơ đồ UML (UML diagrams). Có các loại sơ đồ UML chủ yếu sau:

• Sơ đồ lớp (Class Diagram)

• Sơ đồ tình huống sử dụng (Use Cases Diagram)

• Sơ đồ trình tự (Sequence Diagram)

• Sơ đồ cộng tác (Collaboration Diagram)

• Sơ đồ trạng thái (State Machine Diagram)

• Sơ đồ thành phần (Component Diagram)

• Sơ đồ hoạt động (Activity Diagram)

• Sơ đồ triển khai (Deployment Diagram)

Cụ thể từng sơ đồ xem lại OOP, ko ghi ra vì dài quá không có thời gian làm(^_^)

C5. Đặc tả yêu cầu phần mềm: thế nào là đặc tả định nghĩa yêu cầu tốt?

TL:

o Dễ hiểu với người dùng

o Ít nhập nhằng

o Ít quy ước khi mô tả, có thể tạo đơn giản

o Phong cách từ trên xuống (top-down)

o Dễ triển khai cho các 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...

C6. Theo dõi vết yêu cầu phần mềm.

TL:

Theo dõi vết yêu cầu phần mềm là tài liệu mô tả vòng đời của yêu cầu và cung cấp khả năng truy xuất yêu cầu theo hai hướng giữa rất nhiều yêu cầu khác nhau. Nó cho phép người dùng tìm thấy nguồn gốc của mỗi yêu cầu và theo dõi mọi sự thay đổi đã được thực hiện trên yêu cầu này. Để thực hiện mục đích này, có thể cần thiết lưu trữ lại mọi thay đổi được thực hiện với các yêu cầu.

Phương pháp theo dấu yêu cầu:

• Mỗi yêu cầu nên được gán một khóa (id) riêng biệt.

• Các yêu cầu nên xác định các yêu cầu khác liên quan sử dụng khóa của nó.

• Mỗi yêu cầu nên chứa 1 ma trận chỉ ra các yêu cầu liên quan

Requirement Identifiers Reqs Tested REQ1

UC

1.1 REQ1

UC

1.2 REQ1

UC

1.3 REQ1

UC

2.1 REQ1

UC

2.2 REQ1

UC

2.3.1 REQ1

UC

2.3.2 REQ1

UC

2.3.3 REQ1

UC

2.4 REQ1

UC

3.1 REQ1

UC

3.2 REQ1

TECH

1.1 REQ1

TECH

1.2 REQ1

TECH

1.3

Test Cases 321 3 2 3 1 1 1 1 1 1 2 3 1 1 1

Tested Implicitly 77

1.1.1 1 x

1.1.2 2 x x

1.1.3 2 x x

1.1.4 1 x

1.1.5 2 x x

1.1.6 1 x

1.1.7 1 x

1.2.1 2 x x

1.2.2 2 x x

1.2.3 2 x x

1.3.1 1 x

1.3.2 1 x

1.3.3 1 x

1.3.4 1 x

1.3.5 1 x

etc...

5.6.2 1 x