IEEE830

Machine Translated by Google
IEEE Std 830-1998

(Sửa đổi của
IEEE Std 830-1993)
Cách thực hành được IEEE khuyến nghị cho
Yêu cầu phần mềm

Thông số kỹ thuật
Nhà tài trợ
Ủy ban Tiêu chuẩn Kỹ thuật Phần mềm của
Hiệp hội máy tính IEEE
Phê duyệt ngày 25 tháng 6 năm 1998
Ban Tiêu chuẩn IEEE-SA
Tóm tắt: Nội dung và chất lượng của một đặc tả yêu cầu phần mềm (SRS) tốt được mô tả và một số đề
cương SRS mẫu được trình bày. Thực tiễn được khuyến nghị này nhằm mục đích xác định các yêu cầu
của phần mềm sẽ được phát triển nhưng cũng có thể được áp dụng để hỗ trợ việc lựa chọn các sản
phẩm phần mềm thương mại và nội bộ. Hướng dẫn tuân thủ IEEE/EIA 12207.1-1997 cũng được cung cấp.
Từ khóa: hợp đồng, khách hàng, nguyên mẫu, đặc tả yêu cầu phần mềm, nhà cung cấp, đặc tả yêu cầu
hệ thống
Viện Kỹ sư Điện và Điện tử, Inc.

345 East 47th Street, New York, NY 10017-2394, Hoa Kỳ
Bản quyền © 1998 của Viện Kỹ sư Điện và Điện tử, Inc.

Đã đăng ký Bản quyền. Xuất bản năm 1998. In tại Hoa Kỳ.
ISBN 0-7381-0332-2
Không phần nào của ấn phẩm này được phép sao chép dưới bất kỳ hình thức nào, trong hệ thống truy xuất điện tử hoặc cách khác mà không có sự cho
phép trước bằng văn bản của nhà xuất bản.
Các tài liệu về Tiêu chuẩn IEEE được phát triển trong Hiệp hội IEEE và Ủy ban Điều phối Tiêu
chuẩn của Ban Tiêu chuẩn Hiệp hội Tiêu chuẩn IEEE (IEEE-SA). Các thành viên của ủy ban phục vụ
một cách tự nguyện và không có thù lao. Họ không nhất thiết phải là thành viên của Viện. Các
tiêu chuẩn được phát triển trong IEEE thể hiện sự đồng thuận về chuyên môn sâu rộng về chủ đề
trong Viện cũng như các hoạt động bên ngoài IEEE đã bày tỏ sự quan tâm đến việc tham gia vào
việc phát triển tiêu chuẩn.
Việc sử dụng Tiêu chuẩn IEEE là hoàn toàn tự nguyện. Sự tồn tại của Tiêu chuẩn IEEE không có
nghĩa là không có cách nào khác để sản xuất, thử nghiệm, đo lường, mua, tiếp thị hoặc cung cấp
hàng hóa và dịch vụ khác liên quan đến phạm vi của Tiêu chuẩn IEEE. Hơn nữa, quan điểm được thể
hiện tại thời điểm tiêu chuẩn được phê duyệt và ban hành có thể thay đổi do sự phát triển về
công nghệ và nhận xét nhận được từ người sử dụng tiêu chuẩn. Mọi Tiêu chuẩn IEEE đều phải được
xem xét lại ít nhất 5 năm một lần để sửa đổi hoặc xác nhận lại. Khi một tài liệu đã hơn 5 năm
tuổi và chưa được xác nhận lại thì có lý khi kết luận rằng nội dung của nó, mặc dù vẫn còn một
số giá trị, nhưng không phản ánh đầy đủ tình trạng kỹ thuật hiện tại. Người dùng nên kiểm tra
để xác định xem họ có phiên bản mới nhất của bất kỳ Tiêu chuẩn IEEE nào không.
Mọi ý kiến sửa đổi Tiêu chuẩn IEEE đều được hoan nghênh từ bất kỳ bên quan tâm nào, bất kể tư
cách thành viên của IEEE. Các đề xuất thay đổi trong tài liệu phải ở dạng đề xuất thay đổi văn
bản, kèm theo các ý kiến hỗ trợ phù hợp.
Giải thích: Đôi khi có thể nảy sinh các câu hỏi liên quan đến ý nghĩa của các phần của tiêu
chuẩn khi chúng liên quan đến các ứng dụng cụ thể. Khi IEEE lưu ý đến nhu cầu giải thích, Viện
sẽ bắt đầu hành động để chuẩn bị các phản hồi thích hợp. Vì Tiêu chuẩn IEEE thể hiện sự đồng
thuận của tất cả các lợi ích liên quan nên điều quan trọng là phải đảm bảo rằng bất kỳ cách
giải thích nào cũng nhận được sự đồng thuận về sự cân bằng lợi ích. Vì lý do này, IEEE và các
thành viên trong hiệp hội cũng như Ủy ban Điều phối Tiêu chuẩn của nó không thể đưa ra phản hồi
ngay lập tức đối với các yêu cầu giải thích ngoại trừ những trường hợp mà vấn đề trước đó đã
được xem xét chính thức.
Ý kiến về các tiêu chuẩn và yêu cầu giải thích nên được gửi đến:
Thư ký, Ban Tiêu chuẩn IEEE-SA 445

Hoes Lane PO
Box 1331
Piscataway, NJ 08855-1331
USA
Lưu ý: Cần chú ý đến khả năng việc thực hiện tiêu chuẩn này có thể yêu cầu sử dụng
đối tượng được bảo hộ bằng sáng chế. Bằng việc công bố tiêu chuẩn này, không có
quan điểm nào được đưa ra đối với sự tồn tại hoặc hiệu lực của bất kỳ quyền sáng
chế nào liên quan đến nó. IEEE sẽ không chịu trách nhiệm xác định các bằng sáng
chế mà tiêu chuẩn của IEEE có thể yêu cầu giấy phép hoặc tiến hành điều tra về giá
trị pháp lý hoặc phạm vi của các bằng sáng chế đó được IEEE chú ý.
Viện Kỹ sư Điện và Điện tử, Inc. cấp phép sao chụp các phần của bất kỳ tiêu chuẩn riêng lẻ nào
để sử dụng nội bộ hoặc cá nhân, với điều kiện phải trả khoản phí thích hợp cho Trung tâm cấp
phép bản quyền. Để sắp xếp thanh toán phí cấp phép, vui lòng liên hệ với Trung tâm cấp phép bản
quyền, Dịch vụ khách hàng, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Bạn cũng
có thể xin phép sao chụp các phần của bất kỳ tiêu chuẩn cá nhân nào để sử dụng trong lớp học
giáo dục thông qua Trung tâm cấp phép bản quyền.
Giới thiệu
(Phần giới thiệu này không phải là một phần của IEEE Std 830-1998, Thực hành được khuyến nghị của IEEE cho các đặc tả yêu cầu
phần mềm.)
Thực hành được khuyến nghị này mô tả các phương pháp tiếp cận được khuyến nghị để đặc tả các yêu cầu phần mềm. Nó dựa trên một
mô hình trong đó kết quả của quá trình đặc tả yêu cầu phần mềm là một tài liệu đặc tả đầy đủ và rõ ràng. Nó sẽ giúp
a) Khách hàng sử dụng phần mềm mô tả chính xác những gì họ mong muốn nhận được; b) Nhà
cung cấp phần mềm hiểu chính xác mong muốn của khách hàng; c) Cá nhân thực hiện các
mục tiêu sau:
1) Phát triển một bản phác thảo đặc tả yêu cầu phần mềm tiêu chuẩn (SRS) cho tổ chức của riêng họ-
ý kiến;
2) Xác định định dạng và nội dung của các thông số kỹ thuật yêu cầu phần mềm cụ thể của họ;
3) Phát triển các hạng mục hỗ trợ bổ sung tại địa phương như danh sách kiểm tra chất lượng SRS hoặc tài liệu của người viết SRS
sổ tay.
Đối với khách hàng, nhà cung cấp và các cá nhân khác, một SRS tốt sẽ mang lại một số lợi ích cụ thể, chẳng hạn như sau:
- Thiết lập cơ sở cho sự thỏa thuận giữa khách hàng và nhà cung cấp về chức năng của sản phẩm phần mềm. Mô tả đầy đủ về các
chức năng được thực hiện bởi phần mềm được chỉ định trong SRS sẽ hỗ trợ người dùng tiềm năng xác định xem phần mềm được
chỉ định có đáp ứng được nhu cầu của họ hay không hoặc phần mềm phải được sửa đổi như thế nào để đáp ứng nhu cầu của họ.
- Giảm nỗ lực phát triển. Việc chuẩn bị SRS buộc các nhóm liên quan khác nhau trong tổ chức của khách hàng phải xem xét nghiêm
ngặt tất cả các yêu cầu trước khi bắt đầu thiết kế và giảm thiểu việc thiết kế lại, mã hóa lại và kiểm tra lại sau này.
Việc xem xét cẩn thận các yêu cầu trong SRS có thể sớm phát hiện ra những thiếu sót, hiểu lầm và mâu thuẫn trong chu kỳ
phát triển khi những vấn đề này dễ sửa chữa hơn.
- Cung cấp cơ sở để ước tính chi phí và tiến độ. Mô tả sản phẩm sẽ được phát triển như được nêu trong SRS là cơ sở thực tế để
ước tính chi phí dự án và có thể được sử dụng để xin phê duyệt hồ sơ dự thầu hoặc dự toán giá.
- Cung cấp cơ sở để xác nhận và xác minh. Các tổ chức có thể phát triển kế hoạch xác nhận và xác minh của mình hiệu quả hơn
nhiều từ một SRS tốt. Là một phần của hợp đồng phát triển, SRS cung cấp cơ sở để đo lường sự tuân thủ.
- Tạo điều kiện thuận lợi cho việc chuyển giao. SRS giúp việc chuyển sản phẩm phần mềm tới người dùng mới hoặc máy mới trở nên
dễ dàng hơn. Do đó, khách hàng thấy dễ dàng hơn khi chuyển phần mềm đến các bộ phận khác trong tổ chức của họ và các nhà
cung cấp thấy việc chuyển phần mềm đó cho khách hàng mới dễ dàng hơn.
- Làm cơ sở để nâng cao. Bởi vì SRS thảo luận về sản phẩm chứ không phải dự án đã phát triển nó nên SRS đóng vai trò là cơ sở
cho việc cải tiến thành phẩm sau này. SRS có thể cần phải được thay đổi nhưng nó cung cấp nền tảng cho việc đánh giá sản
xuất liên tục.
Người đọc tài liệu này có thể tham khảo Phụ lục B để biết các hướng dẫn sử dụng thực hành được khuyến nghị này nhằm đáp ứng các
yêu cầu của IEEE/EIA 12207.1-1997, Hướng dẫn IEEE/EIA—Việc triển khai ngành của ISO/IEC 12207: 1995, Tiêu chuẩn cho Công nghệ
thông tin—Phần mềm quy trình vòng đời—Dữ liệu vòng đời.
Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền. iii

Những người tham gia
Thực hành khuyến nghị này được chuẩn bị bởi Nhóm công tác về hài hòa dữ liệu vòng đời của Ủy ban tiêu chuẩn kỹ
thuật phần mềm của Hiệp hội máy tính IEEE. Vào thời điểm khuyến nghị thực hành này được phê duyệt, nhóm công
tác bao gồm các thành viên sau:
Leonard L. Tripp, Chủ tịch
Edward Byrne Dennis Lawrence Terry Rout

Paul R. Croll David Maibor Richard Schmidt
Perry DeWeese Ray Milovanovic Norman F. Schneidewind
Robin Fralick James Moore David Schultz
Marilyn Ginsberg-Finner Timothy Niesen Basil Sherlund
John Harauz Dennis Rilling Peter Voldner
Mark Henley Ronald Wade
Những người sau đây có mặt trong ủy ban bỏ phiếu: Syed Ali
Theodore David A. Gustafson Indradeb P.

K. Atchinson Mikhail Jon D. Hagar Pal Alex
Auguston Robert John Harauz Polack Peter T. Poon
E. Barry Leo Robert T. Harley Lawrence S. Przybylski

Beltracchi H. Herbert Hecht Kenneth R. Ptack
Ronald Berlack William Hefley Annette D. Reilly
Richard E. Biehl Manfred Hein Dennis Rilling
Michael A. Blackledge Mark Heinrich Andrew P. Sage
Sandro Bologna Mark Henley Helmut Sandmayr
Juris Borzovs Debra Herrmann Stephen R. Schach
Kathleen L. Briggs John W. Horch Hans Schaefer
M. Scott Buck Jerry Huller Norman Schneidewind
Michael Caldwell Peter L. Hung David J. Schultz
James E. Cardow George Jackelen Lisa A. Selmon
Enrico A. Carrara Frank V. Jorgensen Robert W. Shillato
Lawrence Catchpole William S. Junk David M. Siefert

Keith Chan George X. Kambic Carl A. Ca sĩ
Antonio M. Cicu Richard Karcich James M . Sivak
Theo Clarke Ron S. Kenett Richard S. Sky
Sylvain Clermont Judith S. Kerner Nancy M. Smith
Rosemary Coleman Robert J. Kierzyk Melford E. Smyre
Virgil Lee Cooper Dwayne L. Knirk Harry M. Sneed
WW Geoff Cozens Shaye Koenig Alfred R. Sorkowitz
Paul R. Thomas M. Kurihara Donald W. Sova
Croll Gregory T. John B. Lane Luca Spotorno

Daich Geoffrey J. Dennis Lawrence Julia Stesney
Darnton Taz Fang Ching Lim Fred J. Strauss
Daughtrey Bostjan William M. James Christine Brown Strysik

K. Derganc Perry J. Longbucco Dieter Toru Takeshita
R. DeWeese James Do sôi nổi Richard H. Thayer
Evelyn S. Dow Nhìn John Booker Thomas
Carl Einar Dragstedt Lord Stan Patricia
Sherman Eagles Magee David Trellue Theodore J.
Christof Ebert Maibor Harold Urbanowicz Glenn
Leo Egan Mains Robert A. D. Venables
Richard E. Fairley Martin Tomoo Udo Voges David
John W. Fendrich Matsubara Mike D. Walden Dolores
Jay Forster McAndrew Patrick Wallace William M.
Kirby Fortenberry D. McCray Christopher Walsh John W.
Eva Freund McMacken Jerome Walz Camille SWhite-
Richard C. Fries W. Mersky Partain Scott A.
Roger U. Fujii Bret Whitmire PA
Adel N. Ghannam Michael Alan Wolfgang Paul
Marilyn Ginsberg-Finner Miller Celia H. R. Work Natalie C.
John Garth Glynn Modell James Yopconka Janusz
Julio Gonzalez-Sanz W. Moore Pavol Navrat Myrna L. Olson Zalewski Geraldine
LM Gunther Zimmerman Peter F. Zoll
iv Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền.

Khi Hội đồng Tiêu chuẩn IEEE-SA phê duyệt khuyến nghị thực hành này vào ngày 25 tháng 6 năm 1998, nó có
các thành viên như sau:
Richard J. Holleman, Chủ tịch Donald N. Heirman, Phó Chủ tịch

Judith Gorman, Thư ký
Satish K. Aggarwal James H. Gurney L. Bruce McClung

Clyde R. Camp Jim D. Isaak Louis-François Pau
James T. Carlo Lowell G. Johnson Ronald C. Petersen
Gary R. Engmann Robert Kennelly Gerald H. Peterson
Harold E. Epstein EG “Al” Kiener John B. Posey
Jay Forster* Joseph L. Koepfinger* Gary S. Robinson
Thomas F. Garrity Stephen R. Lambert Hans E. Weinrich
Ruben D. Garzon Jim Logothetis Donald W. Zipse
Donald C. Loughry
*Thành viên danh dự
Valerie E. Zelenty
Biên tập dự án tiêu chuẩn IEEE
Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền. v

Nội dung
1. Tổng quan................................................. ................................................................. ................................... 1
1.1 Phạm vi................................................................................. ................................................................. ................................... 1
2. Người giới thiệu................................................. ................................................................. ................................... 2
3. Các định nghĩa................................................. ................................................................. ................................... 2
4. Những cân nhắc để tạo ra một SRS tốt.................................................. ................................... 3
4.1 Bản chất của SRS................................................................................. ................................................................. ...................... 3
4.2 Môi trường của SRS .................................................................... ................................................................. ............ 3
4.3 Đặc điểm của một SRS tốt.................................................................. ................................................................. ........ 4
4.4 Chuẩn bị chung SRS ................................................................. ................................................................. .......... số 8
4.5 Sự phát triển của SRS ................................................................. ................................................................. ............................. số 8
4.6 Tạo mẫu................................................................................. ................................................................. ................................. 9
4.7 Thiết kế nhúng trong SRS.................................................................. ................................................................. ........ 9
4.8 Nhúng các yêu cầu của dự án vào SRS.................................................. ................................. 10
5. Các bộ phận của SRS.................................................................. ................................................................. ................... 10
5.1 Giới thiệu (Phần 1 của SRS)................................................ ................................................................. 11
5.2 Mô tả tổng thể (Phần 2 của SRS)................................................ ................................... 12
5.3 Yêu cầu cụ thể (Phần 3 của SRS)................................................ ................................... 15
5.4 Thông tin hỗ trợ.................................................................. ................................................................. ............ 19
Phụ lục A (tham khảo) Mẫu SRS................................................................. ................................................................. .......... 21
Phụ lục B (tham khảo) Hướng dẫn tuân thủ IEEE/EIA 12207.1-1997....................... 0,27
vi
Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền.
Cách thực hành được IEEE khuyến nghị cho
Yêu cầu phần mềm

Thông số kỹ thuật
1. Khái quát chung
Thực hành được khuyến nghị này mô tả các phương pháp tiếp cận được khuyến nghị để đặc tả các yêu cầu phần mềm. Nó được
chia thành năm điều khoản. Điều 1 giải thích phạm vi thực hành được khuyến nghị này. Điều 2 liệt kê các tài liệu tham
khảo được thực hiện theo các tiêu chuẩn khác. Điều 3 đưa ra định nghĩa về các thuật ngữ cụ thể được sử dụng. Điều 4 cung
cấp thông tin cơ bản để viết một SRS tốt. Điều 5 thảo luận về từng phần thiết yếu của SRS. Thực tiễn được khuyến nghị
này cũng có hai phụ lục, một phụ lục cung cấp các mẫu định dạng thay thế và một phụ lục cung cấp các hướng dẫn tuân thủ
IEEE/EIA 12207.1-1997.
1.1 Phạm vi
Đây là cách thực hành được khuyến nghị để viết các đặc tả yêu cầu phần mềm. Nó mô tả nội dung và chất lượng của một đặc
tả yêu cầu phần mềm (SRS) tốt và trình bày một số phác thảo SRS mẫu.
Thực tiễn được khuyến nghị này nhằm mục đích xác định các yêu cầu của phần mềm sẽ được phát triển nhưng cũng có thể
được áp dụng để hỗ trợ việc lựa chọn các sản phẩm phần mềm thương mại và nội bộ. Tuy nhiên, việc áp dụng vào phần mềm
đã được phát triển có thể phản tác dụng.
Khi phần mềm được nhúng vào một số hệ thống lớn hơn, chẳng hạn như thiết bị y tế, thì các vấn đề nằm ngoài những vấn đề
được xác định trong thực tiễn khuyến nghị này có thể phải được giải quyết.
Thực hành được đề xuất này mô tả quá trình tạo sản phẩm và nội dung của sản phẩm. Sản phẩm là SRS. Thực hành được đề
xuất này có thể được sử dụng để tạo SRS trực tiếp hoặc có thể được sử dụng làm mô hình cho một tiêu chuẩn cụ thể hơn.
Thực hành được khuyến nghị này không xác định bất kỳ phương pháp, danh pháp hoặc công cụ cụ thể nào để chuẩn bị SRS.
Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền. 1

IEEE
Tiêu chuẩn 830-1998 IEEE ĐỀ XUẤT THỰC HÀNH CHO
2. Tài liệu tham khảo
Thực hành khuyến nghị này sẽ được sử dụng cùng với các ấn phẩm sau.
ASTM E1340-96, Hướng dẫn tiêu chuẩn để tạo mẫu nhanh các hệ thống máy tính.1
IEEE Std 610.12-1990, Bảng chú giải thuật ngữ kỹ thuật phần mềm tiêu chuẩn IEEE.2
IEEE Std 730-1998, Tiêu chuẩn IEEE về Kế hoạch Đảm bảo Chất lượng Phần mềm.
IEEE Std 730.1-1995, Hướng dẫn của IEEE về Lập kế hoạch Đảm bảo Chất lượng Phần mềm.
IEEE Std 828-1998, Tiêu chuẩn IEEE cho Kế hoạch quản lý cấu hình phần mềm.3
IEEE Std 982.1-1988, Từ điển tiêu chuẩn của IEEE về các biện pháp sản xuất phần mềm đáng tin cậy.
IEEE Std 982.2-1988, Hướng dẫn của IEEE về việc sử dụng Từ điển đo lường tiêu chuẩn của IEEE để sản xuất phần mềm
đáng tin cậy.
IEEE Std 1002-1987 (Reaff 1992), Phân loại tiêu chuẩn IEEE cho các tiêu chuẩn kỹ thuật phần mềm.
IEEE Std 1012-1998, Tiêu chuẩn IEEE về Xác minh và Xác thực Phần mềm.
IEEE Std 1012a-1998, Tiêu chuẩn IEEE về Xác minh và Xác thực Phần mềm: Bản đồ Nội dung tới IEEE/EIA 12207.1-1997.4
IEEE Std 1016-1998, Thực tiễn được IEEE khuyến nghị cho Mô tả thiết kế phần mềm.5
IEEE Std 1028-1997, Tiêu chuẩn IEEE về đánh giá phần mềm.
IEEE Std 1042-1987 (Reaff 1993), Hướng dẫn của IEEE về Quản lý Cấu hình Phần mềm.
IEEE P1058/D2.1, Tiêu chuẩn dự thảo cho kế hoạch quản lý dự án phần mềm, ngày 5 tháng 8 năm 1998.6
IEEE Std 1058a-1998, Tiêu chuẩn IEEE cho Kế hoạch quản lý dự án phần mềm: Bản đồ nội dung tới IEEE/EIA 12207.1-1997.7
IEEE Std 1074-1997, Tiêu chuẩn IEEE để phát triển các quy trình vòng đời phần mềm.
IEEE Std 1233, Phiên bản 1998, Hướng dẫn của IEEE về Phát triển Thông số kỹ thuật Yêu cầu Hệ thống.8
Các ấn phẩm 1ASTM có sẵn tại Hiệp hội Thử nghiệm và Vật liệu Hoa Kỳ, 100 Barr Harbor Drive, West Conshohocken, PA 19428-2959, Hoa Kỳ.
2Các ấn phẩm của IEEE có sẵn tại Viện Kỹ sư Điện và Điện tử, 445 Hoes Lane, PO Box 1331, Piscataway, NJ 08855-1331, USA.
3Khi tiêu chuẩn này được ấn hành, IEEE Std 828-1998; IEEE Std 1012a-1998; Tiêu chuẩn IEEE 1016-1998; và IEEE Std 1233, 1998 Edition đã
được phê duyệt nhưng chưa được xuất bản. Tuy nhiên, các tiêu chuẩn dự thảo có sẵn từ IEEE. Ngày xuất bản dự kiến là mùa thu năm 1998.
Liên hệ với Phòng Tiêu chuẩn IEEE theo số 1 (732) 562-3800 để biết thông tin trạng thái.
4Xem Chú thích 3.
5Xem Chú thích 3.
6Sau khi Hội đồng Tiêu chuẩn IEEE-SA phê duyệt IEEE P1058, tiêu chuẩn này sẽ được tích hợp với IEEE Std 1058a-1998 và được xuất bản dưới
tên IEEE Std 1058, 1998 Edition. Dự kiến phê duyệt vào ngày 8 tháng 12 năm 1998.
7
Khi tiêu chuẩn này được ấn hành, IEEE Std 1058a-1998 đã được phê duyệt nhưng chưa được công bố. Tuy nhiên, tiêu chuẩn dự thảo có sẵn
từ IEEE. Ngày xuất bản dự kiến là tháng 12 năm 1998. Hãy liên hệ với Phòng Tiêu chuẩn IEEE theo số 1 (732) 562-3800 để biết thông tin
trạng thái. Xem chú thích 6.
8 Xem chú thích 3.
2 Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền.

IEEE
YÊU CẦU PHẦN MỀM THÔNG SỐ KỸ THUẬT Tiêu chuẩn 830-1998
3. Định nghĩa
Nhìn chung, định nghĩa của các thuật ngữ được sử dụng trong khuyến nghị này tuân theo các định nghĩa được cung cấp trong
IEEE Std 610.12-1990. Các định nghĩa dưới đây là những thuật ngữ chính được sử dụng trong thực tiễn được khuyến nghị này.
3.1 hợp đồng: Một tài liệu có tính ràng buộc về mặt pháp lý được khách hàng và nhà cung cấp đồng ý. Điều này bao gồm các
yêu cầu về mặt kỹ thuật và tổ chức, chi phí và lịch trình cho một sản phẩm. Hợp đồng cũng có thể chứa những thông tin không
chính thức nhưng hữu ích như những cam kết hoặc mong đợi của các bên liên quan.
3.2 khách hàng: Người hoặc những người trả tiền cho sản phẩm và thường (nhưng không nhất thiết) quyết định các yêu cầu.
Trong bối cảnh thực hành được khuyến nghị này, khách hàng và nhà cung cấp có thể là thành viên của cùng một tổ chức.
3.3 nhà cung cấp: Người hoặc những người sản xuất sản phẩm cho khách hàng. Trong bối cảnh của thông lệ được khuyến nghị
này, khách hàng và nhà cung cấp có thể là thành viên của cùng một tổ chức.
3.4 người dùng: Người hoặc những người vận hành hoặc tương tác trực tiếp với sản phẩm. (Những) người dùng và (những) khách
hàng thường không phải là cùng một người.
4. Những cân nhắc để tạo ra một SRS tốt
Điều khoản này cung cấp thông tin cơ bản cần được xem xét khi viết SRS. Điều này bao gồm những điều sau đây:
a) Bản chất của SRS; b) Môi
trường của SRS; c) Đặc điểm của
một SRS tốt; d) Phối hợp chuẩn bị SRS;
e) Diễn biến SRS; f) Làm nguyên mẫu;

g) Thiết kế nhúng vào
SRS; h) Đưa các yêu
cầu của dự án vào SRS.
4.1 Bản chất của SRS
SRS là thông số kỹ thuật cho một sản phẩm phần mềm, chương trình hoặc bộ chương trình cụ thể thực hiện các chức năng nhất
định trong một môi trường cụ thể. SRS có thể được viết bởi một hoặc nhiều đại diện của nhà cung cấp, một hoặc nhiều đại
diện của khách hàng hoặc bởi cả hai. Khoản 4.4 khuyến nghị cả hai.
Các vấn đề cơ bản mà (những) người viết SRS sẽ giải quyết như sau:
a) Chức năng. Phần mềm phải làm gì? b) Giao diện bên ngoài. Phần
mềm tương tác với con người, phần cứng của hệ thống, phần cứng khác và phần mềm khác như thế nào?
c) Hiệu suất. Tốc độ, tính khả dụng, thời gian phản hồi, thời gian khôi phục của các chức năng phần mềm khác nhau là gì?
các vấn đề, v.v.?
d) Thuộc tính. Những cân nhắc về tính di động, tính chính xác, khả năng bảo trì, bảo mật, v.v. là gì? e) Các ràng
buộc về thiết kế áp đặt cho việc triển khai. Có bất kỳ tiêu chuẩn bắt buộc nào đang có hiệu lực, ngôn ngữ triển khai,
chính sách về tính toàn vẹn của cơ sở dữ liệu, giới hạn tài nguyên, (các) môi trường vận hành, v.v. không?
(Những) người viết SRS nên tránh đặt các yêu cầu về thiết kế hoặc dự án vào SRS.
Để biết nội dung được khuyến nghị của SRS, hãy xem Điều 5.
3
IEEE
4.2 Môi trường của SRS
Điều quan trọng là phải xem xét vai trò của SRS trong kế hoạch tổng thể của dự án, được xác định trong IEEE Std
610.12-1990. Phần mềm về cơ bản có thể chứa tất cả chức năng của dự án hoặc có thể là một phần của hệ thống lớn hơn.
Trong trường hợp sau, thông thường sẽ có một SRS nêu rõ các giao diện giữa hệ thống và phần mềm của nó, đồng thời
sẽ đặt các yêu cầu về chức năng và hiệu suất bên ngoài lên phần phần mềm. Tất nhiên, SRS sau đó sẽ đồng ý và mở rộng
các yêu cầu hệ thống này.
IEEE Std 1074-1997 mô tả các bước trong vòng đời phần mềm và các đầu vào áp dụng cho từng bước.
Các tiêu chuẩn khác, chẳng hạn như các tiêu chuẩn được liệt kê trong Điều 2, liên quan đến các phần khác của vòng đời phần mềm và
do đó có thể bổ sung cho các yêu cầu phần mềm.
Vì SRS có một vai trò cụ thể trong quá trình phát triển phần mềm nên (những) người viết SRS phải cẩn thận để không
vượt quá giới hạn của vai trò đó. Điều này có nghĩa là SRS
a) Nên xác định chính xác tất cả các yêu cầu phần mềm. Yêu cầu phần mềm có thể tồn tại do tính chất của nhiệm vụ
cần giải quyết hoặc do đặc điểm đặc biệt của dự án.
b) Không nên mô tả bất kỳ chi tiết thiết kế hoặc triển khai nào. Những điều này nên được mô tả trong giai đoạn
thiết kế của dự án.
c) Không nên áp đặt thêm ràng buộc lên phần mềm. Những điều này được quy định chính xác trong các tài liệu khác
các tài liệu như kế hoạch đảm bảo chất lượng phần mềm.
Do đó, SRS được viết đúng cách sẽ giới hạn phạm vi của các thiết kế hợp lệ nhưng không chỉ rõ bất kỳ thiết kế cụ thể
nào.
4.3 Đặc điểm của một SRS tốt
Một SRS nên được
a) Đúng; b) Rõ
ràng; c) Hoàn thiện;

d) Nhất quán; e)
Xếp hạng về tầm
quan trọng và/hoặc tính ổn định; f)

Có thể kiểm
chứng; g) Có thể sửa đổi
được; h) Có thể truy nguyên.
4.3.1 Đúng
SRS đúng khi và chỉ khi mọi yêu cầu được nêu trong đó là yêu cầu mà phần mềm phải đáp ứng.
Không có công cụ hoặc thủ tục nào đảm bảo tính chính xác. SRS phải được so sánh với bất kỳ thông số kỹ thuật cao cấp
hiện hành nào, chẳng hạn như thông số kỹ thuật yêu cầu hệ thống, với tài liệu dự án khác và với các tiêu chuẩn hiện
hành khác, để đảm bảo rằng nó phù hợp. Ngoài ra, khách hàng hoặc người dùng có thể xác định xem SRS có phản ánh
chính xác nhu cầu thực tế hay không. Khả năng truy tìm nguồn gốc làm cho quy trình này dễ dàng hơn và ít xảy ra lỗi
hơn (xem 4.3.8).
4.3.2 Rõ ràng
SRS là rõ ràng khi và chỉ khi mọi yêu cầu được nêu trong đó chỉ có một cách giải thích. Ở mức tối thiểu, điều này
đòi hỏi mỗi đặc tính của sản phẩm cuối cùng phải được mô tả bằng một thuật ngữ duy nhất.
4
IEEE
Trong trường hợp một thuật ngữ được sử dụng trong một ngữ cảnh cụ thể có thể có nhiều nghĩa thì nên đưa thuật ngữ đó vào
trong một bảng thuật ngữ nơi ý nghĩa của nó được thực hiện cụ thể hơn.
SRS là một phần quan trọng của quy trình yêu cầu trong vòng đời phần mềm và được sử dụng trong thiết kế,
thực hiện, giám sát dự án, xác minh và xác nhận cũng như đào tạo như được mô tả trong IEEE Std
1074-1997. SRS phải rõ ràng đối với cả những người tạo ra nó và những người sử dụng nó. Tuy nhiên,
những nhóm này thường không có nền tảng giống nhau và do đó không có xu hướng mô tả các yêu cầu phần mềm theo cùng một
cách. Các biểu diễn nhằm cải thiện đặc tả yêu cầu cho nhà phát triển có thể
phản tác dụng ở chỗ chúng làm giảm sự hiểu biết của người dùng và ngược lại.
Các điều khoản từ 4.3.2.1 đến 4.3.2.3 khuyến nghị cách tránh sự mơ hồ.
4.3.2.1 Cạm bẫy ngôn ngữ tự nhiên
Yêu cầu thường được viết bằng ngôn ngữ tự nhiên (ví dụ: tiếng Anh). Ngôn ngữ tự nhiên vốn đã mơ hồ. SRS ngôn ngữ tự
nhiên cần được xem xét bởi một bên độc lập để xác định việc sử dụng mơ hồ của
ngôn ngữ để có thể sửa chữa được.
4.3.2.2 Ngôn ngữ đặc tả yêu cầu
Một cách để tránh sự mơ hồ vốn có trong ngôn ngữ tự nhiên là viết SRS theo một yêu cầu cụ thể.
ngôn ngữ đặc tả. Bộ xử lý ngôn ngữ của nó tự động phát hiện nhiều từ vựng, cú pháp và ngữ nghĩa
lỗi.
Một bất lợi khi sử dụng những ngôn ngữ như vậy là thời gian cần thiết để học chúng. Ngoài ra, nhiều người dùng không
rành về kỹ thuật cũng thấy chúng khó hiểu. Hơn nữa, những ngôn ngữ này có xu hướng thể hiện tốt hơn một số
các loại yêu cầu và giải quyết các loại hệ thống nhất định. Vì vậy, chúng có thể ảnh hưởng đến các yêu cầu trong
những cách tinh tế.
4.3.2.3 Công cụ biểu diễn
Nói chung, các phương pháp, ngôn ngữ yêu cầu và các công cụ hỗ trợ chúng thuộc ba loại chung—đối tượng, quy trình và
hành vi. Các phương pháp tiếp cận hướng đối tượng tổ chức các yêu cầu theo các khía cạnh
các đối tượng trong thế giới thực, các thuộc tính của chúng và các dịch vụ do các đối tượng đó thực hiện. Phương pháp tiếp cận dựa trên quy trình
tổ chức các yêu cầu thành các hệ thống phân cấp chức năng giao tiếp thông qua các luồng dữ liệu. hành vi
Các cách tiếp cận mô tả hành vi bên ngoài của hệ thống dưới dạng một số khái niệm trừu tượng (chẳng hạn như thuộc tính
phép tính), các hàm toán học hoặc máy trạng thái.
Mức độ mà các công cụ và phương pháp đó có thể hữu ích trong việc chuẩn bị SRS phụ thuộc vào quy mô và
sự phức tạp của chương trình. Không có nỗ lực nào được thực hiện ở đây để mô tả hoặc xác nhận bất kỳ công cụ cụ thể nào.
Khi sử dụng bất kỳ phương pháp nào trong số này, tốt nhất nên giữ lại các mô tả bằng ngôn ngữ tự nhiên. Bằng cách đó,
những khách hàng không quen với các ký hiệu vẫn có thể hiểu được SRS.
4.3.3 Hoàn thành
Một SRS hoàn chỉnh khi và chỉ khi nó bao gồm các yếu tố sau:
a) Tất cả các yêu cầu quan trọng, dù liên quan đến chức năng, hiệu suất, các ràng buộc về thiết kế,
thuộc tính hoặc giao diện bên ngoài. Đặc biệt, bất kỳ yêu cầu bên ngoài nào do đặc tả hệ thống áp đặt đều phải
được thừa nhận và xử lý.

IEEE
b) Định nghĩa các phản hồi của phần mềm đối với tất cả các loại dữ liệu đầu vào có thể thực hiện được trong tất cả các loại
tình huống có thể thực hiện được. Lưu ý rằng điều quan trọng là phải chỉ định phản hồi cho cả giá trị đầu vào hợp lệ và
không hợp lệ.
c) Nhãn đầy đủ và tài liệu tham khảo cho tất cả các hình, bảng và sơ đồ trong SRS và định nghĩa của tất cả các thuật ngữ và đơn
vị đo.
4.3.3.1 Sử dụng TBD
Bất kỳ SRS nào sử dụng cụm từ “được xác định” (TBD) đều không phải là SRS hoàn chỉnh. Tuy nhiên, TBD đôi khi cần thiết và phải đi
kèm với
a) Mô tả các tình trạng gây ra TBD (ví dụ: tại sao không biết câu trả lời) để tình huống có thể được giải quyết; b) Mô tả
những gì phải làm để loại
trừ TBD, ai chịu trách nhiệm loại bỏ TBD, và
đến khi nào nó phải được loại bỏ.
4.3.4 Nhất quán
Tính nhất quán đề cập đến tính nhất quán bên trong. Nếu SRS không đồng ý với một số tài liệu cấp cao hơn, chẳng hạn như đặc tả yêu
cầu hệ thống, thì tài liệu đó không chính xác (xem 4.3.1).
4.3.4.1 Tính nhất quán nội bộ
SRS nhất quán nội bộ khi và chỉ khi không có tập hợp con các yêu cầu riêng lẻ nào được mô tả trong đó xung đột.
Ba loại xung đột có thể xảy ra trong SRS như sau:
a) Các đặc điểm cụ thể của các đối tượng trong thế giới thực có thể xung đột. Ví dụ,
1) Định dạng của báo cáo đầu ra có thể được mô tả trong một yêu cầu dưới dạng bảng nhưng trong một yêu cầu khác là
văn bản.
2) Một yêu cầu có thể quy định rằng tất cả các đèn phải có màu xanh trong khi yêu cầu khác có thể quy định rằng tất cả các đèn phải có màu xanh.
sẽ có màu xanh.
b) Có thể có xung đột logic hoặc xung đột tạm thời giữa hai hành động cụ thể. Ví dụ,
1) Một yêu cầu có thể chỉ định rằng chương trình sẽ thêm hai đầu vào và yêu cầu khác có thể chỉ định
rằng chương trình sẽ nhân chúng lên.
2) Một yêu cầu có thể nêu rõ rằng “A” phải luôn tuân theo “B”, trong khi một yêu cầu khác có thể yêu cầu “A”
và B” xảy ra đồng thời.
c) Hai hoặc nhiều yêu cầu có thể mô tả cùng một đối tượng trong thế giới thực nhưng sử dụng các thuật ngữ khác nhau cho đối
tượng đó. Ví dụ: yêu cầu của chương trình về thông tin đầu vào của người dùng có thể được gọi là “lời nhắc” trong một
yêu cầu và “tín hiệu” trong một yêu cầu khác. Việc sử dụng các thuật ngữ và định nghĩa tiêu chuẩn sẽ thúc đẩy tính nhất quán.
4.3.5 Xếp hạng về tầm quan trọng và/hoặc tính ổn định
SRS được xếp hạng về tầm quan trọng và/hoặc tính ổn định nếu mỗi yêu cầu trong đó có một mã định danh để chỉ ra tầm quan trọng
hoặc tính ổn định của yêu cầu cụ thể đó.
Thông thường, tất cả các yêu cầu liên quan đến một sản phẩm phần mềm đều không quan trọng như nhau. Một số yêu cầu có thể cần
thiết, đặc biệt đối với các ứng dụng quan trọng trong cuộc sống, trong khi những yêu cầu khác có thể được mong muốn.

IEEE
Mỗi yêu cầu trong SRS phải được xác định để làm cho những khác biệt này trở nên rõ ràng và rõ ràng. Việc xác định các yêu cầu
theo cách sau sẽ giúp:
a) Yêu cầu khách hàng xem xét cẩn thận hơn từng yêu cầu, điều này thường làm rõ mọi yêu cầu
những giả định ẩn giấu mà họ có thể có.
b) Yêu cầu các nhà phát triển đưa ra quyết định thiết kế chính xác và dành mức độ nỗ lực phù hợp cho các vấn đề khác nhau
các bộ phận khác của sản phẩm phần mềm.
4.3.5.1 Mức độ ổn định
Một phương pháp xác định yêu cầu sử dụng khía cạnh ổn định. Tính ổn định có thể được thể hiện dưới dạng số lượng thay đổi dự
kiến đối với bất kỳ yêu cầu nào dựa trên kinh nghiệm hoặc kiến thức về các sự kiện sắp xảy ra có ảnh hưởng đến tổ chức, các
chức năng và con người được hệ thống phần mềm hỗ trợ.
4.3.5.2 Mức độ cần thiết
Một cách khác để xếp hạng các yêu cầu là phân biệt các loại yêu cầu là thiết yếu, có điều kiện và tùy chọn.
a) Cần thiết. Ngụ ý rằng phần mềm sẽ không được chấp nhận trừ khi những yêu cầu này được cung cấp trong
một cách đã thỏa thuận.
b) Có điều kiện. Ngụ ý rằng đây là những yêu cầu sẽ nâng cao sản phẩm phần mềm nhưng sẽ không thể chấp nhận được nếu thiếu
chúng. c) Tùy chọn. Ngụ ý một lớp chức năng có thể
có hoặc không có giá trị. Điều này mang lại cho nhà cung cấp
cơ hội để đề xuất điều gì đó vượt quá SRS.
4.3.6 Có thể kiểm chứng
SRS có thể kiểm chứng được khi và chỉ khi mọi yêu cầu được nêu trong đó đều có thể kiểm chứng được. Một yêu cầu có thể được
kiểm chứng nếu và chỉ nếu tồn tại một số quy trình hữu hạn về chi phí mà con người hoặc máy móc có thể kiểm tra xem sản phẩm
phần mềm có đáp ứng yêu cầu hay không. Nói chung, bất kỳ yêu cầu mơ hồ nào đều không thể kiểm chứng được.
Các yêu cầu không thể xác minh bao gồm các tuyên bố như “hoạt động tốt”, “giao diện con người tốt” và “thường sẽ xảy ra”. Những
yêu cầu này không thể được xác minh vì không thể xác định các thuật ngữ “tốt”, “tốt” hoặc “thông thường”. Tuyên bố rằng “chương
trình sẽ không bao giờ đi vào vòng lặp vô hạn” là không thể kiểm chứng được vì về mặt lý thuyết, việc kiểm tra chất lượng này
là không thể.
Một ví dụ về một tuyên bố có thể kiểm chứng là
Đầu ra của chương trình sẽ được tạo ra trong vòng 20 giây kể từ sự kiện, chiếm 60% thời gian; và sẽ được
sản xuất trong vòng 30 giây kể từ sự kiện 100% thời gian.
Tuyên bố này có thể được xác minh vì nó sử dụng các thuật ngữ cụ thể và số lượng có thể đo lường được.
Nếu không thể nghĩ ra một phương pháp để xác định xem phần mềm có đáp ứng được một yêu cầu cụ thể hay không thì yêu cầu đó cần
được loại bỏ hoặc sửa đổi.

IEEE
4.3.7 Có thể sửa đổi
SRS có thể được sửa đổi nếu và chỉ khi cấu trúc và kiểu dáng của nó sao cho bất kỳ thay đổi nào đối với các yêu cầu đều có thể
được thực hiện dễ dàng, đầy đủ và nhất quán trong khi vẫn giữ được cấu trúc và kiểu dáng. Khả năng sửa đổi nói chung
yêu cầu SRS để
a) Có một tổ chức mạch lạc và dễ sử dụng với mục lục, chỉ mục và các hướng dẫn chéo rõ ràng.
tham khảo;
b) Không dư thừa (nghĩa là cùng một yêu cầu không được xuất hiện ở nhiều nơi trong SRS);
c) Thể hiện từng yêu cầu một cách riêng biệt, không trộn lẫn với các yêu cầu khác.
Bản thân sự dư thừa không phải là lỗi nhưng nó có thể dễ dàng dẫn đến sai sót. Sự dư thừa đôi khi có thể giúp thực hiện
SRS dễ đọc hơn nhưng vấn đề có thể phát sinh khi tài liệu dư thừa được cập nhật. Ví dụ, một
yêu cầu có thể được thay đổi chỉ ở một trong những nơi nó xuất hiện. SRS sau đó trở nên không nhất quán.
Bất cứ khi nào cần có sự dư thừa, SRS nên bao gồm các tham chiếu chéo rõ ràng để làm cho nó có thể sửa đổi được.
4.3.8 Có thể truy nguyên
SRS có thể truy nguyên được nếu nguồn gốc của từng yêu cầu của nó rõ ràng và nếu nó tạo điều kiện thuận lợi cho việc tham chiếu các yêu cầu của nó.
từng yêu cầu trong tài liệu phát triển hoặc nâng cao trong tương lai. Hai loại khả năng theo dõi sau đây được khuyến nghị:
a) Truy xuất nguồn gốc ngược (tức là tới các giai đoạn phát triển trước đó). Điều này tùy thuộc vào từng yêu cầu
tham chiếu rõ ràng nguồn của nó trong các tài liệu trước đó.
b) Truy xuất nguồn gốc chuyển tiếp (tức là tới tất cả các tài liệu do SRS tạo ra). Điều này tùy thuộc vào từng yêu cầu
trong SRS có tên hoặc số tham chiếu duy nhất.
Khả năng truy xuất nguồn gốc phía trước của SRS đặc biệt quan trọng khi sản phẩm phần mềm đi vào hoạt động
và giai đoạn bảo trì. Khi các tài liệu mã và thiết kế được sửa đổi, điều cần thiết là có thể xác định được
bộ đầy đủ các yêu cầu có thể bị ảnh hưởng bởi những sửa đổi đó.
4.4 Cùng chuẩn bị SRS
Quá trình phát triển phần mềm nên bắt đầu bằng sự thỏa thuận giữa nhà cung cấp và khách hàng về những gì
phần mềm hoàn chỉnh phải làm. Thỏa thuận này, dưới hình thức SRS, cần được cùng nhau chuẩn bị. Đây là
quan trọng vì thông thường cả khách hàng lẫn nhà cung cấp đều không đủ khả năng để viết một SRS tốt một mình.
a) Khách hàng thường không hiểu đủ rõ về quy trình thiết kế và phát triển phần mềm để
viết một SRS có thể sử dụng được.
b) Các nhà cung cấp thường không hiểu đủ rõ vấn đề và lĩnh vực nỗ lực của khách hàng để
xác định các yêu cầu cho một hệ thống thỏa đáng.
Vì vậy, khách hàng và nhà cung cấp nên làm việc cùng nhau để tạo ra một văn bản tốt và đầy đủ.
hiểu SRS.
Một tình huống đặc biệt tồn tại khi một hệ thống và phần mềm của nó đều được xác định đồng thời. Sau đó, chức năng, giao
diện, hiệu suất, các thuộc tính và ràng buộc khác của phần mềm không được xác định trước mà
đúng hơn là được cùng xác định và có thể được đàm phán và thay đổi. Điều này gây khó khăn hơn nhưng không kém phần
quan trọng, phải đáp ứng các đặc điểm nêu ở 4.3. Đặc biệt, một SRS không tuân thủ các
yêu cầu đặc tả hệ thống gốc của nó là không chính xác.
số 8
IEEE
Cách thực hành được đề xuất này không thảo luận cụ thể về phong cách, cách sử dụng ngôn ngữ hoặc kỹ thuật viết hay. Tuy
nhiên, điều khá quan trọng là SRS phải được viết tốt. Sách viết kỹ thuật chung có thể được sử dụng để hướng dẫn.
4.5 Sự phát triển của SRS
SRS có thể cần phải phát triển khi quá trình phát triển sản phẩm phần mềm tiến triển. Có thể không thể chỉ định một số
chi tiết tại thời điểm dự án được bắt đầu (ví dụ: có thể không thể xác định tất cả các định dạng màn hình cho một chương
trình tương tác trong giai đoạn yêu cầu). Những thay đổi bổ sung có thể xảy ra sau đó khi phát hiện ra những thiếu sót,
thiếu sót và thiếu chính xác trong SRS.
Hai cân nhắc chính trong quá trình này là:
a) Các yêu cầu cần được xác định một cách đầy đủ và kỹ lưỡng như đã biết vào thời điểm đó, ngay cả khi những sửa đổi
về mặt tiến hóa có thể được dự đoán trước là không thể tránh khỏi. Thực tế là chúng không đầy đủ cần được lưu ý.
b) Cần bắt đầu một quy trình thay đổi chính thức để xác định, kiểm soát, theo dõi và báo cáo những thay đổi dự kiến.
Những thay đổi đã được phê duyệt trong các yêu cầu phải được đưa vào SRS theo cách 1) Cung cấp bản
kiểm tra chính xác và đầy đủ về các thay đổi; 2) Cho phép xem xét
các phần hiện tại và thay thế của SRS.
4.6 Tạo nguyên mẫu
Tạo mẫu được sử dụng thường xuyên trong phần yêu cầu của dự án. Hiện có nhiều công cụ cho phép tạo ra một nguyên mẫu thể
hiện một số đặc điểm của hệ thống rất nhanh chóng và dễ dàng. Xem thêm ASTM E1340-96.
Nguyên mẫu rất hữu ích vì những lý do sau:
a) Khách hàng có thể có nhiều khả năng xem nguyên mẫu và phản ứng với nó hơn là đọc SRS và phản ứng
đến nó. Vì vậy, nguyên mẫu cung cấp phản hồi nhanh chóng.
b) Nguyên mẫu hiển thị các khía cạnh không lường trước được của hành vi hệ thống. Vì vậy, nó không chỉ tạo ra
câu trả lời nhưng cũng có những câu hỏi mới. Điều này giúp đạt được kết thúc trên SRS.
c) SRS dựa trên nguyên mẫu có xu hướng ít thay đổi hơn trong quá trình phát triển, do đó rút ngắn thời gian
thời gian phát triển.
Một nguyên mẫu nên được sử dụng như một cách để khơi gợi các yêu cầu phần mềm. Một số đặc điểm như định dạng màn hình
hoặc báo cáo có thể được trích xuất trực tiếp từ nguyên mẫu. Các yêu cầu khác có thể được suy ra bằng cách chạy thử nghiệm
với nguyên mẫu.
4.7 Thiết kế nhúng trong SRS
Một yêu cầu chỉ rõ chức năng hoặc thuộc tính có thể nhìn thấy bên ngoài của hệ thống. Một thiết kế mô tả một thành phần
phụ cụ thể của một hệ thống và/hoặc các giao diện của nó với các thành phần phụ khác. (Những) người viết SRS nên phân biệt
rõ ràng giữa việc xác định các ràng buộc thiết kế cần thiết và việc đưa ra một thiết kế cụ thể. Lưu ý rằng mọi yêu cầu
trong SRS đều giới hạn các phương án thiết kế. Tuy nhiên, điều này không có nghĩa là mọi yêu cầu đều là thiết kế.
9
IEEE
SRS phải chỉ rõ những chức năng nào sẽ được thực hiện trên dữ liệu nào để tạo ra kết quả nào ở vị trí nào cho ai. SRS
nên tập trung vào các dịch vụ sẽ được thực hiện. SRS thường không nên chỉ định các hạng mục thiết kế như sau:
a) Phân chia phần mềm thành các module; b) Phân
bổ chức năng cho các module; c) Mô tả luồng
thông tin hoặc điều khiển giữa các module; d) Lựa chọn cấu trúc dữ liệu.
4.7.1 Yêu cầu thiết kế cần thiết
Trong những trường hợp đặc biệt, một số yêu cầu có thể hạn chế nghiêm ngặt việc thiết kế. Ví dụ, các yêu cầu về an ninh
hoặc an toàn có thể phản ánh trực tiếp vào thiết kế như nhu cầu
a) Giữ một số chức năng nhất định trong các mô-đun
riêng biệt; b) Chỉ cho phép liên lạc hạn chế giữa một số khu vực của chương trình; c)
Kiểm tra tính toàn vẹn dữ liệu cho các biến quan trọng.
Ví dụ về các ràng buộc thiết kế hợp lệ là các yêu cầu vật lý, yêu cầu hiệu suất, tiêu chuẩn phát triển phần mềm và tiêu
chuẩn đảm bảo chất lượng phần mềm.
Vì vậy, các yêu cầu cần được nêu ra từ quan điểm hoàn toàn bên ngoài. Khi sử dụng mô hình để minh họa các yêu cầu, hãy
nhớ rằng mô hình chỉ biểu thị hành vi bên ngoài chứ không chỉ định thiết kế.
4.8 Nhúng các yêu cầu của dự án vào SRS
SRS phải đề cập đến sản phẩm phần mềm chứ không phải quy trình sản xuất sản phẩm phần mềm.
Các yêu cầu của dự án thể hiện sự hiểu biết giữa khách hàng và nhà cung cấp về các vấn đề hợp đồng liên quan đến sản
xuất phần mềm và do đó không nên đưa vào SRS. Chúng thường bao gồm các mục như
một khoản
chi phí; b) Lịch giao hàng;
c) Thủ tục báo cáo; d) Phương
pháp phát triển phần mềm; đ) Bảo đảm chất
lượng; f) Tiêu chí xác

nhận và xác minh; g) Thủ tục nghiệm thu.
Yêu cầu của dự án được quy định trong các tài liệu khác, thường là trong kế hoạch phát triển phần mềm, kế hoạch đảm bảo
chất lượng phần mềm hoặc tuyên bố công việc.
5. Các bộ phận của SRS
Điều khoản này thảo luận về từng phần thiết yếu của SRS. Các phần này được sắp xếp trong Hình 1 dưới dạng phác thảo có
thể dùng làm ví dụ để viết SRS.
Mặc dù SRS không nhất thiết phải tuân theo phác thảo này hoặc sử dụng tên được nêu ở đây cho các bộ phận của nó, nhưng một
SRS tốt phải bao gồm tất cả thông tin được thảo luận ở đây.
10
IEEE
Mục lục
1. Giới thiệu
1.1 Mục đích
1.2 Phạm
vi 1.3 Định nghĩa, từ viết tắt và chữ viết tắt

1.4 Tài liệu tham khảo
1.5 Tổng quan
2. Mô tả tổng thể
2.1 Quan điểm sản phẩm

2.2 Chức năng sản phẩm
2.3 Đặc điểm người dùng
2.4 Ràng buộc
2.5 Các giả định và sự phụ thuộc 3.
Yêu cầu cụ thể (Xem 5.3.1 đến 5.3.8 để biết giải thích về các khả năng có thể xảy ra)
yêu cầu cụ thể. Xem thêm Phụ lục A để biết một số cách tổ chức khác nhau của phần
này của SRS.)
Phụ lục
Mục lục
Hình 1 – Sơ đồ nguyên mẫu SRS
5.1 Giới thiệu (Phần 1 của SRS)
Việc giới thiệu SRS sẽ cung cấp cái nhìn tổng quan về toàn bộ SRS. Nó nên chứa các phần phụ sau:
một mục đích;

b) Phạm vi;
c) Định nghĩa, từ viết tắt, từ viết tắt; d)
Tài liệu tham
khảo; e) Tổng quan.
5.1.1 Mục đích (1.1 của SRS)
Tiểu mục này nên
a) Phân định mục đích của SRS; b) Chỉ

định đối tượng dự kiến cho SRS.
5.1.2 Phạm vi (1.2 của SRS)
a) Xác định (các) sản phẩm phần mềm sẽ được sản xuất theo tên (ví dụ: Host DBMS, Trình tạo báo cáo,
v.v.); b) Giải thích (các) sản phẩm phần mềm sẽ làm gì và nếu cần sẽ không
làm gì; c) Mô tả ứng dụng của phần mềm được quy định, bao gồm các lợi ích, mục tiêu và
bàn thắng;
d) Nhất quán với các tuyên bố tương tự trong các đặc tả cấp cao hơn (ví dụ: đặc tả yêu cầu hệ thống),
nếu chúng tồn tại.

IEEE
5.1.3 Định nghĩa, từ viết tắt và từ viết tắt (1.3 của SRS)
Tiểu mục này sẽ cung cấp định nghĩa của tất cả các thuật ngữ, từ viết tắt và chữ viết tắt cần thiết để diễn giải SRS
một cách chính xác. Thông tin này có thể được cung cấp bằng cách tham khảo một hoặc nhiều phụ lục trong SRS hoặc
bằng cách tham khảo các tài liệu khác.
5.1.4 Tài liệu tham khảo (1.4 của SRS)
a) Cung cấp danh sách đầy đủ tất cả các tài liệu được tham chiếu ở nơi khác trong
SRS; b) Xác định từng tài liệu theo tiêu đề, số báo cáo (nếu có), ngày tháng, tổ chức xuất bản; c) Chỉ
định các nguồn mà từ đó có thể lấy được các tài liệu tham khảo.
Thông tin này có thể được cung cấp bằng cách tham khảo một phụ lục hoặc một tài liệu khác.
5.1.5 Tổng quan (1.5 của SRS)
a) Mô tả phần còn lại của SRS chứa đựng những gì;

b) Giải thích cách tổ chức SRS.
5.2 Mô tả tổng thể (Phần 2 của SRS)
Phần này của SRS phải mô tả các yếu tố chung ảnh hưởng đến sản phẩm và các yêu cầu của nó. Phần này không nêu
yêu cầu cụ thể. Thay vào đó, nó cung cấp nền tảng cho các yêu cầu đó, được xác định chi tiết trong Phần 3 của
SRS và làm cho chúng dễ hiểu hơn.
Phần này thường bao gồm sáu phần nhỏ như sau:
a) Phối cảnh sản phẩm; b)

Chức năng của sản phẩm;
c) Đặc điểm người dùng; d)
Những hạn chế; e)
Các giả định và sự phụ thuộc; f) Phân
bổ yêu cầu.
5.2.1 Quan điểm sản phẩm (2.1 của SRS)
Tiểu mục này của SRS sẽ đưa sản phẩm này vào mối quan hệ với các sản phẩm liên quan khác. Nếu sản phẩm độc lập
và hoàn toàn khép kín thì ở đây phải nêu rõ như vậy. Nếu SRS xác định một sản phẩm là thành phần của một hệ
thống lớn hơn, như thường lệ xảy ra, thì tiểu mục này sẽ liên hệ các yêu cầu của hệ thống lớn hơn đó với chức
năng của phần mềm và phải xác định các giao diện giữa hệ thống đó và phần mềm.
Sơ đồ khối thể hiện các thành phần chính của hệ thống lớn hơn, các kết nối liên kết và các giao diện bên ngoài
có thể hữu ích.

IEEE
Tiểu mục này cũng sẽ mô tả cách phần mềm hoạt động bên trong các ràng buộc khác nhau. Ví dụ: những hạn chế này có thể bao
gồm
a) Giao diện hệ thống; b)

Giao diện người dùng;
c) Giao diện phần cứng; d)
Giao diện phần mềm; e) Giao
diện truyền thông; f) Trí nhớ; g)
Hoạt động; h)
Yêu cầu thích ứng
địa điểm.
5.2.1.1 Giao diện hệ thống
Điều này sẽ liệt kê từng giao diện hệ thống và xác định chức năng của phần mềm để đáp ứng yêu cầu hệ thống và mô tả giao
diện phù hợp với hệ thống.
5.2.1.2 Giao diện người dùng
Điều này cần chỉ định những điều sau:
a) Đặc điểm logic của từng giao diện giữa sản phẩm phần mềm và người dùng. Điều này bao gồm các đặc điểm cấu hình đó
(ví dụ: định dạng màn hình bắt buộc, bố cục trang hoặc cửa sổ, nội dung của bất kỳ báo cáo hoặc menu nào hoặc
tính khả dụng của các phím chức năng có thể lập trình) cần thiết để đáp ứng các yêu cầu phần mềm.
b) Tất cả các khía cạnh tối ưu hóa giao diện với người phải sử dụng hệ thống. Điều này có thể chỉ đơn giản bao gồm một
danh sách những việc nên làm và không nên làm về cách hệ thống sẽ hiển thị với người dùng. Một ví dụ có thể là
yêu cầu về tùy chọn thông báo lỗi dài hoặc ngắn. Giống như tất cả những yêu cầu khác, những yêu cầu này phải
được kiểm chứng, ví dụ: “nhân viên đánh máy cấp 4 có thể thực hiện chức năng X trong Z phút sau 1 giờ đào tạo”
thay vì “nhân viên đánh máy có thể thực hiện chức năng X”. (Điều này cũng có thể được chỉ định trong Thuộc tính
hệ thống phần mềm trong phần có tiêu đề Dễ sử dụng.)
5.2.1.3 Giao diện phần cứng
Điều này cần xác định các đặc tính logic của từng giao diện giữa sản phẩm phần mềm và các thành phần phần cứng của hệ
thống. Điều này bao gồm các đặc điểm cấu hình (số lượng cổng, bộ hướng dẫn, v.v.). Nó cũng bao gồm các vấn đề như thiết
bị nào sẽ được hỗ trợ, chúng được hỗ trợ như thế nào và các giao thức. Ví dụ: hỗ trợ thiết bị đầu cuối có thể chỉ định
hỗ trợ toàn màn hình thay vì hỗ trợ từng dòng.
5.2.1.4 Giao diện phần mềm
Điều này sẽ chỉ định việc sử dụng các sản phẩm phần mềm cần thiết khác (ví dụ: hệ thống quản lý dữ liệu, hệ điều hành
hoặc gói toán học) và giao diện với các hệ thống ứng dụng khác (ví dụ: mối liên kết giữa hệ thống tài khoản phải thu và
sổ cái chung hệ thống). Đối với mỗi sản phẩm phần mềm cần thiết phải cung cấp các thông tin sau:
- Tên; - Ghi
nhớ; - Mã số quy
cách; - Số phiên bản; - Nguồn.
13
IEEE
Đối với mỗi giao diện, cần cung cấp những thông tin sau:
— Thảo luận về mục đích của phần mềm giao tiếp liên quan đến sản phẩm phần mềm này.
- Định nghĩa giao diện về nội dung và định dạng tin nhắn. Không cần thiết phải nêu chi tiết bất kỳ giao diện nào được
ghi chép đầy đủ nhưng cần phải tham chiếu đến tài liệu xác định giao diện.
5.2.1.5 Giao diện truyền thông
Điều này sẽ chỉ định các giao diện khác nhau để liên lạc như các giao thức mạng cục bộ, v.v.
5.2.1.6 Hạn chế về bộ nhớ
Điều này sẽ chỉ định mọi đặc điểm và giới hạn áp dụng đối với bộ nhớ chính và phụ.
5.2.1.7 Vận hành
Điều này sẽ chỉ định các hoạt động bình thường và đặc biệt theo yêu cầu của người dùng, chẳng hạn như
a) Các phương thức hoạt động khác nhau trong tổ chức người dùng (ví dụ: các hoạt động do người dùng khởi
tạo); b) Thời gian hoạt động tương tác và thời gian hoạt động không có người giám sát;
c) Chức năng hỗ trợ xử lý dữ liệu; d) Hoạt
động sao lưu và phục hồi.
LƯU Ý—Điều này đôi khi được chỉ định như một phần của phần Giao diện người dùng.
5.2.1.8 Yêu cầu thích ứng trang web
Cái này nên
a) Xác định các yêu cầu đối với bất kỳ dữ liệu hoặc trình tự khởi tạo nào dành riêng cho một địa điểm nhất định,
nhiệm vụ hoặc chế độ vận hành (ví dụ: giá trị lưới, giới hạn an toàn, v.v.);
b) Chỉ định địa điểm hoặc các tính năng liên quan đến nhiệm vụ cần được sửa đổi để điều chỉnh phần mềm phù hợp với một phần
cài đặt ular.
5.2.2 Chức năng sản phẩm (2.2 của SRS)
Tiểu mục này của SRS sẽ cung cấp bản tóm tắt các chức năng chính mà phần mềm sẽ thực hiện.
Ví dụ: SRS cho chương trình kế toán có thể sử dụng phần này để giải quyết vấn đề bảo trì tài khoản khách hàng, báo cáo
khách hàng và chuẩn bị hóa đơn mà không đề cập đến lượng chi tiết khổng lồ mà mỗi chức năng đó yêu cầu.
Đôi khi, bản tóm tắt chức năng cần thiết cho phần này có thể được lấy trực tiếp từ phần đặc tả cấp cao hơn (nếu có) phân
bổ các chức năng cụ thể cho sản phẩm phần mềm. Lưu ý rằng để rõ ràng
a) Các chức năng phải được tổ chức theo cách làm cho danh sách các chức năng có thể hiểu được đối với
khách hàng hoặc bất kỳ ai khác đọc tài liệu lần đầu tiên.
b) Các phương pháp văn bản hoặc đồ họa có thể được sử dụng để thể hiện các chức năng khác nhau và mối quan hệ của chúng.
Sơ đồ như vậy không nhằm mục đích thể hiện thiết kế của sản phẩm mà chỉ đơn giản thể hiện mối quan hệ logic giữa
các biến số.

IEEE
5.2.3 Đặc điểm người dùng (2.3 của SRS)
Tiểu mục này của SRS phải mô tả các đặc điểm chung đó của người dùng dự định của sản phẩm bao gồm trình độ
học vấn, kinh nghiệm và chuyên môn kỹ thuật. Nó không nên được sử dụng để nêu các yêu cầu cụ thể mà nên cung
cấp lý do tại sao các yêu cầu cụ thể sau đó lại được quy định trong Phần 3 của SRS.
5.2.4 Các ràng buộc (2.4 của SRS)
Tiểu mục này của SRS sẽ cung cấp mô tả chung về bất kỳ mục nào khác sẽ hạn chế các lựa chọn của nhà phát
triển. Bao gồm các
a) Chính sách pháp luật;

b) Hạn chế về phần cứng (ví dụ: yêu cầu về thời gian tín
hiệu); c) Giao diện với các ứng dụng
khác; d) Hoạt động song
song; e) Chức năng
kiểm toán; f) Chức năng
điều khiển; g) Yêu cầu về ngôn ngữ bậc
cao; h) Các giao thức bắt tay tín hiệu (ví dụ XON-XOFF, ACK-NACK);
Tôi) Yêu cầu về độ tin cậy; j)
Mức độ quan trọng của ứng
dụng; k) Các cân nhắc về an toàn và an ninh.
5.2.5 Giả định và phụ thuộc (2.5 của SRS)
Tiểu mục này của SRS sẽ liệt kê từng yếu tố ảnh hưởng đến các yêu cầu được nêu trong SRS.
Những yếu tố này không phải là những hạn chế về thiết kế trên phần mềm mà là bất kỳ thay đổi nào đối với
chúng có thể ảnh hưởng đến các yêu cầu trong SRS. Ví dụ: giả định có thể là một hệ điều hành cụ thể sẽ có
sẵn trên phần cứng được chỉ định cho sản phẩm phần mềm. Trên thực tế, nếu hệ điều hành không có sẵn thì SRS
sẽ phải thay đổi tương ứng.
5.2.6 Phân bổ các yêu cầu (2.6 của SRS)
Tiểu mục này của SRS sẽ xác định các yêu cầu có thể bị trì hoãn cho đến các phiên bản tương lai của hệ thống.
5.3 Yêu cầu cụ thể (Phần 3 của SRS)
Phần này của SRS phải chứa tất cả các yêu cầu phần mềm ở mức độ chi tiết đủ để cho phép các nhà thiết kế
thiết kế một hệ thống đáp ứng các yêu cầu đó và những người kiểm tra có thể kiểm tra xem hệ thống có đáp ứng
các yêu cầu đó hay không. Trong suốt phần này, mọi yêu cầu đã nêu phải được người dùng, người vận hành hoặc
các hệ thống bên ngoài khác có thể nhận biết được từ bên ngoài. Các yêu cầu này tối thiểu phải bao gồm mô tả
về mọi đầu vào (kích thích) vào hệ thống, mọi đầu ra (phản hồi) từ hệ thống và tất cả các chức năng được hệ
thống thực hiện để đáp ứng với đầu vào hoặc hỗ trợ đầu ra. Vì đây thường là phần lớn nhất và quan trọng nhất
của SRS nên áp dụng các nguyên tắc sau:
a) Các yêu cầu cụ thể cần được nêu phù hợp với tất cả các đặc tính được mô tả ở 4.3. b) Các yêu cầu cụ
thể cần được tham chiếu chéo tới các tài liệu liên quan trước đó. c) Tất cả các yêu cầu
phải được nhận dạng duy nhất. d) Cần chú ý cẩn thận
đến việc sắp xếp các yêu cầu để tối đa hóa khả năng đọc.
15
IEEE
Trước khi xem xét các cách tổ chức yêu cầu cụ thể, cần hiểu rõ các mục khác nhau bao gồm các yêu cầu như
được mô tả từ 5.3.1 đến 5.3.7.
5.3.1 Giao diện bên ngoài
Đây phải là mô tả chi tiết về tất cả đầu vào và đầu ra của hệ thống phần mềm. Nó phải bổ sung cho các mô tả
giao diện trong 5.2 và không nên lặp lại thông tin ở đó.
Nó phải bao gồm cả nội dung và định dạng như sau:
a) Tên hạng mục; b)

Mô tả mục đích; c) Nguồn đầu
vào hoặc đích đầu ra; d) Phạm vi, độ chính
xác và/hoặc dung sai hợp lệ; e) Đơn vị đo; f)
Thời gian; g) Mối quan
hệ với các
đầu vào/đầu ra khác; h) Hình thức/tổ chức
màn hình; i) Các định dạng/tổ chức
cửa sổ; j) Định dạng dữ liệu; k)
Dạng lệnh; l) Kết
thúc tin nhắn.
5.3.2 Chức năng
Các yêu cầu chức năng cần xác định các hành động cơ bản phải diễn ra trong phần mềm trong việc chấp nhận và
xử lý đầu vào cũng như trong quá trình xử lý và tạo ra đầu ra. Chúng thường được liệt kê dưới dạng câu lệnh
“phải” bắt đầu bằng “Hệ thống sẽ…”
Bao gồm các
a) Kiểm tra tính hợp lệ của đầu vào

b) Trình tự chính xác của các hoạt
động c) Ứng phó với các tình huống bất thường, bao gồm
1) Tràn
2) Cơ sở thông tin liên lạc
3) Xử lý và phục hồi lỗi d) Ảnh
hưởng của các tham số e)
Mối quan hệ giữa đầu ra và đầu vào, bao gồm
1) Trình tự đầu vào/đầu ra
2) Công thức chuyển đổi đầu vào thành đầu ra
Có thể thích hợp để phân chia các yêu cầu chức năng thành các chức năng con hoặc quy trình con. Điều này
không có nghĩa là thiết kế phần mềm cũng sẽ được phân vùng theo cách đó.
5.3.3 Yêu cầu về hiệu suất
Tiểu mục này cần chỉ rõ cả các yêu cầu số tĩnh và động được đặt trên phần mềm hoặc về sự tương tác của con
người với toàn bộ phần mềm. Các yêu cầu về số tĩnh có thể bao gồm:
a) Số lượng thiết bị đầu cuối được hỗ trợ; b)

Số lượng người dùng đồng thời được hỗ trợ; c) Số lượng
và loại thông tin cần xử lý.
16
IEEE
Các yêu cầu số tĩnh đôi khi được xác định trong một phần riêng có tiêu đề Năng lực.
Ví dụ: các yêu cầu số động có thể bao gồm số lượng giao dịch và nhiệm vụ cũng như lượng dữ liệu cần xử lý trong
khoảng thời gian nhất định cho cả điều kiện khối lượng công việc bình thường và cao điểm.
Tất cả những yêu cầu này phải được nêu dưới dạng có thể đo lường được.
Ví dụ,
95% giao dịch sẽ được xử lý trong vòng chưa đầy 1 giây.
còn hơn là,
Nhà điều hành sẽ không phải đợi giao dịch hoàn tất.
CHÚ THÍCH: Các giới hạn bằng số áp dụng cho một chức năng cụ thể thường được quy định như một phần của mô tả tiểu
đoạn xử lý của chức năng đó.
5.3.4 Yêu cầu về cơ sở dữ liệu logic
Điều này sẽ chỉ định các yêu cầu logic đối với bất kỳ thông tin nào sẽ được đưa vào cơ sở dữ liệu. Điều này có
thể bao gồm những điều sau đây:
a) Các loại thông tin được sử dụng bởi các chức năng
khác nhau; b) Tần suất
sử dụng; c) Khả năng tiếp
cận; d) Các thực thể dữ liệu và mối quan hệ
của chúng; e) Ràng buộc
toàn vẹn; f) Yêu cầu lưu giữ dữ liệu.
5.3.5 Hạn chế về thiết kế
Điều này sẽ chỉ rõ các ràng buộc về thiết kế có thể bị áp đặt bởi các tiêu chuẩn khác, các giới hạn phần cứng, v.v.
5.3.5.1 Tuân thủ tiêu chuẩn
Tiểu mục này cần nêu rõ các yêu cầu bắt nguồn từ các tiêu chuẩn hoặc quy định hiện hành. Chúng có thể bao gồm
những điều sau đây:
a) Hình thức báo cáo;

b) Đặt tên dữ liệu;
c) Thủ tục kế toán; d) Theo
dõi kiểm toán.
Ví dụ: điều này có thể chỉ định yêu cầu đối với phần mềm để theo dõi hoạt động xử lý. Những dấu vết như vậy là cần
thiết để một số ứng dụng đáp ứng các tiêu chuẩn tài chính hoặc quy định tối thiểu. Ví dụ: yêu cầu theo dõi kiểm toán
có thể nêu rõ rằng tất cả các thay đổi đối với cơ sở dữ liệu bảng lương phải được ghi lại trong tệp theo dõi với các
giá trị trước và sau.
5.3.6 Thuộc tính hệ thống phần mềm
Có một số thuộc tính của phần mềm có thể dùng làm yêu cầu. Điều quan trọng là các thuộc tính bắt buộc phải được
chỉ định để thành tích của chúng có thể được xác minh một cách khách quan. Các điều khoản từ 5.3.6.1 đến 5.3.6.5
cung cấp một phần danh sách các ví dụ.
17
IEEE
5.3.6.1 Độ tin cậy
Điều này cần chỉ rõ các yếu tố cần thiết để thiết lập độ tin cậy cần thiết của hệ thống phần mềm tại thời điểm chuyển
giao.
5.3.6.2 Tính sẵn có
Điều này sẽ chỉ định các yếu tố cần thiết để đảm bảo mức độ sẵn sàng được xác định cho toàn bộ hệ thống như điểm kiểm
tra, khôi phục và khởi động lại.
5.3.6.3 Bảo mật
Điều này phải chỉ rõ các yếu tố bảo vệ phần mềm khỏi việc truy cập, sử dụng, sửa đổi, phá hủy hoặc tiết lộ một cách
vô tình hoặc có ác ý. Các yêu cầu cụ thể trong lĩnh vực này có thể bao gồm nhu cầu
Sử dụng một số kỹ thuật mã hóa nhất định;

a) b) Lưu giữ các tập dữ liệu nhật ký, lịch sử
cụ thể; c) Gán chức năng nhất định cho các module khác
nhau; d) Hạn chế liên lạc giữa một số khu vực của chương trình; e) Kiểm
tra tính toàn vẹn dữ liệu đối với các biến quan trọng.
5.3.6.4 Khả năng bảo trì
Điều này sẽ chỉ định các thuộc tính của phần mềm liên quan đến việc dễ dàng bảo trì phần mềm. Có thể có một số yêu
cầu về tính mô-đun, giao diện, độ phức tạp nhất định, v.v. Không nên đặt các yêu cầu ở đây chỉ vì chúng được cho là
các phương pháp thiết kế tốt.
5.3.6.5 Tính di động
Điều này sẽ chỉ định các thuộc tính của phần mềm liên quan đến việc dễ dàng chuyển phần mềm sang các máy chủ và/hoặc
hệ điều hành khác. Điều này có thể bao gồm những điều sau đây:
a) Tỷ lệ thành phần có mã phụ thuộc vào máy chủ; b) Tỷ lệ phần

trăm mã phụ thuộc vào máy chủ; c) Sử dụng ngôn ngữ
di động đã được chứng minh; d) Sử dụng một
trình biên dịch hoặc tập hợp con ngôn ngữ cụ thể; e) Sử
dụng một hệ điều hành cụ thể.
5.3.7 Tổ chức các yêu cầu cụ thể
Đối với bất cứ thứ gì ngoại trừ các hệ thống tầm thường, các yêu cầu chi tiết có xu hướng mở rộng. Vì lý do này, nên
cân nhắc cẩn thận để sắp xếp chúng theo cách tối ưu cho sự hiểu biết. Không có một tổ chức tối ưu nào cho tất cả các
hệ thống. Các loại hệ thống khác nhau phù hợp với các tổ chức yêu cầu khác nhau trong Phần 3 của SRS. Một số tổ chức
này được mô tả trong 5.3.7.1 đến 5.3.7.7.
5.3.7.1 Chế độ hệ thống
Một số hệ thống hoạt động khá khác nhau tùy thuộc vào chế độ hoạt động. Ví dụ: một hệ thống điều khiển có thể có các
bộ chức năng khác nhau tùy thuộc vào chế độ của nó: huấn luyện, bình thường hoặc khẩn cấp. Khi tổ chức phần này theo
phương thức nên sử dụng dàn ý ở A.1 hoặc A.2. Sự lựa chọn phụ thuộc vào việc giao diện và hiệu suất có phụ thuộc vào
chế độ hay không.
18
IEEE
5.3.7.2 Lớp người dùng
Một số hệ thống cung cấp các bộ chức năng khác nhau cho các nhóm người dùng khác nhau. Ví dụ, hệ thống điều khiển
thang máy cung cấp các khả năng khác nhau cho hành khách, nhân viên bảo trì và lính cứu hỏa. Khi tổ chức phần này
theo lớp người dùng, nên sử dụng dàn ý trong A.3.
5.3.7.3 Đối tượng
Đối tượng là các thực thể trong thế giới thực có đối tác trong hệ thống. Ví dụ, trong hệ thống theo dõi bệnh nhân,
các đối tượng bao gồm bệnh nhân, cảm biến, y tá, phòng bệnh, bác sĩ, thuốc men, v.v. Gắn liền với mỗi đối tượng là
một tập hợp các thuộc tính (của đối tượng đó) và chức năng (do đối tượng đó thực hiện). Các chức năng này còn được
gọi là dịch vụ, phương pháp hoặc quy trình. Khi tổ chức phần này theo đối tượng, nên sử dụng dàn ý ở A.4. Lưu ý rằng
các tập hợp đối tượng có thể chia sẻ các thuộc tính và dịch vụ. Chúng được nhóm lại với nhau thành các lớp.
5.3.7.4 Tính năng
Tính năng là một dịch vụ được hệ thống mong muốn bên ngoài, có thể yêu cầu một chuỗi đầu vào để đạt được kết quả mong
muốn. Ví dụ: trong hệ thống điện thoại, các tính năng bao gồm cuộc gọi nội hạt, chuyển tiếp cuộc gọi và cuộc gọi hội
nghị. Mỗi đặc điểm thường được mô tả theo một chuỗi các cặp kích thích-phản ứng. Khi tổ chức phần này theo đặc điểm,
nên sử dụng dàn ý ở A.5.
5.3.7.5 Kích thích
Một số hệ thống có thể được tổ chức tốt nhất bằng cách mô tả chức năng của chúng dưới dạng tác nhân kích thích. Ví
dụ, các chức năng của hệ thống hạ cánh máy bay tự động có thể được tổ chức thành các phần dành cho việc mất điện,
cắt gió, thay đổi cuộn đột ngột, vận tốc thẳng đứng quá mức, v.v. Khi tổ chức phần này theo kích thích, hãy phác
thảo trong A.6 nên được sử dụng.
5.3.7.6 Phản hồi
Một số hệ thống có thể được tổ chức tốt nhất bằng cách mô tả tất cả các chức năng hỗ trợ việc tạo ra phản hồi. Ví
dụ: các chức năng của hệ thống nhân sự có thể được tổ chức thành các phần tương ứng với tất cả các chức năng liên
quan đến việc tạo ra tiền lương, tất cả các chức năng liên quan đến việc tạo ra danh sách nhân viên hiện tại, v.v.
Sơ đồ trong A.6 (với tất cả các lần xuất hiện kích thích được thay thế bằng phản ứng) nên được sử dụng.
5.3.7.7 Phân cấp chức năng
Khi không có sơ đồ tổ chức nào ở trên tỏ ra hữu ích thì chức năng tổng thể có thể được tổ chức thành một hệ thống
phân cấp các chức năng được sắp xếp theo đầu vào chung, đầu ra chung hoặc quyền truy cập dữ liệu nội bộ chung. Sơ đồ
luồng dữ liệu và từ điển dữ liệu có thể được sử dụng để hiển thị mối quan hệ giữa và giữa các chức năng và dữ liệu.
Khi tổ chức phần này theo hệ thống phân cấp chức năng, nên sử dụng phác thảo trong A.7.
5.3.8 Nhận xét bổ sung
Bất cứ khi nào dự tính một SRS mới, nhiều kỹ thuật tổ chức nêu trong 5.3.7.7 có thể phù hợp. Trong những trường hợp
như vậy, hãy tổ chức các yêu cầu cụ thể cho nhiều hệ thống phân cấp phù hợp với nhu cầu cụ thể của hệ thống theo đặc
tả. Ví dụ: xem A.8 để biết tổ chức kết hợp lớp người dùng và tính năng. Bất kỳ yêu cầu bổ sung nào có thể được đưa
vào một phần riêng biệt ở cuối SRS.
Có nhiều ký hiệu, phương pháp và công cụ hỗ trợ tự động có sẵn để hỗ trợ việc ghi lại các yêu cầu. Phần lớn, tính hữu
dụng của chúng là chức năng của tổ chức. Ví dụ, khi tổ chức theo phương thức, máy trạng thái hữu hạn hoặc biểu đồ
trạng thái có thể tỏ ra hữu ích; khi tổ chức theo đối tượng, hướng đối tượng

IEEE
phân tích có thể hữu ích; khi tổ chức theo tính năng, trình tự phản ứng kích thích có thể tỏ ra hữu ích;
và khi tổ chức theo hệ thống phân cấp chức năng, sơ đồ luồng dữ liệu và từ điển dữ liệu có thể hữu ích.
Trong bất kỳ phần tóm tắt nào được đưa ra từ A.1 đến A.8, những phần được gọi là “Yêu cầu chức năng i” có thể
được mô tả bằng ngôn ngữ bản địa (ví dụ: tiếng Anh), bằng mã giả, bằng ngôn ngữ định nghĩa hệ thống hoặc
trong bốn phần phụ có tiêu đề: Giới thiệu, Đầu vào, Xử lý và Đầu ra.
5.4 Thông tin hỗ trợ
Thông tin hỗ trợ giúp SRS dễ sử dụng hơn. Nó bao gồm những điều sau đây:
mục lục; b) Mục lục;

c) Phụ lục.
5.4.1 Mục lục và mục lục
Mục lục và chỉ mục khá quan trọng và phải tuân theo các thông lệ chung về bố cục.
5.4.2 Phụ lục
Các phụ lục không phải lúc nào cũng được coi là một phần của SRS thực tế và không phải lúc nào cũng cần thiết. Chúng có
thể bao gồm
a) Mẫu đầu vào/đầu ra, mô tả nghiên cứu phân tích chi phí hoặc kết quả khảo sát người dùng; b)
Thông tin hỗ trợ hoặc thông tin cơ bản có thể giúp ích cho người đọc SRS; c)
Mô tả các vấn đề mà phần mềm cần giải quyết; d) Hướng dẫn đóng
gói đặc biệt đối với mã số và phương tiện để đáp ứng các yêu cầu về bảo mật, xuất khẩu, tải lần đầu
hoặc các yêu cầu khác.
Khi bao gồm các phụ lục, SRS phải nêu rõ liệu các phụ lục có được coi là một phần của yêu cầu hay không.

IEEE
phụ lục A
(nhiều thông tin)
mẫu SRS
A.1 Mẫu SRS Phần 3 được sắp xếp theo chế độ: Phiên bản 1
3. Yêu cầu cụ thể 3.1

Yêu cầu giao diện bên ngoài 3.1.1 Giao
diện người dùng 3.1.2
Giao diện phần cứng 3.1.3
Giao diện phần mềm 3.1.4
Giao diện truyền thông Yêu cầu chức
3.2 năng 3.2.1 Chế độ 1
3.2.1.1 Yêu cầu chức năng 1.1

.
.
.
3.2.1.n Yêu cầu chức năng 1.n 3.2.2

Chế độ 2
.
.
.
3.2.m Chế độ m
3.2.m.1 Yêu cầu chức năng m.1

.
.
.
3.2.mn Yêu cầu chức năng mn Yêu cầu

3,3 về hiệu năng Ràng buộc về
3,4 thiết kế Thuộc
3,5 tính hệ thống phần mềm
3,6 Các yêu cầu khác
A.2 Mẫu SRS Phần 3 được sắp xếp theo chế độ: Phiên bản 2
3. Yêu cầu cụ thể 3.1.

Yêu cầu chức năng 3.1.1 Chế
độ 1 3.1.1.1
Giao diện bên ngoài
3.1.1.1.1 Giao diện
người dùng 3.1.1.1.2 Giao
diện phần cứng 3.1.1.1.3
Giao diện phần mềm 3.1.1.1.4 Giao diện truyền thông
3.1.1.2 Yêu cầu chức năng

3.1.1.2.1 Yêu cầu chức năng 1
.
.
.

IEEE
3.1.1.2.n Yêu cầu chức năng n

3.1.1.3 Hiệu suất
3.1.2 Chế độ 2
Chế độ 3.1.m m
3,2 Hạn chế thiết kế

3,3 Thuộc tính hệ thống phần mềm
3,4 Những yêu cầu khác
A.3 Mẫu SRS Phần 3 được tổ chức theo lớp người dùng
3. Yêu cầu cụ thể

3.1 Yêu cầu về giao diện bên ngoài
3.1.1 Giao diện người dùng

3.1.2 Giao diện phần cứng
3.1.3 Giao diện phần mềm
3.1.4 Giao diện truyền thông
3.2 Yêu cầu chức năng

3.2.1 Người dùng loại 1
3.2.1.1 Yêu cầu chức năng 1.1

.
3.2.1.n Yêu cầu chức năng 1.n

.
3.2.m Lớp người dùng m

.
3.2.mn Yêu cầu chức năng mn

3,3 Các yêu cầu thực hiện
A.4 Mẫu SRS Mục 3 được sắp xếp theo đối tượng


3.2 Lớp/Đối tượng

3.2.1 Lớp/Đối tượng 1

IEEE
3.2.1.1 Thuộc tính (trực tiếp hoặc kế thừa)

3.2.1.1.1 Thuộc tính 1
.
.
.
3.2.1.1.n Thuộc tính n
3.2.1.2 Chức năng (dịch vụ, phương thức, trực tiếp hoặc kế thừa)
3.2.1.2.1 Yêu cầu chức năng 1.1

.
.
.
3.2.1.2.m Yêu cầu chức năng 1.m

3.2.1.3 Tin nhắn (thông tin được nhận hoặc gửi)
3.2.2 Lớp/Đối tượng 2
.
.
.
3.2.p Lớp/Đối tượng p

3,3 Yêu cầu về hiệu suất Ràng
3,4 buộc về thiết kế
3,5 Thuộc tính hệ thống phần
3,6 mềm Các yêu cầu khác
A.5 Mẫu SRS Phần 3 được sắp xếp theo tính năng

Giao diện truyền thông Tính năng hệ
3.2 thống 3.2.1
Tính năng hệ thống 1
3.2.1.1 Giới thiệu/Mục đích của tính
năng 3.2.1.2 Kích thích/Phản hồi
trình tự 3.2.1.3 Yêu cầu chức năng liên
quan 3.2.1.3.1 Yêu cầu chức năng 1
.
.
.
3.2.1.3.n Yêu cầu chức năng n 3.2.2

Tính năng hệ thống 2
.
.
.
3.2.m Tính năng hệ thống m

.
.
.

IEEE
A.6 Mẫu SRS Phần 3 được sắp xếp theo kích thích

3.2 năng 3.2.1 Kích thích 1
3.2.1.1 Yêu cầu
chức năng 1.1

.
.
.
3.2.1.n Yêu cầu chức năng 1.n 3.2.2

Kích thích 2
.
.
.
3,2.m Kích thích m

.
.
.
3.2.mn Yêu cầu chức năng mn Yêu cầu

3,3 về hiệu năng Ràng buộc về
3,4 thiết kế Thuộc
3,5 tính hệ thống phần mềm
3,6 Các yêu cầu khác
A.7 Mẫu SRS Phần 3 được sắp xếp theo cấp bậc chức năng

3.2 năng 3.2.1 Luồng thông
tin 3.2.1.1 Sơ đồ luồng dữ
liệu 1 3.2.1.1.1 Thực thể dữ

liệu 3.2 .1.1.2 Các quy
trình liên quan 3.2.1.1.3 Cấu

trúc liên kết
3.2.1.2 Sơ đồ luồng dữ liệu 2
3.2.1.2.1 Thực thể dữ
liệu 3.2.1.2.2 Các quy trình

liên quan 3.2.1.2.3 Cấu trúc liên kết
.
.
.
3.2.1.n Sơ đồ luồng dữ liệu n

IEEE
3.2.1.n.1 Thực thể dữ liệu
3.2.1.n.2 Các quy trình liên quan
3.2.1.n.3 Cấu trúc liên
kết 3.2.2 Mô tả quy trình 3.2.2.1

Quy trình 1 3.2.2.1.1
Thực thể dữ liệu đầu vào 3.2.2.1.2
Thuật toán hoặc công thức của quy trình 3.2.2.1.3

Các thực thể dữ liệu bị ảnh hưởng
3.2.2.2 Quy trình 2
3.2.2.2.1 Các thực thể dữ liệu
đầu vào 3.2.2.2.2 Thuật toán hoặc công thức của quy
trình 3.2.2.2.3 Các thực thể dữ liệu bị ảnh hưởng
.
.
.
3.2.2.m Quy trình m
3.2.2.m.1 Thực thể dữ liệu đầu
vào 3.2.2.m.2 Thuật toán hoặc công thức của quy

trình 3.2.2.m.3 Thực thể dữ liệu bị ảnh hưởng
3.2.3 Đặc tả cấu trúc dữ liệu 3.2.3.1

Cấu trúc 1 3.2.3.1.1
Loại bản ghi 3.2.3.1.2

Các trường cấu thành 3.2.3.2
Cấu trúc 2 3.2.3.2.1
Loại bản ghi 3.2.3.2.2

Các trường cấu thành
.
.
.
3.2.3.p Xây dựng p

3.2.3.p.1 Loại bản ghi
3.2.3.p.2 Các trường cấu
thành 3.2.4 Từ điển dữ liệu
3.2.4.1 Phần tử dữ liệu 1
3.2.4.1.1 Tên
3.2.4.1.2 Biểu diễn

3.2.4.1.3 Đơn vị/Định
dạng 3.2.4.1.4 Độ chính xác/Độ

chính xác
3.2.4.1.5 Phạm vi 3.2.4.2 Phần tử dữ liệu 2
3.2.4.2.1 Tên
3.2.4.2.2 Biểu diễn

3.2.4.2.3 Đơn vị/Định
dạng 3.2.4.2.4 Độ chính xác/Độ

chính xác 3.2.4.2.5 Phạm vi
.
.
.
3.2.4.q Phần tử dữ liệu

q 3.2.4.q.1 Tên
3.2.4.q.2 Biểu diễn
3.2.4.q.3 Đơn vị/Định
dạng 3.2.4.q.4 Độ chính xác/Độ
chính xác 3.2.4.q. 5 phạm vi
25
IEEE

A.8 Mẫu SRS Phần 3 hiển thị nhiều tổ chức

3.2 Yêu cầu chức năng

3.2.1.1 Tính năng 1.1
3.2.1.1.1 Giới thiệu/Mục đích của tính năng

3.2.1.1.2 Trình tự kích thích/phản hồi
3.2.1.1.3 Yêu cầu chức năng liên quan
3.2.1.2 Tính năng 1.2
3.2.1.2.1 Giới thiệu/Mục đích của tính năng

3.2.1.2.2 Trình tự kích thích/phản hồi
3.2.1.2.3 Yêu cầu chức năng liên quan
.
.
.
3.2.1.m Tính năng 1.m
3.2.1.m.1 Giới thiệu/Mục đích của tính năng

3.2.1.m.2 Trình tự kích thích/phản hồi
3.2.1.m.3 Yêu cầu chức năng liên quan
.
.
.
3.2.n Lớp người dùng n
.
.
.

IEEE
Phụ lục B
(nhiều thông tin)
Hướng dẫn tuân thủ IEEE/EIA 12207.1-1997
B.1 Tổng quan
Ủy ban Tiêu chuẩn Kỹ thuật Phần mềm (SESC) của Hiệp hội Máy tính IEEE đã tán thành chính sách áp dụng các tiêu chuẩn
quốc tế. Năm 1995, tiêu chuẩn quốc tế ISO/IEC 12207, Công nghệ thông tin—Quy trình vòng đời phần mềm đã được hoàn
thành. Tiêu chuẩn này thiết lập một khuôn khổ chung cho các quy trình vòng đời phần mềm, với thuật ngữ được xác định
rõ ràng, có thể được ngành công nghiệp phần mềm tham khảo.
Năm 1995, SESC đã đánh giá ISO/IEC 12207 và quyết định rằng tiêu chuẩn này nên được áp dụng và làm cơ sở cho các quy
trình vòng đời trong Bộ sưu tập Kỹ thuật Phần mềm của IEEE. Phiên bản IEEE của ISO/IEC 12207 là IEEE/EIA 12207.0-1996.
Nó chứa ISO/IEC 12207 và các phần bổ sung sau: phương pháp tuân thủ được cải tiến, mục tiêu quy trình vòng đời, mục
tiêu dữ liệu vòng đời và lỗi.
Việc triển khai ISO/IEC 12207 trong IEEE cũng bao gồm những điều sau:
— IEEE/EIA 12207.1-1997, Hướng dẫn của IEEE/EIA về Công nghệ thông tin—Pro-
ngừng—Dữ liệu vòng đời;
— IEEE/EIA 12207.2-1997, Hướng dẫn của IEEE/EIA về Công nghệ thông tin—Quy trình vòng đời phần mềm—Các cân nhắc
triển khai; Và
— Bổ sung vào 11 tiêu chuẩn SESC (tức là IEEE Stds 730, 828, 829, 830, 1012, 1016, 1058, 1062, 1219, 1233, 1362)
để xác định mối tương quan giữa dữ liệu được tạo ra bởi các tiêu chuẩn SESC hiện tại và dữ liệu được tạo ra
bởi việc áp dụng IEEE/EIA 12207.1-1997.
LƯU Ý—Mặc dù IEEE/EIA 12207.1-1997 là một hướng dẫn nhưng nó cũng có các điều khoản để áp dụng như một tiêu chuẩn
với các yêu cầu tuân thủ cụ thể. Phụ lục này coi 12207.1-1997 là tiêu chuẩn.
B.1.1 Phạm vi và mục đích
Cả IEEE Std 830-1998 và IEEE/EIA 12207.1-1997 đều đặt yêu cầu vào Tài liệu mô tả yêu cầu phần mềm. Mục đích của phụ
lục này là giải thích mối quan hệ giữa hai bộ yêu cầu để người sử dụng tạo ra các tài liệu nhằm tuân thủ cả hai tiêu
chuẩn có thể làm như vậy.
B.2 Mối tương quan
Điều khoản này giải thích mối quan hệ giữa IEEE Std 830-1998 và IEEE/EIA 12207.0-1996 và IEEE/EIA 12207.1-1997 trong
các lĩnh vực sau: thuật ngữ, quy trình và dữ liệu vòng đời.
B.2.1 Tương quan thuật ngữ
Cả thực tiễn được khuyến nghị này và IEEE/EIA 12207.0-1996 đều có ngữ nghĩa tương tự đối với các thuật ngữ chính về
phần mềm, yêu cầu, thông số kỹ thuật, nhà cung cấp, nhà phát triển và nhà bảo trì. Thực hành được đề xuất này sử dụng
27
IEEE
thuật ngữ “khách hàng” trong đó IEEE/EIA 12207.0-1996 sử dụng “bên mua lại” và thông lệ được khuyến nghị này sử dụng
“người dùng” trong đó IEEE/EIA 12207.0-1996 sử dụng “toán tử”.
B.2.2 Tương quan quá trình
IEEE/EIA 12207.0-1996 sử dụng cách tiếp cận theo định hướng quy trình để mô tả định nghĩa về một tập hợp các yêu
cầu đối với phần mềm. Thực tiễn được khuyến nghị này sử dụng cách tiếp cận hướng tới sản phẩm, trong đó sản phẩm là một
Mô tả yêu cầu phần mềm (SRD). Có các bước quy trình tự nhiên, cụ thể là các bước để tạo ra từng bước
phần SRD. Những điều này có thể tương quan với các yêu cầu quy trình của IEEE/EIA 12207.0-1996. Các
điểm khác biệt là phương pháp được khuyến nghị này tập trung vào việc phát triển các yêu cầu phần mềm
trong khi IEEE/EIA 12207.0-1996 cung cấp cái nhìn tổng thể về vòng đời và đề cập đến Yêu cầu phần mềm
Phân tích như một phần của quá trình phát triển của nó. Cách thực hành được khuyến nghị này cung cấp mức độ chi tiết cao hơn về
những gì liên quan đến việc chuẩn bị SRD.
B.2.3 Tương quan dữ liệu vòng đời
IEEE/EIA 12207.0-1996 đưa ra quan điểm rằng các yêu cầu phần mềm bắt nguồn từ hệ thống
yêu cầu. Vì vậy, người ta sử dụng thuật ngữ “mô tả” thay vì “đặc tả” để mô tả phần mềm.
yêu cầu. Trong một hệ thống trong đó phần mềm là một thành phần, mỗi phần mềm yêu cầu đặc tả riêng, có
sẽ là Đặc tả yêu cầu hệ thống (SRS) và một hoặc nhiều SRD. Nếu thuật ngữ Đặc tả yêu cầu phần mềm được sử dụng thì
sẽ có sự nhầm lẫn giữa SRS đề cập đến hệ thống hoặc
Yêu cầu phần mềm. Trong trường hợp có hệ thống phần mềm độc lập IEEE/EIA 12207.1-1997
nêu rõ “Nếu phần mềm là một hệ thống độc lập thì tài liệu này phải là một bản đặc tả.”
B.3 Ánh xạ nội dung
Điều khoản này cung cấp các chi tiết dựa trên tuyên bố rằng SRS tuân thủ thông lệ được khuyến nghị này
cũng sẽ đạt được “sự tuân thủ tài liệu” với SRD được mô tả trong IEEE/EIA 12207.1-1997. Các
các yêu cầu về tuân thủ tài liệu được tóm tắt trong một hàng của Bảng 1 của IEEE/EIA 12207.1-
1997. Hàng đó được tái hiện trong Bảng B.1 của khuyến nghị thực hành này.
Bảng B.1 – Tóm tắt các yêu cầu đối với SRD
trích từ Bảng 1 của IEEE/EIA 12207.1-1997
Điều khoản Điều khoản

Mục thông tin
IEEE/EIA Loại IEEE/EIA Người giới thiệu
12207.0-1996 12207.1-1997
Phần mềm 5.1.1.4, 5.3.4.1, Sự miêu tả 6,22 IEEE Std 830-1998; EIA/IEEE J-
Yêu cầu 5.3.4.2 (Xem ghi chú về STD-016, F.2.3, F.2.4; SỮA-STD
Sự miêu tả 6.22.1 của 961D. Đồng thời xem ISO/IEC
IEEE/EIA 12207.1-1997.) 5806, 5807, 6593, 8631, 8790 và
11411 để biết hướng dẫn sử dụng
ký hiệu.
Các yêu cầu về tuân thủ tài liệu được thảo luận trong các phần sau:
— B.3.1 thảo luận về việc tuân thủ các yêu cầu thông tin được ghi trong cột 2 của Bảng B.1 như
được quy định tại 5.1.1.4, 5.3.4.1 và 5.3.4.2 của IEEE/EIA 12207.0-1996.
28
IEEE
— B.3.2 thảo luận về việc tuân thủ hướng dẫn nội dung chung (“loại” tài liệu) được ghi trong
cột 3 của Bảng B.1 dưới dạng “mô tả”. Nguyên tắc nội dung chung cho "mô tả" xuất hiện
trong 5.1 của IEEE/EIA 12207.1-1997.
— B.3.3 thảo luận về việc tuân thủ các yêu cầu cụ thể đối với Mô tả Yêu cầu Phần mềm
được ghi chú trong cột 4 của Bảng B.1 theo quy định tại mục 6.22 của IEEE/EIA 12207.1-1997.
— B.3.4 thảo luận về việc tuân thủ các mục tiêu dữ liệu vòng đời của Phụ lục H của IEEE/EIA 12207.0-
1996 như được mô tả trong mục 4.2 của IEEE/EIA 12207.1-1997.
B.3.1 Tuân thủ các yêu cầu thông tin của IEEE/EIA 12207.0-1996
Các yêu cầu về thông tin đối với SRD là những yêu cầu được quy định tại 5.1.1.4, 5.3.4.1 và 5.3.4.2 của IEEE/EIA
12207.0-1996. Các yêu cầu về cơ bản giống với những yêu cầu được xem xét trong B.3.3 của thực tiễn được khuyến nghị này.
B.3.2 Tuân thủ các nguyên tắc nội dung chung của IEEE/EIA 12207.1-1997
Theo IEEE/EIA 12207.1-1997, hướng dẫn nội dung chung cho SRD thường là mô tả,
theo quy định tại mục 5.1 của IEEE/EIA 12207.1-1997. Một mô tả phù hợp sẽ đạt được mục đích nêu trong
5.1.1 và bao gồm thông tin được liệt kê trong 5.1.2 của IEEE/EIA 12207.1-1997.
Mục đích của một mô tả là:
IEEE/EIA 12207.1-1997, mục 5.1.1: Mục đích: Mô tả chức năng thực tế hoặc dự kiến,
thiết kế, hiệu suất hoặc quy trình.
SRD tuân thủ thông lệ được khuyến nghị này sẽ đạt được mục đích đã nêu.
Bất kỳ mô tả hoặc thông số kỹ thuật nào tuân theo IEEE/EIA 12207.1-1997 đều phải đáp ứng nội dung chung
yêu cầu nêu trong 5.1.2 của tiêu chuẩn đó. Bảng B.2 của thực hành khuyến nghị này liệt kê các phương pháp chung
các mục nội dung và, khi thích hợp, tham chiếu điều khoản của thực tiễn được khuyến nghị này yêu cầu
thông tin giống nhau.
Bảng B.2 – Phạm vi yêu cầu mô tả chung của IEEE Std 830-1998
Nội dung chung của IEEE/ Các điều khoản tương ứng của Bổ sung các yêu cầu của
EIA 12207.1-1997 IEEE Std 830-1998 IEEE Std 830-1998
a) Ngày phát hành và trạng thái — Ngày phát hành và trạng thái sẽ được cung cấp.
—
b) Phạm vi 5.1.1 Phạm vi c) Tổ chức phát
—
hành d) Tài liệu tham Tổ chức phát hành phải được xác định.
—
khảo e) Bối 5.1.4 Tài liệu tham khảo
—
cảnh f) Ký 5.1.2 Phạm
hiệu mô tả g) Nội dung h) vi 4.3 Đặc điểm của SRS tốt —

—
Tóm tắt 5. Các bộ phận của SRS
5.1.1. Tổng quan —
i) Thuật ngữ
5.1.3 Định nghĩa —

j) Lịch sử
—
thay đổi Lịch sử thay đổi của SRD sẽ được
cung cấp hoặc tham chiếu.
29
IEEE
B.3.3 Tuân thủ các yêu cầu nội dung cụ thể của IEEE/EIA 12207.1-1997
Các yêu cầu nội dung cụ thể đối với SRD trong IEEE/EIA 12207.1-1997 được quy định tại mục 6.22 của IEEE/
ĐTM 12207.1-1997. SRD tuân thủ sẽ đạt được mục đích nêu trong 6.22.1 của IEEE/EIA 12207.1-1997.
Mục đích của SRD là:
IEEE/EIA 12207.1-1997, điều khoản phụ 6.22.1: Mục đích: Chỉ định các yêu cầu đối với một hạng mục
phần mềm và các phương pháp được sử dụng để đảm bảo rằng từng yêu cầu đều được đáp ứng. Đươ c dùng như
cơ sở cho việc thiết kế và kiểm tra chất lượng của một hạng mục phần mềm.
SRS tuân thủ thực hành được khuyến nghị này và đáp ứng các yêu cầu bổ sung trong Bảng B.3 của
thực hành được khuyến nghị này sẽ đạt được mục đích đã nêu.
SRD tuân thủ IEEE/EIA 12207.1-1997 phải đáp ứng các yêu cầu về nội dung cụ thể được cung cấp trong
6.22.3 và 6.22.4 của tiêu chuẩn đó. Bảng B.3 của thực hành khuyến nghị này liệt kê các mục nội dung cụ thể
và, khi thích hợp, tham chiếu điều khoản của thực tiễn được khuyến nghị này yêu cầu thông tin tương tự.
SRD được chỉ định theo các yêu cầu được nêu hoặc tham chiếu trong Bảng B.3 của thực hành được khuyến nghị này phải
được đánh giá dựa trên các tiêu chí được cung cấp trong 5.3.4.2 của IEEE/EIA 12207.0-1996.
Bảng B.3 – Phạm vi yêu cầu SRD cụ thể của IEEE Std 830-1998
IEEE/EIA 12207.1-1997 Các điều khoản tương ứng của Bổ sung các yêu cầu của
nội dung cụ thể IEEE Std 830-1998 IEEE Std 830-1998
Xem Bảng B.2 —

a) Thông tin mô tả chung b) Nhận dạng
—
và tổng quan hệ thống 5.1.1 Phạm vi
c) Chức năng của hạng mục phần mềm bao 5.3.2 Chức năng Cần cung cấp các đặc tính vật lý và điều
gồm: 5.3.3 Yêu cầu về hiệu suất kiện môi trường.
- Các yêu cầu thực hiện

- Tính chất vật lý
- Điều kiện môi trường
5.3.1 Giao diện bên ngoài —

d) Yêu cầu về giao diện bên ngoài
hạng mục phần mềm
—
đ) Yêu cầu về trình độ chuyên môn Cần cung cấp (hoặc viện dẫn) các
yêu cầu được sử dụng cho việc
kiểm tra trình độ chuyên môn.
5.2.4 Ràng buộc —

f) Thông số kỹ thuật an toàn
—
g) Thông số kỹ thuật về bảo 5.3.6.3 Bảo mật
mật và quyền riêng tư
5.2.3 Đặc điểm người dùng —

h) Yêu cầu kỹ thuật về yếu tố con
người 5.2.1.2 Giao diện người dùng
i) Định nghĩa dữ liệu và yêu cầu 5.3.4 Yêu cầu cơ sở dữ liệu logic —
cơ sở dữ liệu
j) Yêu cầu lắp đặt và nghiệm thu 5.2.1.8 Yêu cầu thích ứng địa điểm Yêu cầu lắp đặt và nghiệm thu tại địa điểm vận hành
tại hiện trường
—
k) Yêu cầu lắp đặt và nghiệm thu Yêu cầu lắp đặt và nghiệm thu tại địa
tại địa điểm bảo trì điểm bảo trì
l) Yêu cầu về tài liệu dành cho người dùng Yêu cầu về tài liệu người dùng
- m) Yêu cầu thực hiện và vận hành 5.2.1.7 Vận hành Yêu cầu thực hiện của người dùng
của người dùng
30
IEEE
Bảng B.3 – Phạm vi yêu cầu SRD cụ thể của IEEE Std 830-1998 (tiếp theo)
IEEE/EIA 12207.1-1997 Các điều khoản tương ứng của Bổ sung các yêu cầu của
nội dung cụ thể IEEE Std 830-1998 IEEE Std 830-1998
—
n) Yêu cầu bảo trì của người dùng 5.3.6.4 Khả năng bảo trì
—
o) Đặc tính chất lượng phần mềm 5.3.6 Thuộc tính hệ thống phần mềm
5.2.4 Ràng buộc —

p) Các ràng buộc về thiết kế
và triển khai
q) Yêu cầu về tài nguyên máy tính r) 5.3.3 Yêu cầu về hiệu suất Yêu cầu về tài nguyên máy tính
—
Yêu cầu về đóng gói s) Mức Yêu cầu đóng gói
độ ưu tiên và mức độ quan trọng 5.2.6 Phân bổ các yêu cầu -

của các yêu cầu
4.3.8 Có thể truy nguyên —

t) Truy xuất nguồn gốc các yêu cầu
—
u) Cơ sở lý luận 5.2.5 Giả định và sự phụ
thuộc
—
Các mục a) đến f) dưới đây là từ
6.22.4
Hỗ trợ các mục tiêu dữ liệu vòng đời
a) Hỗ trợ các mục tiêu dữ liệu của Phụ lục H của IEEE/EIA 12207.0-
vòng đời của Phụ lục H của 1996
IEEE/EIA 12207.0-1996
—
b) Mô tả bất kỳ chức năng nào bằng cách sử dụng ký 4.3 Đặc điểm của một SRS tốt
hiệu được xác định rõ ràng
—
c) Xác định không có yêu cầu nào xung đột 4.3 Đặc điểm của một SRS tốt
5.1.3 Định nghĩa —

d) Thuật ngữ và định nghĩa tiêu chuẩn
của người dùng
—
e) Xác định từng yêu cầu duy nhất 4.3 Đặc điểm của một SRS tốt
để tránh sự không nhất quán
—
f) Xác định duy nhất từng yêu cầu 4.3 Đặc điểm của một SRS tốt
B.3.4 Tuân thủ các mục tiêu dữ liệu vòng đời
Ngoài các yêu cầu về nội dung, dữ liệu vòng đời phải được quản lý phù hợp với các mục tiêu
được cung cấp trong Phụ lục H của IEEE/EIA 12207.0-1996.
B.4 Kết luận
Phân tích cho thấy rằng bất kỳ SRS nào tuân thủ thực tiễn được khuyến nghị này và các phần bổ sung được trình bày trong
Bảng B.2 và Bảng B.3 cũng tuân thủ các yêu cầu của SRD trong IEEE/EIA 12207.1-1997. TRONG
Ngoài ra, để tuân thủ IEEE/EIA 12207.1-1997, SRS phải hỗ trợ các mục tiêu dữ liệu vòng đời của
Phụ lục H của IEEE/EIA 12207.0-1996.

31

IEEE830

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IEEE830

Uploaded by

Copyright:

Available Formats

Machine Translated by Google

IEEE Std 830-1998

Cách thực hành được IEEE khuyến nghị cho

Yêu cầu phần mềm

Nhà tài trợ

Ủy ban Tiêu chuẩn Kỹ thuật Phần mềm của

Hiệp hội máy tính IEEE

Phê duyệt ngày 25 tháng 6 năm 1998

Ban Tiêu chuẩn IEEE-SA

Viện Kỹ sư Điện và Điện tử, Inc.

Bản quyền © 1998 của Viện Kỹ sư Điện và Điện tử, Inc.

Thư ký, Ban Tiêu chuẩn IEEE-SA 445

mục tiêu sau:

phát triển khi những vấn đề này dễ sửa chữa hơn.

xuất liên tục.

Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền. iii

Những người tham gia

Leonard L. Tripp, Chủ tịch

Edward Byrne Dennis Lawrence Terry Rout

Theodore David A. Gustafson Indradeb P.

Auguston Robert John Harauz Polack Peter T. Poon

E. Barry Leo Robert T. Harley Lawrence S. Przybylski

Lawrence Catchpole William S. Junk David M. Siefert

Croll Gregory T. John B. Lane Luca Spotorno

Daughtrey Bostjan William M. James Christine Brown Strysik

iv Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền.

Richard J. Holleman, Chủ tịch Donald N. Heirman, Phó Chủ tịch

Satish K. Aggarwal James H. Gurney L. Bruce McClung

*Thành viên danh dự

Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền. v

1. Tổng quan................................................. ................................................................. ................................... 1

1.1 Phạm vi................................................................................. ................................................................. ................................... 1

2. Người giới thiệu................................................. ................................................................. ................................... 2

3. Các định nghĩa................................................. ................................................................. ................................... 2

4. Những cân nhắc để tạo ra một SRS tốt.................................................. ................................... 3

4.1 Bản chất của SRS................................................................................. ................................................................. ...................... 3

4.2 Môi trường của SRS .................................................................... ................................................................. ............ 3

4.3 Đặc điểm của một SRS tốt.................................................................. ................................................................. ........ 4

4.4 Chuẩn bị chung SRS ................................................................. ................................................................. .......... số 8

4.5 Sự phát triển của SRS ................................................................. ................................................................. ............................. số 8

4.6 Tạo mẫu................................................................................. ................................................................. ................................. 9

4.7 Thiết kế nhúng trong SRS.................................................................. ................................................................. ........ 9

4.8 Nhúng các yêu cầu của dự án vào SRS.................................................. ................................. 10

5. Các bộ phận của SRS.................................................................. ................................................................. ................... 10

5.1 Giới thiệu (Phần 1 của SRS)................................................ ................................................................. 11

5.2 Mô tả tổng thể (Phần 2 của SRS)................................................ ................................... 12

5.3 Yêu cầu cụ thể (Phần 3 của SRS)................................................ ................................... 15

5.4 Thông tin hỗ trợ.................................................................. ................................................................. ............ 19

Phụ lục A (tham khảo) Mẫu SRS................................................................. ................................................................. .......... 21

Cách thực hành được IEEE khuyến nghị cho

Yêu cầu phần mềm

1. Khái quát chung

đã được phát triển có thể phản tác dụng.

Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền. 1

2. Tài liệu tham khảo

2 Bản quyền © 1998 IEEE. Đã đăng ký Bản quyền.

hàng thường không phải là cùng một người.

4. Những cân nhắc để tạo ra một SRS tốt

a) Bản chất của SRS; b) Môi

trường của SRS; c) Đặc điểm của

một SRS tốt; d) Phối hợp chuẩn bị SRS;

e) Diễn biến SRS; f) Làm nguyên mẫu;

SRS; h) Đưa các yêu

cầu của dự án vào SRS.