Hiện nay, ngành công nghiệp 4.0 phát triển mạnh mẽ, bùng nổ, dẫn đến có rất nhiều các công ty sản xuất phần mềm đã được hình thành và phát triển. Để mang lại một sản phẩm phần mềm chất lượng, đáng tin cậy thì việc phân tích là một khâu vô cùng quan trọng trong quá trình xây dựng phần mềm.
Tài liệu đặc tả SRS là những yêu cầu về sản phẩm mà đội phát triển đang cần. Chính vì lẽ đó nên tài liệu đặc tả vô cũng quan trọng trong quá trình phát triển phần mềm. Vậy tài liệu đặc tả SRS là gì? Hãy cùng trung tâm testerpro tìm hiểu về nó qua bài viết dưới đây.
Tài liệu srs là gì?
Tài liệu SRS được viết tắt của từ Software Requirement specification có nghĩa là viết tài liệu đặc tả yêu cầu. Nó được sử dụng để mô tả chi tiết các yêu cầu về chức năng và phi chức năng của hệ thống. Các yêu cầu về chức năng giúp mô tả được các chức năng của hệ thống phần mềm và các thành phần của nó.
Tài liệu srs là gì
Các yêu cầu phi chức năng là mô tả các đặc điểm hoạt động của hệ thống phần mềm và các thành phần của nó.Tài liệu đặc tả bao gồm tất các định nghĩa, yêu cầu của người sử dụng và đặc tả yêu cầu của hệ thống , nó không phải là tài liệu thiết kế mà nó chỉ thiết lập những gì mà hệ thống phải làm chứ không phải về việc mô tả rõ nó làm như nào?
Nó được dùng cho tất cả các Stakeholders đọc và hiểu được các nghiệp vụ của các chức năng,…và là một tài liệu vô cùng quan trọng cho đội phát triển và đội kiểm thử phần mềm.
Vai trò của tài liệu SRS
Đây là một tài liệu vô cùng quan trọng trong quá trình phát triển phần mềm:
Giúp các đội phát triển xây dựng hệ thống được chính xác, đặc tả được các tính năng, không đi lạc hướng so với các yêu cầu của khách hàng.
Giúp các bên liên quan hiểu được rõ ràng về hệ thống đi theo một hướng và tránh gặp phải các trường hợp mỗi người mỗi ý.
Việc bảo trì hệ thống và cải tiến các chức năng của hệ thống một cách nhanh chóng và dễ dàng.
Tài liệu kiểm thử SRC giúp các chuyên viên kiểm thử hệ thống hiểu được để từ đó xây dựng nên các kịch bản kiểm thử chi tiết.
Cách viết tài liệu SRS tốt
Tài liệu chính xác: là điều vô cùng quan trọng để bảo đảm rằng SRS luôn phản ánh được các chức năng và các đặc điểm kỹ thuật của sản phẩm
Tính rõ ràng: Rõ ràng tốt hơn mơ hồ, nó không phải là văn học nên không cần văn phong những điều cơ bản nhất không thể bỏ qua được là sự rõ ràng
Hoàn tất: Đây không phải là ý kiến mà nó là những yêu cầu của khách hàng bạn không thể nào bỏ qua được
Phù hợp: Tài liệu đặc tả viết tắt hay các định nghĩa phải sử dụng nhất quán trong bộ SRS
Xếp hạng mức quan trọng: Bạn cần phải xếp hạng mức độ mức quan trọng để xác minh được các yêu cầu
Kiểm chứng: Cần phải có phương pháp xác minh các yêu cầu
Có thể sửa đổi: Các thay đổi với các yêu cầu cần phải thực hiện có hệ thống và tác động đến các yêu cầu khác cần phải được xem xét
tính truy nguyên: truy xuất được nguồn gốc ngay từ đầu
Các thành phần chính của tài liệu SRS
Các thành phần chính của tài liệu SRS
Phần Introduction – Phần giới thiệu
Purpose: Các mô tả chi tiết về các mục đích và ý nghĩa của tài liệu đặc tả yêu cầu, giúp người đọc có thể hiểu được những khái niệm cũng như tầm quan trọng của tài liệu
Application Overview: Có cái nhìn tổng quan hơn về hệ thống đảm bảo các yếu tố như các tính năng của hệ thống, các quyền sở hữu, các mục đích của hệ thống được sinh ra để làm gì?
Intended Audience and Reading Suggestions: Giúp mô tả các đối tượng sở hữu SRS cũng như các mục đích sử dụng
Abbreviations: Danh sách các từ viết tắt giúp người sử dụng hiểu được ý nghĩa
References: Các mục đích kèm theo các mô tả tài liệu liên quan
- Cách viết đặc tả yêu cầu phần mềm
Phần high level Requirement – Yêu cầu mức tổng quan
Mô tả các thực thế quan hệ giữa các đối tượng của hệ thống (Object RelationShip Diagram)
Workflow Diagram: Giúp đảm nhiệm hiển thị các chuỗi công việc hay các bước người dùng thực hiện. Mỗi hành động của người dùng giúp hiển thị được từng giai đoạn của một hệ thống
State Transition Diagram: Đây là một trạng thái từng bước giúp người đọc có thể biết ai là người đang thực hiện điều đó và nó tác động như thế nào đến trạng thái của hệ thống
Use Case Diagram: Đây là sơ đồ thể hiện người dùng có thể thực hiện những chức năng nào của hệ thống.
Mục Security Requirement – Các yêu cầu về bảo mật
Giúp mô tả đầy đủ các permission tương ứng với từng actor của hệ thống và các Actor thực hiện các chức năng và nhiệm vụ của mỗi người và các quyền thực hiện của từng người trong hệ thống.
Đặc tả các use case
Bao gồm các chức năng của hệ thống để giúp nêu ra chi tiết những gì mà hệ thống phải làm ở đầu vào, các hành vi cũng như đầu ra dự kiến. Cùng với đó có các tác nhân bên ngoài bảo vệ hệ thống và các kết quả tương tác của họ.
phần Wireframe – thiết kế màn hình
Đây là một mục đính kèm với tài liệu đặc tả yêu cầu giúp người đọc có thể di chuyển được đến màn hình của hệ thống và có một số chức năng của thiết kế màn hình yêu cầu chức năng hệ thống đối với mỗi khách hàng một cách nhanh chóng và dễ dàng để có thể hiểu được và có cái nhìn chính xác hơn về hệ thống cũng như việc thấu hiểu hơn các yêu cầu của khách hàng và các nhà phân tích nghiệp vụ và thể hiện được năng lực trong nhóm dự án
Các thành phần khác
Xác định các yêu cầu chức năng của hệ thống với khách hàng nhanh hơn
Giúp khach hàng hiểu và hình dung về hệ thống một cách dễ dàng hơn
Thể hiện được những yêu cầu của BA và những yêu cầu mong đợi của khách hàng
Giúp chứng minh được năng lực của team dự án
Dễ tiếp cận, nắm bắt cũng như hiểu nhanh hơn về hệ thống
Phần integration – Yêu cầu tích hợp
Giúp bạn có thể đính kèm được các tài liệu, nội dung liên quan đến hệ thống bên ngoài
Phần Appendices – Mục lục
Cho phép bạn bạn định nghĩa ra các lỗi tin nhắn trong hệ thống hay các email bản mẫu trong hệ thống
Câu hỏi:1/. Tiêu chuẩn ISO-14598 đưa ra:A/. Đưa ra quy trình đánh giá tính an toàn cho sản phẩm phần mềm.B/. Đưa ra quy trình đánh giá hiệu quả của phần mềm.C/. Đưa ra quy trình đánh giá chất lượng cho sản phẩm phần mềm. (đ)D/. Đưa ra quy trình đánh giá tính khả dụng cho sản phẩm phầnmềm. 2/. Trong phát triển phần mềm, yếu tố nào quan trọng nhất?A/. Con người. (đ)B/. Quy trình.C/. Sản phầm.D/. Thời gian.3/. Kỹ thuật nào sau đây là xây dựng phần mềm từ các thành phần đã được thiết kếtrong lĩnh vực công nghệ khác nhau?A/. Extreme programming.B/. Evolutionary prototyping.C/. Component architecture. (đ)D/. Open-source development4/. IEEE 830-1993 là một khuyến nghị tiêu chuẩn choA/. Software requirement specification. (đ)B/. Software design.C/. Testing.D/. Coding.5/. Kỹ sư phần mềm không cầnA/. Kiến thức về phân tích thiết kế hệ thống.B/. Kiến thức về cơ sở dữ liệu.C/. Lập trình thành thạo bằng một ngôn ngữ lập trình. (đ)D/. Kinh nghiệm quản lý dự án phần mềm.6/. Tính khả thi của phần mềm dựa vào các yếu tố sau:A/. Nghiệp vụ và tiếp thị.B/. Phạm vi, ràng buộc và thị trường.C/. Công nghệ, tiền bạc, thời gian và tài nguyên. (đ)D/. Kỹ năng và năng lực của nhà phát triển.7/. Phần mềm dự báo thời tiết thu thập các số liệu về nhiệt độ, độ ẩm, … xử lý tínhtoán để cho ra các dự báo thời tiết là 1 ví dụ của loại phần mềm:A/. Phần mềm hệ thống (System software)B/. Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software)C/. Phần mềm thời gian thực (Real time software) (đ)D/. Phần mềm nghiệp vụ (Business software)8/. Loại phần mềm gì là 1 tập hợp các chương trình để cung cấp dịch vụ cho cácchương trình khác:A/. Phần mềm hệ thống (System software)B/. Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software)C/. Phần mềm thời gian thực (Real time software) (đ)D/. Phần mềm nghiệp vụ (Business software)9/. Phần mềm quản lý sinh viên của 1 trường là:A/. Phần mềm hệ thống (System software)B/. Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software)C/. Phần mềm thời gian thực (Real time software)D/. Phần mềm nghiệp vụ (Business software)10/. Phần mềm quản lý tài chính của một công ty là:A/. Phần mềm nghiệp vụ (Business software)B/. Phần mềm hệ thống (System software)C/. Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software)D/. Phần mềm thời gian thực (Real time software)11/. Theo một báo cáo của IBM, "31% các dự án bị hủy bỏ trước khi chúng được hoànthành, 53% vượt dự toán trung bình 189% và cứ mỗi 100 dự án, có 94 dự án khởiđộng lại". Lý do nào cho số liệu thống kê trên?A/. Thiếu đào tạo đầy đủ về công nghệ phần mềm.B/. Thiếu đạo đức phần mềm và sự hiểu biết.C/. Quản lý các vấn đề trong công ty.D/. Ảnh hưởng của sự suy thoái kinh tế.12/. Điều nào không đúng?A/. Công nghệ phần mềm thuộc ngành khoa học máy tính.B/. Công nghệ phần mềm là một phần của ngành kỹ thuật hệ thống(System Engineering).C/. Khoa học máy tính thuộc ngành công nghệ phần mềm.D/. Công nghệ phần mềm có liên quan với việc phát triển và cung cấp cácphần mềm hữu ích.13/. Mối quan tâm chính của công nghệ phần mềm là gì?A/.Sản xuất phần cứng.B/. Sản xuất phần mềm. (đ)C/. Cấu hình mạng.D/. Phần mềm có thể dùng lại.14/. Điều nào là đặc trưng của một thiết kế phần mềm tốt?A/. Thể hiện kết nối mạnh mẽ giữa các mô-đun của nó.B/. Thực hiện tất cả các yêu cầu trong mô hình phân tích. (đ)C/. Bao gồm các trường hợp thử nghiệm cho tất cả các thànhphần D/. Cung cấp một bức tranh hoàn chỉnh của phần mềm.1/. Theo thống kê từ những thách thức đối với công nghệ phần mềm thì lỗi nhiều nhấtlà doA/. Kiểm tra và bảo trìB/. Phân tích yêu cầu (đ)C/. Thiết kếD/. Viết Code2/. Yêu cầu có thể chia ra thành các lọai nào sau đây? A/.Chức năng, phi chức năng, yêu cầu hệ thống.B/. Chức năng, phi chức năng (đ)C/. Chức năng, phi chức năng, yêu cầu miền ứng dụng.D/. Chức năng, phi chức năng, yêu cầu nghiệp vụ.3/. 2 hình thức dùng mô tả yêu cầu là:A/. Yêu cầu người dùng và yêu cầu hệ thống. (đ)B/. Yêu cầu chức năng và yêu cầu phi chức năng.C/. Yêu cầu chủ động và yêu cầu thụ động.D. Yêu cầu cụ thể và yêu cầu trừu tượng.4/. Loại khả thi nào không được xem xét trong phân tích khảthi A/. Khả thi về kinh tế.B/. Khả thi về thực hiện.C/. Khả thi vể kỹ thuật.D/. Khả thi về chất lượng . (đ)5/. Tính chất cần có của dữ liệu trong phân tích yêu cầuA/. Có định hướng thời gian. (đ)B/. Có giá trị pháp lý.C/. Tính mô tả trừu tượngD/. Có thể mô tả bằng toán học.6/. Câu hỏi nào có liên quan đến phân tích thiết kế?A/. Thời gian hoàn thành dự án có đủ không?B/. Làm thế nào chuyển thiết kế dữ liệu logic sang thiết kế dữ liệu vật lý? (đ)C/. Các xử lý nào được tiến hành và các thông tin chi tiết liên quan?D/. Đâu là phạm vi của hệ thống phần mềm?7/. Tính chất nào không cần thiết cho phân tích dữ liệu ?A/. Cấu trúc dữ liệu.B/. Đầy đủ.C/. Bảo mật. (đ)D/. Độ lớn.8/. Phân tích yêu cầu bao gồm 3 hoạt động theo đúng thứ tự ?A/. Làm tài liệu yêu cầu, làm rõ yêu cầu, xem xét yêu cầu.B/. Làm rõ yêu cầu, xem xét yêu cầu, làm tài liệu yêu cầu.C/. Xem xét yêu cầu, làm tài liệu yêu cầu, làm rõ yêu cầu.D/. Làm rõ yêu cầu, làm tài liệu yêu cầu, xem xét yêu cầu.9/. Làm rõ yêu cầu (Eliciting requirements) làA/. Giao tiếp với khách hàng và người sử dụng để xác định các yêu cầu của họ.B/. Các yêu cầu được ghi nhận lại theo nhiều hình thức.C/. Các yêu cầu được tổng hợp lại theo nhiều hình thức.D/. Xem các yêu cầu có ở tình trạng không rõ ràng?10/. Yêu cầu nào là yêu cầu chức năng?A/. Cảnh báo người dùng khi dung lượng trống trên đĩa còn 20%.B/. Thực hiện thao tác thêm, xem, xóa, sửa dữ liệu nghiệp vụ.C/. Cảnh báo ngày hệ thống bị sai.D/. Yêu cầu chỉnh lại ngày giờ hệ thống mỗi khi làm việc.11/. SRS là viết tắt của:A/. Software Requirement Specification.B/. System Requirement Specification.C/. Studying Requirement Specification.D/. Solve Requirement Specification.12/. Phát biểu nào sau đây là không đúng khi nói đến quá trình thu thập yêu cầu:A/. Yêu cầu rất khó phát hiện.B/. Yêu cầu rất dễ bị thay đổi.C/. Yêu cầu phải luôn thống nhất.D/. Yêu cầu luôn được biết một cách chính xác. (đ)13/. Kết quả của giai đoạn thu thập yêu cầu là:A/. Bảng ước tính chi phí dự ánB/. Tài liệu đặc tả yêu cầu phần mềm. (đ)C/. Lược đồ ngữ cảnhD/. Lược đồ Use case và các được đồ khác.14/. Ai là người viết tài liệu SRS?A/. Người quản lý dự án.B/. Phân tích viên. (đ)C/. Lập trình viên.D/. Khách hàng.15/. Kết quả cuối cùng của giai đoạn xác định và phân tích yêu cầu là:A/. Tài liệu SRS. (đ)B/. Sơ đồ DFD.C/. Sơ đồ Use caseD/. Sơ đồ ERD.16/. Mục nào sau đây không bao gồm trong tài liệu SRS?A/. Yêu cầu chức năngB/. Yêu cầu phi chức năngC/. Mục tiêu thực hiệnD/. Hướng dẫn sử dụng (đ)17/. Loại hình đặc tả nào được dùng phổ biến trong tài liệu SRS?A/. Đặc tả cấu trúc dữ liệu.B/. Đặc tả chức năng.C/. Đặc tả bằng sơ đồ. (đ)D/. Đặc tả đối tượng.18/. Độ lớn (Volume) trong phân tích yêu cầu là:A/. Là số lượng máy tính chạy phần mềm.B/. Là số lượng dữ liệu phát sinh trong một chu kỳ nào đó.C/. Là số lượng các nghiệp vụ hệ thống phải tiến hành trong một chu kỳ nàođó. (đ)D/. Là số lượng người làm việc với phần mềm.19/. Sơ đồ nào sau đây không cần thiết trong phân tích yêu cầu?A/. Use Case.B/. Entity Relationship Diagram.C/. State Transition Diagram.D/. Activity Diagram. (đ)20/. Có bao nhiêu đặc trưng khi xem xét phân tich yêu cầu khả thi?A/. 2B/. 3C/. 4D/. 521/. Có bao nhiêu giai đoạn trong phân tích yêu cầu?A/. 3B/. 4C/. 5D/. 622/. Có bao nhiêu nguyên lý đặc tả yêu cầu?A/. 3B/. 5C/. 7D/. 823/. CASE là từ viết tắt củaA/. Cost Aided Software Engineering.B/. Computer Aided Software Engineering.C/. Control Aided Software EngineeringD/. Computer Analyzing Software Engineering.24/. Kỹ thuật thu thập yêu cầu nào cần đến chuyên gia?A/. Interview.B/. Observation.C/. ExpertD/. Delphi.25/. Kỹ thuật thu thập yêu cầu cầu nào cần đến sự nhất trí của số đông?A/. Prototype.B/. Facilitated WorkshopsC/. ObservationD/.Questionnaires & Surveys26/. Mục nào không dùng cho đặc tả yêu cầu:A/. Đặc tả cú pháp.B/. Đặc tả đối tượng.C/. Đặc tả chức năng.D/. Đặc tả kỹ thuật.27/. Mục nào không dùng cho đặc tả yêu cầu:A/. Đặc tả thao tác.B/. Đặc tả mô hình.C/. Đặc tả bằng sơ đồ.D/. Đặc tả thuật toán.28/. Loại hình đặc tả nào không có?A/. Đặc tả hình thức.B/. Đặc tả phi hình thức.C/. Đặc tả toán học.D/. Đặc tả hỗn hợp.29/. Xác nhận yêu cầu (Requirements Validation) được tiến hànhbởi A/. Phân tích viên và lập trình viên.B/. Phân tích viên và khách hàng.C/. Phân tích viên và các bên có liên quan.D/. Phân tích viên và người dùng.30/. Khi xác nhận yêu cầu, cần phải làm sáng tỏ các từ nào sau đây:A/. “một số”, “đôi khi”, “thường”, “thông thường”, “bình thường”, “phầnlớn”, “đa số”.B/. Danh từ là số nhiều hay số ít.C/. Tính từ chỉ trạng thái.D/. Động từ ở hình thức chủ động hay bị động.Câu hỏi không được kỹ sư phần mềm hiện nay quan tâm nữa0Tại sao chi phí phần cứng máy tính quá cao?ITại sao phần mềm mất một thời gian dài để hoàn tất?IITại sao người ta tốn nhiếu chi phí để phát triển một mẩu phần mềm?III Tại sao những lỗi phần mềm không được loại bỏ trong sản phẩm trướckhi xuất xưởngMô hình phát triển ứng dụng nhanh0 definition, development, supportI what, how, whereII programming, debugging, maintenanceIII analysis, design, testingMô hình phát triển ứng dụng nhanh0Một cách gọi khác của mô hình phát triển dựa vào thành phầnIMột cách hữu dụng khi khách hàng không xàc định yêu cầu rõ ràngIISự ráp nối tốc độ cao của mô hình tuần tự tuyến tínhIII Tất cả mục trênMô hình tiến trình phần mềm tiến hóa0Bản chất lặp0.0 Dễ dàng điều tiết những biến đổi yêu cầu sản phẩm0.1 Nói chung không tạo ra những sản phẩm bỏ đi0.2 Tất cả các mục01234Mô hình phát triển phần mềm lặp lại tăng thêm0Một hướng hợp lý khi yêu cầu được xác định rõ1Một hướng tốt khi cần tạo nhanh một sản phẩm thực thi lõi2Một hướng tốt nhất dùng cho những dự án có những nhóm phát triển lớn3Một mô hình cách mạng không nhưng không được dùng cho sảnphẩm thương mạiMô hình phát triển phần mềm xoắn ốc0Kết thúc với việc xuất xưởng sản phẩm phần mềm1Nhiều hỗn độn hơn với mô hình gia tăng2Bao gồm việc đánh giá những rủi ro phần mềm trong mỗi vòng lặp3Tất cả điều trênMô hình phát triển dựa vào thành phần0Chỉ phù hợp cho thiết kế phần cứng máy tính1Không thể hỗ trợ phát triển những thành phần sử dụng lại2Dựa vào những kỹ thuật hỗ trợ đối tượng3Không định chi phí hiệu quả bằng những độ đo phần mềm có thểđịnh lượngĐể xây dựng mô hình hệ thống, kỹ sư phải quan tâm tới một trong những nhântố hạn chế sau :0Những giả định và những ràng buộc1Ngân sách và phí tổn2Những đối tượng và những hoạt động3Lịch biểu và các mốc sự kiệnTrong kỹ thuật tiến trình nghiệp vụ, ba kiến trúc khác nhau được kiểm tra23 Hạ tầng kỹ thuật, dữ liệu, ứng dụng24 Hạ tầng tài chánh, tổ chức và truyền thông25 Cấu trúc báo cáo, cơ sở dữ liệu, mạng26 Cấu trúc dữ liệu, yêu cầu, hệ thốngThành phần nào của kỹ thuật tiến trình nghiệp vụ là trách nhiệm của kỹ sư phầnmềmPhân tích phạm vi nghiệp vụThiết kế hệ thống nghiệp vụKế hoạch sản phẩmKế hoạch chiến lược thông tinNhững thành phần kiến trúc trong kỹ thuật sản phẩm làDữ liệu, phần cứng, phần mềm, con ngườiDữ liệu, tài liệu, phần cứng, phần mềmDữ liệu, phần cứng, phần mềm, thủ tụcTài liệu, phần cứng, con người, thủ tụcĐặc tả hệ thống mô tảChức năng và hành vi của hệ thống dựa vào máy tínhViệc thi hành của mỗi thành phần hệ thống được chỉChi tiết giải thuật và cấu trúc hệ thốngThời gian đòi hỏi cho việc giả lập hệ thốngCách tốt nhất để đưa tới việc xem xét việc đánh giá yêu cầu làKiểm tra lỗi mô hình hệ thốngNhờ khách hàng kiểm tra yêu cầuGởi họ tới đội thiết kế và xem họ có sự quan tâm nào khôngDùng danh sách các câu hỏi kiểm tra để kiểm tra mỗi yêu cầuSử dụng bảng lần vết giúp58880Debug chương trình dựa theo việc phát hiện lỗi thời gian thực1Xác định việc biểu diễn những sự thi hành giải thuật2Xác định, điều khiển và theo vết những thay đổi yêu cầu3Không có mục nàoMẫu mô hình hệ thống chứa thành phần5888Input5889Output5890Giao diện người dùng5891Tất cả mục trên5889 Tác vụ nào không được biểu diễn như là một phần của phân tích yêu cầuphần mềm5888Định giá và tổng hợp5889Mô hình hóa và thừa nhận vấn đề5890Lập kế hoạch và lịch biểu5891Đặc tả và xem xét5890 Đích của kỹ thuật đặc tả ứng dụng thuận tiện (FAST - facilitatedapplication specification techniques) là nhờ người phát triển và khách hàng5888Xây dựng một nguyên mẫu nhanh chóng5889Học công việc lẫn nhau5890Làm việc với nhau để phát triển một tập những yêu cầu ban đầu5891Làm việc với nhau để phát triển những đặc tả phần mềm kỹ thuật5891 Ai là người không thích hợp để tham dự vào nhóm FAST (facilitatedapplication specification techniques)5888Kỹ sư phần cứng và phần mềm5889Đại diện nhà sản xuất5890Đại diện thị trường5891Nhân viên tài chánh cao cấp0 Những yêu cầu nào được quan tâm suốt QFD (quality function deployment)0 exciting requirements1 expected requirement2 normal requirements3 technology requirements1 Phân tích giá trị được dẫn ra như là một phần của QFD (quality functiondeployment) nhằm xác định0 Chi phí của hoạt động đảm bảo chất lượng của dự án1 Chi phí quan hệ của những yêu cầu qua việc triển khai chức năng, tác vụvà thông tin2 Độ ưu tiên quan hệ của những yêu cầu qua việc triển khai chức năng,tác vụ và thông tin3 Kích thước của bản ý kiến khách hàng2 Use-cases là một kịch bản mà mô tả0 Phần mềm thực hiện như thế nào khi được dùng trong một tìnhhuống cho trước1 Những công cụ CASE sẽ được dùng như thế nào để xây dựng hệ thống2 Kế hoạch xây dựng cho sản phẩm phần mềm3 Những test-case cho sản phẩm phần mềm3 Nội dung thông tin biểu diễn những đối tượng điều khiển và dữ liệu riêng biệt màbao gồm những thông tin mà0 Cần thiết để trình bày tất cả output1 Được đòi hỏi cho việc xử lý lỗi2 Được đòi hỏi cho hoạt động tạo giao diện hệ thống3 Được biến đổi bởi phần mềm4 Dòng thông tin biểu diễn cách thức mà dữ liệu và điều khiển0 Quan hệ với một dữ liệu và điều khiển khác1 Biến đổi khi mỗi lần dịch chuyển qua hệ thốngSẽ được thực thi trong thiết kế cuối cùngKhông có mục nào0123Cấu trúc thông tin biểu diển tổ chức nội của0Những cấu trúc dữ liệu dùng để biểu diễn loại dữ liệu1Mô hình bố trí nhân viên dự án2Mô hình truyền thông dự án3Những dữ liệu khác nhau và những mục điều khiểnLoại mô hình nào được tạo ra trong phân tích yêu cầu phần mềm0Chức năng và hành vi1Giải thuật và cấu trúc dữ liệu2Kiến trúc và cấu trúc3Tính tin cậy và tính sử dụngTrong ngữ cảnh của phân tích yêu cầu, hai loại phân tách vấn đề là0bottom-up và top-down1horizontal and vertical2subordinate và superordinate3Không có mục nàoKhung nhìn (view) nào được quan tâm đầu tiên trong phân tich yêu cầu phầnmềm01234actor viewdata viewessential viewimplementation viewTạo nguyên mẫu tiến hóa thường thích được dùng hơn tạo nguyên mẫu bỏ đibởi vì0Cho phép tái sử dụng nguyên mẫu đầu1Không đòi hỏi làm việc nhiều với khách hàng2Dễ dành thực hiện nhanh0Nhiều tin cậy hơn0Những mục nào không là nguyên tắc cho việc biểu diễn yêu cầu23 Biểu đồ phải thu hẹp về số và toàn vẹn trong sử dụng24 Hình thức và nội dung biểu diễn thích hợp với nội dung25 Những biểu diễn phải có thể xem xét lại26 Dùng không hơn 7 màu dương và 2 màu âm trong biểu đồ1Mục nào không là một mục đích cho việc xây dựng một mô hình phân tích23 Xác định một tập những yêu cầu phần mềm24 Mô tả yêu cầu khách hàng25 Phát triển một giải pháp tóm tắt cho vấn đề26 Thiết lập một nền tảng cho thiết kế phần mềm2Sơ đồ luồng dữ liệu23 Đưa ra hình ảnh quan hệ giữa các đối tượng dữ liệu24 Đưa ra hình ảnh những chức năng biến đổi luồng dữ liệu25 Chỉ ra những quyết định logic chính khi chúng xuất hiện26 Chỉ ra sự tương tác của hệ thống với sự kiện bên ngoài3Biểu đồ quan hệ thực thể23 Đưa ra hình ảnh quan hệ giữa các đối tượng dữ liệu24 Đưa ra hình ảnh những chức năng biến đổi luồng dữ liệu25 Chỉ ra những quyết định logic chính khi chúng xuất hiện26 Chỉ ra sự tương tác của hệ thống với sự kiện bên ngoài4Biểu đồ dịch chuyển trạng thái23 Đưa ra hình ảnh về các đối tượng dữ liệu24 Đưa ra hình ảnh chức năng biến đổi luồng dữ liệu25 Chỉ ra hình ảnh dữ liệu được biến đổi như thế nào bởi hệ thống26 Chỉ ra những tương tác của hệ thống đối với sự kiện bên ngoài34. Phân tích văn phạm của bản tường thuật xử lý là bước đầu tiên tốt nhất để tạora0.0 Tự điển dữ liệu0.1 Biểu đồ dòng dữ liệu0.2 Biểu đồ quan hệ thực thể0.3 Biểu đồ dịch chuyển trạng thái0123Biểu đồ dòng điều khiển0Cần thiết để mô hình những hệ thống hướng sự kiện1Được đòi hỏi cho tất cả hệ thống2Được dùng trong biểu đồ dòng dữ liệu3Hữu dụng trong mô hình hóa giao diện người dùngTừ điển dữ liệu chứa những mô tả của mỗi0Mục cấu hình phần mềm1Đối tượng dữ liệu phần mềm2Biểu đồ phần mềm3Hệ thống ký hiệu phần mềmMô hình thiết kế không quan tâm tới0Kiến trúc1Dữ liệu2Giao diện3Phạm vi dự ánSự quan trọng của thiết kế phần mềm có thể được tóm tắt bằng từ đơn0Accuracy1Complexity2Efficiency3QualityMột đặc trưng của thiết kế tốt là0Cho thấy sự liên kết mạnh giữa các module1Thực hiện tất cả yêu cầu trong phân tích2Bao gồm những test case cho tất cả thành phần3Kết hợp mã nguồn nhằm mục đích mô tảMục nào không là đặc trưng chung trong các phương pháp thiết kế0Quản lý cấu hình1Ký hiệu thành phần chức năng2Nguyên tắc đánh giá chất lượng3Heuristic tinh chếLoại trừu tượng nào được dùng trong thiết kế phần mềm0Điều khiển1Dữ liệu2Thủ tục3Tất cả mục trênLoại mô hình nào không được có trong kiến trúc phần mềm0Dữ liệu1Động2Xử lý3Cấu trúcCấp bậc điều khiển thể hiện0Thứ tự quyết định1Việc tổ chức của các module2Sự lặp lại của những hoạt động3Sự tuần tự của các tiến trìnhThủ tục phần mềm tập trung vàoCấp bậc điều khiển trong một cảm nhận trừu tượng hơnXử lý chi tiết của mỗi module riêng biệtXử lý chi tiết của mỗi tập moduleQuan hệ giữa điều khiển và thủ tụcȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀĀĀȀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀0Nguyên nhâncủa việc sinh lỗi do thiết kế mức thành phần trước khi thiết kế dữ liệu là0.16384⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀⸀ĀȀ⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀЀĀȀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀĀĀЀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ Thiết kế thành phần thì phụ thuộc vào ngôn ngữ còn thiết kế dữ liệu thìkhông0.16385⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀⸀ĀȀ⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀЀĀȀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀĀĀЀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ Thiết kế dữ liệu thì dễthực hiện hơn0.16386⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀⸀ĀȀ⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀЀĀȀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀĀĀЀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ Thiết kế dữ liệu thìkhó thực hiện0.16387⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀⸀ĀȀ⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀЀĀȀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀĀĀЀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Cấu trúc dữ liệu thường ảnh hưởng tới cách thức mà thíết kế thànhphần phải theoȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀĀĀȀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀1Mục đích củatham chiếu chéo những yêu cầu (ma trận) trong tài liệu thiết kế là nhằm1.16384⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀⸀ĀȀ⸀ĀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀЀĀȀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ĀĀĀЀЀĀȀĀ⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀Ā⸀ Cho phép người quảnlý theo dõi năng suất của nhóm thiết kếb. Xác minh là tất cả các yêu cầu đã được xem xét trong thiết kế00Chỉ ra chi phí kết hợp với mỗi yêu cầu1Cung cấp cho việc thực thi tên của những nhà thiết kế cho mỗi yêu cầuMục nào không là một phần của kiến trúc phần mềm0Chi tiết giải thuật1Cơ sở dữ liệu2Thiết kế dữ liệu3Cấu trúc chương trình1Đặc trưng nào là đúng cho kho dữ liệu, không phải là cơ sở dữ liệu đặc trưng0Hướng mức nghiệp vụ và kích thước lớn1Thông tin đúng và hợp thời2Tích hợp và không thường thay đổi3Tất cả những mục trên01234Mẫu kiến trúc nhấn mạnh tới những thành phần0Ràng buộc1Tập hợp những thành phần2Mô hình ngữ nghĩa3Tất cả những mụcNhằm xác định những mẫu kiến trúc hay kết hợp những mẫu phù hợp nhất chohệ thống đề nghị, kỹ thuật yêu cầu dùng để khám phá0Giải thuật phức tạp1Đặc trưng và ràng buộc2Điều khiển và dữ liệu3Những mẫu thiết kếTiêu chuẩn đánh giá chất lượng của một thiết kế kiến trúc phải dựa vào0Tính truy cập và tính tin cậy của hệ thống1Dữ liệu và điều khiển của hệ thống2Tính chức năng của hệ thống3Những chi tiết thực thi của hệ thốngTrong phương pháp phân tích kiến trúc, mô tả mẫu kiến trúc thường dùng khungnhìn0Dòng dữ liệu1Module2Tiến trình3Tất cả các mục trênKhi một luồng tổng thể trong một đoạn của biểu đồ luồng dữ liệu có tính trình tựcao và theo sau những những đường thẳng sẽ thể hiện0Liên kết thấp1Module hóa tốt2Luồng giao dịch (transaction)0Luồng biến đổi (transform)23 Khi luồng thông tin trong một đoạn của sơ đồ luồng dữ liệu thể hiện bằng mộtmục đơn mà bẩy một luồng dữ liệu khác theo một trong nhiều đường sẽ thể hiện23 Liên kết thấp24 Module hóa tốt25 Luồng giao dịch (transaction)26 Luồng biến đổi (transform)24 Một bổ sung cần thiết nhằm biến đổi hay ánh xạ giao dịch để tạo một thiết kếkiến trúc đầy đủ là23 Sơ đồ quan hệ - thực thể24 Từ điển dữ liệu25 Mô tả việc xử lý cho mỗi module26 Những Test-case cho mỗi module23 Những nguyên lý thiết kế giao diện nào không cho phép người dùng còn điềukhiển tương tác với máy tính23 Cho phép được gián đoạn24 Cho phép tương tác có thể undo25 Che dấu những bản chất kỹ thuật với những người dùng thường26 Chỉ cung cấp một cách thức xác định cứng khi hoàn thành tác vụ24 Những nguyên lý thiết kế giao diện cho phép người dùng ít phải nhớ23 Xác định những shortcut trực quan24 Biểu lộ thông tin theo cách diễn tiến25 Thiết lập những trường hợp mặc định có ý nghĩa26 Tất cả những mục trên25 Sự toàn vẹn (consistency) giao diện ngầm định23 Những kỹ thuật input giữ tương tự suốt ứng dụng24 Mỗi ứng dụng phải có look and feel riêng biệt23 Cách thức điều hướng (navigational) nhạy với ngữ cảnh24 Câu a và b59. Mô hình nào đưa ra hình ảnh tiền sử (profile) người dùng cuối của hệ thốngdựa vào máy tính23 Mô hình thiết kế24 Mô hình người dùng25 Mô hình của người dùng26 Mô hình nhận thức hệ thống60. Mô hình nào đưa ra hình ảnh hệ thống trong đầu của người dùng cuối23 Mô hình thiết kế24 Mô hình người dùng25 Hình ảnh hệ thống26 Mô hình nhận thức hệ thống61. Mô hình nào đưa ra hình ảnh look and feel cho giao diện người dùng cùngnhững thông tin hỗ trợ23 Mô hình thiết kế24 Mô hình người dùng25 Mô hình hình ảnh hệ thống26 Mô hình nhận thức hệ thống23 Những hoạt động khung nào thường không kết hợp với những quá trình thiết kếgiao diện người dùng23 Ước lượng giá24 Xây dựng giao diện25 Định trị giao diện26 Phân tích người dùng và tác vụ24 Hướng tiếp cận nào để những phân tích tác vụ của người dùng trong thiết kếgiao diện người dùng23 Người dùng cho biết những ưa thích qua bản câu hỏi23 Dựa vào ý kiến của những lập trình viên có kinh nghiệm24 Nghiên cứu những hệ thống tự động liên quan25 Quan sát thao tác người dùng23 Những vấn đề thiết kế chung nổi trội lên trong hầu hết giao diện người dùng23 Kết nối tiền sử người dùng (profile) và shortcut chức năng24 Xử lý lỗi và thời gian đáp ứng của hệ thống25 Quyết định hiển thị hình ảnh và thiết kế icon26 Không có mục nào24 Những hệ thống phát triển giao diện người dùng đặc trưng cung cấp những kỹthuật cho việc xây dựng những nguyên mẫu giao diện bao gồm23 Tạo code24 Những tool vẽ25 Định trị input26 Tất cả mục trên25 Những bản câu hỏi có ý nghĩa nhất đối với những người thiết kế giao diện khiđược hoàn tất bởi23 Khách hàng24 Những lập trình viên có kinh nghiệm25 Người dùng sản phẩmd. Người quảnlý dự án23 Nhiều đo lường hữu dụng có thể thu thập khi quan sát những người dùng tươngtác với hệ thống máy tính gồm23 Thời gian cho ứng dụng24 Số khiếm khuyết (defect) phần mềm25 Tính tin cậy của phần mềm26 Thời gian đọc tài liệu trợ giúp24 Một bảng quyết định được dùng23 Để tư liệu tất cả những trạng thái phụ thuộc24 Để hướng dẫn phát triển kế hoạch quản lý dự ánc. Chỉ khixây dựng hệ chuyên gia23 Khi một tập phức tạp những điều kiện và hoạt động xuất hiện trongthành phần23 Ngôn ngữ thiết kế chương trình (PDL) thường là một23 Sự kết hợp giữa cấu trúc lập trình và văn bản tường thuậtb. Ngôn ngữ lập trình truyền thống theo luật riêng của nó23 Ngôn ngữ phát triển phần mềm có thể đọc bởi máy24 Một cách hữu dụng để biểu diễn kiến trúc phần mềm23 Những độ đo phức tạp vòng (cyclomatic complexity metric) cung cấp chongười thiết kế thống tin về số23 Chu kỳ trong chương trình24 Số lỗi trong chương trình25 Những đường logic độc lập trong chương trình26 Những phát biểu của chương trình24 Kiểm thử điều kiện là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêuchuẩn dùng để thiết kế test-case23 Dựa vào kiểm thử đường cơ bản24 Thử thách điều kiện logic trong module phần mềm25 Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến26 Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp25 Kiểm thử luồng dữ liệu là một kỹ thuật kiểm thử cấu trúc điều khiển mà nhữngtiêu chuẩn dùng để thiết kế test-case23 Dựa vào kiểm thử đường cơ bản24 Thử thách điều kiện logic trong module phần mềm25 Chọn những đường dẫn kiểm tra dựa vào những vị trí vàdùng những biến