Các kỹ thuật phân tích các yêu cầu phần mềm

Requirements Types
Software Requirements
Function Requiremnts
Non-Function
Requirements
Design Contraints
Phần 2 Các kỹ thuật phân tích các yêu cầu phần mềm
I. Giới thiệu chung
1. Mục đích
Mục đích của phần báo cáo này là giúp người đọc hiểu được các kỹ thuật
phân tích yêu cầu và sử dụng EA trong phân tích yêu cầu.
• Phát hiện và giải quyết xung đột giữa các yêu cầu.
• Phát hiện ra phạm vi của phần mềm và và nó phải tương tác như
thế nào với môi trường.
• Yêu cầu hệ thống phức tạp bắt nguồn từ các yêu cầu phần mềm
2. Phạm vi
Phạm vi trong các dự án phần mềm
3. Tài liệu tham khảo
II. Các kỹ thuật phân tích yêu cầu phần mềm
1. Requirement Classification
1.1.Giới thiệu
1.2 Function Requirements
Yêu cầu chức năng nói rõ hành hệ thống hoạt động như tế nào. Những
yêu cầu thường hướng hành động
1.3 Non-Function Requirements
 Tính khả dụng
 Độ tin cậy
 Hiệu năng
 Hỗ trợ
1.4 Design Contraints
Hạn chế tối thiểu trên thiết kế của hệ thống hoặc quy trình chúng tôi sử

dụng để xây dựng hệ thống.
2. Conceptual Modeling
Mô hình phát triển của một vấn đề thực là chia khóa đến phân tích yêu cầu
phần mềm. Mục đích của chúng là giúp đỡ trong việc hiểu vấn đề hơn là
thực thi thiết kế giải pháp. Sau đây khái niệm mô hình bao gồm mô hình thực
thi từ vẫn đề cấu hình tên miền đến phản ánh các mỗi liên hệ trong thế giới
thực và sự phụ thuộc.
Một số loại mô hình có thể được phát triển, chúng bao gồm dữ liệu và các
luồng điều khiển, trạng thái của mô hình, sự kiện rằng buộc, tương tác giữa
các user, các mô hình đối tượng, các mô hình dữ liệu và nhiều cái khác.
Một vài mô hình có thể được phát triển. Nhân tố ảnh hưởng lựa chọn mô
hình bao gồm :
 Vấn đề tự nhiên. Một vài kiểu nhu cầu phần mềm mà khía cạnh chắc
chắn được phân tích chính xác các phần.
 Sự thành thạo của kĩ sư phần mềm. nó thường tạo ra nhiều hơn chấp
nhận lời giải thích mô hình hoặc phương thức với những kĩ sư phần
mềm có kinh nghiệm.
 Các yêu cầu quy trình của khách hành
 Những phương thức và công cụ có giá trị.
3. Architectural Design and Requirements Allocation
• ở vài điểm này, kiến trúc của giải pháp phải được suy ra . thiết kế kiến trúc là
điểm mà ở đó các yêu cầu tiến triển chồng lên nhau với phần mềm hoặc thiết
kế các hệ thống và minh họa nó có thể xóa sự tách biệt của hai nhiệm vụ.
• Có nhiều lựa chọn, kĩ sư phần mềm hành động như kiến trúc phần mềm bởi
quy trình của phân tích và dàn dựng các yêu cầu theo yêu cầu cái mà thành
phần của chúng sẽ chịu trách nhiệm nhận biết các yêu cầu an toàn. Đây là yêu
cầu cấp phát- sự phân công các thành phần có trách nhiệm đáp ứng các yêu
cầu.
• Phân bỏ rất quan trọng cho việc phân tích chi tiết các yêu cầu. Sau đây cho
ví dụ một bộ các yêu cầu được chỉ định các thành phần, các yêu cầu cá nhân

có thể được tiếp tục phân tích để khám phá thêm các yêu cầu trên các thành
phần cần tương tác với các thành phần khác như thế nào để đáp ứng được sự
phân bố các yêu cầu. trong một dự án lớn, sự phân bố khuyến khích một vòng
lớn của phân tích các hệ thống con.
• Lặp lại yêu cầu và thiết kế.
• Sử dụng các yêu cầu Parent-Child để tăng tính đặc trưng
• Thiết kế kiến trúc được xác định chặt chẽ với khái niệm mô hình hóa. Việc
ánh xạ từ đên miền thực thể trọng thế giới thực đến thành phần phần mềm
không phải luôn luôn rõ ràng, vì vậy thiết kế kiến trúc được xác định là một
chủ đề riêng biệt. các yêu cầu kí hiệu và các phương thức được rộng rãi như
cả hai khái niệm mô hình và thiết kế kiến trúc.
4. Requirements Negotiation
Một thuật ngữ khác được sử dụng cho chủ đề này là “ conflict resolution” . Điều
quan tâm này giải quyết vẫn đề với các yêu cầu mà sự xung đột xảy ra giữa hai
yêu cầu của các bên liên quan cùng các tính năng không tương thích , giữa các
yêu cầu và nguồn lực hoặc giữa yêu cầu chức năng và yêu cầu phi chức năng.
Trong tất cả các trường hợp , nó không thận trọng cho các kĩ sư phần mềm làm
các quyết định đơn phương và do đó nó cần thiết tham khảo từ các bên liên quan
để đạt được một sự đồng thuận trên sự thỏa hiệp thích hợp.
Sử dụng Use Cases
• Để hỗ trợ các hoạt động thiết kế và mã hóa, các Use Case phát triển
trong các hoạt động suy luận hơn là xây dựng đầy đủ.
• Các Use Cases thích hợp nhất khi hệ thống giàu chức năng và phải hỗ
trợ các loại người dùng khác nhau.
• Các Use Case không có hiệu quả khi áp dụng đến hệ thống với một
vài hoặc không có giao diện người dùng tối thiểu, chủ yếu là những
yêu cầu phi chức năng và những hạn chế khi thiết kế.
III. Kĩ thuật trong EA giúp phân tích yêu cầu phần mềm
1. Xem xét cấu trúc phân cáp và cài đặt của yêu cầu phần mềm
Sử dụng cửa sổ Hierachy. Khi lựa chọn 1 Requirement, ta sẽ xem được các thông

tin về:
• Quan hệ phân cấp của Requirement: cho biết nó là con của các
Requirement nào, cha của các Reqiurement nào, quan hệ thuộc loại
nào (sở hữu hay kết tập) …
• Quan hệ về cài đặt của Requirement: nó được cài đạt bởi các Element
nào. Nếu Requirement có các Requirement con, EA có thể chi tiết việc
cài đặt của từng Requirement con đó.
2. Phân tích sự phụ thộc của yêu cầu
Sử dụng ma trận quan hệ (Relationship Matrix): thông qua cửa sổ
Relationship Matrix. Cho biết quan hệ giữa các đối tượng trong 2 package