Top 2 # Yêu Cầu Chức Năng Của Phần Mềm Xem Nhiều Nhất, Mới Nhất 1/2023 # Top Trend | Theindochinaproject.com

Chương 1: Yêu Cầu Phần Mềm

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

Để mang đến 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 yêu cầu là khâu vô cùng quan trọng trong quá trình xây dựng phần mềm. Hoạt động này đòi hỏi sự phố kết hợp rất chặt chẽ giữa khách hàng và người phân tích để vạch ra được xem chúng ta phải phát triển cái gì

1 – Mục tiêu và yêu cầu của phần mềm:

Yêu cầu của phần mềm là tất cả các yêu cầu về phần mềm do người dùng nêu ra bao gồm các chức năng của phần mềm, hiệu năng của phần mềm, giao diện của phần mềm và một số các yêu cầu khác

Thông thường các yêu cầu phần mềm được phân loại dựa trên 4 thành phần của phần mềm như sau:

Các yêu cầu về phần mềm

Các yêu cầu về phần cứng

Các yêu cầu về dữ liệu

Các yêu cầu về con người

Mục tiêu quan trọng nhất đối với chất lượng phần mềm là phần mềm phải thỏa mãn được các yêu cầu và mong muốn của người dùng. Người dùng thường chỉ đưa ra những ý tưởng, nhiều khi rất mơ hồ về phần mềm mà họ mong muốn xây dựng. Và việc của các kỹ sư phát triển phần mềm đó là phải giúp họ đưa những ý tưởng mơ hồ đó thành hiện thực và xây dựng được một phần mềm có đầy đủ các tính năng cần thiết thỏa mãn yêu cầu của người dùng. Hơn thế nữa, ý tưởng của người dùng thường xuyên thay đổi và việc của nhà phát triển là phải nắm bắt và đáp ứng được các yêu cầu thay đổi đó một cách hợp lý.

2 – Những khó khăn trong việc phân tích, nắm bắt yêu cầu: 2.1 – Những vấn đề từ phía người dùng:

Người dùng không hiểu họ muốn gì

Người dùng liên tục thay đổi yêu cầu ngay cả khi việc phát triển sản phẩm đã được bắt đầu

Người dùng không hiểu về kỹ thuật

Người dùng không hiểu về quy trình phát triển

2.2 – Những vấn đề từ phía nhà phát triển:

Ngôn từ của người dùng và nhà phát triển không khớp nhau

Nhà phát triển cố lái cho yêu cầu của người dùng khớp với một hệ thống hay mô hình sẵn có thay vì phát triển một hệ thống theo nhu cầu của khách hàng

Việc phân tích có thể do các lập trình viên thực hiện thay vì các nhân viên có kỹ năng phân tích để có thể hiểu được nhu cầu của khách hàng một cách đúng đắn

2.3 – Những vấn đề khác:

Các yêu cầu thường mang tính đặc thù của tổ chức đặt hàng nó, do đó nó thường khó hiểu, khó định nghĩa và không theo một tiêu chuẩn nào cả

Các hệ thống thông tin lớn có rất nhiều người sử dụng, do đó các yêu cầu thường rất đa dạng và có các mức ưu tiên khác nhau, thậm chí mâu thuẫn lẫn nhau

Người đặt hàng nhiều khi là các nhà quản lý, không phải là người dùng thực sự do đó việc đưa ra các yêu cầu thường không chính xác

3 – Các giai đoạn trong phân tích yêu cầu:

Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển. Tài liệu mô tả yêu cầu phải vừa dễ hiểu với người dùng vừa chặt chẽ để làm cơ sở cho việc lập kế hoạch. Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau, nhiều giai đoạn khác nhau. Cụ thể như sau:

3.1 – Tìm hiểu các yêu cầu của phần mềm:

Các phương pháp để tìm hiểu các yêu cầu của phần mềm bao gồm:

Phỏng vấn, làm việc nhóm, họp và gặp gỡ đối tác…

Tìm kiếm các chuyên gia, người sử dụng có hiểu biết về hệ thống cần xây dựng để thu thập được nhiều ý kiến, đóng góp khác nhau

3.2 – Phân tích yêu cầu và thương lượng:

Sau khi tìm hiểu được các yêu cầu của phần mềm, chúng ta cần:

Thẩm định từng yêu cầu phần mềm để xác định xem chúng có khả năng thực hiện được hay không

Xác định các rủi ro có thể xảy ra với từng yêu cầu

Đưa ra các đánh giá tương đối về giá thành và thời gian thực hiện của từng yêu cầu

3.3 – Mô hình hóa yêu cầu:

Một số phương pháp hay dùng để mô hình hóa yêu cầu đó là:

a – Biểu đồ luồng dữ liệu Biểu đồ luồng dữ liệu (Data Flow Diagram – DFD) là một kỹ thuật để biểu diễn luồng thông tin vào ra của một chức năng trong hệ thống

Các thành phần biểu đồ luồng dữ liệu bao gồm:

Các chức năng cần xử lý

Luồng dữ liệu

Kho dữ liệu

Tác nhân: bao gồm tác nhân trong và tác nhân ngoài

Các ký hiệu được dùng trong biểu đồ luồng dữ liệu như sau:

b – Biểu đồ thực thể quan hệ

Mô hình quan hệ – thực thể ER (Entity Relationship Model) được sử dụng để thiết kế cơ sở dữ liệu ở mức khái niệm. Mô hình này được sử dụng như một công cụ để trao đổi ý tưởng giữa nhà thiết kế và người dùng cuối trong giai đoạn phân tích

Mô hình quan hệ – thực thể bao gồm ba phần tử cơ bản:

3.4 – Đặc tả yêu cầu:

a – Phân loại yêu cầu: Yêu cầu được chia thành nhiều loại:

Yêu cầu chức năng: Mô tả một chức năng cụ thể mà phần mềm cung cấp

Yêu cầu phi chức năng: Các ràng buộc về chất lượng, môi trường, chuẩn sử dụng, quy trình phát triển phần mềm

Yêu cầu về sản phẩm: Gồm tốc độ, độ tin cậy, bộ nhớ, giao diện, quy trình tác nghiệp,…

Yêu cầu về tiến trình phát triển: Gồm các chuẩn, phương pháp thiết kế, ngôn ngữ lập trình….

Yêu cầu khác: Gồm chi phí, thời gian, bản quyền,…

b – Đặc tả yêu cầu: Nếu như tài liệu xác định yêu cầu được viết bởi ngôn ngữ tự nhiên của khách hàng thì tài liệu đặc tả yêu cầu phải rất rõ ràng và được xây dựng theo hướng của người phát triển, tránh gây hiểu nhầm giữa khách hàng và người phát triển.

Có các phương pháp đặc tả như sau:

Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ tự nhiên

Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ đặc tả, công thức và biểu đồ

Đặc tả chức năng: Thông thường, khi đặc tả chức năng của phần mềm, người ta sử dụng các công cụ tiêu biểu sau: Biểu đồ phân rã chức năng (Functional Decomposition Diagram – FDD), Biểu đồ luồng dữ liệu (Data Flow Diagrams-DFD), Biểu đồ trạng thái,….

Đặc tả mô tả: Sử dụng các công cụ tiêu biểu sau: Biểu đồ thực thể liên kết (EntityRelationship Diagrams – ERD), Đặc tả logic (Logic Specifications), Đặc tả đại số (Algebraic Specifications)

Chất lượng cả bản đặc tả yêu cầu được đánh giá qua các tiêu chí sau:

Tính rõ ràng, chính xác

Tính phù hợp

Tính đầy đủ, hoàn thiện

c – Thẩm định yêu cầu: Sau khi các yêu cầu được xây dựng thì chúng cần được thẩm định xem đã thỏa mãn nhu cầu của khách hàng hay chưa. Nếu việc thẩm định không được thực hiện một cách nghiêm túc, chặt chẽ thì các sai sót sẽ có thể gây ra những hậu quả lớn cho các giai đoạn về sau.

Mục tiêu của việc thẩm định là xác định xem yêu cầu có thỏa mãn 4 yếu tố sau không:

Yêu cầu có thỏa mãn nhu cầu người dùng hay không?

Yêu cầu có mâu thuẫn với nhau hay không?

Yêu cầu có mô tả đầy đủ tất cả các chức năng và ràng buộc hay không?

Yêu cầu có đảm bảo các khía cạnh về kỹ thuật, kinh tế và pháp lý hay không?

d – Xây dựng bản mẫu:

Đối với các hệ thống phức tạp, nhiều khi chúng ta không nắm chắc được yêu cầu của khách hàng, chúng ta cũng khó đánh giá được tính khả thi cũng như hiệu quả của hệ thống. Một giải pháp được đưa ra là xây dựng bản mẫu. Bản mẫu vừa được dùng để phân tích yêu cầu vừa có thể tiến hóa thành sản phẩm cuối cùng. Bản mẫu phần mềm không phải nhằm vào việc thẩm định thiết kế (thiết kế của nó thường là hoàn toàn khác với hệ thống được phát triển cuối cùng), mà là để thẩm định yêu cầu của người sử dụng.

All Rights Reserved

Yêu Cầu Chức Năng Và Phi Chức Năng

Trong lĩnh vực phần mềm khái niệm “yêu cầu” là một trong những điều thường xuyên được nhắc đến. Trong đó, yêu cầu chức năng (functional) và yêu cầu phi chức năng (non-functional) là một trong những điều quan trọng nhất.

Khái niệm yêu cầu chức năng và yêu cầu phi chức năng đã có từ rất lâu. Tuy nhiên, nếu không hiểu rõ sẽ rất dễ dàng nhầm lẫn.

Nếu có một điều mà bất kì một phần mềm hoặc dự án nào cũng phải có nếu không muốn thất bại. Đó không thể là gì khác ngoài yêu cầu chức năng và yêu cầu phi chức năng.

Để đạt được sự thành công của phần mềm, hay dự án, đòi hỏi cả người dùng lẫn người lập trình đều phải hiểu được nó. Đây chính là lúc cần đến các yêu cầu để đảm bảo sự cần bằng từ hai bên.

1. Định nghĩa yêu cầu chức năng và yêu cầu phi chức năng

Tuy nhiên, điều gì thực sự khác nhau giữa yêu cầu chức năng và yêu cầu phi chức năng? Điều đó không có gì phức tạp, khi mà bạn hiểu được sự khác nhau thì mọi thứ sẽ trở nên rõ ràng.

1.1 Yêu cầu chức năng ( functional ) là gì?

Yêu cầu chức năng được định nghĩa là sự mô tả của chức năng hoặc dịch vụ của phần mềm hay hệ thống.

Thông thường, yêu cầu chức năng sẽ chỉ ra một hành vi hoặc một chức năng. Ví dụ phần mềm hay hệ thống phải có chức năng:

Hiển thị tên, kích thước, khoảng trống có sẵn và định dạng của một ổ đĩa flash được kết nối với cổng USB. Chức năng thêm khách hàng hay in hóa đơn.

Ví dụ: Yêu cầu chức năng của hộp sữa carton là có thể tích 400ml

Một vài yêu cầu chức năng phổ biến như là:

Nguyên tắc kinh doanh

Các giao dịch đúng, những sự điều chỉnh và hủy bỏ

Chức năng hành chính

Xác thực

Phần quyền

Theo dõi kiểm toán

Giao diện bên ngoài

Yêu cầu chứng chỉ

Yêu cầu báo cáo

Lịch sử dữ liệu

Yêu cầu pháp lí và quy định

1.2 Yêu cầu phi chức năng (Non-Functional) là gì?

Vậy còn Yêu cầu phi chức năng? Chúng là gì? Và chúng khác gì? Có thể nói một cách đơn giản rằng yêu cầu phi chức năng chỉ ra những quy định về tính chất và ràng buộc cho phần mềm hay hệ thống.

Yêu cầu phi chức năng bao gồm tất cả những yêu cầu mà yêu cầu chức năng không có. Chúng chỉ ra những tiêu chí để đánh giá hoạt động của hệ thống thay vì hành vi. Ví dụ:

Thay đổi dữ liệu trong cơ sở dữ liệu nên được cập nhật cho tất cả người dùng sử dụng hệ thống trong 2 giây.

Ví dụ: Yêu cầu phi chức năng của nón bảo hộ là chịu được sức ép 10,000PSI

Một vài yêu cầu phi chức năng phổ biến như:

Hiệu suất ví dụ như thời gian phản hồi, thông lượng, dùng trong việc gì, thể tích tĩnh

Khả năng mở rộng

Sức chứa

Độ khả dụng

Độ tin cậy

Khả năng phục hồi

Khả năng bảo trì

Dịch vụ có sẵn

An ninh

Quy định

Khả năng quản lí

Môi trường

Toàn vẹn dữ liệu

Khả năng sử dụng

Khả năng tương tác

Như đã nói ở trên, yêu cầu phi chức năng chỉ ra những đặc tính chất lượng hay các thuộc tính chất lượng.

Tầm quan trọng của yêu cầu phi chức năng là không thể xem thường. Có một cách chắc chắn để đảm bảo các yêu cầu phi chức năng không bị bỏ sót đó là sử dụng các nhóm yêu cầu phi chức năng.

2. Sự khác nhau giữa yêu cầu chức năng và yêu cầu phi chức năng

Như vậy, có thể thấy sự khác nhau rất rõ ràng giữa yêu cầu chức năng và yêu cầu phi chức năng. Trong đó:

Yêu cầu chức năng: mô tả chức năng hoặc dịch vụ của phần mềm hay hệ thống

Yêu cầu phi chức năng: mô tả những ràng buộc và tính chất của phần mềm hay hệ thống

Vì vậy, trong thực tế yêu cầu phi chức năng sẽ được đánh giá là có phần quan trọng hơn. Nếu không thỏa mãn được các yêu cầu này thì phần mềm hoặc hệ thống sẽ không thể đưa vào sử dụng.

Hiện nay, các khái niệm về yêu cầu đôi lúc gặp phải những khó khăn nhất định về rào cản ngôn ngữ. Tuy nhiên, để có thể đáp ứng chính xác nhu cầu phần mềm hay hệ thống đòi hỏi những yêu cầu phải thực sự rõ ràng.

Bài viết có sử dụng những phần dịch tiếng Việt để giúp bạn đọc có được cái nhìn trực quan nhất. Mong rằng những kiến thức trên sẽ hữu ích với các bạn, nếu có bất kì câu hỏi nào hãy để lại bên dưới bài viết này.

CÁC KHOÁ HỌC BUSINESS ANALYST chúng tôi DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.

– Biên tập nội dung BAC –

Chức Năng Của Phần Mềm Quản Lý Bán Hàng

Hiện nay, công nghệ thông tin ngày cành cho ra các sản phẩm mới, kéo theo đó là sự tich hợp công nghệ thông tin vào các ngành nghề khác. Như trong kinh doanh, bán hàng, các doanh nghiệp, cửa tiệm muốn bán hàng thì phải trang bị một phần mềm quả lý bán hàng. Phần Mềm Quản Lý Bán Hàng cung cấp đẩy đủ các tiện ích nhằm hỗ trợ người dùng quản lý tốt nhất công việc kinh doanh của mình. Những tiện ích nổi bật mà duy nhất chúng tôi cung cấp như là: mở rộng thị trường ra mạng internet, xây dựng website đính kèm, cung cấp các công cụ tìm kiếm khách hàng và xây dựng thương hiệu. Ngoài ra bạn có thể sử dụng sản phẩm của chúng tôi, mọi lúc mọi nơi thông qua mạng internet và các thiết bị di động… Một phần mềm online quản lý bán hàng sẽ giúp người quản lý rất nhiều trong việc kinh doanh buôn bán của mình.

1 tối ưu thời gian, nhân công và chi phí.

Dễ tháy nhất là tiết kiệm thời gian. Việc sử dụng một phần mềm quản lý bán hàng giúp giảm thời gian cho một giải pháp kinh doanh nhất định. Phần mềm này giúp các nhân xử lý các thông tin một cách nhanh chóng nhằm nhằm tiêt skieemj thời gian cho việc quản lý mặt hàng. Khi rút ngắn được khoản thời gian thì người quản lý có thể có nhiều thời gian để phục vụ, chăm sóc kkhacshhangf cũng như làm các việc khác đem lại lợi nhuận cho quán.

Bên cạnh đó phần mềm sẽ giúp người chủ tiết kiệm được một khoảng chi phí. Với cách quản lý thông thường thì người chủ phải thuê thêm nhiều nhân công để kimeer tả – quản lý mặt hàng. Chính vì thuê nhiều nhân công nên chi phí cho quán tăng lên. Nhưng bằng việc sử dụng phần mềm online quản lý bán hàng bạn có thể kiểm tra một cách nhanh chóng bằng các thao tác đơn giản với chiếc máy tính, hạn chế được việc thuê nhiều nhân công sẽ giúp bạn tiết kiệm rât nhiều chi phí.

2 phù họp vơi mọi người.

Niếu bạn là một người đang hay có ý định kinh doanh một mạt hàng gì đó, thì việc sử dụng một phần mềm quản lý bán hàng là rất phù hợp với xá hội hiện tại. Hiện nay thì các phần mềm bán hàng đang được tối ưu hóa nhằm tạo một môi trường, giao diện dễ dàng cho người quản lý dễ tiếp cận nhất có thể. Một lợi thế quan trọng của một phần mềm quản lý hoạt động bán hàng là nó có thể thay đổi để đáp ứng nhu cầu của một doanh nghiệp cụ thể. Việc sử dụng phần mềm này tương đối đơn giản và bạn có thể dễ dàng lên chương trình cho nó để đáp ứng nhu cầu cụ thể của doanh nghiệp.

3 Xử lý dữ liệu nhanh chóng, chính xác.

Là một phần mềm áp dụng sự phát triển của công nghệ thông tin cho nên việc xử lý một loạt số liệu với dữ liệu lớn là điều vô cùng dễ dàng. Việc thống kê số liệu giờ đay không còn là nỗi ám ảnh của người quản lý, bỡi với vài bước cơ bản là bạn có thể quản lý được số liệu mặt hàng của mình .Không những thế, khi bạn sử dụng một phần mềm quản lý bán hàng tốt thì việc mà bạn phải thường xuyên thông kế các loại sản phẩm bán ra hay các mặt hàng tồn đọng trong kho,… giờ đay máy tính sẽ thay thế bạn làm các việc đó một cách nhanh nhất, chính xác nhất.

Qua đó, có thể thấy được sự quan trọng mà một chương trình quản lý bán hàng mang lại, nó tạo nhiều hiệu quả tích cực cho công việc của bạn. Bạn có thể truy cập chúng tôi để được tư vấn về sản phẩm tốt nhất