Báo cáo môn học phân tích và yêu cầu phần mềm

Báo cáo trình bày về các nội dung: “Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mềm (Requirement Elicitation) truyền thống”, “Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mêm (Requirement Elicitation) nâng cao”, “Model– Driven Requirements Engineering (MDRE)”, “Tìm hiểu về các kỹ thuật và phương pháp thương lượng và thỏa thuận các yêu cầu phần mềm” và so sánh một số công cụ UML và lựa chọn công cụ của chúng em.

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ––––––––––––––––––––––––*––––––––––––––––––––––

Báo cáo bài tập tuần

Môn học: Phân tích yêu cầu phần mềm

Tuần 2

Nhóm 3

Danh sách sinh viên:

Lê Trung Hiếu 20111568 CNTT-TT 2.3 K56

Đàm Văn Hoài 20111600 CNTT-TT 2.3 K56

Nguyễn Đức Cương 20111203 CNTT-TT 2.3 K56

Đoàn Văn Đạt 20111370 CNTT-TT 2.3 K56

Giảng viên: PGS.TS Huỳnh Quyết Thắng

Hà Nội Ngày 10 tháng 4 năm 2014

Tóm tắt

Báo cáo trình bày về các nội dung: “Các kỹ thuật liên quan đến phương pháp xác định các yêucầu phần mềm (Requirement Elicitation) truyền thống”, “Các kỹ thuật liên quan đến phươngpháp xác định các yêu cầu phần mêm (Requirement Elicitation) nâng cao”, “Model-DrivenRequirements Engineering (MDRE)”, “Tìm hiểu về các kỹ thuật và phương pháp thương lượng

và thỏa thuận các yêu cầu phần mềm” và so sánh một số công cụ UML và lựa chọn công cụ củachúng em

Mục lục

Contents

Tóm tắt 2

Mục lục 3

Hình vẽ, bảng biểu 4

1.Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mềm (Requirement Elicitation) truyền thống 5

1.1.Phương pháp phỏng vấn (Interviewing customers and domain experts) 5

1.1.1.Khái niệm 5

1.1.2.Bản chất, đặc thù của phỏng vấn 5

1.1.3.Bảng câu hỏi và ghi nhận trả lời 6

1.1.4.Các phương pháp phỏng vấn 6

1.2.Phương pháp bảng hỏi (Questionnaires) 8

1.2.1.Bảng hỏi làm gì? 8

1.2.2.Sử dụng bảng hỏi khi 8

1.2.3.Các kỹ thuật thực hiện 8

1.2.4.Ưu / nhược điểm 9

1.2.5.Những lưu ý khi thực hiện phương pháp bảng hỏi 9

1.2.6.Một số mẫu 9

1.3.Phương pháp Quan sát (Observation) 10

1.3.1.Bản chất, đặc thù 10

1.3.2.Phân loại 10

1.3.3.Các kỹ thuật thực hiện 10

1.3.4.Ưu/ nhược điểm 10

1.4.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ự 11

1.4.1.Bản chất đặc thù 11

1.4.2.Ưu diếm/ nhược điểm của phương pháp 11

2.Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mêm (Requirement Elicitation) nâng cao 11

2.1.Phương pháp nguyên mẫu (Prototyping) 11

2.1.1.Khái niệm, đặc thù 11

2.1.2.Các trường hợp thường dùng 12

2.1.3.Các kỹ thuật thực hiện 12

2.1.4.Ưu/ nhược điểm 13

2.2.Phương pháp Brainstrorming 13

2.2.1.Đặc thù 13

2.2.2.Các kỹ thuật thực hiện 13

2.2.3.Ưu nhược điểm 14

2.3.Phương pháp Joint application development (JAD) 15

2.3.1.Khái niệm và đặc thù 15

2.3.2.Các kỹ thuật thực hiện 15

2.3.3.Ưu/ nhược điểm 15

2.4.Phương pháp Rapid application development (RAD) 16

2.4.1.Khái niệm và đặc thù 16

2.4.2.Các kỹ thuật thực hiện 16

2.4.3.Ưu/ nhược điểm 16

3.Model-Driven Requirements Engineering (MDRE) 17

3.1.Phương pháp luận 17

3.2.Một số kĩ thuật điển hình 18

3.3.Các công cụ phần mềm hỗ trợ 19

3.3.1.GME(Generic Modeling Environment) 19

3.3.2.DSL TOOLS ( Domain-Specific Language Tools) 20

3.3.3.EMF(Eclipse Modeling Framework) 21

3.4.Các dự án phần mềm thành công đã thực hiện dựa trên MDRE 23

3.4.1.DMAN project 23

3.4.2.OPENPROD Project.( Open Model-Driven Whole-Product Development and Simulation Environment) 23

4.Tìm hiểu về các kỹ thuật và phương pháp thương lượng và thỏa thuận các yêu cầu phần mềm .25

4.1.Các phương pháp chung của thương lượng, thỏa thu n yêu cầu phần mềmận yêu cầu phần mềm 25

Trước khi thương lượng, thỏa thu n:ận yêu cầu phần mềm 25

Trong khi thương lượng, thỏa thu n:ận yêu cầu phần mềm 25

Sau khi thương lượng, thỏa thu n:ận yêu cầu phần mềm 25

4.2.Các khía cạnh của thương lượng, thỏa thu n yêu cầuận yêu cầu phần mềm 25

4.2.1.Chiến lược giải quyết xung đ tột 25

4.2.2.Các hình thức c ng tác (Collaboration situations)ột 27

4.2.3.Các công cụ hỗ trợ thương lượng thỏa thu nận yêu cầu phần mềm 27

4.3.Ví dụ về các h thống thương lượng, thỏa thu nệ thống thương lượng, thỏa thuận ận yêu cầu phần mềm 27

4.3.1.Aspire 27

4.3.2.Negoisst 28

4.3.3.EasyWinWin 28

4.3.4.SmartSettle 28

5.Tìm hiểu, so sánh đánh giá lựa chọn công cụ các công cụ UML 30

5.1.ArgoUML 30

5.1.1.Tính năng của ArgoUML 30

5.1.2.Ưu điểm: 31

5.1.3 Nhược điểm: 31

5.2.StarUML 31

5.2.1.Tính năng của StarUML : 31

5.2.2.Ưu điểm: 32

5.2.3.Nhược điểm của StarUML: 33

5.3.Visual Paradigm 33

Các ưu điểm của VP-Paradigm 33

Hình vẽ, bảng biểu

1 Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mềm (Requirement Elicitation) truyền thống.

Phương pháp phỏng vấn (Interviewing customers and domain experts).

Khái niệm.

Phỏng vấn (interviewing) là một kỹ thuật quan trọng để phát hiện thông tin yêu cầu một cáchchi tiết từ một cá nhân Như là một kĩ sư phần mềm, bạn sẽ sử dụng nó trong việc phát hiện yêucầu phần mềm cho một hệ thống lớn Trong những dự án nhỏ, ta có thể sử dụng phương phápnày như một công cụ phát hiện yêu cầu phần mềm duy nhất

Bản chất, đặc thù của phỏng vấn

Phỏng vấn để phát hiện thông tin về:

 Các ý kiến của người được phỏng vấn

 Các cảm nghĩ của người được phỏng vấn

 Tình trạng hiện tại của phần mềm

xuất tồn kho

4 Hệ thống máy

móc, phần mềm

Tìm hiểu kỹ về tài nguyên máymóc, trang thiết bị, phần mềm, hệđiều hành đang sử dụng của tổchức

Hình 1 Kế hoạch phỏng vấn tổng quan.

Bảng kế hoạch phỏng vấn

Hệ thống:………

Vị trí/ phương tiện

Văn phòng, phòng họp, điện thoại,…

Thời gian: - Bắt đầu:

- Kết thúc:

Mục tiêu:

Dữ liệu cần thu thập?

Lãnh vực nào?

Lưu ý: - Kinh nghiệm

- Ý kiến đánh giá, nhận xét của người đượcphỏng vấn

Chi tiết buổi phỏng vấn

Tóm tắt các điểm chính

Câu hỏi của người trả lời phỏng vấn

Bảng câu hỏi và ghi nhận trả lời

Đáng tin cậyCâu hỏi 2:

Tất cả đơn đặt hàng của khách hàng phải được

thanh toán trước rồi mới giao hàng?

Trả lời:

Phải thanh toán trước hoặc ngay khi giao

Kết quả quan sát:

Thái độ không chắc chắn

Câu hỏi 3:

Chị muốn hệ thống mới sẽ giúp cho Chị điều gì?

Trả lời

Dữ liệu chỉ nhập một lần và hệ thống tự độngphát sinh báo cáo các loại

Kết quả quan sátKhông tin tưởng lắm, hình như đã triển khai thấtbại một lần

Hình 3 Bảng câu hỏi và ghi nhận trả lời.

Các phương pháp phỏng vấn.

Phỏng vấn với câu hỏi đóng.

Là câu hỏi mà các đáp án thường nằm trong các tình huống được xác định trước

Câu hỏi đóng thích hợp cho việc tạo các dữ liệu chính xác, tin cậy để dễ dàng phân tích

Hiệu quả và đỏi hỏi người phỏng vấn phải có kỹ năng để điều khiển cuộc phỏng vấn

 Buồn chán cho người được phỏng vấn

 Khó có được nhiều thông tin chi tiết

 Thiếu các ý tưởng

 Mất thời gian chuẩn bị các câu hỏi

 Không tạo mối quan hệ giũa những người phỏng vấn và những người được phỏng vấn

Phỏng vấn với câu hỏi mở.

Là loại câu hỏi với phạm vi trả lời tự do Câu hỏi thích hợp khi người phân tích quan tâm đếncâu trả lời rộng và sâu Câu hỏi mởi làm cho câu trả lời không bị gò bó và không gượng ép

Ưu/nhược điểm:

Ưu điểm:

 Người được phỏng vấn dễ dàng trả lời

 Không ràng buộc câu trả lời

 Có thể phát sinh ý tưởng mới

 Cung cấp nhiều chi tiết hơn

 Có ích cho người phỏng vấn không được chuẩn bị trước

 Tính linh hoạt cao

 Tính chính xác

 Tính tiện lợi

Nhược điểm:

 Thời gian hỏi kéo dài

 Nội dung có thể vượt qua phạm vi câu hỏi

 Ưu điểm / nhược điểm của phương pháp

 Nguồn thông tin phụ thuộc vào người được phỏng vấn

 Người phỏng vấn phải có kỹ năng giao tiếp tốt

 Nếu không chuẩn bị tốt dễ bị thất bại

 Có thể bất đồng về ngôn ngữ khái niệm

Phương pháp bảng hỏi (Questionnaires)

 Thu thập thông tin ở nhiều người với các điạ điểm khác nhau

 Nhiều người tham gia vào dự án

 Cần thực hiện việc tham dò

 Cần giải quyết vấn đề trước khi phỏng vấn

Các kỹ thuật thực hiện

 Các câu hỏi mở

Phù hợp cho việc thu thập các ý kiến

 Các câu hỏi đóng

Được sử dụng khi có một danh sách các tùy chọn

Ưu / nhược điểm.

Ưu điểm.

 Thu thập được nhiều thông tin theo chủ ý của người thiết kế bảng hỏi

 Thông tin tập trung, có tính định hướng

 Dễ thu thập và xử lý

Nhược điểm.

 Thu thập thông tin cứng nhắc do được thiết kế trước, kém linh hoạt

 Người lập bảng hỏi phải có kinh nghiệm và kỹ năng đặt câu hỏi

 Trả lời thụ động dễ điền không chính xác

Những lưu ý khi thực hiện phương pháp bảng hỏi.

 Bắt đầu bằng những câu hỏi thú vị và dễ trả lời

 Ngắn gọn chính xác, tránh viết tắt

 Cách diễn đạt đơn giản để tránh hiểu nhầm

Hình 5 Bảng với câu hỏi đóng.

Phương pháp Quan sát (Observation)

Bản chất, đặc thù

Là phương pháp ghi lại có kiểm soát các sự kiện hoặc hành vi ứng xử của con người

Thường kết hợp với các phương pháp khác để kiểm tra chéo độ chính xác của thu thập dữ liệu

Phân loại

Quan sát thụ động : Người quan sát ngồi tại chỗ và ghi chép lại các hoạt động, các bước xử lýcông việc Các băng video đôi khi có thể được dùng Ghi chép hoặc băng thu hình được phântích các sự hiện, các hoạt động công việc hoặc thông tin về công việc

Quan sát chủ động: tham gia trực tiếp vào các hoạt đông xử lý

Các kỹ thuật thực hiện

Bước 1 Xác định mục đích quan sát

Bước 2 Lựa chọn đối tượng quan sát

Bước 3 Tổ chức và hướng dẫn quan sát

Bước 4 Báo cáo kết quả quan sát

Ưu/ nhược điểm

Ưu điểm:

Dễ thực hiện đối với người quan sát

Theo dõi trực tiếp hoạt động của hệ thống thực tế

Nhược điểm:

Kết quả mang tính chủ quan

Tâm lý của người bị quan sát có những phản ứng nhất định

Sự bị động của phương pháp quan sát

Tốn kém thời gian

Thông tin bề ngoài, hạn chế không đầy đủ

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ự

Nghiên cứu phần mềm: Một cách thường xuyên, các ứng dụng phải thay thế các phần mềm cũ

Hệ thống hiện tại có thể đã có phần mềm hỗ trợ từ trước Nghiên cứu các phần mềm đã tồn tạicung cấp cho chúng ta các thông tin về quá trình xử lý công việc hiện thời và các mở rộng córàng buộc bởi thiết kế phần mềm Khiếm khuyết của việc thu nhận thông tin từ việc xem xétphần mềm là tài liệu có thể không chính xác hoặc kịp thời, mà có thể không đọc được và thờigian có thể lãng phí nếu ứng dụng đã bị xóa bỏ

Ưu diếm/ nhược điểm của phương pháp.

Ưu điểm

 Tìm được các vấn đề còn tồn tại trong hệ thống

 Có cái nhìn tổng quan về các chức năng mà hệ thống cần phải có

Nhược điểm.

 Thiếu tài liệu

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

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

2 Các kỹ thuật liên quan đến phương pháp xác định các yêu cầu phần mêm (Requirement Elicitation) nâng cao.

Phương pháp nguyên mẫu (Prototyping).

Một mô hình làm việc “nhanh và thô” của giải pháp cho hệ thống nhằm kiểm tra một số chứcnăng nào đó.

Có thể miêu tả GUI chi các ứng xử khác nhau của hệ thống

Nội dung có thể mã cứng hơn là truy cập động CSDL

Không thể thiếu trong quy trình phát triển phần mềm

Tính khả thi và hữu dụng của hệ thống có thể ước lượng qua Prototype trước khi thực sự đượccài đặt

Các trường hợp thường dùng.

 Hệ thống xây dựng chi các chức năng thương mại mới

 Dùng trong quá trình xây dựng các kịch bản cho use case

 Các yêu cầu xung đột

 Có vấn đề truyền thông giữa khách hàng và người phát triển

Các kỹ thuật thực hiện.

“Throw-away” prototype.

Bỏ đi khi tiến trình tìm kiếm yêu cầu hoàn tất

Tập trung vào các yêu cầu ít hiểu biết nhất

Thường thực hiện ở bước xác định yêu cầu

Evolutionnary prototype.

Được giữ lại sau khi tiến trình tìm kiếm hoàn tất

Thường đưa ra cho sản phẩm cuối cùng

Hướng đến việc phát triển nhanh hệ thống bằng cách tập trung vào các yêu cầu đã hiểu biếtnhất

Ưu/ nhược điểm

Ưu điểm.

 Phương pháp hữu dụng khi:

 Yêu cầu của người dùng không rõ ràng

 Ít người liên quan

 Các thiết kế phức tạp và đòi hỏi mẫu cụ thể

 Vấn đề truyền thông giữa phân tích và người dùng

 Sẵn công cụ để xây dựng mẫu

Nhược điểm.

 Khó thích ứng cho nhiều loại người dùng

 Chia sẻ dữ liệu với các hệ thống khác thường không được xem xét

 Kiểm tra vòng đời phát triển hệ thống thường bị bỏ qua

 Hình thành xu hướng không chuẩn mực trong việc tạo ra tài liệu hình thức về yêu cầu hệthống

 Các mẫu thường xây dựng trên các hệ thống đơn => chưa xét tương tác với hệ thốngkhác

Phương pháp Brainstrorming

Đặc thù

BrainStorming là kỹ thuật sáng tạo hỗ trợ việc tìm ý tưởng Việc sử dụng Brainstorming chophép tìm được nhiều ý tưởng đặc sắc nhất trong thời gian ít nhất nhờ vào việc không bị phánxét hay đánh giá Việc nhận xét hay đánh giá sẽ chỉ được thực hiện sau khi đã thu thập đủ nhiều

ý tưởng

Brainstorming giúp cho cá nhân hoặc tập thể có thể duy trì luồng suy nghĩ, tư duy một cách liêntục và ý tưởng này có thể là gợi ý cho những người kia nghĩ ra ý mới Giai đoạn tìm ý tưởng kếtthúc khi số lượng ý tưởng tương đối nhiều thì mới chuyển sang giai đoạn đánh giá các ý tưởng

đã được nêu ra để đưa ra kết luận

Các kỹ thuật thực hiện

Nêu ý tưởng.

 Hạn chế xung đột, chê bai ý tưởng trong nhóm

 Tìm thật nhiều ý tưởng trong thời gian ngắn nhất

 Khuyến khích tổ hợp các ý kiến thành viên

 Tìm ý tưởng mới dựa trên ý của các thành viên

Thâu tóm ý tưởng.

 Chọn ra các ý tưởng khả thi nhất theo yêu cầu ban đầu

 Biến các ý tưởng chọn lọc thành giải pháp

 Chọn các giải pháp khả thi, thực tiễn và phù hợp nhất với hoàn cảnh

 Công cụ điển hình thực hiện phương pháp

Ưu nhược điểm.

Ưu điểm.

Khuyến khích 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 hay 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 giải pháp khả thi cho vấn đề

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

Nhược điểm.

Phụ thuộc vào ý tưởng

Có thể không thu được kết quả

Phương pháp Joint application development (JAD)

Các kỹ thuật thực hiện.

Tổ chức cuộc họp từ 10 đến 20 người

Thời gian diễn ra từ 5 đến 10 ngày

Lưu giữ các ý kiến bằng băng ghi âm

Quản trị các xung đột

Công cụ điển hình thực hiện phương pháp

Ưu/ nhược điểm.

Ưu điểm

Hiệu quả

Cho kết quả nhanh

Giảm đáng kể thời gian, chi phí và lỗi dự án

Nhiều vấn đề được thảo luận đến thống nhất

Nhiều thông tin được bổ sung và làm chính xác

Nhược điểm

Chi phí lớn, tốn kém

Cần có văn phòng đặc biệt để tổ chức

Cần người có kinh nghiệm lãnh đạo

Phương pháp Rapid application development (RAD)

Khái niệm và đặc thù.

Phương pháp Rapid application development (RAD) là quy trình phát triển ứng dụng trong thờigian ngắn, tăng dần từng bước với mỗi chu kỳ

Xây dựng dựa trên hướng thành phần, tái sử dụng

Gồm một số nhóm, mỗi nhóm đảm nhiệm một pha trong RAD

Các kỹ thuật thực hiện.

Business modeling

Process and Data modeling

Application Generation and Testing

Ưu/ nhược điểm.

Ưu điểm.

 Quy trình được hoàn thành nhanh

 Khả năng tái sử dụng mã nguồn

Nhược điểm.

 Yêu cầu có thể bị lặp lại

 Cần nguồn nhân lực dồi dào

 Sự xung đột của các thông tin có thể dẫn đến thất bại

 Không phù hợp với các ứng dụng khó module hóa hoặc đòi hỏi tính năng cao

3 Model-Driven Requirements Engineering (MDRE).

Phương pháp luận.

MDRE được đề xuất để đối phó với sự phức tạp ngày càng tăng của kỹ thuật hệ thống theo ýnghĩa của việc cung cấp thông số kỹ thuật yêu cầu như mô hình chính thức cần phải chính xác ,đầy đủ, phù hợp , rõ ràng và dễ đọc và dễ dàng để duy trì Một vấn đề quan trọng trong lĩnh vựcnày là thiếu một mô hình tổng thể và tiêu chuẩn hóa ngôn ngữ mô hình trong đó bao gồm toàn

bộ các yêu cầu quy trình kỹ thuật từ đặc tả yêu cầu , phân bổ để xác minh SysML đang được đềxuất để áp ứng các yêu cầu này Trong bài báo này một mô hình điều khiển yêu cầu quy trình kỹthuật cho các ứng dụng công nghiệp trong lĩnh vực hệ thống tự động được mô tả để tiết lộnhững thiếu sót trong công cụ mô hình gần đây và mô hình hóa ngôn ngữ Đặc biệt tập trungđược layed vào định nghĩa yêu cầu và việc xác minh tự động của thiết kế chống lại các yêu cầu

sử dụng mô hình thực thi Dựa trên phân tích một hồ sơ mới của Unified Modeling Language(UML) được gọi là Model Driven Yêu cầu kỹ thuật cho Bosch Rexroth ( MDRE4BR ) được trìnhbày nhằm mục đích góp phần vào cuộc điều tra mới nhất trong lĩnh vực này

Model-Driven Engineering (MDE) dịch theo tiếng Việt có nghĩa là công nghệ hướng mô hình.MDE là hệ thống phương pháp luận (Methodology) phát triển phần mềm Hệ thống phươngpháp luận này nghiên cứu về: quy trình phát triển phần mềm (Process), các loại mô hình dùng

để mô tả hệ thống, ngôn ngữ mô hình hóa (Modeling Laguage), vá các công cụ hỗ trợ (CASETool) theo các cách tiếp cận khác nhau

Một yếu tố thành công quan trọng trong việc phát triển hệ thống thông tin là sự liên kết của hệthống với mục tiêu kinh doanh , ngữ nghĩa kinh doanh và quy trình kinh doanh Phát triển nênđược giải thoát khỏi mối quan tâm lập trình và có thể tập trung vào những vấn đề liên kết Pháttriển hệ thống mô hình điều khiển (MDD- Model-driven system development ) không chỉ cungcấp một cách tiếp cận có cấu trúc và có hệ thống để phát triển hệ thống , mà còn cung cấp cácnhà phát triển khả năng sử dụng công nghệ mô hình chuyển đổi để lấy mô hình của một mức

độ trừu tượng thấp hơn có thể được tiếp tục tinh chế, và thậm chí tạo ra phần mềm mã tựđộng

Kỹ thuật định hướng mô hình (MDE) đã được chứng minh là có khả năng để đối phó với sựphức tạp trong lĩnh vực công nghệ phần mềm Một xu hướng trong mô hình hóa và mô phỏng

là để áp dụng các MDE mô hình các hệ thống kỹ thuật bao gồm các thành phần trong phầncứng và phần mềm Ngày càng phức tạp hệ thống kỹ thuật đã nêu ra nhiều thách thức như giữthiết kế phù hợp và phê duyệt tương rectness đối với các yêu cầu của khách hàng với nghiêncứu tại Tập đoàn Bosch đã chỉ ra rằng hơn 50% của lĩnh vực vấn đề là do không đủ yêu cầu kỹthuật (RE) RE đi kèm với sự phát triển sản phẩm toàn bộ quá trình, trong đó các ngành kỹthuật khác nhau được tham gia Do đó, một mô hình phổ biến và được tiêu chuẩn hóa ngônngữ là yêu cầu mà chia sẻ sự hiểu biết giữa các kỹ sư từ các ngành khác nhau chung này ngônngữ sẽ cho phép xây dựng các yêu cầu mô hình, mô hình thiết kế hệ thống, mô hình truy xuấtnguồn gốc cũng như xác minh mô hình có chứa thông tin chi tiết tên miền cụ thể

Trong các ngành kỹ thuật hệ thống và kỹ nghệ phần mềm, phân tích yêu cầu là công việc baogồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở

là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống,

chẳng hạn người sử dụng, đưa ra Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thànhcông của một dự án.

Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (requirementsengineering) Đôi khi nó còn được gọi một cách không thật chính xác bằng những cái tênnhư thu thập yêu cầu (requirements gathering, requirements capture), hoặc đặc tả yêucầu(requirements specification) Thuật ngữ "phân tích yêu cầu" còn được áp dụng cụ thể chocông việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm rõ yêu cầu hay viết tàiliệu yêu cầu)

Các yêu cầu phải có tính đo được, kiểm thử được, có liên quan đến các nhu cầu hoặc cơ hộidoanh nghiệp đã được xác định, và các yêu cầu phải được định nghĩa ở một mức độ chi tiết đủcho việc thiết kế hệ thống