01/10/2018, 22:29

[School] Kim tự tháp yêu cầu trong Phân tích quản lý yêu cầu phần mềm

[School] Kim tự tháp yêu cầu trong Phân tích quản lý yêu cầu phần mềm Tháng Mười Hai 2, 2014 nguyenvanquan7826 Z- Thể loại khác Leave a response Kim tự tháp yêu cầu Phục thuộc vào hình thức, nguồn gốc và đặc tính , các yêu cầu ...

[School] Kim tự tháp yêu cầu trong Phân tích quản lý yêu cầu phần mềm

Kim tự tháp yêu cầu

Phục thuộc vào hình thức, nguồn gốc và đặc tính, các yêu cầu được phân loại làm 6 mức như sau:

  1. Stakholder need: Yêu cầu được đề xuất bởi Stakholder
  2. Feadture (Tính năng): Một dịch vụ được cung cấp bởi hệ thống để phục vụ yêu cầu cảu Stakholder
  3. Use Case: Mô mô tả về hành vi của hệ thống.
  4. Supplementary requirement: Các yêu cầu bổ xung, thường là các yêu cầu phi chức năng.
  5. Scenario (Kịch bản): Một chuỗi hành động cụ thể, một đường hành động đi qua một Use Case.
  6. Test Case: Đặc tả về một đầu vào kiểm thử, các điều kiện thực thi và kết quả mong đợi
kimtuthapyeucauKim tự tháp yêu cầu

Chúng ta cần quản lý các yêu cầu theo từng tầng vì các yêu cầu trên đựoc biểu diễn theo hình kim tự tháp, các yêu cầu của Stakholder ở trên thường tổng quát, các yêu cầu ở dưới được phát sinh, phân rã ra dựa vào các yêu cầu tầng trên.

Ở các mức yêu cầu khác nhau thì mức độ chi tiết của chúng cũng khác nhau, yêu cầu tầng dưới thường chi tiết hơn tầng trên.

Việc lưu trữ dấu vết các yêu cầu tạo thuận lợi cho quản lý

Dấu vết là một kỹ thuật giúp lưu giữ các mối quan hệ giữa các yêu cầu, các yêu cầu thường ánh xạ từ trên xuống dưới nên dựa vào dấu viết chúng ta có thể làm được nhiều điều:

  • Biết đuợc nguồn gốc của từng yêu cầu
  • Thẩm tra được hệ thống thỏa mãn đầy đủ mọi yêu cầu của Stakholder
  • Thẩm tra được hệ thống chỉ cài những gì cần thiết
  • Phân tích được mức độ ảnh hưởng khi một yêu cầu thay đổi, bổ xung
  • Giảm thiểu tối đa lỗi được tìm thấy trong chu kỳ phát triển hệ thống
0