BÀI GIẢNG PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU PHẦN MỀM

3.1. Đại cương về phân tích và đặc tả3.1.1. Khái niệm và tầm quan trọng3.1.2. Các yêu cầu và mục tiêu3.2. Nền tảng của phân tích3.2.1. Các nguyên lý phân tích 3.2.2. Các phương pháp mô hình hóa3.3. Phân tích và nắm bắt yêu cầu3.3.1. Các loại yêu cầu3.3.2. Sơ đồ tiến trình3.3.3. Phân tích tìm ra yêu cầu3.3.4. Những khó khăn của việc phân tích3.3.5. Các phương pháp thu thập yêu cầu3.4. Đặc tả yêu cầu3.4.1. Đặc tả yêu cầu phần mềm là gì?3.4.2. Các phương pháp đặc tả

CHƯƠNG 3:

PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU

NHÓM 5:

Nguyễn Ngọc Thành Phạm Thị Chung

Vũ Thanh Tùng Trần Thị Trà Giang Đặng Văn Huy

Đồng Thị Thỏa

 3.3 Phân tích và nắm bắt yêu cầu

3.3.1 Các loại yêu cầu 3.3.2 Sơ đồ tiến trình 3.3.3 Phân tích tìm ra yêu cầu 3.3.4 Những khó khăn của việc phân tích

3.3.5 Các phương pháp thu thập yêu cầu

 3.4 Đặc tả yêu cầu

3.4.1 Đặc tả yêu cầu phần mềm là gì? 3.4.2 Các phương pháp đặc tả

3.1 ĐẠI CƯƠNG VỀ PHÂN TÍCH VÀ ĐẶC TẢ

1 Khái niệm và tầm quan trọng

Hoạt động phân tích là hoạt động phối hợp giữa khách hàng và người phân tích (bên phát triển) Khách hàng phát biểu yêu cầu và người phân tích hiểu, cụ thể hóa và biểu diễn lại yêu cầu

Phần mềm đáng tin cậy có nghĩa là phải thực hiện được chính xác, đầy đủ yêu cầu của người sử dụng

Trong phân tích cần phân biệt giữa yêu cầu và mục tiêu của hệ thống.

Yêu cầu là một đòi hỏi mà chúng ta có thể kiểm tra được còn mục tiêu là cái trừu tượng hơn mà chúng ta hướng tới

- Ví dụ, giao diện của hệ thống phải thân thiện với người sử

dụng là một mục tiêu và nó tương đối không khách quan và khó kiểm tra

=> Tầm quan trọng: Là khâu kỹ thuật đầu tiên của quá trình

phát triển phần mềm Thiếu nó không thể tiếp tục quá trình

2 Các yêu cầu và mục tiêu

Khái niệm : Các yêu cầu là các mô tả trừu tượng đến chi tiết về dịch vụ mà hệ thống cung cấp cũng như các ràng buộc lên sự phát triển và hoạt động của nó.

Quá trình hình thành các yêu cầu.

Mục đích của các yêu cầu:

Làm cơ sở cho việc mời thầu (cần có giải thích từ phía chủ đầu tư)

Làm cở sở cho việc ký hợp đồng thầu (cần đủ và chi tiết)

Làm tư liệu đầu vào cho thiết kế và triển khai (cần

đủ, chính xác và không mâu thuẫn)

- Các mô hình (và vấn đề) phải được phân hoạch theo cách để

lộ ra các chi tiết theo kiểu phân tầng (hay cấp bậc)

- Tiến trình phân tích phải đi từ thông tin bản chất hướng tới chi tiết cài đặt Bằng cách áp dụng những nguyên lý này, người phân tích tiếp cận tới vấn đề một cách hệ thống

3.2.2 Các phương pháp mô hình hóa

- Chúng ta tạo ra các mô hình để thu được hiểu biết rõ hơn

về thực thể thực tế cần xây dựng

- Tuy nhiên, khi thực thể cần xây dựng là phần mềm, thì mô hình của chúng ta phải mang dạng khác Nó phải có khả năng mô hình hóa thông tin mà phần mềm biến đổi, các chức năng (và chức năng con) làm cho phép biến đổi đó thực hiện được, và hành vi của hệ thống khi phép biến đổi xảy ra

3.2 Nền tảng của phân tích

3.2.2 Các phương pháp mô hình hóa

Các mô hình được tạo ra trong khi phân tích yêu cầu còn đóng một

số vai trò quan trọng:

- Mô hình trợ giúp cho người phân tích trong việc hiểu về thông tin, chức năng và hành vi của hệ thống, do đó làm cho nhiệm vụ phân tích yêu cầu được dễ dàng và hệ thống hơn.

- Mô hình trở thành tiêu điểm cho việc xem xét và do đó, trở thành phần mấu chốt cho việc xác định tính đầy đủ, nhất quán và chính xác của đặc tả.

- Mô hình trở thành nền tảng cho thiết kế, cung cấp cho người thiết kế một cách biểu diễn chủ yếu về phần mềm có thể được “ánh xạ” vào hoàn cảnh cài đặt.

3.2.2 Các phương pháp mô hình hóa

1 Biểu đồ luồng dữ liệu

Khi thông tin đi qua phần mềm nó bị thay đổi bởi một loạt các phép biến đổi Biểu đồ luồng dữ liệu (Data Flow Diagram - DFD) là một kỹ thuật vẽ ra luồng dữ liệu di chuyển trong hệ thống và những phép biến đổi được áp dụng lên dữ liệu Ký pháp cơ bản của biểu đồ luồng dữ liệu được minh họa trên hình sau:

3.2.2 Các phương pháp mô hình hóa

1 Biểu đồ luồng dữ liệu

Biểu đồ luồng dữ liệu có thể được dùng để biểu diễn cho một hệ thống hay phần mềm ở bất kì mức trừu tượng nào

- Một DFD mức 0, cũng còn được gọi là biểu đồ nền tảng hay biểu đồ

ngữ cảnh hệ thống, biểu diễn cho toàn bộ phần tử phần mềm như một hình tròn với dữ liệu vào và ra được chỉ ra bởi các mũi tên tới và đi tương ứng

- Một DFD mức 1 cụ thể hóa của DFD mức 0 và có thể chứa nhiều hình tròn (chức năng) với các mũi tên (luồng dữ liệu) nối lẫn nhau Mỗi một trong các tiến trình được biểu diễn ở mức 1 đều là chức năng con của toàn bộ hệ thống được mô tả trong biểu đồ ngữ cảnh Hình 3 minh họa một DFD cho hệ thống bán vé tầu.

3.2.2 Các phương pháp mô hình hóa

2 Biểu đồ thực thể quan hệ

Tất cả đều xác định một tập các thành phần chủ yếu cho biểu

đồ EưR: thực thể, thuộc tính, quan hệ và nhiều chỉ báo kiểu khác nhau

- Mục đích chính của biểu đồ EưR là biểu diễn dữ liệu và mối quan hệ của các dữ liệu (thực thể)

- Ký pháp của biểu đồ EưR cũng tương đối đơn giản Các thực thể được biểu diễn bằng các hình chữ nhật có nhãn Mối quan hệ được chỉ ra bằng hình thoi Các mối nối giữa sự vật dữ liệu và mối quan

hệ được thiết lập bằng cách dùng nhiều đường nối đặc biệt

3.3.1 Các loại yêu cầu

 Phân tích và nắm bắt yêu cầu là giai đoạn đầu của quá trình thiết lập các dịch vụ và các ràng buộc (hệ thống phải giải quyết và tuân theo).

 Phân tích yêu cầu là một quá trình làm mịn, mô hình hóa và đặc tả gồm 5 bước:

 Có 2 loại yêu cầu:

+ Các yêu cầu hệ thống chức năng: Các dịch vụ mà hệ

thống yêu cầu

+ Các yêu cầu phi chức năng: Các ràng buộc mà hệ thống

phải tuân theo

 Yêu cầu hệ thống chức năng

Để bắt đầu, người phân tích giúp cho khách hàng trong việc xác định các mục tiêu của hệ thống (sản phẩm):

+ Thông tin nào cần phải tạo ra?

+ Thông tin nào cần được cung cấp?

+ Cần những chức năng và hiệu suất nào?

 Ngoài ra, còn có các yêu cầu phụ:

+ Liệu có công nghệ để xây dựng hệ thống? + Cần có những tài nguyên chế tạo và phát

triển đặc biệt nào?

+ Cần phải đặt giới hạn nào về chi phí và lịch biểu?

+ Thị trường?

+ Tính cạnh tranh?

+ Vị trí trong công ty?

 Yêu cầu phi chức năng (Yêu cầu của người sử dụng): Là một hạn

chế hoặc ràng buộc về các dịch vụ của hệ thống.

Các yêu cầu có thể được đưa ra:

+ Vì nhu cầu của người dùng

+ Vì hạn chế của kinh phí

+ Vì chính sách của tổ chức

+ Vì sự cần thiết tương tác giữa HW và SW

+ Vì quy tắc bên ngoài như an toàn, bí mật,

Mô hình hóa yêu cầu

Đặc tả yêu cầu

 Tìm hiểu các yêu cầu của phần mềm

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

+ Tìm kiếm các chuyên gia, người sử dụng có hiểu biết về

hệ thống cần xây dựng để thu thập được nhiều ý kiến, đóng góp khác nhau

Phân tích và yêu cầu thương lượng

+ Phân loại các yêu cầu phần mềm, sắp xếp chúng thành các nhóm có liên quan đến nhau dựa trên yêu cầu và đòi hỏi của người dùng

+ Thẩm định từng yêu cầu phần mềm để xác định xem chúng có khả năng thực hiện được hay không

+ Xác định các rủi ro có thể xảy ra với từng yêu cầu

+ Đưa ra các đánh giá tương đối về giá thành và thời gian thực hiện của từng yêu cầu

+ Giải quyết các bất đồng về yêu cầu phần mềm với người dùng trên cơ sở thảo luận và thương lượng

 Mô hình hóa yêu cầu

Sử dụng biểu đồ luồng dữ liệu và biểu đồ thực thể quan hệ

3.3.3 Phân tích và tìm ra yêu cầu

 Phân tích và xác định yêu cầu : còn được gọi là phát hiện yêu cầu

 Các nhà kỹ thuật cùng với khách hang (người dùng , kỹ

sư, nhà quản lý, chuyên gia miền) làm rõ:

- Phạm vi lĩnh vực ứng dụng

- Các dịch vụ mà hệ thống cần cung cấp

- Các ràng buộc đặt lên hoạt động của nó

 Bằng cách xây dựng các mô hình phân tích ( mô hình nghiệp vụ của hệ thống) để làm rõ các yêu cầu trên

3.3.4 Những khó khăn của phân tích

- Khách hàng thường mơ hồ về yêu cầu, không biết rõ mình muốn gì, dễ lẫn lộn giữa yêu cầu và mong muốn.

- Họ thể hiện yêu cầu theo thuật ngữ riêng.

- Khách hàng đa dạng, có thể có yêu cầu mâu thuẫn.

- Những yếu tố tổ chức và chính sách có thể ảnh hưởng đến yêu cầu

- Các yêu cầu thường mang tính đặc thù, khó hiểu, khó có chuẩn chung.

- Các yêu cầu thay đổi trong quá trình phân tích : môi trường nghiệp vụ thay đổi, có người liên quan mới

3.3.5 Các phương pháp thu thập yêu cầu

 Phỏng vấn khách hàng

 Thực hiện các hội thảo/thảo luận

 Chuẩn bị các bảng câu hỏi điều tra

 Quan sát hoạt động nghiệp vụ hiện tại

 Tham khảo các chuyên gia trong lĩnh vực

Phỏng vấn khách hàng

Lấy ý kiến về các yêu cầu sản phẩm, dự án, hoặc yêu cầu chung Có thể thực hiện bằng cách phỏng vấn trực tiếp, thông qua email, điện thoại, thư từ

 Cuộc phỏng vấn có thể được thực hiện dưới hình thức đơn hoăc nhóm (2-3 người) với các bên liên quan

 Nội dung câu hỏi và trả lời được hướng dẫn theo một danh sách thiết kế riêng

 Không nên sắp đặt sẵn ngữ cảnh câu hỏi nhằm thúc đẩy việc thảo luận tự do, sôi nổi

Thực hiện các hội thảo/thảo luận

- Tổ chức cuộc hội thảo gồm những người có quan điểm khác nhau, thảo luận và thống nhất về yêu cầu

- Sau khi đưa ra các tài liệu cơ bản của dự án, quá trình thảo luận trong nhóm sẽ diễn ra để có thể gợi ra nhiều ý tưởng

- Thảo luận có thể vừa bổ sung và thay thế phỏng vấn

Chuẩn bị các bảng câu hỏi điều tra

- Kỹ thuật này thường được sử dụng cho nhóm lớn

- Người điều tra sử dụng bảng câu hỏi (hay phiếu điều tra) để xác định yêu cầu từ những người tham dự (chuyên gia, khách hàng, thành viên đội dự án, Stakeholder, người sử dụng hệ thống)

Quan sát hoạt động nghiệp vụ hiện tại

Lập mô hình đề xuất về sản phẩm và nhận phản hồi của khách hàng trên mô hình Tiến hành cập nhật cho đến khi xác định yêu cầu rõ ràng

Quan sát thực tế những người sử dụng sản phẩm tiềm năng hoặc tham gia trực tiếp vào công việc để xác định yêu cầu

Tham khảo các chuyên gia trong lĩnh vực

Đưa ra điểm so sánh giữa các ý tưởng, việc này được thực hiện trong nội bộ hoặc công cụ bên ngoài

3.4 Đặc tả yêu cầu

3.4.1: Đặc tả yêu cầu phần mềm là gì?

 Khái niệm: là tất cả các mô tả chi tiết về các yêu cầu,

chức năng, ràng buộc của một số sản phẩm phần mềm được thiết kế

- Đặc tả liên quan đến các đối tượng, các khái niệm và các thủ tục nào đó cần đến khi phát triển phần mềm

1.Đặc tả phi hình thức

- Được diễn đạt bằng ngôn ngữ tự nhiên và toán học

- Phương pháp đặc tả này không chặt chẽ nhưng dễ hiểu

và dễ diễn đạt

- Ta thường sử dụng khi cần phát biểu các bài toán, các yêu cầu ban đầu

3.4.2 Các phương pháp đặc tả

2 Đặc tả hình thức

- Được diễn đạt bằng ngôn ngữ đại số và logic toán

- Phương pháp đặc tả này rất chặt chẽ, chính xác và không nhấp nhằng

3 Đặc tả hỗn hợp

- Phối hợp giữa 2 phương pháp: hình thức và phi hình thức

- Thường mô tả phi hình thức nhằm làm giải thích rõ hơn,

dễ hiểu hơn một khi mô tả hình thức quá phức tạp