Bài giảng Thu nhận yêu cầu - Chương 4: Phân tích yêu cầu - Trần Thị Kim Chi

Chương 4Phân tích yêu cầuBộ Môn HTTT - Khoa CNTT - HUI1Nội dungPhân tích yêu cầu là gìQuá trình phân tích yêu cầuTìm kiếm các yêu cầu còn thiếuPhương pháp phân tích yêu cầuPrioritization and Ranking of RequirementsQuality Function Deployment (QFD) MethodCác kỹ thuật mô hình hóaMô hình hóa mục tiêu (Goal modelling)Mô hình hóa phân tích (analysis modelling)Tài liệu đặc tả yêu cầu phần mềm SRSBộ Môn HTTT - Khoa CNTT - HUI2Định nghĩa phân tích yêu cầuLà quá trình suy luận các yêu cầu hệ thống thông qua quan sát hệ thống hiện tại, thảo luận với các người sử dụng, phân tích công việc.Việc này có thể liên quan với việc tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống.Các mẫu hệ thống cũng có thể được phát triển để mô tả các yêu cầu.Bộ Môn HTTT - Khoa CNTT - HUI3Qui trình để có các chức năng của hệ thốngBộ Môn HTTT - Khoa CNTT - HUI4HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI ÝĐịnh nghĩa tầm nhìn và phạm vi của dự án Xác định các lớp người dùng Xác định các đại diện thích hợp của mỗi lớp người dùng Xác định người ra quyết định về yêu cầu và quy trình ra quyết định của họ Chọn các kỹ thuật suy luận mà bạn sẽ dùngỨng dụng các kỹ thuật suy luận để phát triển các use cases và xếp thứ tự ưu tiên các use cases đó cho từng phần của hệ thốngBM HTTT Khoa CNTT - HUI5HƯỚNG DẪN SUY LUẬN YÊU CẦU(REQUIREMENTS ELICITATION GUIDELINES)QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI ÝThu thập thông tin về các thuộc tính chất lượng và các yêu cầu phi chức năng khác từ người dùng.Phác thảo các use cases từ các yêu cầu chức năng cần thiếtRà xét các mô tả use-case và các yêu cầu chức năng Phát triển các mô hình phân tích, nếu cần thiết, để làm sáng tỏ hiểu biết của những người tham gia suy luận về các phần của yêu cầu6Bộ Môn HTTT - Khoa CNTT - HUIHƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI ÝPhát triển và đánh giá các nguyên mẫu giao diện người dùng nhằm trực quan hoá các yêu cầu chưa được hiểu kỹ Phát triển các test cases dưới dạng ý tưởng từ các use cases Sử dụng các test cases để kiểm tra các use cases, các yêu cầu chức năng, các mô hình phân tích, các nguyên mẫu Lặp lại các bước từ 6 đến 13 trước khi thực hiện thiết kế và xây dựng từng phần của hệ thống BM HTTT Khoa CNTT - HUI7Nhiệm vụ của phân tích yêu cầuTrả lời được các câu hỏi sau:Đầu vào của hệ thống là những gìCác quá trình cần xử lý trong hệ thống, hay hệ thống phần mềm sẽ phải xử lý những cái gìĐầu ra: kết quả xử lý của hệ thống là gìNhững ràng buộc trong hệ thống, mối quan hệ giữa đầu vào và đầu ra như thế nàoBộ Môn HTTT - Khoa CNTT - HUI8Nhiệm vụ của phân tích yêu cầuTrong quá trình phân tích cần lưu ý đến tính khả thi của dự án:Khả thi về kinh tế: chi phí phát triển phải cân xứng với lợi ích mà hệ thống đem lại, gồm có:Chi phí:Mua sắm: thiết bị, vật tư (phần cứng), tư vấn, cài đặt thiết bị, quản lý và phục vụ,Chi phí cho khởi công: phần mềm phục vụ cho hệ thống, hệ thống liên lạc(truyền dữ liệu), nhân sự ban đầu, đào tạo, huấn luyện, cải tổ tổ chức cho phù hợp,Bộ Môn HTTT - Khoa CNTT - HUI9Nhiệm vụ của phân tích yêu cầuChi phí:Chi phí liên quan: chi phí nhân công phục vụ thu nhập dữ liệu, sửa đổi, cập nhập hệ thống, chuẩn bị tài liệu,Chi phí liên tục là tốn kém nhất gồm: bảo trì, thuê bao, khấu hao phần cứng, chi phí phục vụ cho vận hành,Lợi nhuận do sử dụng hệ thốngNhiệm vụ xử lý thông tin: giảm chi phí do xử lý tự động, tăng độ chính xác và kết quả tốt hơn, thời gian trả lời rút ngắn,Có được từ hệ thống: thu thập và lưu trữ dữ liệu tự động, đầy đủ, dữ liệu được chuẩn hóa, bảo đảm an toàn và an ninh dữ liệu, tương thích và chuyển đổi giữa các bộ phận, truy cập và tìm kiếm nhanh, kết nối và trao đổi diện rộngBộ Môn HTTT - Khoa CNTT - HUI10Nhiệm vụ của phân tích yêu cầuKhả thi về kỹ thuật:Rủi ro xây dựng: các phần tử hệ thống (chức năng, hiệu suất) khi thiết kế và phân tích có tương đương hay không?Có sẵn tài nguyên: có sẵn con người và tài nguyên cần thiết để phát triển hệ thống?Công nghệ: các công nghệ liên quan cho việc phát triển hệ thống đã có sẵn hay chưa?Bộ Môn HTTT - Khoa CNTT - HUI11Nhiệm vụ của phân tích yêu cầuKhả thi về hợp pháp:Có sự xâm phạm, vi phạm hay khó khăn nào gây ra khi xây dựng hệ thống hay khôngCác phương án: đánh giá về phương án tiếp cận đế việc xây dựng hệ thốngBộ Môn HTTT - Khoa CNTT - HUI12Một số lỗi khi thu thập yêu cầuCố gắng sắp xếp các yêu cầu thu thập được từ hàng tá người dùng sẽ rất khó khăn nếu không có 1 sơ đồ có cấu trúc như use case.Thu thập yêu cầu từ 1 số ít các đại diện hay từ các khách hàng ồn ào hay cho ý kiến có thể gây rắc rối như:Bỏ qua các yêu cầu quan trọng từ các loại người dùng khácQuá chú trọng đến những yêu cầu không tiêu biểu cho nhu cầu của đa số người dùng. Cách cân bằng tốt nhất: quan tâm đến 1 vài product champion, họ đại diện cho các loại người dùng.Bộ Môn HTTT - Khoa CNTT - HUI13Một số lỗi khi thu thập yêu cầuTrong lúc phân tích yêu cầu, có thể phát hiện thấy phạm vi dự án xác định không đúngNếu quá lớn: cần thu thập thêm nhiều yêu cầu để xác định vừa đủ nghiệp vu và nhu cầu khách hàng Nếu quá nhỏ: khách hàng có thể có các nhu cầu cũng quan trọng nhưng hiện nằm ngoài phạm vi đã xác định của dự án. Việc phân tích sẽ dẫn đến phải chỉnh sửa lại product vision hay project scope. Bộ Môn HTTT - Khoa CNTT - HUI14Phát hiện các yêu cầu còn thiếuPhân rã các yêu cầu mức cao đủ chi tiết để phát hiện chính xác cái gì đang được yêu cầu. Phải bảo đảm là tất cả các lớp người dùng đều cung cấp dữ liệu. Phải bảo đảm là mỗi use case có ít nhất 1 actor.Tìm hiểu các yêu cầu hệ thống, use cases, event-response lists, và business rules được chuyển thành yêu cầu chức năng để bảo đảm analyst đã suy dẫn được tất cả chức năng cần thiết. Kiểm tra cac giá trị biên cho các yều cầu còn thiếu đang được xác địnhBộ Môn HTTT - Khoa CNTT - HUI15Phát hiện các yêu cầu còn thiếuVí dụ: Giả sử có 2 yêu cầu như sau:“If the price of the order is less than $100, the shipping charge is $5.95”“If the price the order is more than $100, the shipping charge is 5 percent of the total price”Phí chuyển hàng cho 1 hóa đơn có trị giá chính xác 100 là gì? Vẫn chưa xác định được và được xem như 1 yêu cầu còn thiếuBộ Môn HTTT - Khoa CNTT - HUI16Finding Missing RequirementsBiểu diễn thông tin của mọ̣i yêu cầu theo nhiều cách. Tập hợp các yêu cầu với toán tử Boolean logic (ANDs, ORs, and NOTs) thường không đầy đủ. Nếu tổ hợp các điều kiện logic mà không có yêu cầu nào tương ứng, developer phải suy nghĩ xem hệ thống nên làm gìBộ Môn HTTT - Khoa CNTT - HUI17Ma trận CRUDLà 1 cách để tìm yêu cầu bị thiếu. Viết tắt của Create, Read, Update, and Delete. Ma trận CRUD cho sự tương quan giữa các action của hệ thống với các thực thể dữ liệu giúp ta biết được mỗi data item được tạo, đọc, cập nhật, xóa ở đâu và như thế nào. Bộ Môn HTTT - Khoa CNTT - HUI18Ma trận CRUDL cho hệ thống theo dõi hóa chấtBộ Môn HTTT - Khoa CNTT - HUI19CRUDL (Create, Read, Update, Delete, List)Có thể rút ra các suy luận gì từ ma trận trên khi nói đến thực thể Requester ???Ví dụ ma trận CRUDLSau khi tạo ma trận CRUDL, cần kiểm tra xem: Có ký tự nào trong 5 ký tự CRUDL không xuất hiện trong 1 cột nào đó không? Ví dụ: một cột không có ký tự C  đối tượng được cập nhật mà không bao giờ được tạo ra? Nếu vậy chúng được tạo ra từ đâu? Bộ Môn HTTT - Khoa CNTT - HUI20Ví dụ ma trận CRUDLCột Requester không chứa D, không có use case nào có thể xóa Requester. Ba khả năng xảy ra:Deleting a Requester is not an expected function of the Chemical Tracking System.We are missing a use case that deletes a Requester.The "Edit Requesters" use case is incorrect. Bộ Môn HTTT - Khoa CNTT - HUI21Khi nào thì kết thúc việc thu thập yêu cầu?Nếu người dùng không thể nghĩ ra thêm 1 use case nào khác. Nếu người dùng đề nghị các use case mới nhưng thực tế chúng có thể được suy diễn các use case khác.Nếu người dùng lặp lại các vấn đề đã được xét đến trong các lần thảo luận trước đó. Nếu các tính chất, yêu cầu người dùng, yêu cầu chức năng mới được đề nghị nằm ngoài phạm vi dự án. Bộ Môn HTTT - Khoa CNTT - HUI22Khi nào thì kết thúc việc thu thập yêu cầu?Nếu các yêu cầu mới được đề nghị có độ ưu tiên thấp. Nếu người dùng đưa ra các khả năng có thể đôi khi xuất hiện trong sản phẩm.Tạo một checklist của các miền chức năng chung. Ví dụ checklist bao gồm error logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring user preferences. So sánh định kỳ danh sách này với các chức năng đã xác định của hệ thống. Nếu không tìm thấy lỗ hổng (gap) nào có nghĩa là chúng ta đã phân tích xong.Bộ Môn HTTT - Khoa CNTT - HUI23Requirements Elicitation MethodsBộ Môn HTTT - Khoa CNTT - HUI24Prioritization and Ranking of RequirementsPrioritization là gán mức độ quan trọng cho yêu cầu bắng cách dùng tag hay label. Priorities thường được xác định ngay khi bắt đầu dự án, bằng cách xếp loại bằng số hay cụm từ, e.g., 1 có nghĩa là quan trọng nhất và 5 là ít quan trọng nhất.Ranking là gán 1 thứ tự duy nhất cho mỗi yêu cầu trong 1 nhóm, sao cho không có 2 yêu cầu nào có cùng thứ tự (rank)Bộ Môn HTTT - Khoa CNTT - HUI25Prioritization and Ranking of RequirementsKhi cần phải quyết định tính năng cần có trong sản phẩm sẽ phát hành, thì nên dùng kỹ thuật ranking, trong khi đó kỹ thuật prioritization hầu như được dùng khi xác định phạm vi ban đầu của hệ thống. Bộ Môn HTTT - Khoa CNTT - HUI26Prioritization and Ranking of RequirementsKhi phân phối bảng câu hỏi (questionnaires ) hay phiếu điều tra (survey) cho khách hàng thường luôn có câu hỏi là nên chọn độ ưu tiên nào cho 1 tính năng nào đó của hệ thống , e.g., more likely to buy the product, no difference, less likely to buy the product.Một vấn đề chung hay xảy ra khi để khách hàng đánh giá yêu cầu với 3 mức ưu tiên là “high,” “medium,” hay “low” thì một số khách hàng sẽ luôn gán độ ưu tiên là high cho mọi yêu cầu. Bộ Môn HTTT - Khoa CNTT - HUI27Các kỹ thuật Prioritization“Analytic Hierarchy Process” (AHP)“planning game,” or PG,Bộ Môn HTTT - Khoa CNTT - HUI28“Analytic Hierarchy Process” (AHP)(hay pairwise ranking)Để xếp loại yêu cầu, Stakeholder hay analyst tìm 2 yêu cầu, so sánh chúng và đánh giá chúng để tìm ra cái nào quan trọng hơn. Quy trình này sẽ lập lại cho đến khi tất cả yêu cầu được xếp loại. Phương pháp này chỉ thích hợp cho những tập hợp yêu cầu không quá lớn. Vì các stakeholder khác nhau có thể xếp loại yêu cầu rất khác nhau, nên tạo công thức để hợp nhất các tập yêu cầu được đánh giá khác nhau  nên hạn chế các yêu cầu của stakeholder hay các tính năng của sản phẩm. Bộ Môn HTTT - Khoa CNTT - HUI29“Planning game” (PG)Các yêu cầu của stakeholder, các tính năng hay yêu cầu của sản phẩm được phân chia thành 3 tập hợp theo tiêu chuần Kano:“needed for the system to function,” “add real value,”“nice to have but not necessary.” Thực hiện 1 phân tích rủi ro không chính thức để xác định mức độ thực thi, sau đó quyết định xem nên chọn features hay requirements nào để thực thi.Bộ Môn HTTT - Khoa CNTT - HUI30Đặc tính của rankingViệc xếp loại đánh giá phải dựa vào thực tế, e.g., chi phí và rủi ro luôn có liên quan với nhau.Một số ngành công nghiệp, có 1 số yêu tố như mối nguy hiểm cho người dùng và công nghệ mới cần phải được khảo sát cùng nhau. Bộ Môn HTTT - Khoa CNTT - HUI31Đặc tính của rankingVí dụ: kỹ thuật mới cho việc đóng mở cửa sổ của xe hơi dùng cảm biến ánh sáng thay vì dùng công tắc vật lý như trước đây có chi phí thấp được khách hàng đánh giá rất cao, nhưng khi phân tích mối nguy hiểm (hazard analysis ) thì thấy rằng không bảo đảm an toàn, có thể làm cho trẻ con bị thương khi cửa sổ đột ngột mở ra, do đó kỹ thuật này đã không được đưa vào mô hình xe hơi trong năm kế tiếp.Bộ Môn HTTT - Khoa CNTT - HUI32Prioritization and rankingPrioritization : Việc xác định độ ưu tiên ban đầu cho các yêu cầu của stakeholder nên được thực hiện càng sớm càng tốt trong chu kỳ phát triển sản phẩm. Ranking: Việc xếp loại đánh giá được thực hiện ngay khi các yêu cầu đã thu thập khá đủ như về chi phí, tài nguyên Bộ Môn HTTT - Khoa CNTT - HUI33Quality Function Deployment (QFD) MethodMục đích: Để tích hợp các nhu cầu của người dùng vào thiết kế sản phẩm.Trình tự thực hiện:Tìm ra nhu cầu khách hàng từ những người dù nói ra hay không nói ra, từ những lời nói mập mờ không đầy đủ.Phát hiện ra các đặc tính “tích cực” làm phấn chấn khách hàng. Chuyển các đặc tính này thành các đặc tính thiết kế và hành động có thể chuyển giao. Xây dựng và phân phối sản phẩm/dịch vụ có chất lượng bằng cách tập trung vào các chức năng nghiệp vụ hướng tới mục tiêu chung – thỏa mãn khách hàng. Bộ Môn HTTT - Khoa CNTT - HUI34 Six Sigma là gì?Assignment 17??QFD is often part of a Six Sigma programBộ Môn HTTT - Khoa CNTT - HUI35Quality Function Deployment (QFD) MethodProcess Modeling TechniqueKỹ thuật mô hình hóa quy trình (model driven) phù hợp cho cả elicitation và analysis. Data flow diagrams (DFDs) Use case analysis (use case = business process)Bộ Môn HTTT - Khoa CNTT - HUI36Data flow diagrams (DFDs) Được sử dụng trong 1 thời gian dàiTập trung vào dòng dữ liệu và cấu trúc dữ liệu hơn là vào dịch vụ (services). Bộ Môn HTTT - Khoa CNTT - HUI37Bộ Môn HTTT - Khoa CNTT - HUI38Bộ Môn HTTT - Khoa CNTT - HUI39Use case analysisDùng để chỉ ra quy trình nghiệp vụ và mối quan hệ giữa hệ thống và thế giới bên ngoài.Có thể dùng ngôn ngữ tự nhiên hay bảng biểu để mô tả use case. Bộ Môn HTTT - Khoa CNTT - HUI40Use case analysisMột use case mô tả một dãy các tương tác giữa một hệ thống và một “actor” bên ngoài, kết quả là actor hoàn thành một tác vụ (tasks) cho ai đó. Một actor là một người, một ứng dụng phần mềm khác, một thiết bị phần cứng, một thực thể khác nào đó tương tác với hệ thống để đạt được một mục đích nào đó. Còn được gọi là user role.VD:use case “Đề nghị một hoá chất” của CTS bao hàm một actor gọi là “Requester” (Người đề xuất). Không có lớp người dùng nào trong CTS gọi là “Requester” cả, cả lớp người dùng các nhà hoá học và lớp người dùng nhân viên kho đều có thể đóng vai trò Requester.Bộ Môn HTTT - Khoa CNTT - HUI41USE CASES VÀ KỊCH BẢN SỬ DỤNG (USE CASES AND USAGE SCENARIOS)Một use case có thể bao hàm một số các tác vụ (tasks) liên kết logic với nhau và một số chuỗi công việc tương tác lẫn nhau để hoàn thành các tác vụ này. Use case là phương pháp nổi bật trong hướng OO, là tâm điểm của tiến trình RUP.Use case chuyển hướng việc phát triển yêu cầu thành việc thảo luận xem người dùng cần hoàn thành cái gì (what), ngược lại với phương pháp truyền thống hỏi người dùng muốn hệ thống làm cái gì.Mục tiêu của phương pháp use case là mô tả tất cả các nhiệm vụ mà người dùng sẽ cần thực thi với hệ thống. Bộ Môn HTTT - Khoa CNTT - HUI42USE CASES VÀ KỊCH BẢN SỬ DỤNG (USE CASES AND USAGE SCENARIOS)Use case là một tập hợp các kịch bản (scenario) thông thường có liên quan nhau.Một kịch bản được gọi là một tiến trình chuẩn (normal course) của các sự kiện nối tiếp nhau tạo nên use case, nó cũng được gọi là tiến trình chính (main course), tiến trình cơ sở (basic course), luồng chuẩn (normal flow), hay là “đường yên lành” (happy path). Tiến trình chuẩn được mô tả bằng cách liệt kê một dãy đối thoại (dialogue elements) hoặc dãy tương tác giữa actor và hệ thống.Bộ Môn HTTT - Khoa CNTT - HUI43Bộ Môn HTTT - Khoa CNTT - HUI44Bộ Môn HTTT - Khoa CNTT - HUI45Use case của hệ thống theo dõi hóa chấtBộ Môn HTTT - Khoa CNTT - HUI46Mô tả Use case “request a chemical”Bộ Môn HTTT - Khoa CNTT - HUI47Mô tả Use case “request a chemical”Bộ Môn HTTT - Khoa CNTT - HUI48Use case và yêu cầu chức năngKhông phải yêu cầu chức năng nào cũng được đưa vào UseCaseKhi đặc tả UC nên xác nhận yêu cầu chức năng nào cho phép người dùng hoàn thành mỗi UCKiểm tra xem trong tài liệu đặc tả yêu cầu (SRS) đã bao gồm các yêu cầu chức năng được mô tả trong các UC chưaBộ Môn HTTT - Khoa CNTT - HUI49Use case và yêu cầu chức năngCác kịch bản khác trong use case được mô tả là các tiến trình thay thế (alternative courses). Các tiến trình thay thế cũng nhằm hoàn thành tác vụ (tasks) nhưng chúng được dùng để thay thế tiến trình chuẩn khi một số điều kiện xảy ra khiến không thể thực hiện được tiến trình chuẩn. Tiến trình chuẩn có thể tách thành một tiến trình thay thế tại một điểm quyết định nào đó trên dãy đối thoại (dialogue sequence), và nhập lại vào tiến trình chuẩn sauBộ Môn HTTT - Khoa CNTT - HUI50Use case và yêu cầu chức năngBộ Môn HTTT - Khoa CNTT - HUI51LỢI ÍCH CỦA USE CASES (BENEFITS OF USE CASES)Sức mạnh của cách tiếp cận use-case là suy luận yêu cầu theo quan điểm hướng người dùng (user-centric) và hướng tác vụ (task – centric).Giúp phân loại các ý tưởng cần phải làm đối với mỗi khách hàng. Use cases giúp các nhà phân tích và các nhà phát triển hiểu cả nghiệp vụ của người dùng (user’s business) và miền ứng dụng (problem domain) của bài toán.Kỹ thuật use-case ngăn ngừa tính năng “mồ côi” – các chức năng có vẻ như là cần thiết khi suy luận nhưng không có ai sử dụng vì chúng chả liên quan gì đến các tác vụ (tasks) của họBộ Môn HTTT - Khoa CNTT - HUI52TRÁNH CÁC BẪY KHI SỬ DỤNG USE CASES (USE CASE TRAPS TO AVOID)Quá nhiều use cases (Too many use cases): Đừng tạo ra một use case riêng cho mỗi kịch bản. Thay vì vậy, hãy gom tiến trình chuẩn (normal course), các tiến trình thay thế (alternative courses), các loại trừ (exceptions) thành các kịch bản (scenarios) trong một use case duy nhất. Đừng xử lý mỗi bước trong chuỗi tương tác giữa actor và system như một use case riêng.Trùng lặp trong các use cases (Duplicatiom across use cases): Để tránh sự lặp lại đó, hãy sử dụng quan hệ “include” để nhiều use cases sử dụng chung một chức năng.Bộ Môn HTTT - Khoa CNTT - HUI53TRÁNH CÁC BẪY KHI SỬ DỤNG USE CASES (USE CASE TRAPS TO AVOID)Thiết kế giao diện người dùng kèm theo use cases (User interface design included in the use cases).Đưa các định nghĩa dữ liệu vào use cases (Including data definitions in use cases). Hãy tập hợp các định nghĩa dữ liệu của toàn bộ dự án vào data dictionaryCố gắn kết mỗi yêu cầu với một use case (Attempting to associate every requirement with a use case).Bộ Môn HTTT - Khoa CNTT - HUI54Assignment 18: Ôn lại use case và mô tả use caseYêu cầu:Các dạng use case: include, “macro”, extendCác dạng scenarioCác cách xác định use caseUse case và yêu cầu chức năngLợi ích của use caseMột số trường hợp cần tránh khi dùng use caseBộ Môn HTTT - Khoa CNTT - HUI55Event-Response TablesPhương pháp dùng bảng Event-Response để xác định các event bên ngoài mà hệ thống cần phải đáp ứng. Event là 1 số thay đổi hay hoạt động xảy ra trong môi trường người dùng để kích khởi một đáp ứng (response) từ hệ thống phần mềm. Bảng event-response (còn được gọi là event table hay event list) liệt kê tất cả các event và hành vi mà hệ thống đáp ứng lại ứng với mỗi sự kiện.Bộ Môn HTTT - Khoa CNTT - HUI56Ví dụ các loại sự kiện và đáp ứng hệ thốngBộ Môn HTTT - K