Requirement Analysis under Incomplete Assumptions

Context

Trong nhiều contexts, Requirement Analysis được
hiểu như "quá trình trích xuất requirements."

Tuy nhiên, trong software đang vận hành hoặc maintenance projects,
requirements hầu như không bao giờ căn chỉnh một cách hoàn chỉnh hoặc nhất quán.
Specifications từng phần, assumptions cho các quyết định không được chia sẻ,
và stakeholder expectations cũng thay đổi theo thời gian.

Requirement Analysis được thực hiện trong các tình huống như vậy
cần được coi
không phải như hành động thu thập requirements,
mà là tổ chức assumptions để các quyết định có thể thành lập.

Objective

Mục đích của topic này là
không phải precise requirements definition hoặc complete specification consensus.

Nó nằm trong việc tạo ra một trạng thái mà các quyết định liên quan đến
các thay đổi và implementation có thể được thực hiện
ngay cả dưới incomplete assumptions.

Requirement Analysis được
coi như một phương tiện tránh các quyết định bị hoãn lại.

Minimal Inputs

Minimal inputs trong Requirement Analysis
được cấu thành không phải từ "điều gì xây dựng,"
mà điều gì cố định như assumptions cho các quyết định.

• SoT (Source of Truth)
  Information source trở thành ultimate basis cho requirements decisions

• Constraints
  Contracts, deadlines, organizational và technical constraints

• Non-Changeables
  Assumptions được thỏa thuận không thay đổi trong các quyết định lần này

• Uncertainties
  Items không thể được xác định tại thời điểm này và được coi như hypotheses

Trừ khi những điều này được cố định,
requirements vẫn trong một trạng thái mà chúng có thể được liên tục diễn giải lại.

Working Model

Requirement Analysis là
không phải là một quá trình để hoàn thiện requirements.

Nó có một working model
để xử lý requirements như hypotheses
dưới incomplete assumptions.

• Requirements được coi như hypotheses
• Basis hỗ trợ những hypotheses đó
• Conditions mà dưới đó hypotheses sụp đổ
• Deadline cho phép chúng như hypotheses

Hypotheses không có deadlines
có xu hướng được coi như implicit finalized items.

Tactics

Intervention trong Requirement Analysis
không phải là tăng requirements.

• Trước tiên cố định assumptions cần thiết cho các quyết định
• Làm cho undetermined requirements rõ ràng như hypotheses
• Cố ý để lại điều không quyết định

Đây không phải là procedures,
mà là design để duy trì decision-making capability.

Risks

Requirement Analysis
dễ dàng biến thành các thất bại sau.

• Requirements được thêm vào vô hạn và các quyết định dừng lại
• Hypotheses không được xác minh và assumptions trở nên cố định
• "Requirements vẫn không đủ" được sử dụng như evasion của responsibility

Những điều này,
với Decision Avoidance và Context Erosion như background,
trở thành breeding grounds gây ra Failure Patterns.

Interaction with Failure Patterns

Requirement Analysis
liên quan mạnh mẽ đến các Failure Patterns sau.

• Decision-less Agility
  Countermeasure chống lại các trạng thái mà không quyết định được hợp lý hóa

• Context-Blind Change
  Countermeasure chống lại các trạng thái mà các thay đổi tiến hành mà không có decision assumptions được cố định

• Specification-by-Absence
  Framework để làm cho assumptions rõ ràng trước khi implicit specifications được tạo ra

AI Collaboration

Khi sử dụng AI cho Requirement Analysis,
thay vì bản thân requirements,
passing decision assumptions trở nên quan trọng.

• Điều gì làm SoT
• Constraints nào không vượt qua
• Điều gì coi như non-changeable
• Uncertainties nào cho phép như hypotheses

Nếu những điều này không được cố định,
AI tạo ra plausible requirements,
nhưng không thể thực hiện các quyết định.