Đề cương chi tiết phân tích yêu cầu phần mềm

Đề cương ôn thi cuối kì học phần phần tích yêu cầu phần mềm.

Mục lục

CHƯƠNG I TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM VÀ QUY TRÌNH

1. Các quan điể m khác nhau trong đinh ngḥia về yêu cầ u phầ n mề m Đinh ngḥia ̃ chuẩn theo IEEE.

<bai tap tuan 1> or slide

2. Hãy nêu bản chất của yêu cầu phần mềm Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng

 Bản chất

Bản chất của yêu cầu phần mềm là mâu thuẫn

Sự mâu thuẫn thể hiện ở ý niệm về yêu cầu phần mềm xuất phát từ khách hàng và từ người sử

dụng

• Các yêu cầu phần mềm xuất phát từ người sử dụng đối với người phát triển phần mềm thông thường quá trừu tượng, ở mức cao

• Ngược lại yêu cầu phần mềm được mô tả từ người phát triển đối với người sử

dụng lại ở mức quá thấp, quá chi tiết cho nên người sử dụng không thể hiểu hết

được

Vì sự mâu thuẫn đó nên IEEE 1997 đã đưa ra một định nghĩa yêu cầu phần mềm nhìn

từ góc độ

người sử dụng và người phát triển, và những yêu cầu đó cần được đúc kết thành một văn bản để

thống nhất giữa 2 bên

Định nghĩa IEEE:

• Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để giải quyết một vấn đề hoặc để giải quyết một mục tiêu (1)

• Điều kện hay khả năng cần phải thỏa mãn hoặc cần có của 1 hệ thống hoặc 1

thành phần hệ thống nhằm đáp ứng 1 hợp đồng, 1 tiêu chuẩn hoặc 1 đặc tả của

một tài liệu khác.(2)

• Văn bản thể hiện các điều kiện khả năng được thể hiện ở (1) và (2)

 Định nghĩa từ khách hàng

Định nghĩa IEEE về yêu cầu phần mềm từ phía khách hàng: • Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để

giải quyết một vấn đề hoặc để giải quyết một mục tiêu (1)

3. Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần mềm

 Thói quen tốt:

• Luôn hỏi lại người dùng những gì mình chưa hiểu hết về yêu cầu của họ

• Không chỉ khảo sát yêu cầu với một loại người sử dụng, mà phải bao quát tất cả những người sử dụng

• Đánh dấu những điểm chưa rõ trong đặc tả: Đôi khi chúng ta thiếu một số thông tin về các yêu cầu phần mềm, chúng ta cần thảo luận với người sử dụng để hiểu

chi tiết hơn Tất cả những chỗ như vậy đc đánh đấu là TBD( Tobe determined).

=> Tất cả TBD này phải đc giải quyết trước khi bắt đầu quá trình phân tích và xây dựng phần mềm

 Thói quen không tốt:

• Tự mình nghĩ ra những yêu cầu của người dùng, hay tự cho mình là người dùng phần mềm

• Người sử dụng là chuyên viên trong lĩnh vực nào đó nên có thói quen nghĩ là tất

cả các phân tích viên đề là các chuyên gia trong lĩnh vực đó => Đưa ra các yêu cầu ngắn gọn mà ko miêu tả kỹ lưỡng hơn chúng là gì

4. Nêu các thuôc tính chất lương của yêu cầu phần mề m Quan hê ̣ giữa các thuôc tính chất lương.

5. Nêu các phương pháp phân loai yêu cầ u phầ n mềm Phân tích đăc điể m của từng phân loai

6. Mô tả Quy trình công nghệ học yêu cầu phần mềm (Requirement Engineering Process)

Quy trình công nghệ học phần mềm được chia thành 2 giai đoạn: Phát triển yêu cầu

và Quản lý

yêu cầu Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn: Phát hiện yêu cầu,

Phân tích yêu cầu, Đặc tả yêu cầu và kiểm thử yêu cầu

- Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn:

Phát hiện yêu cầu

Phân tích yêu cầu

Đặc tả yêu cầu

Kiểm thử yêu cầu

- Quản lý yêu cầu được hiểu là :”thiết lập và duy trì một thoả thuận với khách hàng về các yêu

cầu của dự án phần mềm” (CMU/SEI 1995) Quản lý yêu cầu gồm các bước sau

Xác định giới hạn yêu cầu phần mềm (Requirement baseline).

Duyệt các giới hạn của phần mềm

Quản lý các thay đổi yêu cầu phần mềm

Quy trình phát triển được thể hiện trên hình vẽ sau:

Mô tả quy trình như sau:

Maketing Customer Managerment lấy yêu cầu từ khách hàng, sau đó các yêu cầu đó được tổng

hợp lại, phân tích, thỏa thuận với khách hàng, rà soát lại ( Đây là quá trình phát triển yêu cầu )

Kết quả của quá trình phát triển yêu cầu là bản Baseline Requrirements Tài liệu này được chuyển

chuẩn hóa và làm mốc cho cả quá trình thay đổi ( gọi là phiên bản cơ sở 1.0)

Phiên bản cơ sở 1.0 được gửi cho khách hàng, bộ phận MCM lại tiếp tục đàn phán với khách

hàng trên cơ sở phiên bản này, những yêu cầu thay đổi được tổng hợp, xử lý cập nhập lại

Baseline Requirements

Với mỗi thay đổi cập nhập lại gồm : thay đổi cái gì, ai là người thay đổi, thay đổi ảnh hưởng như

thế nào đến hệ thống, đề phòng ra sao Tất cả các thông tin trên được chuẩn hóa thành phiên bản

1.1

Bây giờ phiên bản 1.1 được lấy làm cơ sở Quy trình cứ tiếp tục cho đến khi có sự thống nhất từ

khách hàng và đội phát triển

7. Nêu vai trò của từng tác nhân trong yêu cầu phần mề m Ảnh hưởng của các tác nhân đến các thuôc tính chất lương yêu cầ u phần mềm

CHƯƠNG II PHÁT HIỆN, TỔNG HỢP VÀ PHÂN TÍCH CÁC YÊU CẦU PHẦN MỀM và CHƯƠNG III ĐẶC TẢ CÁC YÊU CẦU PHẦN MỀM

1. Trình bày quy trình, kỹ thuật và nội dung cần hoàn thành khi xác định nhiệm vụ

và phạm vi của phần mềm

Trong phát triển phần mềm, có nhiều yếu tố cấu thành phạm vi của dự án Phạm vi dự

án là

một hàm của:

• Chức năng cần có để đáp ứng nhu cầu người dùng

• Tài nguyên sẵn sàng cho dự án

• Thời gian cần có để có thể thực hiện dự án

Phạm vi dự án

- Tài nguyên, trước hết bao gồm lao động từ developers, testers, tech writers, nhân viên đảm bảo chất lượng

Nếu thời gian đủ dài, kết quả công việc có thể được tăng lên, nhưng nó không tăng tỷ

lệ với tài nguyên đầu tư thêm Hiệu quả tổng thể của dự án vì thế mà sẽ bị giảm sút Thêm tài nguyên thậm chí có thể làm chậm dự án bởi vì cần phải đào tạo và hỗ trợ cho nhân sự mới, vì thế sẽ làm giảm năng suất của dự án

Nhằm mục đích phân tích phạm vi, ta coi tài nguyên là không đổi trong suốt dự án

- Thời gian, có thể thay đổi nếu như tài nguyên sẵn có không đủ để hoàn thành các chức năng mong muốn Để phân tích phạm vi, ta coi như thời gian là yếu tố cố định

Chức năng tổng thể bị giới hạn bởi thời gian (cố định) và tài nguyên (cũng cố định),

vì thế

phạm vi khả thi chính là hình chữ nhật màu trắng

Nếu hiệu năng đòi hỏi phải bổ sung đặc tính của hệ thống bằng với tài nguyên trên thời gian

sẵn có thì dự án có phạm vi khả thi.

Thông thường trong công nghiệp, các dự án đều là dự án vượt phạm vi

2. Nêu các phương pháp để phát hiên yêu cầu phần mềm và nguồn gốc yêu cầ u phần mềm

3. So sánh đánh giá các kỹ thuât phát hiên yêu cầ u phần mềm

 Phương pháp phỏng vấn

 Phương pháp bảng hỏi

 Phương pháp quan sát

 Phương pháp nghiên cứu tài liệu và các

phần mềm tương ứng

<Xem bai tập tuần 2> or slide

4. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Phỏng vấn (Interviewing customers and domain experts)

Đặt ra các câu hỏi về bản chất của các vấn đề người dùng Để giải quyết vấn đề này, cần sử dụng các câu hỏi:

- Người sử dụng là ai?

- Khách hàng là ai?

- Nhu cầu của họ có khác nhau không?

- Trong trường hợp nào thì có thể tìm thấy giải pháp cho vấn đề này?

Nội dung của cuộc phỏng vấn có thể được thực hiện theo mẫu như sau:

- Thiết lập tiểu sử người dùng hay khách hàng

- Đi vào vấn đề

- Tìm hiểu về môi trường người dùng

- Tóm tắt lại những gì thu được

- Phân tích đầu vào trên các vấn đề của khách hàng

- Đi vào giải pháp của mình (nếu thích hợp)

- Đi vào cơ hội

- Đi vào sự đáng tin cậy, hiệu quả và các nhu cầu hỗ trợ

- Những yêu cầu khác - Bao quát lại

- Tổng kết phân tích Những điểm cần lưu ý khi tiến hành phỏng vấn:

- Chuẩn bị trước nội dung cần phỏng vấn Xem lại các câu hỏi trước khi tiến hành phỏng vấn

- Trước cuộc phỏng vấn nên tìm hiểu về nền tảng của các bên liên quan và công ty được phỏng vấn

- Ghi lại những câu trả lời trong quá trình phỏng vấn (Không cố gắng lấy ra thông tin trong lúc này) - Tham khảo mẫu trong quá trình phỏng vấn để đảm bảo đặt ra những câu hỏi đúng

5. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Bảng hỏi (Questionnaires)

Quy trình thực hiện và kỹ thuật xác định yêu cầu phần mềm hội thảo

- Chuẩn bị Hội thảo

o Quảng bá nội dung

o Đảm bảo các bên liên quan sẽ tham dự

o Chuẩn bị hậu cần tốt

o Khởi động vật chất (warm-up materials): gửi material ra trước hội thảo để chuẩn bị tham dự và cũng để tăng hiệu quả của cuộc hội thảo Có 2 loại warm-up materials:

♣ Thông tin cụ thể về dự án Trong đó có thể bao gồm bản phác thảo của các tài liệu yêu cầu, liệt kê những tính năng được đề nghị, bản sao các cuộc phỏng vấn với những người dùng tiềm năng, báo cáo phân tích về xu hướng, thư từ khách hàng, báo cáo lỗi

về hệ thống hiện hành, chỉ thị quản lý mới, dữ liệu marketing mới…

♣ Chuẩn bị cách suy nghĩ vượt ra khỏi giới hạn

- Chuẩn bị vai trò cho facilitator (vai trò như người dẫn chương trình hay người chủ tọa):

o Đó là người bên ngoài, có kinh nghiệm.xử lý về quản lý yêu cầu hoặc

o Là một thành viên trong nhóm và đã đạt được những thành tựu nhất định

- Lên lịch trình Hội thảo

- Chạy chương trình

o Các vấn đề và phương pháp thương mại

o Brainstorming

o Sự trình bày và những việc tiếp theo: sau Hội thảo, facilitator ghi lại các kết quả thu được Sau đó, facilitator kết thúc nhiệm vụ của mình và chuyển sang cho nhóm phát triển

6. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp Nghiên cứu tài liệu và các Hệ thống phần mềm tương tự (Study of documents and software systems)

Các thông tin mang lại

 Các vấn đề còn tồn đọng trong hệ thống

 Các cơ hội tiếp cận nhu cầu mới

 Phương hướng tiếp cận có thể tác động đến yêu cầu của HTTT

 Lí do tồn tại của hệ thống hiện hành

 Tìm ra tên và vị trí của những cá nhân có liên quan tới hệ thống Giúp cho việc giao tiếp, liên lạc đúng mục tiêu hơn

 Dữ liệu cấu trúc, quy tắc xử lí dữ liệu

Những hạn chế

 Thiếu tài liệu

 Tài liệu hết hạn

 Các tài liệu cũng là nguồn cung cấp thông tin không đúng, trùng lặp

7. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Brainstorming

Brainstorming gồm có 2 pha:

- Nêu ra các ý tưởng: Mục đích là đưa ra được càng nhiều ý tưởng càng tốt, mục đích mới là bề rộng, chưa cần có chiều sâu

- Thâu tóm lại ý tưởng: Phân tích các ý tưởng được đưa ra, chọn lọc, tổ chức, đánh giá, mở rộng theo chiều sâu, tinh chỉnh chúng lại thành ý tưởng thích hợp Kỹ thuật này có những lợi ích chính sau:

• Khuyến khích được mọi thành viên tham gia.

• Cho phép các thành viên tranh luận với nhau về các ý kiến đề xuất

• Người điều phối hoặc thư ký duy trì cuộc hội thảo không bị gián đoạn

• Diễn ra nhanh chóng

• Đưa ra các giải pháp khả thi cho vấn đề

• Khuyến khích các ý tưởng, suy nghĩ sáng tạo, độc đáo

Quy định:

8. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Prototyping

Prototyping là phương pháp xác định yêu cầu phần mềm bằng cách đưa ra các mẫu thử

Người phát triển sẽ dựa vào các yêu cầu khảo sát để đưa ra 1 sản phẩm ban đầu phác thảo có thể

bằng công nghệ khác với công nghệ sẽ được sử dụng Sau đó có sự trao đổi với người

sử dụng, từ

đó tìm ra các yêu cầu một cách cụ thể, rõ ràng hơn, đặc biệt là các yêu cầu có tính

“mờ” Việc tạo

mẫu thử có thể được sử dụng nhiều lần ở nhiều phần và giai đoạn khác nhau Các mẫu thử được

tạo ra có thể có khả năng tái sử dụng, các mẫu thử sau sẽ phát triển liên tiếp nên nền các mẫu thử

trước.(Mô hình tiến hóa)

Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm như là sự

thực thi riêng lẻ của hệ thống, nhằm mục đích giúp đỡ người phát triển, người sử dụng và khách

hàng hiểu cặn kẽ hơn về yêu cầu của hệ thống

Với mục đích phân tích yêu cầu ta có thể chon xây dựng các mẫu thử : throwaway, horizontal, user interface (Nếu muốn nói cụ thể từng loại mọi người đọc sách

Managing

Requirement Software chương 13 nhe)

Để xây dựng các mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát các yêu cầu của hệ thống, tiến hành trao đổi đàm phán với khách hàng

Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử Dựa vào các yêu cầu đã khảo sát tạo bản

mẫu rồi tro đổi với người sử dụng, với khách hàng, để phát hiện cụ thể hơn các yêu cầu đặc biệt

các yêu cầu có tính “mờ” Tiến hành phát triển theo mẫu thử đã được phê duyệt, sau bước đó tiếp

tục tạo các mẫu thử có thể sử dụng các mẫu thử đã có từ trước.

9. Nêu các phương pháp phân nhóm yêu cầu phần mề m Muc đích của phân nhóm Đánh giá kết quả phân nhóm

10. Nêu các phương pháp mô hình hó a các yêu cầ u phầ n mề m

11. Trình bày các bước (quy trình) Phân tích các yêu cầu phần mềm Nêu các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm

Sau khi thu thập được các thông tin về yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân

tích các yêu cầu đó Mục đích của việc phân tích này là để xác các yêu cầu đó có dư thừa, mức độ

quan trọng của các yêu cầu đó

-Từ các yêu cầu phần mềm, ta xác định biếu đồ use case

-Xác định các hoạt động nghiệp vụ với các điểm bắt đầu và kết thúc Trong các chu trình này, ta

cần xác định các đối tượng tham gia, các luồng thông tin và điều khiển trong chu trình -Xác định vấn đề của môi trường hoạt động phần mềm

-Thực hiền kết nối các yêu cầu nghiệp vụ và yêu cầu của người sử dụng

-Mô ta cụ thể chính xác các điều kiện và thuận lợi trong khi thực hiện các yêu cầu đó

Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm là:

1 Mã giả (Pseudocode)

2 Máy trạng thái hữu hạn (Finite state machines)

3 Cây quyết định (Decision trees)

4 Cây quyết định dạng đồ thị (Graphic decision trees)

5 Biểu đồ hoạt động (Activity diagrams (flowcharts)) 6 Mô hình thực thể liên kết (Entity relationship models)

7 Phân tích hướng đối tượng (Object-oriented analysis)

8 Phân tính cấu trúc (Structured analysis)

9 Biểu đồ luồng dữ liệu (Data flow Diagrams)

12. Trình bà y kỹ thuât thương lư ơng và thỏ a thuân yêu cầ u phần mềm Đánh giá quan hê ̣ giữa các tiêu chí "chất lương", "thời gian thưc hiên" trong thương lương ̣

13. Mô tả ngắn gọn cấu trúc của Tài liệu đặc tả yêu cầu phần mềm theo chuẩn IEEE830-1998 14 Nêu các kỹ thuật gán nhãn các yêu cầu phần mềm theo chuẩn IEEE830-1998

Nôi dung gồm có 6 phần:

1. Giới thiệu chung

1.1 Mục đích

1.2 Tài liệu thỏa thuận

1.3 Đối tượng đự định và đề xuất đọc

1.4 Phạm vi dự án

1.5 Tài liệu tham khảo

2. Mô tả hệ thống

2.1 Quan điểm sản phẩm

2.2 Đặc tính sản phẩm

2.3 Các lớp và đặc điểm của user

2.4 Môi trường hoạt động

2.5 Thiết kế và các hạn chế thực hiện

2.6 Tài liệu người dung

2.7 Giả định và phụ thuộc

3. Tính năng hệ thống

3.1 Mô tả và ưu tiên

3.2 Trình tự kích thích/phản hồi

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

4. Yêu cầu giao diện bên ngoài

4.1 Giao diện người dung

4.2 Giao diện phần cứng

4.3 Giao diện phần mềm

4.4 Giao diện truyền thông

5. Yêu cầu không có chức năng khác

5.1 Các yêu cầu hiệu suất

5.2 Các yêu cầu an toàn

5.3 Các yêu cầu bảo mật

5.4 Thuộc tính chất lượng phầm mềm

6. Yêu cầu khác

CHƯƠNG IV DUYỆT VÀ KIỂM SOÁT CÁC YÊU CẦU PHẦN MỀM

1. Phân biệt hai khái niệm: Requirements Verification and Requirements Validation Làm rõ sự khác biệt của các khái niệm này

 Requirements Verification (Xác nhận):

Kiểm tra xem đúng là sản phẩm khách hàng yêu cầu đang được xây dựng không Đảm bảo rằng các phần mềm đang được phát triển ( hoặc thay đổi) sẽ làm hài lòng tất cả các bên liên quan hay là được thẩm định bởi các bên liên quan tới sản phẩm Kiểm tra tính nhất quán của các đặc tả yêu cầu của các sản phẩm phần mềm đang phát triển ( thiết kế, thực hiện, ) đối với các đặc tả kĩ thuật

Chiếm khoản 20% khối lượng công việc nhưng có vai trò hết sức quan trọng hiệu quả đôi lúc chiếm phần lớn hiệu quả chung do có liên quan tới khách hàng