Tôi đã được giao nhiệm vụ phát triển các yêu cầu và thông số kỹ thuật cho một dự án mà nhóm chúng tôi đang bắt đầu.
Tôi nhận ra rằng tôi không biết sự khác biệt; một tìm kiếm Google chỉ làm tôi bối rối hơn - có vẻ như một số người nói rằng thông số kỹ thuật là yêu cầu, nhưng ở mức độ thấp hơn.
Tôi đồng ý với các câu trả lời bỏ phiếu cao nhưng tôi cũng nghĩ rằng thuật ngữ đặc tả đôi khi được sử dụng như một thuật ngữ chung hơn trong ngành công nghiệp phần mềm đề cập đến bất kỳ tài liệu nào mô tả một hệ thống hoặc một phần mềm. Bằng chứng - google "yêu cầu kỹ thuật". Khi nó được sử dụng theo cách đó, nó có nghĩa là một tài liệu chỉ định một cái gì đó - tức là: chỉ định các yêu cầu cho một phần mềm. Tôi sẽ không phán xét nếu đó là cách sử dụng chính xác của từ đó hay không, tôi chỉ muốn chỉ ra rằng đặc điểm kỹ thuật không phải lúc nào cũng có ý nghĩa tương tự với mọi người.
Vâng, đó là lý do tại sao mọi người nên nói "Yêu cầu kinh doanh" và "Đặc tả thiết kế"https://ttmn.mobi/"Đặc tả kỹ thuật" hoặc một cái gì đó. Các từ trên của họ là khá mơ hồ.
Hãy nghĩ về nó như thế này (nói một cách thô thiển): Yêu cầu = yêu cầu tài liệu và thông số kỹ thuật = trường hợp sử dụng / tài liệu thiết kế
Tại sao bạn không hỏi người mà bạn đang làm cho? Chỉ họ mới có thể trả lời những gì cần thiết trong trường hợp cụ thể của bạn .
Bài viết này cung cấp một câu trả lời thấu đáo: ece.cmu.edu/~koopman/des_s99/requirements_specs
Câu trả lời đúng đắn là các yêu cầu là những gì chương trình của bạn nên làm, các thông số kỹ thuật là cách bạn dự định thực hiện.
Một cách khác để xem xét nó là các yêu cầu đại diện cho ứng dụng từ quan điểm của người dùng, hoặc toàn bộ doanh nghiệp. Các đặc điểm kỹ thuật đại diện cho ứng dụng từ quan điểm của nhóm kỹ thuật. Thông số kỹ thuật và yêu cầu đại khái truyền đạt cùng một thông tin, nhưng đến hai đối tượng hoàn toàn khác nhau.
Những gì / làm thế nào âm thanh cắn là đúng, sắp xếp; nhưng khó hiểu, bởi vì bạn cũng có thể xem đặc tả kỹ thuật của một chương trình như mô tả những gì nó nên làm và thiết kế là cách nó nên làm. Một cái khác là pl khai báo (như prolog và SQL), trong đó bạn nêu cái không phải như thế nào . Một giải pháp là chúng là một hệ thống phân cấp trừu tượng, với một phụ huynh nói rõ những gì và trẻ em nói như thế nào (bên ngoài so với bên trong). Tôi rất thích xem thứ hai của bạn, đó là gần gũi hơn với "những gì nó cho " và "những gì nó là " tức là lợi ích so với tính năng.
Tôi thường đồng ý với bạn, nhưng đó chỉ là ý kiến "khác" và không phải là câu trả lời đúng. Ví dụ: hãy xem trang Wiki về Yêu cầu ( en.wikipedia.org/wiki/Requloyment ). Có những yêu cầu phi chức năng, theo định nghĩa là dành cho đội ngũ kỹ thuật. Hoặc các yêu cầu về Kiến trúc và Ràng buộc, một lần nữa về mặt kỹ thuật nhưng họ không gọi chúng là "thông số kỹ thuật". Tôi nghĩ rằng không có câu trả lời chính xác và nó sẽ luôn luôn "mờ" từ công ty này sang công ty khác và nhà phát triển đến nhà phát triển.
Hãy xem câu trả lời "Adam Wuerl" dưới đây, tôi nghĩ đó là tuyên bố chính xác nhất cho câu hỏi được đăng.
là tương đối. Nó có thể ở dưới bài viết này tại thời điểm này, nhưng nó có thể di chuyển lên trên, làm cho nhận xét của bạn khó hiểu hơn— Bryan Oakley
1
Một viễn cảnh khác .. Wikipedia định nghĩa các thông số kỹ thuật là một "tập hợp các yêu cầu". Điều này có nghĩa là một thông số có thể chỉ là 1 yêu cầu, s: = {r1}. Dường như nhiều hơn "yêu cầu" thông tục là yêu cầu "cấp cao", trong khi "thông số kỹ thuật" là yêu cầu cấp thấp, một điều LOD.
— Lance Pollard
38
Yêu cầu ghi lại những gì cần thiết - họ không nên chỉ định cách thức, nhưng những gì.
Tài liệu thông số kỹ thuật làm thế nào để đạt được các yêu cầu - họ nên chỉ định làm thế nào.
Ở nhiều nơi các tài liệu này không tách rời và được sử dụng thay thế cho nhau.
— Oded nguồn
2
Trong công ty của tôi, chúng tôi thường sử dụng thuật ngữ "đặc tả yêu cầu" cho những gì (bạn chỉ định, ghi lại chi tiết, về những gì bạn) và "đặc tả thiết kế" cho cách thức (bạn chỉ định, viết chi tiết, về cách bạn kế hoạch thực hiện nó).
— Giorgio
16
Tôi là một kỹ sư hệ thống trong lĩnh vực hàng không vũ trụ, nơi cả hai thuật ngữ được sử dụng rộng rãi. Sự khác biệt là rõ ràng và không phức tạp như những người khác đang làm cho nó.
Một đặc điểm kỹ thuật là một tài liệu mà xác định một hệ thống hoặc sản phẩm, ví dụ như một đặc điểm kỹ thuật phát triển Thủ-item cho một chiếc F-14. Có rất nhiều phần / nội dung trong một thông số: yêu cầu, định nghĩa, tài liệu tham khảo, bảng chú giải, thông tin xác minh, v.v.
Một yêu cầu là một tuyên bố duy nhất của một cái gì đó các sản phẩm hoặc hệ thống phải làm. Một thông số có thể có hàng trăm yêu cầu trong đó. Phương pháp học cũ cho biết tuyên bố yêu cầu phải sử dụng từ "sẽ", để tách các yêu cầu khỏi các tuyên bố về sự kiện hoặc định nghĩa. .
Vì vậy, một thông số kỹ thuật là một tài liệu đầy đủ các yêu cầu, cộng với một số thông tin hỗ trợ và phụ trợ khác.
— Adam Wuerl nguồn
4
Như tôi đã nói trong một bình luận khác, nó rất mờ đối với mọi người và có lẽ sẽ luôn như vậy. Nhưng dựa trên nghiên cứu sâu rộng RẤT của riêng tôi về chủ đề chính xác này, tôi sẽ nói rằng câu trả lời của bạn là chính xác nhất với kết quả / kết luận của riêng tôi.
— Jeach
2
Luôn luôn hữu ích để có được một đầu vào thực sự của kỹ sư. Cảm ơn!
— LeWoody
Ngoài ra, một Spec có thể có 0 yêu cầu trong đó. Ví dụ của bạn là một ví dụ thực sự tốt cho một chuyên ngành kỹ thuật hàng không rất cụ thể. Tôi không chắc là nó thường áp dụng cho miền lập trình / phát triển phần mềm. Khi hầu hết các phần mềm được điều khiển bởi nhu cầu kinh doanh, sẽ rất hợp lý khi bắt đầu với Tài liệu yêu cầu kinh doanh chi tiết trước khi đánh giá các hạn chế kỹ thuật và thiết kế một giải pháp. Đặc tả kỹ thuật sẽ tuân theo BRD, các ràng buộc tài liệu và cung cấp một cách tiếp cận chi tiết và cụ thể để đáp ứng các yêu cầu kinh doanh trong BRD.
— Bryan 'BJ' Hoffpauir Jr.
1
Bryan"BJ"Hoffpauir Tôi chắc chắn có những trường hợp tài liệu được dán nhãn thông số kỹ thuật và không có yêu cầu nào trong đó, nhưng tôi cho rằng đó là những trường hợp sử dụng sai thuật ngữ này. Một đặc điểm kỹ thuật là một tài liệu yêu cầu - kết thúc câu chuyện. Đó là một thuật ngữ nghệ thuật được chấp nhận rộng rãi trên nhiều lĩnh vực hàng không vũ trụ và quốc phòng và không có sẵn trong kỹ thuật hệ thống, đây là ngành học chịu trách nhiệm cho các yêu cầu và xác minh. Ngay cả trong trường hợp bạn mô tả thuật ngữ được áp dụng: BRD là một thông số kỹ thuật, thông số kỹ thuật cũng giống như vậy, chỉ với các loại yêu cầu khác nhau.
— Adam Wuerl
13
Yêu cầu:
Xác định nhu cầu hoặc điều kiện để đáp ứng cho một sản phẩm mới hoặc thay đổi, có tính đến các yêu cầu có thể xung đột của các bên liên quan khác nhau.
Thông số kỹ thuật:
Họ cung cấp một ý tưởng chính xác về vấn đề cần giải quyết để họ có thể thiết kế hệ thống một cách hiệu quả và ước tính chi phí thay thế thiết kế. Họ cung cấp hướng dẫn cho người kiểm tra để xác minh (trình độ) của từng yêu cầu kỹ thuật.
Trích dẫn là từ "Hệ thống kỹ thuật cơ bản * ".
Yêu cầu dựa trên nhu cầu của các bên liên quan, thông số kỹ thuật là một tài liệu kỹ thuật và chi tiết bên trong. Họ khác nhau, nhưng họ nói về cùng một điều.
* Nhà xuất bản Đại học Quốc phòng, 2001. Phiên bản PDF của văn bản.
— bùa nguồn
Tôi nghĩ rằng điều quan trọng là định nghĩa của bạn nói rằng thông số kỹ thuật đó xác định VẤN ĐỀ. Theo cách đó, một thông số PROBLEM là một yêu cầu. Một thông số GIẢI PHÁP hoặc THIẾT KẾ là một phần của thiết kế.
— LeWoody
6
Yêu cầu là mô tả của người dùng về những gì thành phẩm, trong mắt họ, nên làm.
Đặc điểm kỹ thuật là mô tả kỹ thuật của giải pháp nói chung, bao gồm các yêu cầu và nhiều hơn nữa - ví dụ: chi phí, kỹ thuật, vấn đề, v.v.
Do đó, một trong những điểm chính là Yêu cầu phải được ưu tiên trước khi có thể viết Thông số kỹ thuật.
(Lưu ý thuật ngữ - sản phẩm và giải pháp - cùng một thứ nhưng từ những quan điểm khác nhau ...)
— Arj nguồn
1
Tôi sẽ trao đổi các thuật ngữ "sản phẩm" và "giải pháp", bởi vì một giải pháp thường là về vấn đề của khách hàng, trong khi một sản phẩm thường là về mặt người bán (tức là người thực hiện kỹ thuật). Một sự tương phản tương tự là lợi ích / tính năng, trong đó lợi ích là về mặt khách hàng (lợi ích của nó đối với họ) và tính năng là trong các điều khoản triển khai (thực tế nó là gì, vì vậy chúng tôi có thể làm cho nó).
— 13ren
1
Tôi thấy quan điểm của bạn, nhưng tôi nghĩ một trong hai góc mô tả đầy đủ tình huống. Tôi đã đưa ra quan điểm rằng một khách hàng sẽ mua một sản phẩm - như bạn làm khi bạn đến một cửa hàng. Một nhà cung cấp phần mềm sau đó sẽ đưa ra giải pháp của họ cho vấn đề tiềm ẩn. Nếu tôi ra ngoài mua một giải pháp cho vấn đề của mình, có lẽ tôi sẽ nghĩ, "Tôi cần một sản phẩm có xyz", chứ không phải, "Tôi cần một giải pháp cho vấn đề abc của tôi". Tôi nghĩ đó chỉ là vấn đề ưu tiên.
— Arj
hấp dẫn. Tôi có thể thấy khách hàng "tìm kiếm sản phẩm" khi có danh mục sản phẩm đã được thiết lập. Nhưng họ tìm kiếm sản phẩm đó vì họ đã tìm ra rằng nó sẽ giải quyết vấn đề của họ - tức là họ tìm kiếm sản phẩm đó, không phải vì lợi ích của riêng họ, mà là một giải pháp. Cũng đúng là một nhà cung cấp tiếp thị sản phẩm của họ như một "giải pháp" - nhưng đó là vì họ đang cố gắng giao tiếp với khách hàng (những người tìm kiếm giải pháp cho vấn đề của họ) và xây dựng một thứ gì đó sẽ được mong muốn. Trên thực tế, việc xây dựng sản phẩm (nghĩa là bản thân nó và các tính năng của nó độc lập với lý do tại sao chúng cần thiết)
— 13ren
Tôi có thể thấy khách hàng "tìm kiếm sản phẩm", khi có một danh mục sản phẩm đã được thiết lập - nhưng họ tìm kiếm nó như một giải pháp cho một vấn đề / nhu cầu họ có. Các nhà cung cấp tiếp thị sản phẩm của họ dưới dạng "giải pháp" - bởi vì họ đang giao tiếp với khách hàng (những người có vấn đề cần giải pháp). Khi xây dựng sản phẩm (bản thân nó và các tính năng của nó, không phải tại sao họ xây dựng chúng). Một lập luận là một vấn đề có thể có các giải pháp rất khác nhau - nhưng một sản phẩm là một điều cụ thể.
— 13ren
— 13ren
4
Yêu cầu - những gì hệ thống hoặc hệ thống con nên (phải) làm.
Đặc điểm kỹ thuật - Thành phần, hệ thống con hoặc hệ thống IS.
Xem thêm: Vì Sao Trung Quốc Gia Tăng Tranh Chấp Chủ Quyền Biển Đông, — TiếNg ViệT
Điều này rất quan trọng trong ngành sản xuất thiết bị y tế vì bạn phải tiến hành Xác minh theo yêu cầu của bạn (Đầu vào) để chứng minh rằng bạn có thông số kỹ thuật hợp lệ (Đầu ra). Cạm bẫy điển hình trong ngành này là các công ty (1) quên xác định các yêu cầu (vì họ không hiểu sự khác biệt giữa yêu cầu so với thông số kỹ thuật); (2) Tiến hành Xác minh chỉ dựa trên các thông số kỹ thuật và (3) Không đảm bảo rằng các Yêu cầu đang được dịch chính xác sang các thông số kỹ thuật của bộ phận lắp đặt và thành phần.
Khi việc này hoàn tất, bạn sẽ được yêu cầu Xác thực các yêu cầu của Người dùng cho sản phẩm đã được đáp ứng.
— Paul Bacchus nguồn
3
Có lẽ sự nhầm lẫn là tôi đã nghe các thông số kỹ thuật đề cập đến các tài liệu Đặc tả yêu cầu nghiệp vụ hoặc các tài liệu SRS (Thông số yêu cầu phần mềm) theo tiêu chuẩn của IEEE.
Ví dụ mẫu SRS tiêu chuẩn của IEEE
Tôi cũng đã nghe các thuật ngữ thông số kỹ thuật tham khảo chính thức hơn đến Thông số kỹ thuật giải thích các quyết định thiết kế và kế hoạch thực hiện.
EDIT: Tôi chỉ nhận thấy liên kết không chính xác ... Tôi sẽ đăng một liên kết chính xác trong thời gian ngắn.
— phong_shaft nguồn
1
Điểm tốt về thuật ngữ SRS!
— LeWoody
2
Liên kết bây giờ đã bị hỏng hoàn toàn . Tôi không chắc những gì nó chỉ vào cũng như những gì nó nên chỉ ra.
3
Một đặc điểm kỹ thuật là một yêu cầu thông qua tính khả thi và sẵn sàng để được thực hiện. Đó là một yêu cầu đã phát triển đến giai đoạn thiết kế.
Nói cách khác:
Yêu cầu là hành vi (hoặc không hành vi) "theo kế hoạch" hoặc "như mong muốn"Một đặc tả là hành vi (hoặc không hành vi) "được xây dựng" hoặc "như được xây dựng"Thí dụ:
yêu cầu: 1. người dùng nhấn nút OK 2. hệ thống in hóa đơnđặc điểm kỹ thuật: 1. người dùng nhấn nút OK 2. hệ thống in hóa đơnNhư bạn có thể thấy, nội dung của cả hai có thể giống nhau. Sự khác biệt là yêu cầu đó là một tạo tác phân tích. Các đặc điểm kỹ thuật là một tạo tác thiết kế.
Trong tài liệu được xây dựng cuối cùng, thông thường bạn sẽ tìm thấy từ "đặc tả", thay vì "yêu cầu", vì các yêu cầu đã được chuyển đổi thành thông số kỹ thuật.
Ghi chú: ví dụ trên có chứa các yếu tố thiết kế, vì hạn chế thiết kế.
— cáo.bailey nguồn
0
Yêu cầu là những gì ứng dụng LÀM
Cụ thể là CÁCH ứng dụng làm những gì nó làm.
Chúng phải trực giao!
Quản lý sản phẩm viết các yêu cầu, kỹ sư trưởng viết các thông số kỹ thuật.
— tháng giêng 100 nguồn
2
Tôi không chắc chắn chúng hoàn toàn trực giao, ít nhất là trong thực tế. Có rất nhiều màu xám không may.
— LeWoody
Chúng chỉ có màu xám nếu bạn rời khỏi bộ sửa đổi - Yêu cầu nghiệp vụ, Yêu cầu chức năng, Yêu cầu phi chức năng đề cập đến khả năng của hệ thống (CÁI GÌ nó làm). Thông số kỹ thuật là trực giao với Yêu cầu nghiệp vụ (CÁCH LÀM nó).
— Bryan 'BJ' Hoffpauir Jr.
0
Một cách, có thể không đúng cách, để xem xét nó:
Yêu cầu là những thứ (khả năng, tính năng, hành vi, v.v.) mang lại giá trị cho người dùng. Không quan tâm đến nội bộ; chỉ có đầu vào và đầu ra của hộp (và có thể kích thước, hình dạng và màu sắc) là quan trọng ở đây.
Thông số kỹ thuật là những thứ (khả năng, tính năng, hành vi, v.v.) cho phép giá trị đó cho người dùng. Ở đây, các hộp bên trong rất quan trọng, bởi vì cùng với các giao diện và đặc điểm bên ngoài được đề cập ở trên, chúng xác định toàn bộ hệ thống.
— bến nguồn
Đây chỉ là ý kiến của bạn hoặc bạn có thể sao lưu nó bằng cách nào đó?
— gnat
2
gnat, tôi nghĩ rằng đã được giải quyết trong dòng mở đầu? Chắc chắn, đây là từ kinh nghiệm và tôi không yêu cầu bất cứ điều gì khác - từ những gì tôi thu thập được đây là một câu hỏi hơi chủ quan trên một diễn đàn khá chủ quan, và bài đăng này cho thấy rằng các câu hỏi nên khách quan nhất có thể nhưng ít đề cập đến câu trả lời . Nhưng tôi có một cái tên của tôi và bạn có nhiều hơn rất nhiều vì vậy tôi sẵn sàng để được giáo dục 🙂
— berad
0
Trong nghiên cứu của tôi, tôi đã tìm thấy Thông số kỹ thuật được sử dụng cho bằng sáng chế và Xây dựng nhà (như một phần của hợp đồng).
Định nghĩa của một yêu cầu từ Từ điển không rút gọn của Webster (Bản quốc tế mới thứ 3) là:
a) một cái gì đó được mong muốn hoặc cần thiết: Sự cần thiết b) một cái gì đó được yêu cầu hoặc yêu cầu: một điều kiện cần thiết hoặc cần thiết: một chất lượng, khóa học hoặc loại đào tạo cần thiết
Tôi nghĩ ở trên cho thấy họ là khác nhau rõ ràng. Tôi đoán bạn có thể gọi các yêu cầu cấp thấp hơn của spec, nhưng tôi nghĩ đó là sự sai lệch của thuật ngữ yêu cầu imho.
— LeWoody nguồn
0
Trong một công ty trước đây tạo ra các sản phẩm thương mại, chúng tôi có sự phân biệt sau:
Yêu cầu là những gì hệ thống phải làm. Chúng có thể là cấp thấp hơn, yêu cầu chi tiết, và chúng có thể là chức năng hoặc không chức năng.
Thông số kỹ thuật là những thứ mà hệ thống được xây dựng thực sự làm. Ví dụ: bạn có thể yêu cầu hệ thống phải có hành vi X ở mức 10 ° C. Thông số kỹ thuật thực tế của hệ thống có thể là hệ thống thực hiện X ở mức5 ° C; điều này sẽ có trong tờ gửi cho khách hàng tiềm năng khi họ muốn mua hệ thống.
NB trong trường hợp này đặc điểm kỹ thuật không bằng yêu cầu.
— Hoàng gia nguồn
-1
Hãy suy nghĩ, bạn sẽ xây dựng một tòa nhà cao tầng trên một khu đất.
Bây giờ bạn cần xem xét các Yêu cầu trước khi bắt đầu, chẳng hạn như:
Kỹ sư kiến trúc hoặc thiết kếKỹ sư kiểm tra đấtĐội kiểm tra áp lực gióPhá hủyThợ lặnSức mạnh đàn ôngCung cấp nướcKhu vực sinh hoạt / nghỉ ngơi của công nhânĐủ quỹQuản lý dự ánQuản lý chất lượngKiểm soát an ninh và an toànVân vân.
Bây giờ các nội dung trên là một phần của Yêu cầu để xây dựng một tòa nhà cao tầng. Từ nhóm trên, bạn có được kết quả kỹ thuật, mà họ nắm giữ như một phần của nghề nghiệp.
Đây chính xác là những gì đang xảy ra trong ngành công nghiệp phần mềm, một nhóm người chuyên nghiệp tham gia để cung cấp kiến thức để xây dựng các đặc tả kỹ thuật, chẳng hạn như ai đó làm việc về thiết kế UI, thiết kế OO, thiết kế cơ sở dữ liệu, thiết kế đồ họa, thiết kế trường hợp thử nghiệm, mã hóa, tích hợp , nhóm triển khai, vv
Đoạn trên sẽ là một phần của cẩm nang, bạn có thể gọi Thông số kỹ thuật.
— Mohammed Hoq nguồn
1
Tôi nghĩ rằng bạn đang nhầm lẫn các yêu cầu với tài nguyên ( en.wikipedia.org/wiki/Resource_%28project_man Quản lý% 29 ).
— Jay Elston
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 cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.
