Requirement là gì?

Requirement là gì? Về cơ bản sự diễn đạt cho một nhu cầu nào đó.

Theo BABOK:

A more precise definition is provided by the IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®). Both define a requirement as a

  1. condition or capability needed by a user to solve a problem or achieve an objective.
  2. condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
  3. documented representation of a condition or capability in (1) or (2).

The BABOK® defines the following requirements types: business, user (stakeholder), functional (solution), non-functional (quality of service), constraint, and implementation (transition).

Có mấy loại Requirement 

  1. Business  Requirements: là những yêu cầu rất high-level, ở mức chung chung, tổng quát từ phía khách hàng. Kiểu như tôi cần hệ thống quản lý tất cả thông tin của khách hàng trong hệ thống trading. 

Theo BABOK thì:

Business Requirement is statements of goals, objectives, and outcomes that describe why a change has been initiated.

  1. Stakeholder Requirements: Là những nhu cầu cụ thể của từng đối tượng Stakeholder. Yêu cầu đã thể hiện được họ cần gì. Ví dụ: Theo yêu cầu ở trên thì quản lý thông tin cá nhân của khách hàng

Theo BABOK định nghĩa:

Stakeholder requirements describe the needs of stakeholders that must be met in order to achieve the business requirements.

  1. Solution Requirement

Theo BABOK định nghĩ:

Solution requirements describe the capabilities and qualities of a solution that meets the stakeholder requirements

Function requirement:

 Là những thứ mà hệ thống có thể làm được. Là tất cả các hành vi của hệ thống

Non functional requirement:

  • Monitoring function & backup requirement: Trả lời cho câu hỏi những chức năng nào cần monitor và monitor bằng cách nào . Ví dụ: trong dự án chức năng nạp tiền, sẽ thế nào khi ngân hàng đã trừ tiền nhưng hệ thống chưa tính tiền cho bạn? Chính vì thế cần monitor khi hệ thống gặp vấn đề để tìm cách giải quyết nhanh nhất hoặc thông báo đến khách hàng kịp thời.
  • Yêu cầu về performance của hệ thống: Chức năng này có cần quan tâm đến hiệu suất không, nếu có thì nó là gì? Chức năng cần đáp ứng bao nhiêu giao dịch trong 1 giây? Thời gian phản hồi của giao dịch (trung bình, tối đa) là bao nhiêu? Khi vượt quá số lượng cho phép hệ thống sẽ như thế nào? Đây là những câu hỏi cơ bản khi nói đến performance của hệ thống.
  • Yêu cầu về security: Phần này mô tả tất cả các yêu cầu liên quan đến bảo mật dữ liệu. Dữ liệu nào cần mã hóa, mã hóa như thế nào? Những thông tin nào không được hiển thị trong log? Khi giao tiếp với hệ thống bên ngoài cần những xác minh gì?…
  1. Transition Requirement: là toàn bộ những yêu cầu của khách hàng liên quan tới việc áp dụng giải pháp vào tổ chức như thế nào cho hiệu quả. Tức là những yêu cầu liên quan tới việc chuyển đổi tổ chức từ trạng thái cũ, sang trạng thái mới.

Theo BABOK định nghĩa:

Transition requirements describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete.

Các bước phân tích requirement

  • Thu thập requirements: Là quá trình thu thập requirements bằng cách giao tiếp, trao đổi với khách hàng. Yêu cầu được đưa ra từ các cuộc họp trực tiếp với khách hàng, từ tài liệu, quy trình sẵn có của khách hàng. Đôi khi yêu cầu của sản phẩm xuất phát từ nhu cầu thực tế của một nhóm end user.
  • Phân tích requirements: Bước này giúp quyết định chất lượng của requirements, nó bao gồm việc chỉ ra requirements có bị không rõ ràng, không hoàn chỉnh, mơ hồ hay mâu thuẫn không. Các vấn đề đó sẽ được giải quyết trước khi đi tới bước tiếp theo.

Một yêu cầu được gọi là lý tưởng khi

  • Đầy đủ (Complete)
  • Rõ ràng (Clear)
  • Chính xác (Correct)
  • Consistent
  • Model hóa requirements: Trong bước model hóa requirements, các requirements thường được viết thành các dạng tài liệu khác nhau: Tài liệu doc hoặc được đặc tả dưới dạng các biểu đồ ví dụ như Use case, Flowchart, Sequence,  Activity, Data flow,…
  • Review: Bước này xem xét lại các quá trình thu thập requirements trước nhằm cải thiện cả quá trình.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *