Cách thích hợp để tạo tài liệu yêu cầu là gì?

Ngay bây giờ người giám sát của tôi đang tạo tài liệu yêu cầu / thông số kỹ thuật cho tôi bằng phần mềm sửa lỗi. Đây có vẻ là một ý tưởng tồi tệ đối với tôi, tất cả các yêu cầu đều nằm trên những chiếc vé nhỏ này và tôi phải nhấp xung quanh biểu mẫu web ngu ngốc này để có được yêu cầu. Một giải pháp phần mềm lành mạnh cho các yêu cầu / thông số kỹ thuật phần mềm là gì?

Để rõ ràng, tôi đang xây dựng thành phần phần mềm lớn này với khá nhiều tính năng và các tính năng này đang được đặt ra trong phần mềm sửa lỗi này.

Tôi khá ngạc nhiên khi cho đến nay chưa có ai khuyến nghị sử dụng wiki để theo dõi các yêu cầu.

Tôi đã tìm thấy nó là một hệ thống gần như hoàn hảo, bởi vì:

• Nó cho phép mọi người cộng tác theo các yêu cầu và làm cho khía cạnh này trở nên rõ ràng;
• Nó cho phép bạn dễ dàng cập nhật các yêu cầu khi dự án tiến triển;
• Bạn có thể vào và xem lịch sử bất cứ lúc nào, trong trường hợp có tranh chấp "đó không phải là điều chúng tôi đã đồng ý";
• Hầu hết các wiki hiện đại đều có khả năng định dạng khá, vì vậy nó trông gần giống như một tài liệu Word;
• Bạn có thể siêu liên kết trực tiếp từ yêu cầu của bạn vào tài liệu thực tế;
• Bạn không bao giờ phải lo lắng về những người làm việc với các bản sao khác nhau / lỗi thời;
• Các yêu cầu có thể bắt đầu được coi là một quá trình lặp lại, giống như thiết kế / thực hiện;
• Nếu các yêu cầu bắt đầu trở nên thực sự lớn / phức tạp, thật dễ dàng để phân chia chúng thành các trang / chủ đề.
• Hầu hết các wiki chấp nhận HTML, vì vậy nếu bạn thực sự cần định dạng nâng cao, có lẽ bạn có thể sử dụng một công cụ như Windows Live Writer .

Có sự lựa chọn, tôi hầu như luôn chọn phương pháp wiki ngày nay, nó thực sự khá đau đớn so với các tài liệu Word lỗi thời hoặc cố gắng nhồi nhét tất cả vào một trình theo dõi lỗi.

Tôi luôn sử dụng IEEE Std 830-1998 (Thực hành theo khuyến nghị của IEEE về Đặc tả yêu cầu phần mềm) làm mẫu cho tài liệu SRS của tôi. Xem http://stiterias.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

Bản thân tài liệu SRS cuối cùng thường là một tài liệu OpenOffice.org, nhưng thường có nhiều phần cấu thành đi vào nó, bao gồm bảng tính và sơ đồ.

Tôi thường đặt tất cả các tài liệu này cùng nhau trong một kho lưu trữ mà tôi đặt vào một hệ thống kiểm soát sửa đổi , như SVN hoặc CVS. Tất cả các nhà phân tích kinh doanh, nhà thiết kế, nhà phát triển, người thử nghiệm, người quản lý dự án và khách hàng khác đều có quyền truy cập vào kho lưu trữ này, vì vậy họ có thể đọc nó và chỉnh sửa.

Hãy nhớ rằng, SRS là một tài liệu sống, phát triển. Nó sẽ tiếp tục thay đổi và phát triển trong một thời gian. Điều quan trọng không chỉ đối với tất cả các bên liên quan là có quyền truy cập vào SRS, mà điều quan trọng nữa là phải có lịch sử đầy đủ về các thay đổi và khả năng khôi phục các thay đổi này nếu cần thiết. Vì vậy, một hệ thống kiểm soát sửa đổi hoạt động tuyệt vời cho mục đích này. Chúc may mắn!

Sử dụng trình theo dõi lỗi để quản lý yêu cầu có xu hướng che giấu sự thiếu hợp tác và giao tiếp trong công ty.

Không thông qua phán xét về bất kỳ phương pháp cụ thể:

• nếu bạn định sử dụng thác nước, bạn cần các tài liệu nhiều trang có cấu trúc tốt, chính xác (không phải là một đoạn mà nhiều người thường gõ như một mô tả lỗi). Những tài liệu này cũng không thể viết và duy trì ở mức chất lượng tốt nếu nhân viên tiếp thị / bán hàng (người có nguồn gốc yêu cầu) không làm việc tốt với nhân viên kỹ thuật.
• nếu bạn sẽ sử dụng một trong các phương thức nhanh, thì một đơn vị yêu cầu là câu chuyện người dùng, được thể hiện bằng thẻ câu chuyện. Bản thân thẻ không phải là một yêu cầu, chỉ là điểm bắt đầu của cuộc trò chuyện.

Một kinh nghiệm (ngắn gọn) của một trong những người sử dụng lao động trước đây của tôi khi sử dụng trình theo dõi lỗi cho các yêu cầu là nó mang lại cho nhiều người một cách rất dễ dàng để ngừng giao tiếp hoàn toàn. Mọi người chỉ đơn giản là viết một điều ước, bỏ nó vào trình theo dõi lỗi và cho rằng điều đó cuối cùng sẽ trở thành sự thật.

Tất nhiên họ đã làm như vậy mà không quan tâm đến:

• trình độ chuyên môn của họ
• cổ phần của họ trong dự án
• xung đột với các yêu cầu khác
• khoảng trống trong yêu cầu
• chi phí
• bất kỳ cân nhắc kỹ thuật
• v.v.

Tôi tin rằng các tài liệu "Word" là cách sai để đi theo yêu cầu, vì những lý do sau:

1. Không có cách nào để "khác biệt" hai tài liệu để xem những gì đã thay đổi.
2. Giao diện người dùng không khuyến khích sử dụng một kiểu nhất quán xuyên suốt. Có, sử dụng các kiểu có thể được thực hiện, nhưng hầu hết mọi người không thể bị làm phiền vì khó khăn.
3. Định dạng tài liệu về cơ bản là ẩn. Chắc chắn, có một thông số kỹ thuật cho các tệp OLE, mà tôi đoán là các tài liệu "Word", nhưng Microsoft đã chôn giấu mọi thứ hữu ích dưới hàng tấn blather, vì vậy không ai thực sự biết. Sớm hay muộn, "Word" mới, sáng bóng của bạn sẽ không mở tài liệu.
4. Không chơi tốt với các định dạng khác. Đó là, trừ khi bạn sử dụng Windows và IE, bạn sẽ không gặp may nếu ai đó tổ chức các tài liệu của dự án trong các tệp HTML có liên kết đến các tệp định dạng "Word". Nhấp vào liên kết sai và bạn phải trải qua giai đoạn tải xuống và bắt đầu từ dài, làm gián đoạn dòng suy nghĩ. Các siêu liên kết từ tài liệu "Word" đến người khác có thể hoặc không thể hoạt động.
5. "Word" về cơ bản là để viết các tài liệu dự định xuất hiện trên giấy. Một mục tiêu đáng ngưỡng mộ, nhưng một mục tiêu làm cho nó ít hữu ích hơn khi xem trực tuyến.

Tôi không có đề xuất thay thế nào mà tôi có kinh nghiệm, nhưng tôi đã nghĩ về Văn bản tái cấu trúc hoặc Đánh dấu của Python là các lựa chọn thay thế.

Chúng tôi thường sử dụng Word, nhưng trong thực tế, cách bạn tạo chúng trong phần mềm ít quan trọng hơn cách bạn thu thập dữ liệu để tạo chúng và liệu người thu thập thông tin có đủ biết khi nào yêu cầu quá phức tạp và sẽ tốn kém hơn nhiều so với một yêu cầu đơn giản hơn nhưng không thêm giá trị thực cho bất kỳ ai (chẳng hạn như khi họ muốn số ID luôn được gán theo thứ tự mà không bao giờ bỏ qua) hoặc khi nó sẽ xung đột với yêu cầu hiện có hoặc tính năng được lên kế hoạch khác. Thông thường người dùng thực tế không bao giờ được nói chuyện và có nhiều điều ngạc nhiên khi người quản lý của họ không biết điều gì đó hoàn toàn phải được thực hiện và đó không phải là phiên bản mới của phần mềm.

Chúng tôi cũng có thể sử dụng các tệp pdf, Excel hoặc Visio khác nhau. Tất cả chúng cho dự án được thu thập và chỉnh sửa từ SharePoint, vì vậy chúng tôi có thể xem các phiên bản trước nếu cần.

Tôi duy trì một sản phẩm tồn đọng (một cho mỗi dự án hoặc sản phẩm) có chứa Câu chuyện của người dùng . Chúng có thể được lưu trữ trong phần mềm theo dõi lỗi như phần mềm bạn sử dụng. Tôi cá nhân sử dụng Excel cho backlog và Trac cho backlog chạy nước rút (bạn có thể sử dụng một công cụ như công cụ đó).

Khi chỉ được yêu cầu, tôi tạo một tài liệu Word mô tả Câu chuyện người dùng với nhiều chi tiết hơn và đính kèm nó vào câu chuyện của người dùng. Nhưng tôi cố gắng tránh điều này bằng cách chia câu chuyện của người dùng thành những câu chuyện nhỏ hơn.

Câu chuyện người dùng nhỏ dễ quản lý hơn (bao gồm cả ước tính)

Tôi thích tài liệu Word vì nó cho phép tôi đặt liên kết, định dạng văn bản, đặt bảng, ảnh chụp màn hình và hơn thế nữa và mọi người đều có thể đọc nó.

Tất nhiên, mỗi Câu chuyện người dùng được giải thích chi tiết trong phiên ước tính và lập kế hoạch chạy nước rút và tôi luôn sẵn sàng cho nhiều câu hỏi hơn khi nhà phát triển quyết định làm việc với nó. Phản hồi thường xuyên sử dụng đánh giá nước rút ngăn cản các nhà phát triển làm điều gì đó khác với yêu cầu của chủ sở hữu sản phẩm.

Cá nhân tôi, trước đây tôi đã sử dụng Tài liệu Word, nhưng đã quyết tâm tìm một công cụ trong tương lai để quản lý việc này cho tôi ... đặc biệt là với khả năng đặt lỗi theo yêu cầu, vì rất nhiều lần, lỗi là trong các yêu cầu, không phải là độ lệch giữa thông số kỹ thuật và việc thực hiện.

Tôi thậm chí chưa bao giờ sử dụng một công cụ theo dõi lỗi, nhưng nó hoàn toàn có ý nghĩa.

Vì tò mò, bạn không thích điều gì?

EDIT: một cảnh báo; nói với người quản lý của bạn để đổi thương hiệu phần mềm theo dõi lỗi. Nếu không, tất cả mọi thứ trong đó được coi là một lỗi. Tôi gặp vấn đề chính trị này ở khách hàng cuối cùng của mình, nơi tôi đặt các nhiệm vụ trong trình theo dõi lỗi. Không tốt.

Tôi đã viết một cơ sở dữ liệu yêu cầu 6 hoặc 7 năm trước để xử lý việc này. Mỗi bản ghi yêu cầu có một mô tả ngắn, một bản ghi nhớ "định nghĩa" và một bản ghi nhớ "ghi chú" (cả văn bản phong phú, với khả năng nhúng ảnh chụp màn hình, v.v.). Ngoài ra còn có các trường khác, đối với dự án, có thể phân phối, số thứ tự (để chúng có thể được sắp xếp một cách hợp lý), trường hợp sử dụng / tính năng liên quan đến, ước tính thời gian, trường cho người xử lý nó, nếu ai đó đã chọn nó để thực hiện, v.v.

Ngoài ra còn có "Trạng thái" - "Đã nhập", trong khi chúng tôi đang thiết kế các tính năng; "Đã phê duyệt", được đặt khi một nhóm các yêu cầu được xem xét và xác định để sẵn sàng thực hiện; "Đã triển khai", được lập trình viên đặt ra khi họ nghĩ rằng yêu cầu đã được thực hiện và "Xác thực" khi công nghệ QA đồng ý với lập trình viên. (Nếu công nghệ QA không đồng ý, anh ta có thể đặt lại thành "Đã phê duyệt" để lập trình viên lấy lại.) Các yêu cầu cũng có thể là "Trì hoãn", "Từ chối" hoặc "Bị hỏi" .)

Bí quyết để làm tốt điều này là độ chi tiết hợp lý. Đôi khi có thể có nghĩa là có một yêu cầu câu (ví dụ: "vấn đề được mô tả trong vấn đề 12345 đã được khắc phục"), nhưng nói chung, các yêu cầu phải mô tả tất cả các khía cạnh quan trọng của toàn bộ tính năng (hoặc một đoạn lớn của một tính năng). Ví dụ: tính năng "báo cáo mới" điển hình sẽ có yêu cầu về định dạng báo cáo (đầu ra trông như thế nào) và yêu cầu cho hộp thoại tùy chọn (giải thích các trường, xác thực, v.v.) Thậm chí có thể có một phần ba nếu có một trình tạo phức tạp đang xử lý dữ liệu, thay vì chỉ là một truy vấn dễ dàng hoặc một cái gì đó. Ngoài ra, chúng tôi sẽ tạo yêu cầu "Trợ giúp" cho chủ đề trợ giúp tương ứng.

Có những lợi thế rất lớn của việc giữ công cụ này trong hồ sơ cơ sở dữ liệu hơn là một tài liệu lớn. Nhiều lập trình viên có thể làm việc theo yêu cầu cùng một lúc. Các hồ sơ cá nhân bị khóa để chỉ một người có thể chỉnh sửa tại một thời điểm, nhưng chúng có thể được mở và đọc trong khi người khác đang chỉnh sửa. Tuy nhiên, ưu điểm lớn nhất là nó cung cấp tài liệu tìm kiếm dễ dàng về cả những yêu cầu và ghi chú về cách chúng được thực hiện. Hiện tại chúng tôi có hơn 25.000 yêu cầu và chúng tôi có thể dễ dàng tìm thấy tất cả các yêu cầu với các từ cụ thể trong tất cả các trường hoặc định nghĩa hoặc ghi chú hoặc bất cứ điều gì trong vòng dưới 10 giây. (Hãy thử điều đó với tài liệu Word có giá trị hơn 6 năm.)

Tôi có thể thấy lý do tại sao mọi người có thể nói rằng đó là một ý tưởng tồi khi thực hiện các yêu cầu trong "trình theo dõi lỗi", nhưng tôi đoán đó là vì các công cụ này không phải vì giữ các yêu cầu trong cơ sở dữ liệu có thể tìm kiếm là một ý tưởng tồi.

Tôi đã sử dụng một lần http://www.pivotaltracker.com/ nhưng trong công ty hiện tại của chúng tôi, chúng tôi đang sử dụng .doc làm nguồn thông số kỹ thuật cốt lõi và Ngọn hải đăng dưới dạng kết hợp các tính năng mong muốn và theo dõi vấn đề. Đối với tôi thật khó để khiến những người khác trong nhóm bắt đầu sử dụng bất kỳ công cụ nào khác khi họ đã quá quen với Word.

Nếu bạn có thể làm theo phương pháp Agile, các liên kết sau có thể hướng dẫn bạn trong việc chọn một công cụ Quản lý Dự án Agile tốt:

• Công cụ quản lý dự án Agile
• So sánh các công cụ quản lý dự án Agile khác nhau

Và nghiêm túc, hãy thử phương pháp Agile - nó giảng về cách tiếp cận đơn giản, thanh lịch, không vô nghĩa, không gây cười, bất cứ điều gì bạn làm, để mọi thành viên trong nhóm hiểu và đánh giá cao vai trò và nỗ lực của mọi thành viên khác.

Chúc may mắn!