[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"_public_topic_publications_y%C3%AAu%20c%E1%BA%A7u{\"limit\":5}":3,"_public_topic_byId_yêu cầu":11},{"code":4,"data":5,"meta":10},"SUCCESS",{"latest":6,"mostCited":7,"vietnamFeatured":8,"vietnamLatest":9},[],[],[],[],null,{"code":4,"data":12,"meta":10},{"id":13,"title":14,"description":15,"content":16,"term":13,"englishTitle":10,"synonyms":10,"definition":17,"discipline":18,"references":19,"faqs":44,"createUser":54,"publishUser":58,"keywords":62,"keywordCount":73,"enrichTopicLink":74,"status":75,"createTime":76,"updateTime":77,"publishTime":78,"linkEnrichedTime":79,"publicationScanTime":10,"contentErrorMessage":10,"viewCount":80,"relateTopics":81},"yêu cầu","Yêu cầu là gì? Các bài báo nghiên cứu khoa học liên quan","Yêu cầu là mô tả có thể kiểm chứng về chức năng, hành vi hoặc đặc tính của hệ thống, sản phẩm hoặc dịch vụ nhằm đáp ứng nhu cầu và mục tiêu của các bên liên quan. Yêu cầu là cơ sở để thiết kế, phát triển, kiểm thử và quản lý thay đổi trong suốt vòng đời dự án, bảo đảm tính khả thi, hiệu quả và minh bạch. ","\u003Ch2>Định nghĩa “Yêu cầu”\u003C\u002Fh2>\u003Cp>\u003Cstrong>yêu cầu\u003C\u002Fstrong> (\u003Cem>Software Requirement\u003C\u002Fem>) là sự mô tả chi tiết về các tính năng, hành vi, điều kiện vận hành và các ràng buộc kỹ thuật mà một hệ thống phần mềm phải đáp ứng để giải quyết vấn đề thực tế của người dùng.\u003C\u002Fp>\u003Cp>Yêu cầu có thể xuất phát từ nhiều nguồn: khách hàng, người dùng cuối, quy định pháp luật, tiêu chuẩn ngành hoặc giới hạn công nghệ. Việc xác định đầy đủ và chính xác các yêu cầu ban đầu là cơ sở để thiết kế, phát triển và kiểm thử thành công sản phẩm.\u003C\u002Fp>\u003Cp>Một yêu cầu tốt cần đáp ứng các tiêu chí SMART: Specific (cụ thể), Measurable (đo lường được), Achievable (có thể đạt được), Relevant (liên quan) và Time-bound (có thời hạn). Việc tuân thủ các tiêu chí này giúp giảm thiểu hiểu nhầm và thay đổi sau này.\u003C\u002Fp>\u003Ch2>Phân loại yêu cầu\u003C\u002Fh2>\u003Cp>Yêu cầu chức năng (Functional Requirement) mô tả các chức năng mà hệ thống phải thực hiện, thường được định nghĩa qua các use case hoặc user story. Ví dụ: “Hệ thống cho phép người dùng đăng nhập bằng mã OTP gửi qua email.”\u003C\u002Fp>\u003Cp>Yêu cầu phi chức năng (Non-Functional Requirement) tập trung vào các đặc tính chất lượng như hiệu năng, bảo mật, {{topic|%7B%22topic%22%3A%22kh%E1%BA%A3%20n%C4%83ng%20m%E1%BB%9F%20r%E1%BB%99ng%22%7D}}, {{topic|%7B%22topic%22%3A%22kh%E1%BA%A3%20n%C4%83ng%20s%E1%BB%AD%20d%E1%BB%A5ng%22%7D}} và độ tin cậy. Ví dụ: “Thời gian phản hồi trang web không vượt quá 2 giây khi truy cập đồng thời 1.000 người dùng.”\u003C\u002Fp>\u003Cp>Yêu cầu nghiệp vụ (Business Requirement) phản ánh mục tiêu kinh doanh cao nhất, thể hiện giá trị và lợi ích khi dự án hoàn thành. Ví dụ: “Tăng tỷ lệ chuyển đổi khách hàng mới thêm 15% trong vòng 6 tháng.”\u003C\u002Fp>\u003Cp>Yêu cầu kỹ thuật (Technical Requirement) liên quan đến hạ tầng, công nghệ và tiêu chuẩn phát triển. Ví dụ: “Hệ thống phải sử dụng OAuth2 cho xác thực và tuân thủ tiêu chuẩn OWASP Top 10.”\u003C\u002Fp>\u003Ch2>Quy trình thu thập yêu cầu\u003C\u002Fh2>\u003Cp>Xác định bên liên quan (Stakeholder Analysis): liệt kê và phân loại các nhóm đối tượng có nhu cầu hoặc chịu ảnh hưởng bởi dự án (khách hàng, người dùng, quản lý, nhóm vận hành). Sử dụng ma trận power-interest để ưu tiên phỏng vấn và tương tác.\u003C\u002Fp>\u003Cul>\u003Cli>High Power, High Interest: Chủ động tham vấn thường xuyên.\u003C\u002Fli>\u003Cli>High Power, Low Interest: Cập nhật định kỳ.\u003C\u002Fli>\u003Cli>Low Power, High Interest: Mời tham gia workshop.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Phỏng vấn và workshop: tổ chức buổi làm việc nhóm tập trung (JAD session) và phỏng vấn cá nhân để thu thập yêu cầu chi tiết, kịch bản sử dụng, và các điều kiện bất thường.\u003C\u002Fp>\u003Cp>Quan sát hiện trường (Observation) và khảo sát (Survey): ghi nhận quy trình thực tế, {{topic|%7B%22topic%22%3A%22thu%20th%E1%BA%ADp%20d%E1%BB%AF%20li%E1%BB%87u%22%7D}} định lượng về tần suất, lỗi phát sinh để bổ sung yêu cầu liên quan đến hiệu suất hoặc tính ổn định.\u003C\u002Fp>\u003Cp>Prototype và mô hình hóa (Prototyping & Modeling): xây dựng mẫu giao diện nhanh (wireframe) hoặc mô hình luồng nghiệp vụ (process flow) để rà soát và hiệu chỉnh yêu cầu trực quan trước khi phát triển chi tiết.\u003C\u002Fp>\u003Ch2>Tiêu chuẩn và công cụ\u003C\u002Fh2>\u003Cp>ISO\u002FIEC\u002FIEEE 29148:2018 – Chuẩn quốc tế về Kỹ thuật yêu cầu (Systems and software engineering — Life cycle processes — Requirements engineering) quy định quy trình thu thập, phân tích, xác thực và quản lý yêu cầu.\u003C\u002Fp>\u003Cp>BABOK® Guide (A Guide to the Business Analysis Body of Knowledge) do IIBA xuất bản cung cấp khung phân tích nghiệp vụ, bao gồm kỹ thuật elicitation, phân tích và quản lý yêu cầu.\u003C\u002Fp>\u003Cul>\u003Cli>Jira: quản lý backlog, user story, workflow phê duyệt yêu cầu.\u003C\u002Fli>\u003Cli>IBM DOORS: theo dõi traceability và quản lý yêu cầu phức tạp.\u003C\u002Fli>\u003Cli>Azure DevOps: tích hợp quản lý yêu cầu, mã nguồn và CI\u002FCD.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Các công cụ modeling (UML, BPMN) hỗ trợ vẽ sơ đồ use case, luồng dữ liệu (DFD) và sơ đồ thực thể – quan hệ (ERD) giúp mô tả {{topic|%7B%22topic%22%3A%22y%C3%AAu%20c%E1%BA%A7u%20ch%E1%BB%A9c%20n%C4%83ng%22%7D}} và dữ liệu.\u003C\u002Fp>\u003Ch2>Viết và mô tả yêu cầu\u003C\u002Fh2>\u003Cp>Mỗi yêu cầu cần được mô tả rõ ràng, đầy đủ và nhất quán, đảm bảo mọi bên liên quan có thể hiểu và kiểm chứng. Định dạng yêu cầu thường bao gồm ID duy nhất, tiêu đề ngắn gọn, mô tả chi tiết, điều kiện tiền đề (preconditions), bước thực hiện (steps) và tiêu chí chấp nhận (acceptance criteria).\u003C\u002Fp>\u003Cp>Ví dụ định dạng user story:\u003Cbr>As a [role], I want [feature] so that [benefit]. Trong đó:\u003Cbr> \u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>role:\u003C\u002Fstrong> người dùng hoặc {{topic|%7B%22topic%22%3A%22h%E1%BB%87%20th%E1%BB%91ng%20t%C6%B0%C6%A1ng%20t%C3%A1c%22%7D}}\u003C\u002Fli>\u003Cli>\u003Cstrong>feature:\u003C\u002Fstrong> hành vi mong muốn\u003C\u002Fli>\u003Cli>\u003Cstrong>benefit:\u003C\u002Fstrong> giá trị kinh doanh\u003C\u002Fli>\u003C\u002Ful>\u003Cp> \u003C\u002Fp>\u003Cp>Yêu cầu phi chức năng có thể mô tả theo dạng:\u003Cbr>The system shall [quality attribute] such that [quantifiable measure]. Ví dụ: “The system shall handle 5,000 concurrent users with response time under 2 seconds.”\u003C\u002Fp>\u003Ch2>Xác minh và xác thực yêu cầu\u003C\u002Fh2>\u003Cp>Xác minh (verification) đảm bảo yêu cầu được viết đúng theo tiêu chuẩn và không mâu thuẫn, thường thực hiện qua peer review, walkthrough hoặc inspections. Phương pháp này kiểm tra tính hoàn chỉnh, độ rõ ràng và tính khả thi của từng yêu cầu so với tiêu chuẩn ISO\u002FIEC\u002FIEEE 29148 https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72011.html.\u003C\u002Fp>\u003Cp>Xác thực (validation) đảm bảo giải pháp triển khai đáp ứng nhu cầu thực tế của bên liên quan, thực hiện qua việc thiết kế test case dựa trên acceptance criteria và thực thi kiểm thử chức năng, kiểm thử hiệu năng hoặc kiểm thử người dùng (UAT).\u003C\u002Fp>\u003Cfigure class=\"table\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Hoạt động\u003C\u002Fth>\u003Cth>Mục tiêu\u003C\u002Fth>\u003Cth>Công cụ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Peer Review\u003C\u002Ftd>\u003Ctd>Phát hiện lỗi mô tả\u003C\u002Ftd>\u003Ctd>Checklist, review meeting\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Walkthrough\u003C\u002Ftd>\u003Ctd>Đồng thuận hiểu biết chung\u003C\u002Ftd>\u003Ctd>Wireframe, prototype\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Test Case Design\u003C\u002Ftd>\u003Ctd>Đảm bảo tính khả thi\u003C\u002Ftd>\u003Ctd>JUnit, Selenium\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Ffigure>\u003Ch2>Quản lý sự thay đổi\u003C\u002Fh2>\u003Cp>Quy trình kiểm soát thay đổi yêu cầu (Change Control) gồm đề xuất thay đổi, {{topic|%7B%22topic%22%3A%22%C4%91%C3%A1nh%20gi%C3%A1%20t%C3%A1c%20%C4%91%E1%BB%99ng%22%7D}} (impact analysis), phê duyệt và theo dõi. Hội đồng kiểm soát thay đổi (Change Control Board - CCB) gồm đại diện kỹ thuật, kinh doanh và quản lý nhằm đảm bảo mọi thay đổi được cân nhắc toàn diện.\u003C\u002Fp>\u003Cp>Các bước chính:\u003Cbr> \u003C\u002Fp>\u003Col>\u003Cli>Ghi nhận yêu cầu thay đổi (RFC)\u003C\u002Fli>\u003Cli>Phân tích tác động: chi phí, lịch trình, rủi ro\u003C\u002Fli>\u003Cli>Phê duyệt hoặc từ chối bởi CCB\u003C\u002Fli>\u003Cli>Cập nhật tài liệu yêu cầu và traceability matrix\u003C\u002Fli>\u003Cli>Thông báo tới các bên liên quan và điều chỉnh kế hoạch\u003C\u002Fli>\u003C\u002Fol>\u003Cp> \u003C\u002Fp>\u003Ch2>Theo dõi và truy xuất nguồn gốc\u003C\u002Fh2>\u003Cp>Traceability matrix liên kết yêu cầu với thiết kế, mã nguồn và các ca kiểm thử, đảm bảo tính toàn vẹn và khả năng theo dõi suốt vòng đời. Ma trận thường có dạng bảng:\u003C\u002Fp>\u003Cfigure class=\"table\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Requirement ID\u003C\u002Fth>\u003Cth>Thiết kế (Design Doc)\u003C\u002Fth>\u003Cth>Module Code\u003C\u002Fth>\u003Cth>Test Case ID\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>REQ-001\u003C\u002Ftd>\u003Ctd>DD-Login-01\u003C\u002Ftd>\u003Ctd>AuthService.java\u003C\u002Ftd>\u003Ctd>TC-Login-01\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>REQ-002\u003C\u002Ftd>\u003Ctd>DD-Profile-05\u003C\u002Ftd>\u003Ctd>UserProfile.js\u003C\u002Ftd>\u003Ctd>TC-Profile-03\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Ffigure>\u003Cp>Theo dõi tự động qua các công cụ ALM như Jira, Azure DevOps, giúp báo cáo trực quan tiến độ, độ bao phủ kiểm thử và trạng thái phê duyệt.\u003C\u002Fp>\u003Ch2>Thách thức và kinh nghiệm\u003C\u002Fh2>\u003Cp>Thiếu rõ ràng dẫn đến scope creep khi phát triển những tính năng ngoài phạm vi ban đầu; khắc phục bằng việc duy trì backlog, ưu tiên theo MoSCoW (Must, Should, Could, Won’t).\u003C\u002Fp>\u003Cp>Mâu thuẫn yêu cầu giữa các bên liên quan: cần tổ chức workshop để thương lượng ưu tiên và xác lập ràng buộc rõ ràng trước khi phê duyệt.\u003C\u002Fp>\u003Cp>Khó đo lường yêu cầu phi chức năng: đề xuất thiết lập chỉ số đo lường (KPI) cụ thể như {{topic|%7B%22topic%22%3A%22th%E1%BB%9Di%20gian%20ph%E1%BA%A3n%20h%E1%BB%93i%22%7D}}, {{topic|%7B%22topic%22%3A%22kh%E1%BA%A3%20n%C4%83ng%20ch%E1%BB%8Bu%20t%E1%BA%A3i%22%7D}} và tỉ lệ lỗi, kiểm thử định kỳ để đảm bảo tuân thủ.\u003C\u002Fp>\n\n\u003Ch2>Quản lý sự thay đổi yêu cầu trong phương pháp luận Agile\u003C\u002Fh2>\n\u003Cp>Trong môi trường {{topic|%7B%22topic%22%3A%22ph%C3%A1t%20tri%E1%BB%83n%20ph%E1%BA%A7n%20m%E1%BB%81m%22%7D}} hiện đại, yêu cầu hệ thống không còn là tài liệu tĩnh được cố định một lần từ đầu (Big Design Up Front) mà liên tục biến đổi theo phản hồi thực tế của người dùng và biến động thị trường. Khung phương pháp luận Agile và Scrum quản lý yêu cầu dưới dạng danh sách các hạng mục tồn đọng sản phẩm (Product Backlog), trong đó mỗi yêu cầu được mô tả ngắn gọn thông qua câu chuyện người dùng (User Story) kèm theo các tiêu chí chấp nhận cụ thể (Acceptance Criteria) tuân thủ bộ nguyên tắc INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).\u003C\u002Fp>\n\u003Cp>Kỹ thuật phát triển hướng hành vi (Behavior-Driven Development - BDD) kết nối chặt chẽ giữa đặc tả yêu cầu và kiểm thử tự động thông qua {{topic|%7B%22topic%22%3A%22ng%C3%B4n%20ng%E1%BB%AF%20t%E1%BB%B1%20nhi%C3%AAn%22%7D}} có cấu trúc Gherkin (cú pháp Given-When-Then). Điều này cho phép chuyển đổi trực tiếp các yêu cầu nghiệp vụ thành các ca kiểm thử chấp nhận tự động (Automated Acceptance Tests), đảm bảo tính đồng bộ tuyệt đối giữa mã nguồn hệ thống và tài liệu yêu cầu, đồng thời hỗ trợ truy vết lỗi và đánh giá tác động tức thì khi có yêu cầu thay đổi.\u003C\u002Fp>\n\n\u003Ch2>Ma trận truy vết yêu cầu và quản trị biến động trong phát triển phần mềm\u003C\u002Fh2>\n\u003Cp>Ma trận truy vết yêu cầu (Requirements Traceability Matrix - RTM) là một bảng biểu kỹ thuật thiết yếu liên kết trực tiếp từng mục yêu cầu kỹ thuật với các ca kiểm thử (Test Cases), thành phần thiết kế kiến trúc và mô-đun mã nguồn tương ứng. RTM cho phép đội ngũ kỹ sư phần mềm thực hiện phân tích tác động (Impact Analysis) chính xác khi có bất kỳ sự thay đổi nào từ phía khách hàng, đảm bảo 100% yêu cầu được kiểm thử đầy đủ và loại bỏ hiện tượng tính năng bị bỏ sót hoặc phát triển thừa (Gold Plating).\u003C\u002Fp>\n\u003Cp>Trong các phương pháp phát triển linh hoạt hiện đại (Agile\u002FScrum), kỹ thuật bản đồ câu chuyện người dùng (User Story Mapping) phân rã các yêu cầu phức tạp của hệ thống thành các lát cắt giá trị tối thiểu (Minimum Viable Product - MVP). Thông qua các tiêu chí nghiệm thu rõ ràng (Acceptance Criteria) viết theo cú pháp Given-When-Then của kỹ thuật Phát triển hướng hành vi (Behavior-Driven Development - BDD), sự đồng thuận tuyệt đối giữa đội ngũ lập trình viên, chuyên viên phân tích nghiệp vụ và khách hàng được duy trì xuyên suốt toàn bộ vòng đời dự án.\u003C\u002Fp>","là sự mô tả chi tiết về các tính năng, hành vi, điều kiện vận hành và các ràng buộc kỹ thuật mà một hệ thống phần mềm phải đáp ứng để giải quyết vấn đề thực tế của người dùng.","ENGINEERING_TECHNOLOGY",[20,28,36],{"citationText":21,"title":22,"authors":23,"source":24,"year":25,"doi":26,"url":27},"Ali, Lai (2015). A method of software requirements specification and validation for global software development. Requirements Engineering.","A method of software requirements specification and validation for global software development","Ali, Lai","Requirements Engineering",2015,"10.1007\u002Fs00766-015-0240-4","https:\u002F\u002Fdoi.org\u002F10.1007\u002Fs00766-015-0240-4",{"citationText":29,"title":30,"authors":31,"source":32,"year":33,"doi":34,"url":35},"Panichella, Ruiz (2020). Requirements-Collector: Automating Requirements Specification from Elicitation Sessions and User Feedback. 2020 IEEE 28th International Requirements Engineering Conference (RE).","Requirements-Collector: Automating Requirements Specification from Elicitation Sessions and User Feedback","Panichella, Ruiz","2020 IEEE 28th International Requirements Engineering Conference (RE)",2020,"10.1109\u002Fre48521.2020.00057","https:\u002F\u002Fdoi.org\u002F10.1109\u002Fre48521.2020.00057",{"citationText":37,"title":38,"authors":39,"source":40,"year":41,"doi":42,"url":43},"Laplante, Kassab (2022). Requirements Elicitation. Requirements Engineering for Software and Systems.","Requirements Elicitation","Laplante, Kassab","Requirements Engineering for Software and Systems",2022,"10.1201\u002F9781003129509-3","https:\u002F\u002Fdoi.org\u002F10.1201\u002F9781003129509-3",[45,48,51],{"question":46,"answer":47},"Sự khác biệt cốt lõi giữa yêu cầu chức năng (functional) và phi chức năng (non-functional) là gì?","Yêu cầu chức năng mô tả trực tiếp những gì hệ thống phải thực hiện (các dịch vụ, tính năng cụ thể, xử lý dữ liệu và phản ứng với các đầu vào nhất định). Trong khi đó, yêu cầu phi chức năng chỉ định các tiêu chí chất lượng và ràng buộc về cách hệ thống hoạt động, chẳng hạn như hiệu năng, độ tin cậy, tính bảo mật, khả năng mở rộng và tính khả dụng.",{"question":49,"answer":50},"Quy trình kỹ thuật yêu cầu phần mềm (Requirements Engineering) bao gồm các giai đoạn nào?","Quy trình chuẩn gồm 4 giai đoạn nối tiếp: (1) Khơi mở yêu cầu (Elicitation) thông qua phỏng vấn, khảo sát và phân tích ngữ cảnh; (2) Phân tích và thương lượng yêu cầu (Analysis & Negotiation) nhằm phát hiện xung đột và ưu tiên hóa; (3) Đặc tả yêu cầu (Specification) thể hiện qua tài liệu SRS, user stories hoặc use cases; và (4) Thẩm định yêu cầu (Validation) để đảm bảo tính đầy đủ, nhất quán và khả thi.",{"question":52,"answer":53},"Ma trận truy vết yêu cầu (Traceability Matrix) có mục đích gì trong quản lý dự án phần mềm?","Ma trận truy vết liên kết trực tiếp từng mục yêu cầu với các ca kiểm thử (test cases), thành phần thiết kế kiến trúc và mô-đun mã nguồn tương ứng. Điều này đảm bảo toàn bộ yêu cầu của khách hàng đều được hiện thực hóa và kiểm thử đầy đủ, đồng thời giúp đánh giá chính xác tác động dây chuyền khi có sự thay đổi yêu cầu phát sinh trong vòng đời dự án.",{"id":55,"researcherId":10,"name":56,"imageUrl":57},2633,"Hoài Đặng","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocLVXVafUxrnnC_H60UeQdpLE3UgeKGCSesypz_6Vi59B-n9C41A=s96-c",{"id":59,"researcherId":10,"name":60,"imageUrl":61},2681,"Cuong Ta","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocKFuWh0ZD601Hp0_V_2xAK3kIOs20Kyv3V5ZLBo6fwfjyymJYzE=s96-c",[63,64,65,66,67,68,69,70,71,72],"khả năng mở rộng","khả năng sử dụng","thu thập dữ liệu","yêu cầu chức năng","hệ thống tương tác","đánh giá tác động","thời gian phản hồi","khả năng chịu tải","phát triển phần mềm","ngôn ngữ tự nhiên",10,true,"PUBLISHED","2025-06-03T03:00:33.071+00:00","2026-09-13T08:10:04.158+00:00","2025-06-17T06:43:27.077+00:00","2026-09-13T08:10:03.764+00:00",211,[82,85,88,91,94,97,100,103,106,109],{"id":83,"title":84,"term":83,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"ngữ nghĩa","Ngữ nghĩa là gì? Các nghiên cứu khoa học về Ngữ nghĩa",{"id":86,"title":87,"term":86,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"chất lượng thông tin","Chất lượng thông tin là gì? Nghiên cứu khoa học liên quan",{"id":89,"title":90,"term":89,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"cường độ chịu uốn","Cường độ chịu uốn là gì? Các nghiên cứu về Cường độ chịu uốn",{"id":92,"title":93,"term":92,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"thu thập thông tin","Thu thập thông tin là gì? Các nghiên cứu khoa học liên quan",{"id":95,"title":96,"term":95,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"thí nghiệm vật lí","Thí nghiệm vật lí là gì? Các công bố khoa học về Thí nghiệm vật lí",{"id":98,"title":99,"term":98,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"phương pháp mô hình hóa","Phương pháp mô hình hóa là gì? Các công bố khoa học",{"id":101,"title":102,"term":101,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"webgis","WebGIS là gì? Các bài báo nghiên cứu khoa học về WebGIS",{"id":104,"title":105,"term":104,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"whoqol bref","WHOQOL-BREF là gì? Các nghiên cứu khoa học về WHOQOL-BREF",{"id":107,"title":108,"term":107,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"ngôn ngữ học tri nhận","Ngôn ngữ học tri nhận là gì? Nghiên cứu khoa học liên quan",{"id":110,"title":111,"term":110,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"ngôn ngữ kí hiệu","Ngôn ngữ kí hiệu là gì? Các nghiên cứu khoa học liên quan"]