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 3. Quản lý thay đổi Sử dụng cửa sổ Audit View: ghi chép lại các thay đổi đã thực hiện. Kích hoạt Audit View: • Mở cửa sổ Audit View • Chọn Audit Settings • Enable Auditing 4. Lập báo cáo Sử dụng menu Project | Documentation • Lập các báo cáo đặc tả thông thường : thông tin về Requirement và các Requirement con tương ứng. Có nhiều định dạng văn bản khác nhau như: Rich Text Format, HTML, … • Báo cáo quan hệ cài đặt • Báo cáo quan hệ phụ thuộc . 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. • 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