Làm thế nào để làm cho một đặc tả chức năng tuyệt vời

Tôi sẽ sớm bắt đầu một dự án phụ nhỏ, nhưng lần này tôi không chỉ muốn mô hình miền UML nhỏ và sơ đồ trường hợp tôi thường làm trước khi lập trình, tôi nghĩ về việc tạo ra một đặc tả chức năng đầy đủ. Có ai có kinh nghiệm viết các đặc tả chức năng có thể giới thiệu cho tôi những gì tôi cần thêm vào nó không? Làm thế nào sẽ là cách tốt nhất để bắt đầu chuẩn bị nó? Ở đây tôi sẽ viết ra những chủ đề mà tôi nghĩ có liên quan hơn:

• Mục đích
• Tổng quan về chức năng
• Sơ đồ ngữ cảnh
• Các yếu tố thành công của dự án quan trọng
• Phạm vi (Vào & Ra)
• Giả định
• Diễn viên (Nguồn dữ liệu, Diễn viên hệ thống)
• Sử dụng sơ đồ trường hợp
• Sơ đồ quy trình
• Sơ đồ hoạt động
• Yêu cầu bảo mật
• Các yêu cầu thực hiện
• Yêu cầu đặc biệt
• Quy tắc kinh doanh
• Mô hình miền (Mô hình dữ liệu)
• Flow Scenario (Thành công, xen kẽ)
• Lịch trình thời gian (Quản lý công việc)
• Bàn thắng
• yêu cầu hệ thống
• Chi phí dự kiến

Bạn nghĩ gì về những chủ đề đó? Tôi có nên thêm cái gì khác không? hoặc có thể loại bỏ một cái gì đó?

Tôi đạp từng câu trả lời, và tôi muốn cảm ơn tất cả các bạn về thông tin hữu ích.

Tôi đang thực hiện dự án phụ này cho một công ty và họ truyền cho tôi một luồng giao tiếp liên tục và tôi sẽ cần giải thích lý do tại sao tôi làm mọi việc, bởi vì tôi sẽ phải quản lý các tài nguyên họ sẽ cung cấp cho tôi. Đây sẽ là thông số kỹ thuật đầu tiên của tôi và như tôi đã nói tôi muốn nó hữu ích, không chỉ lớn và vô dụng. Tôi nghĩ rằng đây là việc phải làm, nhưng tôi muốn làm theo cách có ích hơn cho tôi và nhóm của tôi. Thật tệ khi tôi không có người quản lý, vì vậy đó là lý do tại sao tôi cũng cần quan tâm đến một số nhiệm vụ hành chính ...

Liên quan đến lập trình nhanh, tôi nghĩ rằng điều này tương thích 100% với aproach nhanh. Tôi là một lập trình viên Agile, bản thân tôi và tôi thực sự tự tin hơn khi ai đó đã nghĩ cho tôi. Tôi vẫn còn Junnior, nhưng tôi đã từng làm việc với tư cách là nhà phát triển web Tapestry trong các dự án khác, là tổ chức là một sự hỗn loạn hoàn toàn.

Tôi không đồng ý rằng tôi đang thực hiện một thác nước, tôi nghĩ rằng tôi chỉ đang cố gắng xác định một số ranh giới sẽ giúp dự án trở nên dễ dàng hơn khi quá trình phát triển bắt đầu.

Những gì bạn đề xuất là tốt từ quan điểm của những người theo chủ nghĩa thuần túy Kỹ thuật hệ thống.

(Sẽ có một vài tín đồ Agile nghĩ rằng tất cả đều vượt qua đỉnh cao ... và bạn chỉ nên ra ngoài và làm mọi thứ với các đánh giá thông thường, v.v.).

Tuy nhiên, bạn cần phải tính đến những gì bạn đang làm, và bạn đang làm điều đó cho ai.

Làm một dự án cho chính mình khác với làm cho người khác - vì tiền.

Khi bạn làm việc cho người khác (trong công ty hoặc theo hợp đồng), phương tiện giao tiếp CHỈ là nói và viết. (Cuối cùng sẽ có một sản phẩm hoặc kết quả có thể được đánh giá.)

Toàn bộ quan điểm của một đặc điểm kỹ thuật là cố gắng và giảm chi phí thực hiện các sửa lỗi và thay đổi đến sau. Bạn có thể đã thấy các biểu đồ hiển thị chi phí thực hiện các bản sửa lỗi ở các giai đoạn khác nhau của dự án, nó sẽ diễn ra như sau:

• Một bản sửa lỗi được thực hiện cho một ý tưởng ngu ngốc có giá $ 1

• Một bản sửa lỗi được thực hiện khi ý tưởng ngu ngốc biến nó thành một đặc tả (phải được cập nhật) có giá $ 10

• Một bản sửa lỗi được thực hiện khi bạn đã xây dựng một nguyên mẫu có giá 100 đô la

• Một bản sửa lỗi được thực hiện về thời gian bạn đang chấp nhận trước khi chi phí vận chuyển $ 1000

• Một sửa chữa được thực hiện sau khi bạn đã vận chuyển và chọc giận khách hàng của bạn có giá 10000 đô la.

Vì vậy, những gì bạn viết trong một đặc điểm kỹ thuật là khá quan trọng.

Để tranh luận rằng bạn không nên có đặc điểm kỹ thuật nào là ngây thơ, dại dột và có lẽ nguy hiểm.

Một trong những vấn đề lớn nhất bạn gặp phải khi viết một đặc tả là biết khi nào bạn đã đi quá xa. Điều này thay đổi tùy thuộc vào quy mô của dự án. Ví dụ, một dự án mất 1-2 người khoảng một năm nên có tổng số khoảng 2 đến 4 TUẦN dành cho đặc tả ... bao gồm cả việc điều tra tính khả thi ... thông số được viết bởi những người thực sự làm công việc không phải là một loại phân tích falutin cao, những người không biết các chi tiết chính. Một dự án mất 10 người 2 năm cần nhiều thời gian hơn.

Bây giờ cho một số ý kiến ​​về các điểm khác nhau của bạn:

• Mục đích

CÓ, viết cái này. Giữ nó đến 1-2 đoạn văn, tối đa 1/2 trang.

• Tổng quan về chức năng

CÓ LẼ. Chỉ khi nó thêm giá trị cho mọi thứ khác.

• Sơ đồ ngữ cảnh

THIẾT YẾU. Hiển thị TẤT CẢ đầu vào và đầu ra. Hiển thị bối cảnh. Bạn có thể (và nên) dành một khoảng thời gian hợp lý cho việc này.

• Các yếu tố thành công của dự án quan trọng

CÓ LẼ. Chắc chắn nếu dự án đáp ứng yêu cầu thì thành công. Tôi nghĩ rằng điều này là không thực sự cần thiết.

• Phạm vi (Vào & Ra)

KHÔNG. Sơ đồ ngữ cảnh của bạn làm điều này.

• Giả định

ĐÚNG. Hãy thử và giữ cho nó ngắn gọn.

• Diễn viên (Nguồn dữ liệu, Diễn viên hệ thống)

CÓ LẼ. Điều này nghe có vẻ giống như các bit kỹ thuật của thiết kế đối với tôi không phải là một đặc điểm kỹ thuật FUNCTIONAL.

• Sử dụng sơ đồ trường hợp

CÓ LẼ. Đặt cái này (cái này) trong một phụ lục. Giải thích bằng lời nói. Cố gắng giữ những thứ này đến một số nhỏ. Tôi đã thấy các đề xuất rằng một dự án nên có không quá 8 Ca sử dụng được giải thích chi tiết. Đừng bao gồm tất cả các con đường "unahppy" hoặc bạn sẽ không bao giờ hoàn thành.

Rất hiếm khi bất kỳ phần nào của s / w có một Sơ đồ ca sử dụng / Ca sử dụng duy nhất.

• Sơ đồ quy trình

CÓ LẼ. Chỉ khi nó thêm giá trị quan trọng, nếu không bạn đang lãng phí thời gian của bạn.

• Sơ đồ hoạt động

CÓ LẼ. Chỉ khi nó thêm giá trị quan trọng, nếu không bạn đang lãng phí thời gian của bạn.

• Yêu cầu bảo mật

CÓ - nếu có liên quan.

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

CÓ - bắt buộc. Phải nói những gì phải làm (và với mức độ hiệu suất).

• Yêu cầu đặc biệt

MAYBE - nếu có gì đặc biệt.

• Quy tắc kinh doanh

MAYBE - nếu hữu ích.

• Mô hình miền (Mô hình dữ liệu)

MAYBE - nếu hữu ích.

• Flow Scenario (Thành công, xen kẽ)

MAYBE - nếu hữu ích.

• Lịch trình thời gian (Quản lý công việc)

KHÔNG. Đây không phải là những gì nên có trong một spec. Đó là về lịch trình, kế hoạch, vv

• Bàn thắng

CÓ LẼ. Mục tiêu không phải là yêu cầu, chúng là những thứ lông tơ mơ hồ sẽ không đẹp, phục vụ cho việc làm vũng nước. Hãy cố gắng và tránh.

• yêu cầu hệ thống

ĐÚNG. Thiết yếu. Nói những gì phải làm.

• Chi phí dự kiến

KHÔNG. Một phần của kế hoạch và quản lý, không phải là yêu cầu của điều bạn đang làm.

Giải thích: Tôi đã viết thông số kỹ thuật cho các sản phẩm, phần mềm và hệ thống phức tạp trong hơn 15 năm. Tất cả các công cụ thương mại. Chủ yếu là thành công về mặt thương mại và kiếm được nhiều tiền cho các nhà tuyển dụng khác nhau. Bao gồm đặc tả cho phát triển Agile s / w trong đó bạn vẫn cần một thông số kỹ thuật trước khi bạn nhảy vào phát triển. Sự phát triển THỰC TẾ có thể được thực hiện trong bất kỳ quy trình nào bạn muốn, nhưng cuối cùng, bạn phải có 3 điều để thành công:

1. Biết những gì bạn muốn làm. VÀ VIẾT NÓ XUỐNG. (Đó là một thông số.)

2. Làm công cụ để đáp ứng # 1 ở trên.

3. Thực hiện một số mức độ kiểm tra chấp nhận đối với thông số kỹ thuật (về cơ bản là "bạn đã làm những gì bạn nói bạn sẽ làm").

Có ba điều cần lưu ý

1) Bạn phải bắt đầu ở đâu đó

Bạn đã xác định vấn đề mà dự án này đang cố gắng giải quyết là gì chưa? Bạn cũng có thể bắt đầu bằng cách nói "Đây là những điều mà dự án này sẽ không hoàn thành nếu không thể làm được." Tôi cũng đã thấy một số dự án (một số thành công, một số khác không nhiều) thiết kế màn hình chính và điền vào chỗ trống từ đó.

2) Bạn phải kết thúc ở đâu đó

Bạn có thể chỉ ra những điều quái quỷ, nhưng nếu bạn không bao giờ thực sự làm bất cứ điều gì bạn đã làm thì lãng phí rất nhiều thời gian và giấy tờ và bỏ qua vợ con trong bảy tuần. (Đã có ai làm điều đó chưa, có ai không?) Vì vậy, hãy đảm bảo đặt ra một số giới hạn về việc thông số kỹ thuật của bạn sẽ đi được bao xa. Đây có phải là một thông số kỹ thuật cũng như một thông số chức năng?

3) Bạn phải đi từ đầu đến cuối

Đừng bắt đầu bằng cách nhận một yêu cầu chính và sau đó điền vào mọi chi tiết về nó trước khi nhận được yêu cầu chính thứ hai ít nhất là trong đề cương. Xây dựng thông số kỹ thuật của bạn theo chiều ngang trước, sau đó theo chiều dọc. Mặt khác, khi bạn nhận ra một số chi tiết nhỏ của yêu cầu, làm cho tất cả các yêu cầu trở thành không thể, bạn sẽ gặp một số vấn đề lớn.

Tôi sẽ chia danh sách của bạn thành ba phần: những thứ người dùng quan tâm, những thứ lập trình viên quan tâm và những thứ mà người quản lý quan tâm. Hãy để một lập trình viên làm phần của họ và một người quản lý làm phần của họ. Lập trình viên có thể sẽ cần cung cấp các ước tính cho các phần của dự án cho người quản lý và người quản lý để cung cấp các ràng buộc ngân sách cho lập trình viên (tức là không thể mất hơn X tuần). Nếu mọi người (khách hàng, người quản lý, lập trình viên) đồng ý, thì đó là đèn xanh và bắt đầu dự án. Đối với các lập trình viên, nhiều người thông số kỹ thuật poo-poo, đôi khi đúng như vậy. Tôi sẽ chỉ xác định các phần mà hai hoặc nhiều bên đang liên lạc (ví dụ: máy khách-máy chủ). Đối với phần còn lại, chỉ cần thực hành một số hình thức TDD dựa trên câu chuyện của người dùng. Một dòng cho khách hàng cũng có lợi để có được câu chuyện.

Câu chuyện của người dùng

• Mục đích Tổng quan về chức năng
• Diễn viên (Nguồn dữ liệu, Diễn viên hệ thống)
• Sử dụng sơ đồ trường hợp
• Sơ đồ quy trình
• Sơ đồ hoạt động
• Sơ đồ ngữ cảnh
• Quy tắc kinh doanh
• Yêu cầu đặc biệt
• Các yêu cầu thực hiện

Giám đốc

• Các yếu tố thành công của dự án quan trọng
• Chi phí dự kiến
• Flow Scenario (Thành công, xen kẽ)
• Lịch trình thời gian (Quản lý công việc)

Lập trình viên

• Yêu cầu bảo mật
• Mô hình miền (Mô hình dữ liệu)
• yêu cầu hệ thống

Ngoài ra, có lẽ không có một công thức hoàn hảo cho tất cả các loại vấn đề phần mềm. Đối với một ứng dụng Facebook, có lẽ bạn muốn demo sớm và thường xuyên. Đối với một hệ thống dẫn đường tên lửa, có lẽ không nhiều ;-)

Chuẩn bị tất cả các tài liệu này có thể mất vài tháng! Trông giống như một loại thác nước tiếp cận với tôi.

Tôi không thể đề nghị thêm bất cứ điều gì thêm vào danh sách của bạn trừ khi bạn lấy ra một vài từ nó. Tôi đoán các đồ tạo tác được sản xuất sẽ phụ thuộc vào văn hóa trong tổ chức của bạn và bộ kỹ năng của các nhà phát triển.

Không có đặc điểm kỹ thuật chức năng tốt hơn mà một nguyên mẫu hoạt động nhưng chạy trốn, chính xác là do các vấn đề với cách tiếp cận thác nước.