Viết một đặc tả yêu cầu phần mềm

Tôi có một vài câu hỏi về việc viết một đặc tả và chúng là:

1. Khi chúng ta viết một đặc tả phần mềm, trong chủ đề "Định nghĩa yêu cầu của người dùng", chúng ta chỉ phải chỉ định "Hàm" và "Ràng buộc"?

2. "Giao diện người dùng" có rơi vào "chức năng" hay "ràng buộc" không?

3. Các lĩnh vực chính (yêu cầu) mà một phần mềm có thể được chia thành (ví dụ: UI) là gì?

Trong khi tôi không phải là một fan hâm mộ lớn của việc thu thập tất cả yêu cầu một cách chi tiết (vì chúng có thể thay đổi rất nhiều trong quá trình của một dự án không tầm thường), nếu bạn đang viết tài liệu yêu cầu, mẫu đặc tả yêu cầu của Volere là một hướng dẫn tuyệt vời .

Mặc dù có thể quá mức cần thiết cho một số dự án, nhưng nó cung cấp một danh sách kiểm tra tuyệt vời về những điều cần suy nghĩ, ngay cả khi chỉ cần kiểm tra tinh thần danh sách mà bạn không cần mục đó cho yêu cầu này.

Đây là một liên kết để biết thêm thông tin về mẫu:

http://www.volere.co.uk/template.htmlm

Bản thân mẫu (và cuốn sách Làm chủ quy trình yêu cầu - thực sự rẻ hơn một chút so với mẫu và chứa văn bản mẫu đầy đủ) chứa nhiều thông tin, ví dụ và lời khuyên trong các phần khác nhau về những gì sẽ có trong mỗi phần.

Dưới đây là tóm tắt về các phần trong đó (trích dẫn từ liên kết trên):

1. Mục đích của dự án

2. Các bên liên quan

3. Những ràng buộc bắt buộc

4. Quy ước đặt tên và định nghĩa

5. Các sự kiện và giả định có liên quan

6. Phạm vi công việc

7. Mô hình dữ liệu kinh doanh và từ điển dữ liệu

8. Phạm vi của sản phẩm

9. Yêu cầu về chức năng và dữ liệu

10. Yêu cầu Nhìn và Cảm nhận

11. Yêu cầu về tính khả dụng và tính nhân văn

12. Các yêu cầu thực hiện

13. Yêu cầu hoạt động và môi trường

14. Yêu cầu bảo trì và hỗ trợ

15. Yêu cầu bảo mật

16. Yêu cầu về văn hóa và chính trị

17. Yêu cầu pháp lý

18. Vấn đề mở

19. Giải pháp giảm giá

20. Vấn đề mới

21. Nhiệm vụ

22. Di chuyển sang sản phẩm mới

23. Rủi ro

24. Chi phí

25. Tài liệu và đào tạo người dùng

26. Phòng chờ

27. Ý tưởng cho giải pháp

Tôi khuyên bạn nên đọc Joel trên phần mềm. Tôi không chắc liệu nó có trả lời các câu hỏi cụ thể của bạn không, nhưng anh ấy có một cái nhìn tổng quan tuyệt vời về ý nghĩa của việc viết các đặc tả chức năng :

Chức năng quan trọng nhất của thông số kỹ thuật là thiết kế chương trình . Ngay cả khi bạn tự mình làm việc về mã và bạn viết một thông số chỉ vì lợi ích của riêng bạn, hành động viết thông số đó - mô tả cách chương trình hoạt động chi tiết trong vài phút - sẽ buộc bạn phải thiết kế thực sự chương trình ...

... Khi bạn thiết kế sản phẩm của mình bằng ngôn ngữ của con người, chỉ mất vài phút để thử suy nghĩ về một số khả năng, sửa đổi và cải thiện thiết kế của bạn. Không ai cảm thấy tồi tệ khi họ xóa một đoạn trong trình xử lý văn bản. Nhưng khi bạn thiết kế sản phẩm của mình bằng ngôn ngữ lập trình, phải mất hàng tuần để thực hiện các thiết kế lặp. Tệ hơn nữa, một lập trình viên chỉ mất 2 tuần để viết một số mã sẽ khá gắn bó với mã đó, bất kể nó sai đến đâu ...

... Khi bạn viết một thông số, bạn chỉ phải truyền đạt cách chương trình được cho là hoạt động một lần . Mọi người trong nhóm chỉ có thể đọc thông số kỹ thuật. Người QA đọc nó để họ biết chương trình này hoạt động như thế nào và họ biết phải kiểm tra cái gì. Những người tiếp thị sử dụng nó để viết những tờ giấy trắng hơi nước mơ hồ của họ để tung lên trang web về những sản phẩm chưa được tạo ra. Những người phát triển kinh doanh đã đọc sai nó để quay những tưởng tượng kỳ lạ về cách sản phẩm sẽ chữa trị chứng hói đầu và mụn cóc và các thứ, nhưng nó được các nhà đầu tư, vì vậy điều đó ổn. Các nhà phát triển đọc nó để họ biết nên viết mã nào. Các khách hàng đọc nó để đảm bảo các nhà phát triển đang xây dựng một sản phẩm mà họ muốn trả tiền. Các nhà văn kỹ thuật đọc nó và viết một hướng dẫn tốt đẹp ...

Khi bạn không có thông số kỹ thuật, tất cả các giao tiếp này vẫn xảy ra, bởi vì nó phải , nhưng nó xảy ra đặc biệt . Những người QA lúng túng với chương trình willy-nilly, và khi có gì đó kỳ lạ, họ lại đi và làm gián đoạn các lập trình viên một lần nữa để hỏi họ một câu hỏi ngu ngốc khác về cách thức hoạt động của nó ...

không có thông số kỹ thuật chi tiết, không thể lập lịch trình ... Trong quá nhiều tổ chức lập trình, mỗi khi có một cuộc tranh luận về thiết kế, không ai từng đưa ra quyết định, thường là vì lý do chính trị. Vì vậy, các lập trình viên chỉ làm việc trên các công cụ không gây tranh cãi. Khi thời gian trôi qua, tất cả các quyết định khó khăn được đẩy đến cuối cùng ... Viết một thông số kỹ thuật là một cách tuyệt vời để khắc phục tất cả các quyết định thiết kế khó chịu, lớn và nhỏ, được che đậy nếu bạn không có thông số kỹ thuật. ..

Khi chúng ta viết một đặc tả phần mềm, trong chủ đề "Định nghĩa yêu cầu của người dùng", chúng ta chỉ phải chỉ định "Hàm" và "Ràng buộc"?

Yêu cầu là sự kết hợp của hai thứ ...

1. Những gì nó làm. Yêu cầu về chức năng.
2. Làm thế nào tốt nó làm điều đó. Yêu cầu phi chức năng hoặc "Ràng buộc"

"Giao diện người dùng" có rơi vào "chức năng" hay "ràng buộc" không?

Tôi sẽ nói "Giao diện người dùng" sẽ là loại yêu cầu như bạn đã xác định trong câu hỏi cuối cùng của mình.

Các lĩnh vực chính (yêu cầu) mà một phần mềm có thể được chia thành (ví dụ: UI) là gì?

Nó phụ thuộc vào phần mềm. Bạn có thể nhóm các yêu cầu dựa trên các bộ phận của hệ thống hoặc bạn có thể nhóm chúng dựa trên trường hợp sử dụng hoặc yêu cầu nghiệp vụ mà các chức năng đang đáp ứng.

Tất nhiên tất cả những điều này chỉ là thứ yếu so với mục tiêu thực tế của bạn, đó là xác định một mô tả rõ ràng, rõ ràng và có thể kiểm tra được của hệ thống phần mềm.

Yêu cầu chính cho một yêu cầu là nó có thể kiểm tra được. Nếu bạn không thể tìm ra cách kiểm tra một yêu cầu, tỷ lệ cược là nó sẽ không được thực hiện theo cách người viết dự định.

Tôi chưa bao giờ thấy tài liệu yêu cầu chỉ giới hạn ở Hàm và ràng buộc, nhưng tôi có thể thấy một số giá trị khi có cấu trúc như thế này - nó buộc người viết phải phân loại các yêu cầu thành "những điều phần mềm cần làm" và "quy tắc phần mềm cần phải tuân theo. "

Tôi nghĩ rằng một giao diện người dùng có yêu cầu trong cả hai loại

Các ràng buộc:

• "màn hình khởi động sẽ hiển thị hai nút:" Bắt đầu "và" Dừng "
• "Phông chữ hiển thị không được nhỏ hơn 10 điểm."

Chức năng:

• "Khi Startnhấn phím, phần mềm sẽ thiết lập kết nối TCP / IP tới WOPR "