2009-04-29 40 views
6

Cách thu thập yêu cầu kỹ thuật hoặc sản phẩm của hệ thống? Ví dụ, nếu chúng ta muốn chế tạo một chiếc xe, chúng ta nên thu thập các yêu cầu như thế nào? Vui lòng hướng dẫn tôi.Cách tốt nhất để thu thập các yêu cầu cho một dự án là gì?

+0

Bạn có yêu cầu kỹ thuật yêu cầu hoặc cho các công cụ không? –

+0

Tôi nghĩ anh ấy hỏi cách thu thập đủ các yêu cầu để thực sự có thể xây dựng một sản phẩm với họ. – kemiller2002

+0

Anh ấy hỏi làm thế nào để xây dựng một cái bẫy chuột tốt hơn. Hoặc thứ 2 trong 1) Làm gì đó, 2) ???, 3) Lợi nhuận? – jmucchiello

Trả lời

7

Đây thực sự là một câu hỏi thực sự lớn. Câu trả lời tôi đặt ra là "nó phụ thuộc." Thu thập yêu cầu là một điều rất khó khăn. Cách tốt nhất để thu thập yêu cầu phụ thuộc vào phương pháp dự án của bạn. Trước tiên, bạn sẽ sử dụng phương pháp tiếp cận lặp lại hay phương pháp tiếp cận thác nước? Bạn cũng cần phải xác định ai là đối tác của dự án của bạn (ví dụ: người quản lý dự án, nhà phát triển, nhà phân tích kinh doanh, khách hàng, nhà tài trợ dự án ...) Sau đó, bạn cần phải có các bên liên quan dự án của bạn nói về những gì họ muốn.

Khi bạn có mọi người nói về những gì bạn muốn nhà phân tích kinh doanh sẽ giúp hướng dẫn khách hàng mô tả những gì họ muốn. Nhà phân tích của bạn cần đào sâu cho các yêu cầu. Rất nhiều lần khách hàng không biết những gì họ thực sự muốn hoặc làm thế nào để mô tả hệ thống theo cách có ý nghĩa với các nhà phát triển.

Bước đầu tiên của giai đoạn này là mô tả phạm vi dự án. Khi phạm vi tốt đã được xác định, bạn sẽ có thể xác định các yêu cầu nào nằm trong phạm vi hoặc nằm ngoài phạm vi. Sau đó, cách tốt nhất để xác định các yêu cầu là thảo luận vấn đề và những gì họ muốn giải quyết. Cố gắng không xây dựng một giải pháp trong giai đoạn yêu cầu, chỉ mô tả sản phẩm cuối cùng nên làm gì.

Kiềm chế không dành quá ít thời gian thu thập các yêu cầu. Bạn càng có nhiều thay đổi sau này trong vòng đời của dự án thì càng tốn nhiều tiền để thực hiện những sửa đổi đó. Ngoài ra, không dành quá nhiều thời gian hoàn thiện các yêu cầu hoặc bạn sẽ tìm thấy chính mình trong những gì được gọi là "phân tích tê liệt." Hãy ghi nhớ những điểm này chỉ là trầy xước bề mặt. Dưới đây là một vài cuốn sách đàng hoàng mà tôi đọc một số thông tin này:

Yêu cầu Phần mềm 2nd Edition bởi Karl E. Wiegers

thêm về Phần mềm Yêu cầu bởi Karl E. Wiegers

Đây là những những cuốn sách phong nha và họ nói về tất cả các chủ đề từ chuẩn bị SRS cho nhiều người xem đến "Yêu cầu bổ sung."

1

Nó được gọi là phân tích hệ thống - bạn đi và nói chuyện với những người dùng sẽ là sản phẩm của bạn.

1

Sử dụng SRS document để ghi lại các yêu cầu mà bạn lấy từ khách hàng.

0
  1. Nói chuyện với mọi người - các bên liên quan và người dùng dự án nói riêng.
  2. Đặt câu hỏi. Rất nhiều người trong số họ.
  3. Ghi lại các cuộc thảo luận và kết luận của bạn.
  4. Sử dụng các nguyên mẫu để xác thực các kết luận.
0

Thông thường nó là hữu ích để nhớ rằng bạn đang phục vụ nhiều bậc thầy tất cả cùng một lúc:

  1. dùng
  2. Quản lý
  3. môi trường thiết kế của bạn Sự kết thúc và bất cứ giới hạn nó áp đặt

Điều tốt nhất là dành thời gian với tất cả các số

trước đây tance: Gần đây tôi đã được thuê để lập trình hệ thống từ đầu cho một công ty giao hàng - tôi phải làm hài lòng người dùng cuối (trình điều khiển - làm cho nó đơn giản và nhanh chóng) quản lý (chúng tôi muốn biết mọi người đã làm gì và khi nào/như thế nào) cũng như làm việc trong một môi trường hạn chế (máy quét di động)

Tôi đã dành rất nhiều thời gian với quản lý rồi quay lại và tiến hành giao hàng với người lái xe. Chỉ sau đó tôi mới có thể thực sự xử lý nó.

Điều quan trọng cần nhớ là KHÔNG chỉ đơn giản là đưa ra giải pháp bạn giống như thực tế giải quyết các vấn đề mà khách hàng gặp phải hàng ngày. Các chỉ cách bạn sẽ bao giờ làm điều này là dành một số thời gian chất lượng với họ, preferaly trong khi họ đang làm công việc của họ.

Điều đáng tiếc là điểm cuối cùng - trong khi họ là đang làm công việc của họ ... nếu bạn chỉ yêu cầu họ, bạn gần như chắc chắn sẽ nhận được câu trả lời chưa hoàn chỉnh. Hầu hết mọi người làm nhiều việc trong công việc của họ rằng họ thậm chí không nghĩ về nó nữa, nó đã trở thành thói quen. Đó là những công việc nhỏ mà khó có thể nhận được và bao gồm trong một hệ thống mới mà không có kinh nghiệm tay đầu tiên.

Tôi xin lỗi nếu bạn yêu cầu các công cụ thay vì phương pháp.

1
  • thảo luận thường xuyên với khách hàng và đặc biệt là những người sử dụng trong tương lai và chính người tiêu dùng
  • Hãy ghi chú nhỏ trong các cuộc đàm phán
  • Sau mỗi cuộc nói chuyện viết một danh sách yêu cầu chính thức và trình bày nó cho việc phê duyệt. Sau đó sẽ rất khó để tranh luận với tất cả các tài liệu đã được đồng ý
  • đảm bảo Khách hàng của bạn biết chi phí gần đúng về thời gian và tiền bạc để thực hiện các yêu cầu "tốt đẹp" ("nice to have")
  • đảm bảo bạn ghi nhãn các yêu cầu là "phải có "," nên có "và" tốt để có "ngay từ đầu, đảm bảo Khách hàng hiểu sự khác biệt giữa các loại này cũng như
  • tích hợp tất cả tài liệu vào phân tích yêu cầu mới nhất và cuối cùng (hoặc phiên bản hiện tại cho lần lặp lại hoặc bất kỳ thứ gì chu kỳ lập trình nhanh mà bạn đang sử dụng ...)
  • nhớ rằng các yêu cầu làm thay đổi theo vòng đời phần mềm, vì vậy việc thu thập là một chuyện nhưng việc quản lý và thực hiện một
  • KISS - giữ nó càng đơn giản càng tốt
  • đọc tuyên ngôn nhanh nhẹn - phần mềm làm việc là đo chỉ cho sự thành công của dự án phần mềm
  • cũng nghiên cứu môi trường nơi hệ thống tương lai sẽ cư trú - có nhiều hạn chế công nghệ hơn từ các hệ thống kế thừa hoặc xung quanh, vì các công ty không muốn vứt rác vào số tiền mà họ đã đầu tư trong nhiều thập kỷ ngay cả khi trong tâm trí hiện đại của chúng tôi, mã 20 tuổi là rác ...
Các vấn đề liên quan