1. Trang chủ
  2. » Luận Văn - Báo Cáo

KHẢO SÁT VỀ ĐẶC TẢ YÊU CẦU PHẦN MỀM

48 0 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Khảo Sát Về Đặc Tả Yêu Cầu Phần Mềm
Tác giả Nguyễn Dũng
Trường học Trường Đại Học
Chuyên ngành Phần Mềm
Thể loại Đề Tài Tốt Nghiệp
Định dạng
Số trang 48
Dung lượng 854,08 KB

Nội dung

Kinh Tế - Quản Lý - Công Nghệ Thông Tin, it, phầm mềm, website, web, mobile app, trí tuệ nhân tạo, blockchain, AI, machine learning - Kế toán Đặc tả yêu cầu Giáo viên: Nguyễn Dũng Email: nguyendung622gmail.com Nội dung Khái niệm và tầm quan trọng Phân loại các yêu cầu Phân tích và xác định yêu cầu Đặc tả yêu cầu Định dạng tài liệu yêu cầu 2 Khái niệm và tầm quan trọng Xác định và đặc tả yêu cầu 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 Là sự phối hợp của nhà phát triển và khách hàng Nó quyết định chất lượng phần mềm đạt được với chi phí dự kiến và thời hạn cho trước 3 Các yêu cầu và mục tiêu 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ó 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) 4 Các loại yêu cầu Yêu cầu người sử dụng Đơn giản, dễ hiểu Diễn đạt bằng ngôn ngữ tự nhiên và sơ đồ về dịch vụ hệ thống cần cung cấp và các ràng buộc trong hoạt động của nó Dành cho khách hàng Yêu cầu hệ thống Mô tả đủ chi tiết về các dịch vụ hệ thống cung cấp Các đặc trưng hệ thống cần có Như một hợp đồng giữa khách hàng và chủ đầu tư Đặc tả phần mềm Đủ chi tiết làm cơ sở cho việc thiết kế và triển khai Dành cho nhà phát triển 5 Yêu cầu người sử dụng Nên mô tả Yêu cầu chức năng Yêu cầu phi chức năng Dễ hiểu đối với người sử dụng Không có kiến thức chi tiết về kĩ thuậttin học Nên được mô tả bởi: Ngôn ngữ tự nhiên Ưu điểm: Dễ hiểu, dễ sử dụng Hạn chế: Không rõ ràng, thiếu chính xác, nhập nhằng Lẫn lộn giữa yêu cầu chức năng và phi chức năng Quá mềm dẻo (trình bày nhiều cách) Biểu đồ, bảng biểu 6 Yêu cầu hệ thống Là đặc tả chi tiết hơn yêu cầu người sử dụng Phục vụ cơ bản cho bước thiết kế Có thể sử dụng làm một phần của hợp đồng Có thể sử dụng các mô hình để mô tả 7 Tài liệu đặc tả Là các phát biểu chính thức về hệ thống cần xây dựng Không phải là tài liệu thiết kế Xác định hệ thống cần làm gì (What?) Không trả lời cho câu hỏi như thế nào (How?) 8 Tài liệu đặc tả Các yêu cầu đối với tài liệu đặc tả Đặc tả hành vi bên ngoài của hệ thống Đặc tả các ràng buộc cài đặt Dể dàng thay đổi Sử dụng như là công cụ tham khảo khi bảo trì Dự báo thời gian sống của hệ thống Đặc tả trả lời các sự kiện không mong đợi 9 Những người đọc yêu cầu Người dùng hệ thống Người quản lý của khách hàng Kỹ sư của khách hàng Nhà kiến trúc hệ thống Các nhà phát triển và bảo trì phần mềm  Yêu cầu viết ra cần đáp ứng được các đối tượng trên 10 Yêu cầu từ nghiệp vụ Các yêu cầu chức năng (Function requirement): Mô tả các chức năng hay các dịch vụ mà hệ thống phần mềm cần cung cấp Các yêu cầu phi chức năng (Non-Function requirement): Mô tả các ràng buộc đặt lên dịch vụ và quá trình phát triển hệ thống (về chất lượng, về môi trường, chuẩn sử dụng, qui trình phát triển,…) Các yêu cầu miềnlĩnh vực ngoài: Những yêu cầu đặt ra từ miền ứng dụng, phản ánh những đặc trưng miền đó. 11 Các yêu cầu chức năng Mô tả chức năng hay dịch vụ của hệ thống Chúng phụ thuộc vào: Loại phần mềm sẽ được xây dựng Sự mong muốn của khách hàng Loại hệ thống mà phần mềm trợ giúp Mức độ các yêu cầu Trừu tượng: hệ thống làm gì? Chi tiết : nhiệm vụ cụ thể của hệ thống cần thực hiện 12 Ví dụ Người sử dụng có thể tìm kiếm tài liệu dựa trên các từ khóa có trong tài liệu hoặc tên tài liệu Hệ thống phải đọc được các định dạng khác nhau của tài liệu: văn bản (.txt), PDF, Word, Excel,… Hệ thống cần cung cấp phương tiện hiển thị dễ dàng các tài liệu từ CSDL 13 Các yêu cầu phi chức năng Định nghĩa các tính chất và ràng buộc của hệ thống Yêu cầu tiến trình Phương pháp thiết kế Ngôn ngữ lập trình Công cụ sử dụng Thời gian trả lời Độ tin cậy Yêu cầu về lưu trữ dữ liệu 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 yêu cầu phi chức năng không được đáp ứng  hệ thống trở nên vô dụng 14 Các yêu cầu phi chức năng Yêu cầu về sản phẩm: Tốc độ, độ tin cậy, bộ nhớ cần, giao diện,… Yêu cầu về tổ chứctiến trình phát triển: Các chuẩn áp dụng, phương pháp thiết kế, ngôn ngữ lập trình, mô trình tiến trình,… Yêu cầu từ bên ngoài: Về chi phí, thời gian, bản quyền, liên kết,… 15 Các loại yêu cầu phi chức năng 16 Ví dụ Yêu cầu về sản phẩm Chỉ sử dụng tối đa 256 MB bộ nhớ Yêu cầu về tổ chức Tiến trình phải đáp ứng chuẩn DO178 Yêu cầu bên ngoài Hệ thống không được để lộ thông tin của khách hàng. 17 Tiến trình kỹ nghệ yêu cầu Các hoạt động của tiến trình kỹ nghệ Nghiên cứu khả thi  Báo cáo khả thi Phân tích, xác định yêu cầu  Mô hình hệ thống Đặc tả yêu cầu  Các yêu cầu được đặc tả Thẩm định yêu cầu  Tài liệu yêu cầu 18 Tiến trình kỹ nghệ yêu cầu 19 Nghiên cứu khả thi Nhằm trả lời câu hỏi: Có nên phát triển hệ thống hay không? Nội dung nghiên cứu khả thi tập trung để trả lời các câu hỏi: Hệ thống được xây dựng sẽ giúp ích gì cho tổ chức? Hệ thống sử dụng công nghệ nào, kinh phí bao nhiêu, thời gian bao nhiêu? Hệ thống cần phải tích hợp với hệ thống nào đang sử dụng? 20 Triển khai nghiên cứu khả thi Báo cáo khả thi được viết dựa trên các thông tin, báo cáo thu thập được, những đánh giá ban đầu về hệ thống hiện tại và phác thảo các phương án dự kiến Câu hỏi đặt ra cho người của tổ chức: Cái gì xảy ra nếu hệ thống không được triển khai? Những vấn đề gì cần giải quyết? Hệ thống được đề xuất giúp họ như thế nào? Những tích hợp gì cần phải có? Công nghệ mới là gì, kỹ năng gì cần có? Những tiện ích gì cần trợ giúp từ hệ thống? 21 Phân tích và xác định yêu cầu Làm rõ: Phạm vi lĩnh vực ứng dụng Các dịch vụ hệ thống cần cung cấp Các ràng buộc đặt lên hệ thống 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 22 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ác yêu cầu có thể mâu thuẩn nhau Những yếu tố tổ chức và chính sách có thể ảnh hưởng đến yêu cầu 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ô...

Trang 1

Đặc tả yêu cầu

Giáo viên: Nguyễn Dũng

Trang 2

Nội dung

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

• Phân loại các yêu cầu

• Phân tích và xác định yêu cầu

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

Trang 3

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

• Xác định và đặc tả yêu cầu

• 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

• Là sự phối hợp của nhà phát triển và khách

hàng

• Nó quyết định chất lượng phần mềm đạt được

với chi phí dự kiến và thời hạn cho trước

Trang 4

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

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ó

• 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

Trang 5

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

Yêu cầu người sử dụng

• Đơn giản, dễ hiểu

• Diễn đạt bằng ngôn ngữ tự nhiên và sơ đồ về dịch vụ hệ

thống cần cung cấp và các ràng buộc trong hoạt động của nó

Trang 6

Yêu cầu người sử dụng

• Nên mô tả

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

• Dễ hiểu đối với người sử dụng

• Không có kiến thức chi tiết về kĩ thuật/tin học

• Nên được mô tả bởi:

• Ngôn ngữ tự nhiên

• Ưu điểm: Dễ hiểu, dễ sử dụng • Hạn chế:

•Không rõ ràng, thiếu chính xác, nhập nhằng

•Lẫn lộn giữa yêu cầu chức năng và phi chức năng

• Quá mềm dẻo (trình bày nhiều cách)

Trang 7

Yêu cầu hệ thống

• Là đặc tả chi tiết hơn yêu cầu người sử dụng

• Phục vụ cơ bản cho bước thiết kế

• Có thể sử dụng làm một phần của hợp đồng

• Có thể sử dụng các mô hình để mô tả

Trang 9

Tài liệu đặc tả

•Các yêu cầu đối với tài liệu đặc tả

•Đặc tả hành vi bên ngoài của hệ thống

Trang 10

Những người đọc yêu cầu

Trang 11

Yêu cầu từ nghiệp vụ

Các yêu cầu chức năng (Function requirement):

• Mô tả các chức năng hay các dịch vụ mà hệ thống phần

mềm cần cung cấp

Các yêu cầu phi chức năng (Non-Function requirement):

• Mô tả các ràng buộc đặt lên dịch vụ và quá trình phát

triển hệ thống (về chất lượng, về môi trường, chuẩn sử dụng, qui trình phát triển,…)

Các yêu cầu miền/lĩnh vực ngoài:

• Những yêu cầu đặt ra từ miền ứng dụng, phản ánh

những đặc trưng miền đó

Trang 12

Các yêu cầu chức năng

Mô tả chức năng hay dịch vụ của hệ thống • Chúng phụ thuộc vào:

Trang 13

Ví dụ

•Người sử dụng có thể tìm kiếm tài liệu dựa

trên các từ khóa có trong tài liệu hoặc tên

Trang 14

Các yêu cầu phi chức năng

• Định nghĩa các tính chất và ràng buộc của hệ thống

• Yêu cầu tiến trình

• Yêu cầu về lưu trữ dữ liệu

• 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 yêu cầu phi chức năng không được đáp

ứng  hệ thống trở nên vô dụng 14

Trang 15

Các yêu cầu phi chức năng

Yêu cầu về sản phẩm:

• Tốc độ, độ tin cậy, bộ nhớ cần, giao diện,…

Yêu cầu về tổ chức/tiến trình phát triển:

• Các chuẩn áp dụng, phương pháp thiết kế,

ngôn ngữ lập trình, mô trình tiến trình,…

Yêu cầu từ bên ngoài:

• Về chi phí, thời gian, bản quyền, liên kết,…

Trang 16

Các loại yêu cầu phi chức năng

16

Trang 17

Ví dụ

•Yêu cầu về sản phẩm

•Chỉ sử dụng tối đa 256 MB bộ nhớ

•Yêu cầu về tổ chức

•Tiến trình phải đáp ứng chuẩn DO178

•Yêu cầu bên ngoài

•Hệ thống không được để lộ thông tin của

khách hàng

Trang 18

Tiến trình kỹ nghệ yêu cầu

• Các hoạt động của tiến trình kỹ nghệ

• Nghiên cứu khả thi  Báo cáo khả thi

• Phân tích, xác định yêu cầu  Mô hình hệ

thống

• Đặc tả yêu cầu  Các yêu cầu được đặc tả

Trang 19

Tiến trình kỹ nghệ yêu cầu

Trang 20

Nghiên cứu khả thi

• Nhằm trả lời câu hỏi:

Có nên phát triển hệ thống hay không?

• Nội dung nghiên cứu khả thi tập trung để trả lời các câu

hỏi:

Hệ thống được xây dựng sẽ giúp ích gì cho tổ chức? Hệ thống sử dụng công nghệ nào, kinh phí bao nhiêu,

thời gian bao nhiêu?

Hệ thống cần phải tích hợp với hệ thống nào đang sử

dụng?

20

Trang 21

Triển khai nghiên cứu khả thi

• Báo cáo khả thi được viết dựa trên các thông tin, báo cáo

thu thập được, những đánh giá ban đầu về hệ thống hiện tại và phác thảo các phương án dự kiến

• Câu hỏi đặt ra cho người của tổ chức:

Cái gì xảy ra nếu hệ thống không được triển khai?

Trang 22

Phân tích và xác định yêu cầu

• Làm rõ:

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

• Các dịch vụ hệ thống cần cung cấp • Các ràng buộc đặt lên hệ thống

• 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

Trang 23

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ác yêu cầu có thể mâu thuẩn nhau

Trang 24

Mục tiêu, mong muốn và yêu cầu

Mục tiêu, mong muốn: là cái hướng tới

• Chẳng hạn: xây dựng giao diện thân thiện với

người dùng

Yêu cầu: là cái cụ thể, kiểm tra được

• Chẳng hạn: giao diện đồ họa, các lệnh được

chọn bằng thực đơn hay biểu tượng

 Nhiệm vụ của người phân tích là gợi mở, xác định đúng, đầy đủ, chính xác các yêu cầu

24

Trang 25

Tiến trình phân tích yêu cầu

• Các hoạt động chính:

• Tìm hiểu miền ứng dụng • Phát hiện, thu thập yêu cầu • Phân loại yêu cầu

• Giải quyết xung đột (nếu có) • Sắp xếp ưu tiên các yêu cầu

25

Trang 26

Các nguyên lý

Mô hình hóa miền thông tin:

• Xác định các thực thể dữ liệu (đối tượng) • Xác định các thuộc tính của chúng

• Thiết lập mối quan hệ giữa các dữ liệu

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

• Xác định 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 (luồng dữ liệu)

• Xác định các tác nhân tạo và nhận dữ liệu 26

Trang 27

Các nguyên lý

Mô hình hóa 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 của hệ thống

• Phân hoạch, làm mịn: biểu diễn các mô tả ở các mức chi tiết

khác nhau

• Làm mịn các mô hình dữ liệu

• Tạo cây (biểu đồ) phân rã chức năng

• Biểu diễn hành vi ở các mức chi tiết khác nhau

Trang 28

Đặc tả yêu cầu

• Đặc tả yêu cầu là mô tả yêu cầu một cách đặc

biệt Yêu cầu nên được biểu diễn ở nhiều mức trừu tượng khác nhau: đầy đủ, chính xác dần, nhiều đối tượng có thể đọc:

Trang 29

Các mức trừu tượng của yêu cầu

Trang 30

Ví dụ: Chức năng kiểm tra chính tả • Định ra yêu cầu: Thông báo lỗi chính tả của văn bản

• Đặc tả:

• Các lỗi chính tả được gạch đỏ bên dưới • Lỗi soạn thảo được gạch xanh bên dưới

Lỗi chính tả

• Từ đơn không có trong từ điển Lỗi soạn thảo

• Thừa dấu cách

Trang 31

Đòi hỏi đặc tả yêu cầu

Đầy đủ: Mọi yêu cầu của người dùng phải được

mô tả

Không mâu thuẫn với nhau

Chính xác: Yêu cầu không được mơ hồ

• Chỉ được hiểu theo một nghĩa duy nhất

Trang 32

Nhiều cách biểu diễn cho một khái niệm

Khó phân hoạch, khó sửa đổi 32

Trang 33

• Mô hình luồng dữ liệu

• Mô hình thực thể - mối quan hệ (ERD) • Mô hình dữ liệu quan hệ

• Các mô hình nghiệp vụ, mô hình phân tích hướng đối tượng với

Trang 34

Đặc tả hình thức

• Biểu diễn mô hình toán học

• Khái niệm và ký pháp toán học

• Quy tắc khai báo và biểu diễn biểu thức • Các luật biểu diễn biểu thức

Có thể tự động hóa giải mô hình

Sử dụng mô hình cho chứng minh, kiểm

chứng

Khó hiểu, khó sử dụng

34

Trang 35

Thẩm định yêu cầu

• Liên quan đến việc kiểm tra tính đúng đắn, tính

đầy đủ, tính nhất quán, tính hiện thực và kiểm tra được của yêu cầu Cụ thể trả lời được các câu

hỏi:

• Còn nhu cầu nào của người dùng chưa kể đến? • Có mâu thuẩn gì giữa các yêu cầu?

• Chức năng, ràng buộc gì chưa kể? • Có thực hiện được không?

Trang 36

Các kỹ thuật thẩm định yêu cầu

• Xem xét lại yêu cầu: • Kiểm tra tính thực hiện được

• Tạo ca kiểm thử (test case)

Trang 37

Phương pháp xác định, đặc tả yêu cầu

• Mô hình nghiệp vụ (Chức năng)

• Biểu đồ phân rã chức năng (FDD) • Mô hình ca sử dụng (use case)

• Biểu đồ hoạt động (Activity Diagram)

• Biểu đồ chuyển trạng thái • Mô hình luồng dữ liệu (DFD)

Trang 38

Biểu đồ phân rã chức năng

FDD – 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ệ thống

38

Trang 39

Ví dụ:

Trang 40

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

DFD – Data Flow Diagram

•Mô tả quá trình xử lý thông tin nghiệp vụ •Biểu diễn cách thức dữ liệu di chuyển,

được xử lý, lưu trữ trong hệ thống và trao đổi với môi trường

•Có nhiều mức trừu tượng khác nhau •Làm cở sở cấu trúc phần mềm

40

Trang 41

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

• Khái niệm

• Tác nhân: người, tổ chức, hệ khác

• Đối tượng ngoài hệ thống

• Phát sinh hoặc tiếp nhân dữ liệu/thông tin

• Tiến trình: hoạt động nghiệp vụ

• Dãy hoạt động tác động lên dữ liệu

• Luồng dữ liệu: dữ liệu di chuyển

• Dữ liệu di chuyển từ nguồn tới đích

• Kho dữ liệu: dữ liệu được lưu trữ

• Dữ liệu được lưu trữ ở một vị trí

Tên luồng dữ liệu

Trang 42

Ví dụ: DFD mức 0 bán vé tàu

42

Trang 43

Mô hình thực thể mối quan hệ

Trang 44

Tầm quan trọng của ERD

• Phân tích dữ liệu độc lập với lưu trữ và xử lý

• Nghiên cứu phạm vi miền thông tin

• Tạo ra mô hình trừu tượng hướng khách hàng

(mô hình khái niệm), trực quan

• Xác định các mối quan hệ mang tính cấu trúc giữa

các dữ liệu Dễ dàng chuyển sang mô hình thiết

Trang 45

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

• Phỏng vấn

• Quan sát

• Điều tra bằng bảng hỏi

• Nghiên cứu tài liệu

Trang 46

Tài liệu yêu cầu

•Yêu cầu:

•Chỉ mô tả chức năng, ràng buộc

•Không mô tả về phương thức cài đặt •Phải dể thay đổi

Khó xác định chính xác, đầy đủ ngay Phải qua nhiều bước xét lại

46

Trang 47

Định dạng tài liệu yêu cầu

Giới thiệu: Mô tả sự cần thiết của hệ thống

Thuật ngữ: Định nghĩa các khái niệm kỹ thuật được sử dụng

trong tài liệu này

Định nghĩa yêu cầu người sử dụng: yêu cầu chức năng và phi

chức năng

Kiến trúc hệ thống

Đặc tả yêu cầu hệ thống: Mô tả yêu cầu cơ bản chi tiết hơn • Mô hình hệ thống: Mô hình đối tượng, mô hình luồng dữ liệu

và ngữ nghĩa dữ liệu,…

Phát triển/thay đổi của hệ thống: Các giả thiết, các dự đoán về

phát triển phần cứng, yêu cầu người dùng

Phụ lục

Trang 48

Question

48

Ngày đăng: 22/04/2024, 15:06

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w