TOGAF® Standard — Architecture Development Method¶

13. Quản lý yêu cầu Kiến trúc ADM (ADM Architecture Requirements Management)¶

"ADM Architecture Requirements Management" (Quản lý Yêu cầu Kiến trúc ADM) trong Tiêu chuẩn TOGAF® tập trung vào quy trình quản lý các yêu cầu kiến trúc xuyên suốt Phương pháp Phát triển Kiến trúc (Architecture Development Method - ADM).

Figure 13-1: ADM Architecture Requirements Hình 13-1: ADM Architecture Requirements

13.1. Mục tiêu (Objectives)¶

Đảm bảo rằng quy trình Quản lý Yêu cầu được duy trì và vận hành cho tất cả các giai đoạn ADM có liên quan.
Quản lý các yêu cầu kiến trúc (Manage architecture requirements) được xác định trong bất kỳ lần thực thi nào của chu trình ADM hoặc một giai đoạn.
Đảm bảo rằng các yêu cầu kiến trúc liên quan sẵn sàng để sử dụng bởi mỗi giai đoạn khi giai đoạn đó được thực thi.

13.2. Đầu vào (Inputs)¶

Các đầu vào cho giai đoạn Quản lý Yêu cầu bao gồm:

Kho lưu trữ Kiến trúc (Architecture Repository) đã được điền đầy đủ.
Mô hình Tổ chức cho Kiến trúc Doanh nghiệp (Organizational Model for Enterprise Architecture), bao gồm:
Phạm vi các tổ chức bị ảnh hưởng (Scope of organizations impacted)
Đánh giá mức độ trưởng thành, các khoảng trống và phương pháp giải quyết (Maturity assessment, gaps, and resolution approach)
Vai trò và trách nhiệm cho các nhóm kiến trúc (Roles and responsibilities for architecture team(s))
Các ràng buộc đối với công việc kiến trúc (Constraints on architecture work)
Yêu cầu ngân sách (Budget requirements)
Chiến lược quản trị và hỗ trợ (Governance and support strategy)
Khung Kiến trúc được Tùy chỉnh (Tailored Architecture Framework), bao gồm:
Phương pháp kiến trúc được tùy chỉnh (Tailored architecture method)
Nội dung kiến trúc được tùy chỉnh (Tailored architecture content) (các sản phẩm bàn giao và tạo tác - deliverables and artifacts)
Các công cụ đã được cấu hình và triển khai (Configured and deployed tools)
Tuyên bố về Công việc Kiến trúc (Statement of Architecture Work).
Tầm nhìn Kiến trúc (Architecture Vision).
Yêu cầu kiến trúc (Architecture requirements), điền vào một Đặc tả Yêu cầu Kiến trúc (Architecture Requirements Specification).
Đánh giá Tác động Yêu cầu (Requirements Impact Assessment).

13.3. Các bước thực hiện (Steps)¶

Các bước trong giai đoạn Quản lý Yêu cầu là:

Bước 1: Xác định yêu cầu (Identify requirements). Điều này thường được thực hiện bằng cách phân tích cách các mục tiêu kinh doanh có thể đạt được thông qua việc thiết kế các luồng giá trị (value streams), kịch bản kinh doanh (business scenarios), trải nghiệm người dùng (user experiences) hoặc cung cấp thông tin quản lý. Các yêu cầu này được ghi lại trong Đặc tả Yêu cầu Kiến trúc (Architecture Requirements Specification) và Kho lưu trữ Yêu cầu (Requirements Repository).
Bước 2: Thiết lập yêu cầu cơ sở (Establish baseline requirements). Xác định các ưu tiên, xác nhận sự đồng thuận của các bên liên quan về các ưu tiên, và ghi lại chúng trong Đặc tả Yêu cầu Kiến trúc và Kho lưu trữ Yêu cầu.
Bước 3: Giám sát yêu cầu cơ sở (Monitor baseline requirements).
Bước 4: Xác định các yêu cầu mới và thay đổi (Identify new and changed requirements). Các hành động bao gồm loại bỏ hoặc đánh giá lại các ưu tiên, thêm yêu cầu và đánh giá lại ưu tiên, hoặc sửa đổi các yêu cầu hiện có.
Bước 5: Xác định các yêu cầu thay đổi và ghi lại ưu tiên (Identify changed requirements and record priorities) . Đảm bảo các yêu cầu được ưu tiên bởi kiến trúc sư chịu trách nhiệm cho giai đoạn hiện tại và các bên liên quan, ghi lại các ưu tiên mới, xác định và quản lý các xung đột, và tạo Đánh giá Tác động Yêu cầu (Requirements Impact Assessment). Các yêu cầu thay đổi có thể đến từ bất kỳ nguồn nào. Quy trình này cần định hướng các giai đoạn ADM và ghi lại các quyết định liên quan đến yêu cầu.
Bước 6: Đánh giá tác động của các yêu cầu thay đổi (Assess impact of changed requirements). Điều này bao gồm đánh giá tác động lên giai đoạn hiện tại và các giai đoạn trước đó, quyết định thực hiện thay đổi hay trì hoãn, và nếu thực hiện, đánh giá khung thời gian cho việc triển khai quản lý thay đổi. Sau đó, một phiên bản Đánh giá Tác động Yêu cầu mới được phát hành.
Bước 7: Triển khai các yêu cầu phát sinh từ Giai đoạn H (Implement requirements arising from Phase H). Quá trình này đảm bảo các yêu cầu mới hoặc thay đổi từ Giai đoạn H (Quản lý Thay đổi Kiến trúc - Architecture Change Management) được quản lý phù hợp.
Bước 8: Cập nhật Kho lưu trữ Yêu cầu Kiến trúc (Update the Architecture Requirements Repository) với thông tin liên quan đến các thay đổi được yêu cầu, bao gồm các quan điểm của bên liên quan bị ảnh hưởng.
Bước 9: Triển khai thay đổi trong giai đoạn hiện tại (Implement change in the current phase).
Bước 10: Đánh giá và sửa đổi phân tích khoảng trống (Assess and revise gap analysis) cho các giai đoạn đã qua. Phân tích khoảng trống xác định các khoảng trống giữa Kiến trúc Hiện trạng (Baseline) và Kiến trúc Mục tiêu (Target). Một "yêu cầu khoảng trống" (gap requirement) là bất cứ điều gì đã bị loại bỏ một cách vô tình và cần thay đổi Kiến trúc Mục tiêu. Bước này đảm bảo các yêu cầu khoảng trống được giải quyết, ghi lại và Kho lưu trữ Yêu cầu Kiến trúc và Kiến trúc Mục tiêu được sửa đổi tương ứng.

Bước (Steps)	Các bước Quản lý Yêu cầu (Requirements Management Steps)	Các bước trong Giai đoạn ADM (ADM Phase Steps)
Bước 1		Xác định các yêu cầu (thường bằng cách phân tích cách mà các mục tiêu/đích kinh doanh có thể được đáp ứng thông qua việc thiết kế các luồng giá trị, kịch bản kinh doanh, trải nghiệm người dùng hoặc việc cung cấp thông tin quản trị) và ghi nhận chúng trong Đặc tả Yêu cầu Kiến trúc (Architecture Requirements Specification) và Kho Yêu cầu (Requirements Repository).
Bước 2	Thiết lập các yêu cầu cơ sở: xác định mức độ ưu tiên, xác nhận sự đồng thuận của các bên liên quan đối với các mức độ ưu tiên đó, và ghi nhận trong Đặc tả Yêu cầu Kiến trúc (Architecture Requirements Specification) và Kho Yêu cầu (Requirements Repository).
Bước 3	Giám sát các yêu cầu cơ sở
Bước 4		Xác định các yêu cầu mới và thay đổi: a. Loại bỏ hoặc đánh giá lại mức độ ưu tiên b. Thêm yêu cầu và đánh giá lại mức độ ưu tiên c. Sửa đổi các yêu cầu hiện có
Bước 5	Xác định các yêu cầu đã thay đổi và ghi lại mức độ ưu tiên: a. Xác định các yêu cầu đã thay đổi và đảm bảo rằng các yêu cầu này được sắp xếp ưu tiên bởi kiến trúc sư chịu trách nhiệm cho giai đoạn hiện tại và bởi các bên liên quan có liên quan b. Ghi lại các mức độ ưu tiên mới c. Đảm bảo rằng mọi xung đột được xác định và được quản lý xuyên suốt các giai đoạn để đi đến một kết luận và sự sắp xếp mức độ ưu tiên thành công d. Tạo Đánh giá Tác động của Yêu cầu (Requirements Impact Assessment – xem TOGAF Standard — Architecture Content) nhằm định hướng cho nhóm kiến trúc Ghi chú: * Các yêu cầu thay đổi có thể đến từ bất kỳ kênh nào Để đảm bảo rằng các yêu cầu được đánh giá và sắp xếp mức độ ưu tiên một cách đúng đắn, quy trình này cần dẫn hướng các giai đoạn ADM và ghi lại các quyết định liên quan đến các yêu cầu * Giai đoạn Quản lý Yêu cầu (Requirements Management) cần xác định mức độ hài lòng của các bên liên quan đối với các quyết định Trường hợp có sự không hài lòng, giai đoạn này vẫn chịu trách nhiệm đảm bảo việc giải quyết vấn đề và xác định các bước tiếp theo
Bước 6		a. Đánh giá tác động của các yêu cầu đã thay đổi đối với giai đoạn hiện tại (đang hoạt động) b. Đánh giá tác động của các yêu cầu đã thay đổi đối với các giai đoạn trước đó c. Xác định có nên triển khai thay đổi ngay hay hoãn sang chu kỳ ADM sau; nếu quyết định triển khai, cần đánh giá khung thời gian cho việc thực hiện quản lý thay đổi d. Phát hành Bản Đánh giá Tác động Yêu cầu (Requirements Impact Assessment), Phiên bản n+1
Bước 7		Thực hiện các yêu cầu phát sinh từ Giai đoạn H. Kiến trúc có thể được thay đổi trong suốt vòng đời của nó thông qua giai đoạn Quản lý Thay đổi Kiến trúc (Phase H). Quy trình Quản lý Yêu cầu đảm bảo rằng các yêu cầu mới hoặc thay đổi được hình thành từ Giai đoạn H sẽ được quản lý một cách phù hợp.
Bước 8	Cập nhật Kho Yêu cầu Kiến trúc với các thông tin liên quan đến những thay đổi được yêu cầu, bao gồm cả quan điểm của các bên liên quan bị ảnh hưởng.
Bước 9		Thực hiện thay đổi trong giai đoạn hiện tại.
Bước 10		Phân tích khoảng cách (gap analysis) trong các Giai đoạn B đến D của ADM dùng để xác định những khoảng trống giữa Kiến trúc Hiện tại (Baseline Architecture) và Kiến trúc Mục tiêu (Target Architecture). Một số loại khoảng trống nhất định có thể phát sinh ra các yêu cầu khoảng trống (gap requirements). ADM mô tả hai loại khoảng trống: * Một yếu tố có trong kiến trúc hiện tại nhưng không có trong kiến trúc mục tiêu (tức là yếu tố đó đã bị loại bỏ — có thể do vô tình hoặc cố ý) * Một yếu tố không có trong kiến trúc hiện tại nhưng lại xuất hiện trong kiến trúc mục tiêu (tức là yếu tố mới) Một “yêu cầu khoảng trống” (gap requirement) là bất kỳ yếu tố nào bị loại bỏ một cách vô tình, và do đó cần phải có thay đổi đối với Kiến trúc Mục tiêu để bổ sung lại. Nếu phân tích khoảng trống tạo ra các yêu cầu khoảng trống, thì bước này sẽ đảm bảo rằng chúng được xử lý, được ghi lại và lưu trữ trong Kho Yêu cầu Kiến trúc, đồng thời Kiến trúc Mục tiêu được điều chỉnh phù hợp.

13.4. Đầu ra (Outputs)¶

Các đầu ra của quy trình Quản lý Yêu cầu có thể bao gồm, nhưng không giới hạn ở:

Đánh giá Tác động Yêu cầu (Requirements Impact Assessment). Khi các yêu cầu mới phát sinh hoặc các yêu cầu hiện có thay đổi, một Đánh giá Tác động Yêu cầu được tạo ra, xác định các giai đoạn ADM cần được xem xét lại để giải quyết các thay đổi. Tuyên bố này trải qua nhiều lần lặp lại cho đến phiên bản cuối cùng, bao gồm đầy đủ các hàm ý của yêu cầu (ví dụ: chi phí, thời gian biểu và các chỉ số kinh doanh) đối với việc phát triển kiến trúc.
Đặc tả Yêu cầu Kiến trúc được cập nhật (Updated Architecture Requirements Specification), nếu cần. Đặc tả này nên được cập nhật khi các yêu cầu cho chu trình ADM hiện tại đã được hoàn thiện.
Kho lưu trữ Yêu cầu Kiến trúc (Architecture Requirements Repository) sẽ được cập nhật như một phần của giai đoạn Quản lý Yêu cầu và nên chứa tất cả thông tin yêu cầu.

13.5. Phương pháp tiếp cận (Approach)¶

13.5.1. Tổng quan (General)¶

Như được chỉ ra bởi vòng tròn "Requirements Management" ở trung tâm đồ họa ADM, ADM liên tục được thúc đẩy bởi quy trình Quản lý Yêu cầu.
Điều quan trọng cần lưu ý là vòng tròn Quản lý Yêu cầu biểu thị không phải một tập hợp yêu cầu tĩnh, mà là một quy trình động (dynamic process). Quy trình này giúp xác định, lưu trữ, và đưa các yêu cầu cho Kiến trúc Doanh nghiệp và các thay đổi sau đó vào và ra khỏi các giai đoạn ADM liên quan, cũng như giữa các chu trình của ADM.
Khả năng xử lý các thay đổi trong yêu cầu là rất quan trọng vì kiến trúc thường đối phó với sự không chắc chắn và thay đổi, cũng như các động lực và ràng buộc nằm ngoài tầm kiểm soát của doanh nghiệp (ví dụ: điều kiện thị trường thay đổi, luật pháp mới).
Quy trình Quản lý Yêu cầu tự nó không giải quyết, xử lý, hoặc ưu tiên bất kỳ yêu cầu nào (does not dispose of, address, or prioritize any requirements); điều này được thực hiện trong giai đoạn ADM liên quan. Nó chỉ đơn thuần là quy trình để quản lý các yêu cầu trong toàn bộ ADM.
Nên sử dụng một Kho lưu trữ Yêu cầu Kiến trúc (Architecture Requirements Repository) để ghi lại và quản lý tất cả các yêu cầu kiến trúc. Không giống như Đặc tả Yêu cầu Kiến trúc và Đánh giá Tác động Yêu cầu, Kho lưu trữ Yêu cầu Kiến trúc có thể chứa thông tin từ nhiều chu trình ADM.

13.5.2. Phát triển Yêu cầu (Requirements Development)¶

Các yêu cầu cấp cao đầu tiên được trình bày như một phần của Tầm nhìn Kiến trúc (Architecture Vision), được tạo ra bằng kỹ thuật kịch bản kinh doanh (business scenario) hoặc kỹ thuật tương tự.
Mỗi giai đoạn của ADM (từ Sơ bộ đến Giai đoạn H) phải chọn các yêu cầu đã được phê duyệt cho giai đoạn đó từ Kho lưu trữ Yêu cầu Kiến trúc và Đặc tả Yêu cầu Kiến trúc. Khi hoàn thành giai đoạn, trạng thái của tất cả các yêu cầu đó cần được cập nhật.
Trong quá trình thực hiện giai đoạn, các yêu cầu mới được tạo ra cho công việc kiến trúc trong tương lai nằm trong phạm vi của Tuyên bố về Công việc Kiến trúc hiện tại cần được ghi lại trong Đặc tả Yêu cầu Kiến trúc. Các yêu cầu mới nằm ngoài phạm vi của Tuyên bố về Công việc Kiến trúc hiện tại phải được đưa vào Kho lưu trữ Yêu cầu Kiến trúc để quản lý thông qua quy trình Quản lý Yêu cầu.
Trong mỗi giai đoạn ADM liên quan, kiến trúc sư nên xác định các loại yêu cầu phải được đáp ứng bởi kiến trúc, bao gồm:
Yêu cầu chức năng (Functional requirements)
Yêu cầu phi chức năng (Non-functional requirements)
Khi xác định yêu cầu, kiến trúc sư nên xem xét:
Giả định cho yêu cầu (Assumptions for requirements)
Ràng buộc cho yêu cầu (Constraints for requirements)
Các nguyên tắc đặc thù của miền (Domain-specific principles) thúc đẩy yêu cầu
Chính sách ảnh hưởng đến yêu cầu (Policies affecting requirements)
Tiêu chuẩn mà yêu cầu phải đáp ứng (Standards that requirements must meet)
Hướng dẫn tổ chức cho yêu cầu (Organization guidelines for requirements)
Thông số kỹ thuật cho yêu cầu (Specifications for requirements)
Các sản phẩm bàn giao trong các giai đoạn ADM sau này cũng chứa các ánh xạ đến các yêu cầu thiết kế và có thể tạo ra các loại yêu cầu mới (ví dụ: yêu cầu tuân thủ, khung thời gian triển khai).

13.5.3. Tài nguyên (Resources)¶

Tiêu chuẩn TOGAF không bắt buộc hoặc khuyến nghị bất kỳ quy trình hoặc công cụ cụ thể nào; nó chỉ nêu rõ những gì một quy trình Quản lý Yêu cầu hiệu quả nên đạt được.
Kịch bản Kinh doanh (Business Scenarios) là một kỹ thuật được sử dụng để phân tích cách một mục tiêu kinh doanh có thể được đáp ứng bởi một quy trình hoặc luồng giá trị. Phân tích nơi các hoạt động trong quy trình được thực hiện bởi con người và tác nhân máy tính là một cách rất hiệu quả để xác định và làm rõ các yêu cầu kiến trúc.
Có một số lượng lớn các công cụ thương mại sẵn có (COTS tools) để hỗ trợ Quản lý Yêu cầu, mặc dù không nhất thiết được thiết kế cho các yêu cầu kiến trúc.