Cập nhật nội dung chi tiết về Chương 1: Yêu Cầu Phần Mềm mới nhất trên website Photomarathonasia.com. Hy vọng thông tin trong bài viết sẽ đáp ứng được nhu cầu ngoài mong đợi của bạn, chúng tôi sẽ làm việc thường xuyên để cập nhật nội dung mới nhằm giúp bạn nhận được thông tin nhanh chóng và chính xác nhất.
1.1. Kiến thức cơ bản
Tổng quan
Định nghĩa
Yêu cầu cho 1 phần mềm cụ thể là tổng hợp những yêu cầu từ nhiều người khác nhau về tổ chức, mức độ chuyên môn và mức độ tham gia, tương tác với phần mềm trong môi trường hoạt động của nó.
Có thể kiểm chứng một cách riêng rẽ ở mức chức năng(yêu cầu chức năng) hoặc mức hệ thống(yêu cầu phi chức năng)
Cung cấp các chỉ số đánh giá độ ưu tiên về các mặt khi cân nhắc về nguồn tài nguyên.
Cung cấp các giá trị trạng thái để theo dõi tiến độ của dự án.
Phân loại
Theo sản phẩm và tiến trình
Yêu cầu sản phẩm: là những đòi hỏi hay ràng buộc mà phần mềm phải thực hiện.
Ví dụ: Trong Project 1:
Yêu cầu sản phẩm là xây dựng trang web Trường học điện tử với các tính năng như Giáo viên quản lý câu hỏi, đề thi; Học sinh tham gia làm bài; Admin duyệt câu hỏi của giáo viên trước khi đăng,…
Yêu cầu tiến trình: Phải thực hiện theo mô hình Agile. Sản phẩm cuối cùng bao gồm cả sản phẩm và backlog cho từng Sprint.
Theo chức năng
Yêu cầu chức năng: đặc tả các chức năng mà phần mềm phải thực hiện.
Yêu cầu phi chức năng: là các ràng buộc về giải pháp và chất lượng(hiệu năng, việc bảo trì, độ an toàn, bảo mật,…).
Yêu cầu đặc tả các thuộc tính nổi bật: là các đặc tả cho các thuộc tính phụ thuộc vào sự vận hành,… đặc biệt là kiến trúc hệ thống. Các thuộc tính này không thể xác định được cho từng thành phần đơn lẻ.
Theo tính kiểm định
Mơ hồ, không thể kiểm định
Rõ ràng, định lượng và có thể kiểm định được.
Theo phạm vi đặc tả
Yêu cầu hệ thống: đặc tả các cấu hình, cơ sở hạ tầng, phần cứng, phần mềm, con người, kỹ thuật,… của toàn bộ hệ thống.
Yêu cầu phần mềm: đặc tả các chức năng, giao diện,… của các cấu phần phần mềm.
1.2. Tiến trình yêu cầu phần mềm
Vị trí trong mô hình tiến trình
Xuất phát từ giai đoạn khởi tạo dự án, cho tới khi hoàn thiện các tiến trình trong vòng đời phát triển của phần mềm. Không chỉ là các hoạt động bề nổi nhìn thấy được.
Được nhận biết như phần cấu hình của mọi việc, và được quản lí như việc quản lí các cấu hình; hoặc là sản phẩm của các quá trình trong vòng đời phát triển.
Được thiết kế theo từng tổ chức và hoàn cảnh của từng dự án.
Các nhân tố tham gia
Người dùng: vận hành phần mềm.
Khách hàng: gồm những người được hưởng mục tiêu cuối cùng của phần mềm, những giá trị thương mại mà phần mềm hướng đến.
Nhà phân tích thị trường: phân tích nhu cầu thị trường và tương tác với bên đại diện khách hàng.
Đại diện pháp lý: kiểm soát việc tuân thủ quy định, quy ước chung, quy định pháp lý.
Kỹ sư phần mềm: thu lợi nhuận hợp pháp từ việc phát triển phần mềm.
Quản lý và Hỗ trợ quy trình
Quản lí nguồn tài nguyên được sử dụng trong các tiến trình.
Cân đối nguồn nhân lực, tài chính, đào tạo và công cụ.
Chất lượng và cải tiến
Xác định vai trò của tiến trình xây dựng yêu cầu về các mặt chi phí, thời gian và sự thoả mãn của khách hàng với sản phẩm.
Định hướng tiến trình theo các chuẩn chất lượng và xây dựng mô hình cải tiến cho phần mềm và hệ thống.
Bao gồm:
Độ bao phủ theo các mô hình và chuẩn cải tiến.
Việc đo đạc và đánh giá tiến trình.
Việc thực hiện và lên kế hoạch cải tiến.
Việc cài đặt và lên kế hoạch cho an ninh.
1.3. Thu thập yêu cầu
Tạo được niềm tin của khách hàng khi họ được tham gia vào giai đoạn thu thập yêu cầu.
Giảm việc phải làm lại trong quá trình phát triển
Quá trình phát triển sẽ nhanh hơn, giảm được những chi phí cho những yêu cầu không cần thiết.
Hạn chế phạm vi hệ thống bị phình rộng.
1.3.1. Nguồn yêu cầu – Requirements Sources
Các yêu cầu có rất nhiều nguồn trong đặc thù phần mềm và điều quan trọng là tất cả các nguồn tiềm năng cần được xác minh và đánh giá. Phần này nhằm nâng cao nhận thức của các nguồn khác nhau của yêu cầu phần mềm và những framework để quản lý chúng. Những điểm chính của nguồn yêu cầu bao gồm:
Mục tiêu – Goal. Các mục tiêu về giá trị và giá thành thường mơ hồ, không rõ ràng. Kĩ sư phần mềm cần chú ý để xác định rõ các mục tiêu đó. Nghiên cứu tính khả thi là sẽ giúp giảm giá thành của quá trình phát triển. Ví dụ kỹ sư phần mềm cần xác định chi phí xây dựng server với chi phí đi mua cái nào sẽ tối ưu hơn để lựa chọn.
Hiểu biết về các lĩnh vực. Các kỹ sư phần mềm cần có kiến thức về các lĩnh vực như: mua sắm, ngân hàng, chăm sóc sức khỏe,… lĩnh vực mà phần mềm được sử dụng. Việc hiểu biết về các lĩnh vực sẽ giúp cho người thu thập yêu cầu thu thập được những thông tin chính xác cao.
Nguyên tắc kinh doanh. Là những điều kiện hoặc các ràng buộc được xác định để các doanh nghiệp hoạt động được. “Một sinh viên không thể đăng ký vào các khóa học học kỳ tiếp theo nếu vẫn còn một số môn chưa thanh toán học phí” sẽ là một ví dụ của nguyên tắc kinh doanh đó cho các phần mềm đăng ký môn học của trường đại học.
Môi trường vận hành. Các yêu cầu sẽ được bắt nguồn từ môi trường mà trong đó phần mềm sẽ được thực thi. Ví dụ như ràng buộc thời gian trong phần mềm thời gian thực hoặc ràng buộc hiệu năng trong môi trường kinh doanh.
Môi trường tổ chức. Phần mềm thường có thể bị ràng buộc bởi cấu trúc, văn hóa và tổ chức chính trị. Các kỹ sư phần mềm cần phải hiểu biết về chúng, phần mềm không nên ép buộc thay đổi ngoài ý muốn trong quá trình kinh doanh.
1.3.2. Kỹ thuật thu thập- Elicitation Techniques
Phỏng vấn. Phỏng vấn là cách truyền thống để thu thập yêu cầu. Ưu điểm: Thu thập được được những thông tin trực tiếp các thông tin có chất lượng cao, tính chân thực và độ tin cậy có thể kiểm nghiệm được trong quá trình phỏng vấn. Nhược điểm: Đòi hỏi người phỏng vấn phải có trình độ cao, am hiểu, có kỹ năng xử lý các tình huống. Khó triển khai được trên quy mô rộng. Tiếp cận khách hàng là việc tương đối khó vì cần hẹn trước.
Kịch bản. Kỹ sư phần mềm cung cấp một hệ thống các câu hỏi bằng việc sử sụng các câu hỏi như “What if” và “How is this done”. Các loại kịch bản phổ biến được sử dụng là mô tả các trường hợp sử dụng. Ví dụ: Điều gì sẽ xảy ra với phần mềm khi bị mất kết nối mạng,…
Các bản mẫu. Kỹ thuật này sẽ làm rõ các yêu cầu không rõ ràng. Có thể sử dụng mockup hoặc màn hình thiết kế hoặc các bản thử nghiệm để xác minh những yêu cầu từ khách hàng. Ví dụ: Thu thập các yêu cầu về thiết kế hoặc chức năng của phần mềm.
Cuộc hội họp. Một nhóm người sẽ mang lại nhiều cái nhìn sâu sắc hơn vào các yêu cầu phần mềm. Mọi người sẽ cùng suy nghĩ, tinh chỉnh các yêu cầu. Lợi thế của phương pháp này là các yêu cầu mâu thuẫn sẽ dễ dàng xử lý hơn.
1.4. Phân tích yêu cầu
Nhằm mục đích:
Phát hiện và giải quyết xung đột giữa các yêu cầu
Tìm ra những giới hạn của phần mềm và cách phần mềm tương tác với tổ chức và môi trường hoạt động của nó.
Nghiên cứu các yêu cầu hệ thống để lấy được các yêu cầu phần mềm.
1.4.1. Mô hình hóa khái niệm
Xây dựng các mô hình trong một vấn đề thực tế là chìa khóa của phân tích yêu cầu phần mềm. Mục đích của nó là để hiểu rõ về những vấn đề xảy ra cũng như miêu tả được giải pháp của vấn đề. Do dó mô hình khái niệm báo gồm các mô hình của các thực thể từ miền vấn đề, cấu hình để phản ánh các mối quan hệ trong thế giới thực và ràng buộc. Có rất nhiều loại mô hình có thể được phát triển bao gồm biểu đồ use case, mô hình luồng dữ liệu, mô hình trạng thái, mô hình dựa trên mục tiêu, tương tác người dùng, mô hình dữ liệu, mô hình đối tượng… Các yếu tố ảnh hưởng đến sự lựa chọn mô hình bao gồm:
Vấn đề tự nhiên. Một số loại phần mềm đòi hỏi một số khía cạnh được phân tích đặc biệt nghiêm ngặt. ví dụ mô hình trạng thái và mô hình tham số của phần mềm thời gian thực quan trọng hơn so với hệ thống thông tin.
Sự thành thạo của kỹ sư phần mềm. Kỹ sư phần mềm có kinh nghiệm sẽ lựa chọn các mô hình hay phương pháp để được kết quả tốt hơn.
Các yêu cầu về quy trình của khách hàng. Khách hàng có thể áp đặt các ký hiệu ưa thích của họ hoặc phương pháp hoặc ngăn cản bất cứ cái gì mà họ thấy không quen thuộc. Nhân tố này có thể xung đột với các nhân tố trước đó.
1.4.2. Thiết kế kiến trúc và phân bổ yêu cầu
Thiết kế kiến trúc là điểm mà tại đó quá trình yêu cầu trùng lặp với phần mềm hoặc các hệ thống thiết kế. Trong nhiều trường hợp, các hành vi kỹ sư phần mềm như là kiến trúc sư phần mềm bởi vì quá trình phân tích và xây dựng các yêu cầu đòi hỏi rằng các thành phần kiến trúc / thiết kế đó sẽ chịu trách nhiệm đáp ứng các yêu cầu được xác định. Phân bổ là quan trọng để cho phép phân tích chi tiết các yêu cầu. Do đó, ví dụ, khi một bộ các yêu cầu đã được phân bổ cho một thành phần, các yêu cầu cá nhân có thể được phân tích thêm để khám phá thêm các yêu cầu về cách thành phần tương tác với thành phần khác để đáp ứng các yêu cầu được giao. Trong các dự án lớn, phân bổ thúc đẩy một vòng mới của phân tích cho mỗi hệ thống. Thiết kế kiến trúc được xác định chặt chẽ với các mô hình khái niệm.
1.4.3. Đàm phán, giải quyết các xung đột giữa các yêu cầu
1.4.4. Phân tích hình thức – Formal Analysis
Formal Analysis đã có một tác động trên một số lĩnh vực ứng dụng, đặc biệt là các hệ thống toàn vẹn cao. Các hình thức thể hiện của các yêu cầu đòi hỏi một ngôn ngữ với ngữ nghĩa định nghĩa chính thức(vd: Ngôn ngữ Z). Việc sử dụng một phân tích hình thức cho các yêu cầu biểu hiện có hai lợi ích. Đầu tiên, nó cho phép các yêu cầu thể hiện bằng ngôn ngữ được xác định một cách chính xác và rõ ràng, do vậy tránh được khả năng hiểu sai. Thứ hai, yêu cầu có thể được lý giải trên, cho phép đặc tính mong muốn của phần mềm cụ thể để chứng minh. Phân tích hình thức nhất là tập trung vào giai đoạn khá muộn của phân tích yêu cầu.
1.5. Đặc tả yêu cầu
Đặc tả yêu cầu là một mô tả của hệ thống phần mềm được phát triển, đưa ra các yêu cầu chức năng và phi chức năng, và có thể bao gồm một tập hợp các ca sử dụng (use cases) để mô tả tương tác giữa người dùng với phần mềm. Đặc tả yêu cầu tạo cơ sở cho một thỏa thuận giữa khác hàng và nhà cung cấp về những gì phần mềm đã làm được tốt cũng như những gì chưa được như mong đợi. Nó cũng cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro và lịch trình. Đối với các hệ thống phức tạp có 3 loại tài liệu được tạo ra là: định nghĩa hệ thống, yêu cầu hệ thống và các yêu cầu phần mềm. Đối với sản phẩm phần mềm đơn giản chỉ cần 1 trong 3 tài liệu.
1.5.1. Tài liệu đặc tả hệ thống.
Còn được biết như là tài liệu yêu cầu người dùng hay là tài liệu vận hành ghi lại những yêu cầu hệ thống. Nó xác định yêu cầu hệ thống ở mức cao với cách nhìn từ domain. Độc giả của tài liệu bao gồm hệ thống người dùng hoặc khác hàng. Vì vậy nội dung của nó phải được diễn đạt bằng những từ ngữ của những lĩnh vực riêng. Tài liệu sẽ liệt kê các yêu cầu hệ thống cùng với các thông tin cơ bản về đối tượng hệ thống, môi trường mục tiêu của nó, giả định và các yêu cầu phi chức năng. Nó có thể bao gồm mô hình khái niệm được thiết kế để minh họa cho ngữ cảnh hệ thống, sử dụng kịch bản, và các miền thực thể chính, cũng như luồng công việc.
1.5.2. Đặc tả yêu cầu hệ thống
Người phát triển những dự án phần mềm có những thành phần thuần túy là software và những phần non-software – ví dụ như máy bay hiện đại thường tách biệt yêu cầu hệ thống với yêu cầu phần mềm. Theo quan điểm này, yêu cầu hệ thống được quy định, các yêu cầu phần mềm có nguồn gốc từ các yêu cầu hệ thống, và sau đó các yêu cầu đối với các thành phần phần mềm được xác định.
1.5.3. Đặc tả yêu cầu phần mềm
1.6. Thẩm định yêu cầu
Tất cả tài liệu yêu cầu cần được thông qua quá trình thẩm định và kiểm duyệt. Vậy Thẩm định yêu cầu là j?
Khái niệm
Thẩm định yêu cầu quan tâm đến việc chứng tở rằng các yêu cầu định nghĩa được hệ thống mà khách hàng thực sự muốn. Các yêu cầu phải được thẩm định để đảm bảo rằng người thực thi, người lập trình hiểu được yêu cầu.
Việc thẩm định phải đảm bảo dễ hiểu, nhất quán và hoàn thiện
Thẩm định yêu cầu được quan tâm đến quá trình kiểm tra tài liệu yêu cầu có đảm bảo đầu ra là 1 phần mềm hoàn chỉnh, đúng đắn.
Các kĩ thuật thẩm định yêu cầu
xem lại yêu cầu
sử dụng phiên bản mẫu, thử nghiệm
thầm định mô hình
kiểm thử chấp thuận
1.6.1. Xem lại yêu cầu
Có lẽ phương tiện phổ biến nhất của việc thẩm định là sự kiểm tra hoặc xem lại các tài liệu yêu cầu. Một nhóm người được giao nhiệm vụ tìm các lỗi, sai sót, thiếu sự rõ ràng, và độ lệch so với tiêu chuẩn. Thành phần của nhóm này đặc biệt quan trọng (ít nhất cần có đại diện khách hàng để có được định hướng đúng đắn), và họ có thể cung cấp sự hướng dẫn trong việc tìm kiếm thông tin chuẩn xác. Việc nhận xét có thể được thành lập sau khi hoàn thành các tài liệu định nghĩa hệ thống, các tài liệu đặc tả hệ thống, đặc tả cơ bản cho 1 phiên bản mới sắp phát hành, hoặc bất kì bước nào khác trong quá trình làm yêu cầu. Ví dụ. Công ty đưa ra 1 tiêu chuẩn chung khi làm tài liệu, các kí hiệu, mô hình đối tượng, cần phải được thống nhất, Nhưng 1 nhân viên mới vào chưa nắm rõ được các tiêu chuẩn này nên làm sai 1 số chỗ. Phương pháp xem lại yêu cầu sẽ giúp tìm ra sai sót này giúp đồng nhất trong quá trình viết tài liệu.
1.6.2. Sử dụng phiên bản mẫu, thử nghiệm
1.6.3. Thẩm định mô hình
Thẩm định model là thẩm định lại chất lượng các model(information model, behavior model, structure model) đã được phát triển trong suốt quá trình phân tích. Ví dụ trong mô hình đối tượng, chúng ta phải kiểm tra xem liên kết giữa các đối tượng, giữa sự trao đổi dữ liệu giữa các đối tượng có chuẩn xác không. Các model phải đủ các tiêu chí: Hoàn thiện, nhất quán và chuẩn xác.
1.6.4. Kiểm thử chấp thuận
Một đặc điểm quan trọng của yêu cầu phần mềm là nó có thể kiểm định rằng sản phẩm cuối cùng phải thỏa mãn các yêu cầu. Viết các testcase dành cho các yêu cầu để kiểm tra khả năng đáp ứng được các yêu cầu end-user. Sản phẩm cuối cùng phải thỏa mãn các testcase
1.7. Khảo sát hiện trạng
Thực trạng có rất nhiều thay đổi, do đó quản lí những thay đổi và duy trì những yêu cầu là chìa khóa quyết định sự thành công của phần mềm. Ví dụ : không phải tổ chức nào cũng có thói quen làm tài liệu cũng như quản lý yêu cầu đặc biệt với những công ty mới thành lập hoặc những công ty có nguồn nhân lực hạn chế. Khi những công ty này mở rộng, số lượng khách hàng trở lên lớn hơn, sản phẩm của họ bắt đầu phát triển, thì lúc này việc tìm lại những yêu cầu và thúc đẩy thêm nhiều tính năng để đáp ứng nhu cầu thị trường và sự thay đổi của môi trường là rất cần thiết. Do đó, tài liệu yêu cầu và quản lí những thay đổi là chìa khóa cho sự thành công của bất kì quá trình yêu cầu nào.
1.7.1. Quản lý thay đổi
1.7.2. Định danh yêu cầu
Đinh danh yêu cầu cần được định nghĩa, ghi nhân và cập nhật như phần phần mềm trong quá trình phát triển và bảo trì.
Bao gồm:
việc phân loại yêu cầu Ví dụ: functional requirement and non-functional requirement
phương pháp xác minh Ví dụ: . xác minh bằng cách xem lại yêu cầu . xác minh bằng sử dụng phiên bản mẫu, thử nghiệm
thầm định mô hình
kiểm thử chấp thuận
kế hoạch kiểm thử
thuộc tính duy nhất để thuận tiện cho việc tham chiếu giữa các yêu cầu và lần vết. Ví dụ: thông tin của yêu cầu duy nhất để tiện cho việc thêm và chỉnh sửa sau khi có sự thay đổi.
1.7.3. Lần vết yêu cầu
Truy vết để thực hiện phân tích những ảnh hưởng khi yêu cầu thay đổi.
Ngược lại. một yêu cầu nên được truy đến những yêu cầu khác nhằm thỏa mãn nó(ví dụ: từ yêu cầu hệ thống đến yêu cầu phần mềm)
1.7.4. Ðánh giá yêu cầu
Đánh giá kích thước của sự thay đổi yêu cầu.
Ví dụ: đánh giá độ khó khăn của việc triển khai thay đổi yêu cầu, đánh giá xem nó ảnh hưởng tới những phân hệ nào trong hệ thống.
Đánh giá chi phí cho việc phát triển hoặc duy trì 1 yêu cầu
Ví dụ: đánh giá nguồn lực, chi phí, mandate cho việc thay đổi yêu cầu.
1.8. Công cụ sử dụng trong việc làm yêu cầu phần mềm
Công cụ cho việc vẽ model (CASE tool , starUML )
Phân Tích Yêu Cầu Phần Mềm Qua Các Ví Dụ
Các khái niệm chung
Một yêu cầu là một đặc trưng của hệ thống, mô tả những việc mà hệ thống có khả năng thực hiện để hoàn thành mục tiêu nhất định
Yêu cầu cho 1 phần mềm cụ thể là tổng hợp những yêu cầu về tổ chức, mức độ chuyên môn và mức độ tham gia, tương tác với phần mềm trong môi trường hoạt động của nó.
Có thể kiểm chứng một cách riêng rẽ ở mức chức năng(yêu cầu chức năng) hoặc mức hệ thống (yêu cầu phi chức năng)
ở mức độ chức năng nó cung cấp dịch vụ cụ thể cho người dùng.
ở mức độ phi chức năng, nó định nghĩa các tính chất và ràng buộc của hệ thống: phương pháp thiết kế, ngôn ngữ lập trình, công cụ sử dụng, thời gian trả lời, độ tin cậy, yêu cầu về lưu trữ dữ liệu…
Vì vậy, về cơ bản yêu cầu phần mềm bao gồm các yêu cầu chức năng và yêu cầu phi chức năng cần phải được thực hiện trong hệ thống.
Trong bài viết này chúng ta sẽ tìm hiểu các đầu mục sau :
1, Phân loại yêu cầu
2, Các nguồn yêu cầu khác
3, Phần kết luận
1. Phân loại yêu cầu
1.1: Yêu cầu nghiệp vụ:
Đây là loại yêu cầu cao được lấy từ các môi trường kinh doanh cụ thể áp dụng vào dự án phần mềm
Ví dụ: Một hệ thống dịch vụ ngân hàng trực tuyến cung cấp dịch vụ ngân hàng cho các tài khoản. Yêu cầu nghiệp vụ kinh doanh được quyết định cho người dùng A là tóm lược tài khoản và chuyển tiền. Trong khi đối với người dùng B yêu cầu kinh doanh là tóm lược tài khoản và thanh toán hóa đơn.
Tên quốc gia Dịch vụ ngân hàng cung cấpngười dùng A
Tóm tắt tài khoản và chuyển tiền
người dùng B
Tóm tắt tài khoản và thanh toán hóa đơn tiền điện
2.2 Yêu cầu về kiến trúc và thiết kế:
Những yêu cầu này chi tiết hơn các yêu cầu kinh doanh. Nó định nghĩa việc thiết kế tổng thể các yêu cầu cần thực hiện từ các yêu cầu kinh doanh.
Thanh toán hóa đơn
Mô tả cách khách hàng có thể đăng nhập vào tài khoản ngân hàng trực tuyến và sử dụng chức năng thanh toán hóa đơn.
Thanh toán hóa đơn
Khách hàng sẽ có thể thấy bảng điều khiển các hóa đơn chưa thanh toán của các hóa đơn đã được đăng ký thanh toán trực tuyến.
Thanh toán hóa đơn
Khách hàng có thể thêm, sửa đổi và xóa chi tiết hóa đơn.
Thanh toán hóa đơn
Khách hàng có thể cài đặt SMS, cảnh báo qua email cho các hành động thanh toán khác nhau.
Thanh toán hóa đơn
Khách hàng có thể thấy lịch sử của các hóa đơn đã thanh toán trong quá khứ.
Thanh toán hóa đơn
Đối tượng sử dụng của trường hợp này là khách hàng của ngân hàng hoặc nhân viên hỗ trợ.
2.3 Yêu cầu hệ thống và tích hợp:
Ở mức thấp nhất, chúng tôi có yêu cầu về hệ thống và tích hợp . Nó là mô tả chi tiết của tất cả các yêu cầu. Nó có thể được mô tả bằng ngôn ngữ kinh doanh hàng ngày của người sử dụng. Tuy nhiên cần có càng nhiều chi tiết càng tốt để các nhà phát triển có thể bắt đầu viết chương trình.
Thêm mới người tạo hóa đơn
Tên người tạo hóa đơn
mối quan hệ: khách hàng
Thanh toán tự động – Có / Không
Thanh toán toàn bộ hóa đơn – Có / Không
Giới hạn thanh toán tự động – Không thanh toán nếu hóa đơn vượt quá số tiền được chỉ định
2. Các nguồn yêu cầu khác
Đôi khi một số dự án bạn có thể không nhận được bất kỳ yêu cầu nào từ khách hàng cũng không có tài liệu để làm việc. Tuy nhiên sẽ luôn có các nguồn khách mà bạn có thể dựa vào để tìm kiếm thông tin và xem xét áp dụng cho việc thiết kế phầm mềm của bạn. Cụ thể:
Chuyển giao kiến thức từ các đồng nghiệp hoặc nhân viên đã làm việc trong dự án đó
Nói chuyện về dự án để phân tích thông tin kinh doanh, quản lý sản phẩm,quản lý dự án và các nhà phát triển
Phân tích phiên bản phần mềm trước đó đã được triển khai vào hệ thống
Phân tích các yêu cầu tài liệu cũ của dự án
Nhìn vào các báo cáo lỗi trong quá khứ, một số báo cáo lỗi được chuyển thành yêu cầu bổ sung có thể được triển khai vào phiên bản hiện tại mà bạn sẽ làm
Xem hướng dẫn cài đặt nếu có để xem yêu cầu cài đặt là gì
Phân tích kiến thức nghiệp vụ hoặc kiến thức chuyên ngành mà nhóm đang cố gắng triển khai
Bất cứ nguồn yêu cầu nào bạn nhận được bằng bất cứ hình thức nào để xây dựng thành tài liệu hãy nhờ các thành viên có kinh nghiệm và kiến thức trong đôị dự án kiểm tra lại cho bạn để đảm bảo thông tin bạn nhận được là đúng đắn.
3, Cách phân tích yêu cầu
Để nghiên cứu làm thế nào để phân tích các yêu cầu đảm bảo chất lượng theo mong muốn của khách hàng. Chúng ta có thể căn cứ vào các tính chất cơ bản sau của yêu cầu:
Tính nguyên tử
Tính xác định duy nhất
Tính hoàn thành
Tính nhất quán và rõ ràng
Có thể theo dõi được
Ưu tiên
Có thể kiểm tra được
lưu trữ thông tin
Duy trì thông tin sinh viên được ánh xạ tới BRQ req.ID?
Duy trì thông tin sinh viên-Ánh xạ tới BRQ req ID 4.1
Tiếp theo chúng ta sẽ tiến hành phân tích từng tính chất trên để hiểu rõ hơn về cách phân tích yêu cầu!
3.1 Tính nguyên tử
Mỗi một yêu cầu phải là nguyên tử, có nghĩa là nó phải ở mức độ thấp nhất, chi tiết nhất và duy nhất. Sau nó không thể tách thành các thành phần khác được nữa.
Chúng ta có thể phân tích một chút như sau:
Yêu cầu chưa tốt là:
Sinh viên sẽ có thể ghi danh vào các khóa học đại học và sau đại học. Vì nó chưa phải là mức độ thấp nhất. Nó hoàn toàn có thể tách ra thành:
Sinh viên sẽ có thể ghi danh vào các khóa học đại học
Sinh viên sẽ có thể ghi danh vào các khóa học sau đại học
Yêu cầu tốt là:
1, Sinh viên sẽ có thể ghi danh vào các khóa học đại học
2, Sinh viên sẽ có thể ghi danh vào các khóa học sau đại học
Với yêu cầu được xác định thành 2 trường như trên đã thỏa mãn tính chi tiết nhất và tính duy nhất của yêu cầu. Do đó, hoàn toàn có thể căn cứ vào chúng để thực hiện xây dựng hệ thống.
3.2 Tính duy nhất
Chất lượng yêu cầu tiếp theo được đề cập đến là tính duy nhất của yêu cầu.
Phần xác định yêu cầu chưa tốt: chúng ta có hai yêu cầu riêng biệt nhưng cả hai đều có cùng một ID # 1. Việc này sẽ gây nhầm lẫn khi thực hiện khi không rõ yêu cầu chính xác của hệ thống.
Phần xác định yêu cầu tốt: đã thực hiện chia xử lý Đăng ký khóa học thành ra thành 2 yêu cầu cụ thể và duy nhất giúp đội dự án khi viết chương trình và kiểm thử chương trình không bị lack xử lý.
3.3 Tính hoàn thành
Mỗi yêu cầu cần phải được hoàn thành. Tính hoàn thành giúp lập trình viên có thông tin đầy đủ để thực hiện viết hệ thống. Việc đưa ra đích hoàn thành cho các yêu cầu nhất định là tiêu chuẩn đầu vào đảm bảo chương trình chạy đúng với mong muốn của khách hàng.
Trong ví dụ dưới , khi xác định yêu cầu không tốt thì các thông tin nhận được không rõ ràng ở chỗ:
Điều này gây khó khăn khi tiến hành thực hiện hệ thống. Do đó, với việc xác định rõ yêu cầu một cách rõ ràng các điều kiện cụ thể cần dùng:
cung cấp tên người dùng, mật khẩu và mã bộ phận
sẽ giúp hoàn thành được phần xử lý cho yêu cầu đưa ra.
3.4 Tính nhất quán và rõ ràng
Tiếp theo mỗi yêu cầu phải nhất quán và rõ ràng. việc này giúp tránh được xung đột khi tiến hành xây dựng sản phẩm.
Trong ví dụ dưới, việc xác đinh yêu cầu chưa tốt lấy ra 2 yêu cầu “Một sinh viên sẽ được chọn các khóa học đại học hoặc các khóa học sau đại học nhưng không được chọn cả hai. ” và yêu cầu khác là “Một số khóa học sẽ được mở cho cả sinh viên chưa tốt nghiệp và sau đại học “
Với vế đầu tiên đại ý sẽ phân loại các khóa học thành 2 loại: Đại học và sau đại học. và sinh viên chỉ có thể chọn 1 trong 2. Tuy nhiên vế thứ 2 lại bị xung đột với vế đầu khi đưa ra yêu cầu sẽ tạo các khóa học chung cho cả 2 hệ đại học và sau đại học.
Vì vậy, yêu cầu này cần được chuyển thành yêu cầu tốt là “Một sinh viên sẽ có các khóa học sau đại học hoặc sau đại học nhưng không phải cả hai”. Điều đó có nghĩa là mỗi khóa học sẽ được phân loại cụ thể thành khóa học dành cho hệ đại học hoặc khóa học dành cho hệ sau đại học mà thôi.
3.5 Tính nguồn gốc
Mỗi và mọi yêu cầu phải có nguồn gốc rõ ràng vì đã có các mức yêu cầu khác nhau, ở trên cùng chúng ta có các yêu cầu nghiệp vụ, các yêu cầu về kiến trúc hệ thống và thiết kế theo yêu cầu tích hợp hệ thống.
Khi tiến hành chuyển đổi yêu cầu nghiệp vụ thành các yêu cầu kiến trúc và thiết kế hoặc chuyển đổi các yêu cầu kiến trúc và thiết kế thành các yêu cầu tích hợp hệ thống thì phải có truy xuất nguồn gốc thông tin.
Điều này có nghĩa là chúng ta có thể thực hiện từng yêu cầu nghiệp vụ và lập bản đồ quan hệ cho một hoặc nhiều yêu cầu về thiết kế và kiến trúc phần mềm tương ứng. Trong ví dụ , yêu cầu chưa tốt có nội dung “Bảo trì thông tin sinh viên được liên hệ tới ID? ” id của yêu cầu không được cung cấp ở đây.
Vì vậy, chuyển đổi nó thành một yêu cầu tốt là chỉ rõ ID được ánh xạ là ID 4.1. Giúp cho việc thực hiện bảo trì thông tin rõ ràng và đúng đắn hơn. Vì vậy, việc đưa ra bản đồ quan hệ truy xuất nguồn gốc thông tin giữa các yêu cầu nên được thiết lập trên toàn bộ dự án.
3.6 Độ ưu tiên
Việc thực hiện các yêu cầu trong hệ thống cần phải được xét độ ưu tiên để biết cần làm cái gì trước cái gì sau. Cần có cái gì rồi mới xây dựng được cái còn lại. Xét độ ư tiên hợp lý giúp việc xây dựng hệ thống tiết kiêm được thời gian và hiệu quả hơn. Việc này cũng tùy thuộc vào từng dự án mà thứ tự các yêu cầu cũng được sắp xếp khác nhau.
Trong ví dụ dưới: yêu cầu chưa tốt đang để tất cả các yêu cầu có chung độ ưu tiên cao nhất. Tuy nhiên việc này là không thể được. Chúng ta cần phải đăng ký được thông tin sinh viên và đăng ký khóa học với độ ưu tiên thực hiện cao nhất rồi mới có thể duy trì thông tin ở mức độ ưu tiên thứ 2 và xem thẻ báo cáo của các dữ liệu đã đăng ký là mức độ ưu tiên thấp nhất.
**3.7 Tính kiểm thử **
Mọi yêu cầu phải được kiểm tra.
với ví dụ trên:
Mỗi trang của hệ thống sẽ tải trong khung thời gian có thể chấp nhận được
Phân tích một chút với yêu cầu này:
Vì vậy, việc chuyển đổi đối số không thể kiểm tra thành đối số có thể kiểm tra, cụ thể là chỉ ra 2 trang “đăng ký học sinh và đăng ký khóa học” với thời gian tải của mỗi trang 5 giây giúp người kiểm thử có thể tiến hành kiểm thử một cách dễ dàng hơn hết.
Kết luận
Cuối cùng mục đích của việc phân tích yêu cầu là tạo ra bản đặc tả các yêu cầu phần mềm. Đặc tả cần được xét duyệt để đảm bảo rằng người phát triển và khách hàng có cùng nhận biết về hệ thống cần phát triển. Từ đó sẽ bảo bảo hệ thống được xây dựng lên là sản phẩm đảm bảo được chất lượng và thỏa mãn được khách hàng.
All Rights Reserved
Công Ty Tnhh Giải Pháp Phần Mềm Số 1
CÔNG TY TNHH GIẢI PHÁP PHẦN MỀM SỐ 1 được Sở kế hoạch và đầu tư cấp giấy chứng nhận đăng ký kinh doanh ngày 08/11/2019. Cơ quan thuế đang quản lý là Chi cục Thuế Quận Cầu Giấy. Hiện tại công ty do ông/bà Phạm Quốc Hùng làm đại diện pháp luật. Công ty có ngành nghề kinh doanh chính là Xuất bản phần mềm.
Tên chính thức: CÔNG TY TNHH GIẢI PHÁP PHẦN MỀM SỐ 1
Tên giao dịch: NO.1 SOFTWARE SOLUTIONS COMPANY LIMITED
Ngày cấp đăng ký kinh doanh: 08/11/2019
Số điện thoại: 024 7106 5686
Trạng thái: Đang hoạt động (đã được cấp GCN ĐKT)
Cơ quan thuế quản lý: Chi cục Thuế Quận Cầu Giấy
Địa chỉ trụ sở: Tầng 8, tòa nhà Sannam, Số 78 phố Duy Tân,, Phường Dịch Vọng Hậu, Quận Cầu Giấy, Hà Nội
Ngành nghề đăng ký kinh doanh:
Ghi chú:Thông tin về CÔNG TY TNHH GIẢI PHÁP PHẦN MỀM SỐ 1 chỉ mang tính tham khảo, khi doanh nghiệp có thay đổi thông tin mà hệ thống chưa cập nhật kịp thời, vui lòng
Chương 1: Quản Trị Chất Lượng
Published on
Chương 1: Quản trị chất lượng
1. chúng tôi Giảng Viên: Ngô Đình Tâm Điện thoại: 0985051628 Email: tamspkt2002@yahoo.com QUẢN TRỊ CHẤT LƯỢNG
2. LOGO TÀI LIỆU THAM KHẢO 1. Giáo trình Quản trị chất lượng chúng tôi Nguyễn Đình Phan TS. Đặng Ngọc Sự 2. Giáo trình Quản trị chất lượng – Đại học kinh tế TPHCM 3. Quản trị chất lượng – TS. Lưu Thanh Tâm 4. Bài giảng Quản trị chất lượng – Ngô Đình Tâm www.themegallery.com
3. chúng tôi NỘI DUNG MÔN HỌC Chất lượng sản phẩm, dịch vụ, khách hàng1 Chi phí – Chất lượng – Năng suất2 Quản lý chất lượng3 Hệ thống quản lý chất lượng4 Tiêu chuẩn hóa và đo lường chất lượng5 Các công cụ thống kê trong QLCL7 Kiểm tra chất lượng sản phẩm6
4. chúng tôi CHƯƠNG 1: CHẤT LƯỢNG SẢN PHẨM, DỊCH VỤ, KHÁCH HÀNG 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ 1.3. CÁC NHÂN TỐ ẢNH HƯỞNG ĐẾN CHẤT LƯỢNG SẢN PHẨM – DỊCH VỤ 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG
5. LOGO 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM 1.1.1. Sản phẩm và phân loại sản phẩm Khái niệm sản phẩm: Theo TCVN ISO 9000:2007 sản phẩm là “Kết quả của các hoạt động hay quá trình”. Kết luận: Sản phẩm là kết quả tạo ra từ các hoạt động của doanh nghiệp để bán cho khách hàng hay tiêu dùng nội bộ. www.themegallery.com
6. LOGO 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM 1.1.1. Sản phẩm và phân loại sản phẩm chúng tôi Quá trình hoạt động Đầu ra Sản phẩm Phần cứng Yếu tố hữu hình Phần mềm Yếu tố vô hình – Nguyên vật liệu – Bộ phận, chi tiết – Sản phẩm hoàn chỉnh -Thông tin -Khái niệm -Hoạt động phục vụ -Cảm nhận
7. LOGO 1.1.1. Sản phẩm và phân loại sản phẩm Phân loại sản phẩm: Căn cứ vào những tiêu chí khác nhau, có nhiều cách phân loại sản phẩm khác nhau: Chức năng, công dụng của sản phẩm. Đặc điểm công nghệ sản xuất. Nguồn gốc nguyên liệu sử dụng chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM
8. LOGO 1.1.2. Chất lượng sản phẩm 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Chất lượng sản phẩm Quan niệm về chất lượng siêu hình Chất lượng xuất phát từ thuộc tính Quan niệm của các nhà sản xuất Quan niệm từ giá trị Quan niệm từ người tiêu dùng Quan niệm từ mục đích làm tăng khả năng cạnh tranh.
9. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Quan niệm về chất lượng siêu hình cho rằng: “Chất lượng là sự tuyệt hảo của sản phẩm”
10. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Quan niệm về chất lượng xuất phát từ thuộc tính của sản phẩm: “Chất lượng là tổng thể những tính chất, thuộc tính cơ bản của sự vật này phân biệt với sự vật khác”
11. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Quan niệm của nhà sản xuất thì chất lượng là sự đảm bảo đạt được và duy trì một tập các tiêu chuẩn, quy cách hoặc yêu cầu đã đặt ra từ trước.
12. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Quan niệm về chất lượng xuất phát từ người tiêu dùng thì “Chất lượng là sự phù hợp của sản phẩm với mục đích của người tiêu dùng hay thỏa mãn người tiêu dùng”.
13. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Quan niệm về chất lượng xuất phát từ giá trị thì “chất lượng là cái mà khách hàng trả đúng với cái họ nhận được”
14. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Quan niệm xuất phát từ mục đích làm tăng khả năng cạnh tranh của sản phẩm: chất lượng là việc tạo ra những thuộc tính của sản phẩm mang lại lợi thế cạnh tranh, phân biệt nó với sản phẩm cùng loại trên thị trường.
15. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Quan niệm chất lượng tổng hợp: Thỏa mãn nhu cầu Giá cả Dịch vụ Giao hàng Chất lượng thuộc tính sản phẩm Chất lượng dịch vụ đi kèm Chi phí bỏ ra
16. LOGO 1.1.2. Chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Khái niệm chất lượng của tổ chức quốc tế về tiêu chuẩn hóa (ISO): “Chất lượng là mức độ mà một tập hợp có tính chất đặc trưng của thực thể có khả năng thỏa mãn những nhu cầu đã nêu ra hay tìm ẩn”
17. LOGO 1.1.3. Các yếu tố cấu thành chất lượng sản phẩm chúng tôi 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM Yếu tố hữu hình Yếu tố vô hình Yếu tố Dịch vụ kèm theo Chất lượng sản phẩm Các yếu tố cấu thành -Tính năng, tác dụng của SP. -Tuổi thọ (độ bền) SP. – Tính thẩm mỹ – Độ an toàn của SP. – Tính tiện dụng SP. -Tính kinh tế – Tên SP. -Nhãn hiệu. – Danh tiếng. -Uy tín
18. chúng tôi Vai trò CLSP 2 6 3 4 5 1 Tạo ra sức hấp dẫn, thu hút người mua Tăng uy tín, danh tiếng và hình ảnh của DN Cơ sở cho hoạt động duy trì và mở rộng thị trường, phát triển và bền vững cho DN Cơ sở quan trọng cho việc thúc đẩy mạnh quá trình hội nhập và giao lưu kinh tế Tăng chất lượng SP giúp giảm chi phí và sức lực của người tiêu dùng Tăng chất lượng SP tương đương, tăng năng suất lao động xã hội, giảm phế phẩm trong sản xuất 1.1. CHẤT LƯỢNG VÀ VAI TRÒ CỦA CHẤT LƯỢNG SẢN PHẨM 1.1.4. Vai trò của chất lượng sản phẩm
19. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Khái niệm: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ DỊCH VỤ Các quan điểm Truyền thống Cách hiểu phổ biến Cách hiểu khác ISO 8402
20. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Khái niệm: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ Dịch vụ Là những gì không phải nuôi trồng và không phải sản xuất. Quan điểm truyền thống
21. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Khái niệm: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ Dịch vụ Là một hoạt động mà sản phẩm của nó là vô hình. Nó giải quyết các mối quan hệ với khách hàng hoặc tài sản do khách hàng sở hữu mà không có sự chuyển giao quyền sở hữu. Theo quan điểm phổ biến
22. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Khái niệm: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ Dịch vụ Là một hoạt động xã hội mà hoạt động này đã xảy ra trong mối quan hệ trực tiếp giữa khách hàng và đại diện của công ty cung ứng dịch vụ. Quan điểm khác
23. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Khái niệm: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ Dịch vụ Là kết quả tạo ra do các hoạt động tiếp xúc giữa người cung ứng với khách hàng và các hoạt động nội bộ của người cung ứng nhu cầu của khách hàng. ISO 8402
24. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Khái niệm: Yếu tố cấu thành dịch vụ: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ Dịch vụ cốt lỗi Dịch vụ gia tăng Dịch vụ
25. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Phân loại dịch vụ: Có nhiều cách phân loại dịch vụ, cụ thể: Phân loại theo chủ thể thực hiện dịch vụ Theo mục đích Theo nội dung Theo mức độ tiêu chuẩn hóa có khả năng tiêu chuẩn hóa cao Dịch vụ theo yêu cầu chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ
26. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Phân loại dịch vụ: Theo mục tiêu cạnh tranh của doanh nghiệp, một số học giả đã phân loại theo sơ đồ sau: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ Dịch vụ Dịch vụ chính Dịch vụ GTGT Dịch vụ GTGT không thu thêm phí Dịch vụ GTGT thu thêm phíDịch vụ mang tính cạnh tranh
27. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Đặc điểm của dịch vụ: chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ 1 2 3 4 Tính vô hình Tính không thể chia cắt Tính không ổn định Tính không lưu giữ được
28. LOGO 1.2.1. Khái niệm, phân loại và đặc điểm của dịch vụ Đặc điểm dịch vụ: Dựa vào tính không lưu trữ được, nhiều doanh nghiệp cung ứng dịch vụ đã áp dụng các biện pháp điều hòa cung cầu theo thời gian, cụ thể: Định giá phân biệt để có thể chuyển một phần nhu cầu từ giờ cao điểm sang giờ vắng khách. Có thể chủ động làm tăng nhu cầu vào thời kỳ suy giảm bằng cách giảm giá. Áp dụng hệ thống đặt hàng trước. Dùng các biện pháp tăng năng lực hiện có, như: Tập trung nhân viên các khâu vào giờ cao điểm. chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ
29. LOGO 1.2.2. Chất lượng dịch vụ Theo ISO 8402: Chất lượng dịch vụ là “tập hợp các đặc tính của một đối tượng, tạo cho đối tượng có khả năng thỏa mãn những yêu cầu đã nêu ra hoặc tiềm ẩn” chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ
30. LOGO 1.2.2. Chất lượng dịch vụ Theo các học giả tiếp cận trên quan điểm khách hàng: Chất lượng (Quality) = Mức độ thỏa mãn (Satisfaction) Cảm nhận – Kỳ vọng Perception Expectation chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ
31. LOGO 1.2.2. Chất lượng dịch vụ chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ Cảm nhận vượt quá mong đợi Cảm nhận bằng mong đợi Cảm nhận thấp hơn mong đợi Chất lượng dịch vụ tốt Chất lượng dịch vụ thỏa mãn Chất lượng dịch vụ kém
33. LOGO 1.2.2. Chất lượng dịch vụ 5 chỉ tiêu dánh giá chất lượng dịch vụ Sự tin cậy Tinh thần trách nhiệm Sự đảm bảo Sự đồng cảm Sự hữu hình chúng tôi 1.2. DỊCH VỤ VÀ CHẤT LƯỢNG DỊCH VỤ
34. chúng tôi 1.3. CÁC YẾU TỐ ẢNH HƯỞNG ĐẾN CHẤT LƯỢNG SẢN PHẨM, DỊCH VỤ
35. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.1. Khách hàng và vai trò của khách hàng trong quản trị chất lượng Vị trí vai trò của khách hàng trong quản trị chất lượng Khách hàng là điều kiện tiên quyết để Doanh nghiệp tồn tại và phát triển. Chìa khóa thành công của Doanh nghiệp là luôn đáp ứng nhu cầu của khách hàng. www.themegallery.com
36. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.1. Khách hàng và vai trò của khách hàng trong quản trị chất lượng Phân loại khách hàng: Đứng về góc độ quản lý: Khách hàng bên trong (nội bộ). Khách hàng bên ngoài. Căn cứ vào tầm quan trọng của khách hàng đối với Doanh nghiệp: Khách hàng có ý nghĩa sống còn với Doanh nghiệp. Khách hàng là số đông có lợi cho Doanh nghiệp www.themegallery.com
37. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.1. Khách hàng và vai trò của khách hàng trong quản trị chất lượng Phân loại khách hàng: Căn cứ vào mục đích sử dụng sản phẩm: Nhóm khách hàng mua sản phẩm để sản xuất, chế biến. Nhóm khách hàng mua để bán. Nhóm khách hàng mua để tiêu dùng trực tiếp. Ngoài ra có thể căn cứ vào địa lý, căn cứ vào thời điểm … để phân chia khách hàng. www.themegallery.com
38. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.2. Nhu cầu của khách hàng với vấn đề chất lượng Nhu cầu của khách hàng là gì? Nhu cầu của khách hàng là mong muốn hay kỳ vọng của khách hàng là nhu cầu tự nhiên có dạng đặc thù. www.themegallery.com
39. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.2. Nhu cầu của khách hàng với vấn đề chất lượng chúng tôi Chất lượng mong đợi Chất lượng thực Nhu cầu thực Kỳ vọng Sản phẩm Khác Chênh lệch Doanh nghiệp
40. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.2. Nhu cầu của khách hàng với vấn đề chất lượng Phân loại nhu cầu: chúng tôi Nhu cầu bộc lộ Nhu cầu thực Nhu cầu hiện tại Nhu cầu tiềm ẩn Nhu cầu nhận thức Nhu cầu văn hóa
41. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.2. Nhu cầu của khách hàng với vấn đề chất lượng Cấu trúc kỳ vọng của khách hàng chúng tôi Kỳ vọng tuyệt đối Kỳ vọng rõ ràng Kỳ vọng tiềm ẩn
42. LOGO 1.4. KHÁCH HÀNG VÀ NHU CẦU CỦA KHÁCH HÀNG 1.4.3. Phương pháp xác định nhu cầu về chất lượng sản phẩm Tổ chức cuộc điều tra với quy mô lớn. Điều tra theo nhóm tập trung. Phương pháp xây mối quan hệ trực tiếp và lâu đời với khách hàng. www.themegallery.com
43. LOGOwww.themegallery.com
Bạn đang đọc nội dung bài viết Chương 1: Yêu Cầu Phần Mềm trên website Photomarathonasia.com. Hy vọng một phần nào đó những thông tin mà chúng tôi đã cung cấp là rất hữu ích với bạn. Nếu nội dung bài viết hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!