Làm thế nào để dán nhãn yêu cầu phần mềm?


8

Một chiến lược tốt để dán nhãn các yêu cầu phần mềm trong SRS là gì?

Thông thường đánh số phác thảo được sử dụng trên các tiêu đề - nhưng chúng sẽ đánh số lại nếu một tiêu đề mới được chèn vào tài liệu. Đối với tôi có vẻ như là một ý tưởng tốt để nhắm đến một chỉ định ổn định hơn cho từng yêu cầu phần mềm. Điều này sẽ giúp dễ dàng tham chiếu một yêu cầu cụ thể ngay cả khi đối mặt với SRS được cập nhật.

Kinh nghiệm của bạn về điều này là gì?


1
Tại sao downvote? Quản lý yêu cầu có thể không tầm thường. Thực hành phát triển phần mềm tốt thúc đẩy phần mềm tốt.
throwback1986 18/03/13

Câu trả lời:


7

Một chiến lược:

  1. Hãy coi ID SRS chỉ là một số và không ngụ ý bất kỳ khái niệm mạnh mẽ nào về thứ tự liên tiếp (Số an sinh xã hội là một ví dụ hợp lý.)
  2. Đừng tái chế số lượng. Khi một ID trong chuỗi bị xóa, đánh dấu nó là "Đã xóa", "Không dùng nữa", v.v. Tôi thích giữ văn bản yêu cầu trong mục bị xóa để tôi có bản ghi tiến trình yêu cầu. Nếu bạn chọn thực hiện việc này, hãy đánh dấu văn bản đã xóa rõ ràng, ví dụ: phông chữ xuất hiện.
  3. # 2 ngụ ý rằng bổ sung yêu cầu mới sẽ không bao giờ xảy ra "tại chỗ"; thay vào đó, chúng luôn được gắn vào tài liệu.
  4. Chiến lược này có thể trở nên khó tổ chức hoặc phân cụm theo cấp bậc khi các thay đổi được tích lũy, vì vậy hãy gắn thẻ cho mỗi ID SRS với nhãn có ý nghĩa để tìm kiếm, ví dụ [GUI], [DB], v.v.

Có các chiến lược khác, chẳng hạn như sử dụng số thập phân rải rác cho các yêu cầu cụm, ví dụ:

  • GUI 1.0
  • 2.0 DB
  • Xử lý 3.0

Như bạn có thể đoán, các yêu cầu tương ứng phải được sắp xếp theo số cấp cao nhất tương ứng: 1.1, 1.2 ... cho GUI, 2.1, 2.3, 2.4 cho DB, v.v. Lưu ý rằng chiến lược này sẽ cần một số phương thức được kiểm soát cho quản lý xóa và bổ sung.

Điều quan trọng để thực thi trong một tài liệu yêu cầu: một khi ID đã được sử dụng cho một yêu cầu, nó không thể được sử dụng lại yêu cầu khác. Nói cách khác, nếu SRS 1234 được sử dụng và sau đó bị xóa, nó không thể xuất hiện lại sau đó. (Cho phép nó làm như vậy sẽ tàn phá tuyệt đối các yêu cầu truy xuất nguồn gốc trong quá trình của một dự án đang phát triển.)

Lưu ý rằng hầu như bất kỳ tổ chức / cấu trúc SRS nào cũng sẽ có thiếu sót. Chọn một cái phù hợp với môi trường phát triển và nhu cầu ứng dụng của bạn. (Ví dụ: các chiến lược trên hoạt động hợp lý tốt trong môi trường phát triển được kiểm soát cao, chẳng hạn như các chiến lược được giám sát bởi FDA hoặc các cơ quan chính phủ khác.)

Cuối cùng, xem xét sử dụng một công cụ quản lý yêu cầu. Có những cái tốt ngoài kia (mã nguồn mở cho UAH) sẽ lo tất cả những thứ này cho bạn.


Các yêu cầu được tổ chức thông qua khu vực ngăn xếp công nghệ (GUI, DB, Xử lý) không yêu cầu, chúng là các nhiệm vụ. Nếu bất cứ điều gì, các yêu cầu kỹ thuật nên được giới hạn trong một khu vực thảo luận về các hạn chế kỹ thuật, ví dụ: Phải chạy trên Windows 7 trở lên. Phân định các yêu cầu thông qua ngăn xếp công nghệ là một mùi hôi.
Michael Brown

Mục đích là để cung cấp một ví dụ về tổ chức các yêu cầu logic cấp cao (ví dụ: giao diện người dùng so với lưu trữ, v.v.). Không có "ngăn xếp" công nghệ hoặc các ràng buộc được nêu hoặc ngụ ý trong bài.
throwback1986 18/03/13

1

Tư duy khái niệm tốt nhất là Yêu cầu là các mục riêng biệt, liên quan đến nhau theo nhiều cách khác nhau và do đó nên được lưu trữ trong Cơ sở dữ liệu. Sử dụng một trình xử lý văn bản để lưu trữ các yêu cầu là sai cách và dẫn đến nhiều vấn đề vì nó thúc đẩy suy nghĩ khái niệm rằng "các yêu cầu là một tài liệu" - do đó câu hỏi này. Nếu bạn phải sử dụng trình xử lý văn bản, hãy tách riêng từng yêu cầu, giống như khi bạn sử dụng Word để lưu trữ danh bạ.

Do đó, sử dụng đánh số Outline để duy trì các yêu cầu sẽ gây ra vấn đề. Hãy tưởng tượng bạn đang cố gắng kiểm tra chéo tham khảo và SRS và yêu cầu của khách hàng nếu bạn thay đổi số? Hãy tưởng tượng thảo luận về "Yêu cầu 10.2.3.1" chỉ để thấy rằng trong tài liệu hôm nay bạn đã gửi cho khách hàng đó là "10.2.2.1"

Yêu cầu là một nhãn hiệu, và nên truyền đạt ít ý nghĩa. Bạn có thể có một hoặc một vài tiền tố ngắn 2 đến 5 chữ cái để xác định phạm vi hoặc đơn vị, nhưng tại thời điểm bạn có vài nghìn, bất kỳ ý nghĩa ngụ ý nào cũng nên được giới hạn. ví dụ trong xe hơi, bạn có thể có EM-FUEL-1234 (Quản lý động cơ, Hệ thống kiểm soát nhiên liệu, yêu cầu 1234).

Yêu cầu phải có thể được sử dụng lại trên các dự án.

Yêu cầu phải là duy nhất, trong phạm vi và vòng đời của dự án. Theo hướng dẫn, thay đổi một yêu cầu để làm rõ là cùng một số, nhưng để khắc phục nó một cách đáng kể, hãy xóa cái cũ và thay thế nó. Sử dụng sơ đồ phiên bản (Nối thêm_1, _2, v.v.) có thể hữu ích.

Nếu bạn phải sử dụng Word để lưu trữ cơ sở dữ liệu này, một cách tốt là sử dụng mã thông báo bắt đầu và kết thúc để xác định các yêu cầu. Nếu bạn sử dụng Kiểu phông chữ duy nhất để đánh số yêu cầu, việc đánh dấu và tìm kiếm chúng bằng cách sử dụng Macros trở nên dễ dàng (có thể vào cơ sở dữ liệu). Ví dụ có thể là

#Req 1234 #

Bla bla bla bla

# Yêu cầu #

#Req 1234a #

Bla bla bla bla và nhiều hơn nữa

# Yêu cầu #

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.