Yêu cầu phần mềm

Các yêu cầu phần mềm là mô tả các tính năng và chức năng của hệ thống đích. Các yêu cầu chuyển tải những mong đợi của người dùng từ sản phẩm phần mềm. Các yêu cầu có thể rõ ràng hoặc ẩn, đã biết hoặc chưa biết, mong đợi hoặc bất ngờ theo quan điểm của khách hàng.

Kỹ thuật yêu cầu

Quá trình thu thập các yêu cầu phần mềm từ khách hàng, phân tích và ghi lại chúng được gọi là kỹ thuật yêu cầu.

Mục tiêu của kỹ thuật yêu cầu là phát triển và duy trì tài liệu 'Đặc tả yêu cầu hệ thống' phức tạp và mang tính mô tả.

Quy trình kỹ thuật yêu cầu

Đây là một quy trình bốn bước, bao gồm:

Nghiên cứu khả thi
Thu thập các yêu cầu
những yêu cầu chi tiết của phần mềm
Xác thực yêu cầu phần mềm

Hãy để chúng tôi xem quy trình ngắn gọn -

Nghiên cứu khả thi

Khi khách hàng tiếp cận tổ chức để phát triển sản phẩm mong muốn, họ nảy ra ý tưởng sơ bộ về những gì tất cả các chức năng mà phần mềm phải thực hiện và tất cả các tính năng được mong đợi từ phần mềm.

Tham khảo thông tin này, các nhà phân tích thực hiện một nghiên cứu chi tiết về việc liệu hệ thống mong muốn và chức năng của nó có khả thi để phát triển hay không.

Nghiên cứu khả thi này tập trung vào mục tiêu của tổ chức. Nghiên cứu này phân tích liệu sản phẩm phần mềm có thể được hiện thực hóa trên thực tế về mặt thực hiện, đóng góp của dự án cho tổ chức, các ràng buộc chi phí và theo các giá trị và mục tiêu của tổ chức. Nó khám phá các khía cạnh kỹ thuật của dự án và sản phẩm như khả năng sử dụng, khả năng bảo trì, năng suất và khả năng tích hợp.

Đầu ra của giai đoạn này là một báo cáo nghiên cứu khả thi cần có các nhận xét và khuyến nghị đầy đủ cho ban quản lý về việc có nên thực hiện dự án hay không.

Thu thập các yêu cầu

Nếu báo cáo khả thi là tích cực đối với việc thực hiện dự án, giai đoạn tiếp theo bắt đầu với việc thu thập các yêu cầu từ người sử dụng. Các nhà phân tích và kỹ sư giao tiếp với khách hàng và người dùng cuối để biết ý tưởng của họ về những gì phần mềm nên cung cấp và những tính năng nào họ muốn phần mềm bao gồm.

những yêu cầu chi tiết của phần mềm

SRS là một tài liệu được tạo bởi nhà phân tích hệ thống sau khi các yêu cầu được thu thập từ các bên liên quan khác nhau.

SRS xác định cách phần mềm dự định sẽ tương tác với phần cứng, giao diện bên ngoài, tốc độ hoạt động, thời gian phản hồi của hệ thống, tính di động của phần mềm trên các nền tảng khác nhau, khả năng bảo trì, tốc độ phục hồi sau khi gặp sự cố, Bảo mật, Chất lượng, Hạn chế, v.v.

Các yêu cầu nhận được từ khách hàng được viết bằng ngôn ngữ tự nhiên. Người phân tích hệ thống có trách nhiệm ghi lại các yêu cầu bằng ngôn ngữ kỹ thuật để nhóm phát triển phần mềm có thể hiểu được và hữu ích.

SRS sẽ đưa ra các tính năng sau:

Yêu cầu của người dùng được thể hiện bằng ngôn ngữ tự nhiên.
Các yêu cầu kỹ thuật được thể hiện bằng ngôn ngữ có cấu trúc, được sử dụng bên trong tổ chức.
Mô tả thiết kế nên được viết bằng mã Pseudo.
Định dạng biểu mẫu và bản in màn hình GUI.
Ký hiệu điều kiện và toán học cho DFD, v.v.

Xác thực yêu cầu phần mềm

Sau khi các thông số kỹ thuật yêu cầu được phát triển, các yêu cầu được đề cập trong tài liệu này sẽ được xác nhận. Người dùng có thể yêu cầu giải pháp bất hợp pháp, không thực tế hoặc các chuyên gia có thể giải thích các yêu cầu không chính xác. Điều này dẫn đến việc tăng chi phí rất lớn nếu không được khai thác từ trong trứng nước. Các yêu cầu có thể được kiểm tra dựa trên các điều kiện sau:

Nếu chúng có thể được triển khai trên thực tế
Nếu chúng hợp lệ và theo chức năng và miền của phần mềm
Nếu có bất kỳ sự mơ hồ nào
Nếu chúng hoàn thành
Nếu chúng có thể được chứng minh

Quy trình kích thích yêu cầu

Quá trình kích thích yêu cầu có thể được mô tả bằng cách sử dụng sơ đồ folloiwng:

Requirements gathering - Các nhà phát triển thảo luận với khách hàng và người dùng cuối và biết mong đợi của họ từ phần mềm.
Organizing Requirements - Các nhà phát triển ưu tiên và sắp xếp các yêu cầu theo thứ tự quan trọng, khẩn cấp và thuận tiện.
Negotiation & discussion - Nếu các yêu cầu không rõ ràng hoặc có một số xung đột trong các yêu cầu của các bên liên quan khác nhau, nếu có, thì nó sẽ được thương lượng và thảo luận với các bên liên quan. Các yêu cầu sau đó có thể được ưu tiên và thỏa hiệp hợp lý.

Các yêu cầu đến từ các bên liên quan khác nhau. Để loại bỏ sự mơ hồ và xung đột, chúng được thảo luận để rõ ràng và đúng đắn. Các yêu cầu phi thực tế được thỏa hiệp một cách hợp lý.
Documentation - Tất cả các yêu cầu chính thức và không chính thức, chức năng và phi chức năng đều được lập thành văn bản và sẵn sàng cho quá trình xử lý giai đoạn tiếp theo.

Kỹ thuật kích thích yêu cầu

Yêu cầu Kích thích là quá trình tìm ra các yêu cầu đối với một hệ thống phần mềm dự kiến bằng cách giao tiếp với khách hàng, người dùng cuối, người dùng hệ thống và những người khác có cổ phần trong việc phát triển hệ thống phần mềm.

Có nhiều cách khác nhau để khám phá các yêu cầu

Phỏng vấn

Phỏng vấn là phương tiện mạnh mẽ để thu thập các yêu cầu. Tổ chức có thể tiến hành một số hình thức phỏng vấn như:

Phỏng vấn có cấu trúc (kín), trong đó mọi thông tin thu thập đều được quyết định trước, họ tuân theo khuôn mẫu và vấn đề thảo luận một cách chắc chắn.
Phỏng vấn không cấu trúc (mở), nơi thông tin thu thập không được quyết định trước, linh hoạt hơn và ít thiên vị hơn.
Phỏng vấn miệng
Phỏng vấn viết
Phỏng vấn 1-1 được tổ chức giữa hai người trên bàn.
Phỏng vấn nhóm được tổ chức giữa các nhóm người tham gia. Họ giúp phát hiện bất kỳ yêu cầu còn thiếu nào khi có nhiều người tham gia.

Khảo sát

Tổ chức có thể tiến hành khảo sát giữa các bên liên quan khác nhau bằng cách truy vấn về kỳ vọng và yêu cầu của họ từ hệ thống sắp tới.

Bảng câu hỏi

Một tài liệu với các câu hỏi khách quan được xác định trước và các phương án tương ứng được giao cho tất cả các bên liên quan trả lời, được thu thập và biên soạn.

Một thiếu sót của kỹ thuật này là, nếu một tùy chọn cho một số vấn đề không được đề cập trong bảng câu hỏi, vấn đề có thể bị bỏ mặc.

Phân tích công việc

Nhóm kỹ sư và nhà phát triển có thể phân tích hoạt động mà hệ thống mới được yêu cầu. Nếu khách hàng đã có một số phần mềm để thực hiện một số hoạt động nhất định, nó sẽ được nghiên cứu và thu thập các yêu cầu của hệ thống đề xuất.

Phân tích tên miền

Mọi phần mềm đều thuộc một số danh mục miền. Những người có chuyên môn trong lĩnh vực này có thể trợ giúp đắc lực để phân tích các yêu cầu chung và cụ thể.

Động não

Một cuộc tranh luận không chính thức được tổ chức giữa các bên liên quan khác nhau và tất cả các đầu vào của họ được ghi lại để phân tích các yêu cầu thêm.

Tạo mẫu

Prototyping là xây dựng giao diện người dùng mà không thêm chức năng chi tiết để người dùng diễn giải các tính năng của sản phẩm phần mềm dự định. Nó giúp đưa ra ý tưởng tốt hơn về các yêu cầu. Nếu không có phần mềm nào được cài đặt ở cuối máy khách để nhà phát triển tham khảo và khách hàng không biết về các yêu cầu của chính nó, nhà phát triển sẽ tạo một nguyên mẫu dựa trên các yêu cầu đã đề cập ban đầu. Nguyên mẫu được hiển thị cho khách hàng và phản hồi được ghi nhận. Phản hồi của khách hàng đóng vai trò là đầu vào để thu thập yêu cầu.

Quan sát

Nhóm chuyên gia đến thăm tổ chức hoặc nơi làm việc của khách hàng. Họ quan sát hoạt động thực tế của các hệ thống đã được cài đặt. Họ quan sát quy trình làm việc ở cuối của khách hàng và cách xử lý các vấn đề thực thi. Nhóm tự rút ra một số kết luận hỗ trợ hình thành các yêu cầu mong đợi từ phần mềm.

Đặc điểm yêu cầu phần mềm

Thu thập các yêu cầu phần mềm là nền tảng của toàn bộ dự án phát triển phần mềm. Do đó chúng phải rõ ràng, chính xác và được xác định rõ ràng.

Thông số kỹ thuật yêu cầu phần mềm hoàn chỉnh phải là:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Nguồn đáng tin cậy

Yêu cầu phần mềm

Chúng ta nên cố gắng hiểu những loại yêu cầu nào có thể phát sinh trong giai đoạn kích thích yêu cầu và những loại yêu cầu nào được mong đợi từ hệ thống phần mềm.

Nhìn chung, các yêu cầu phần mềm nên được phân loại thành hai loại:

Yêu cầu chức năng

Các yêu cầu liên quan đến khía cạnh chức năng của phần mềm thuộc loại này.

Chúng xác định các chức năng và chức năng bên trong và từ hệ thống phần mềm.

Ví dụ -

Tùy chọn tìm kiếm được cung cấp cho người dùng để tìm kiếm từ các hóa đơn khác nhau.
Người dùng sẽ có thể gửi bất kỳ báo cáo nào đến ban quản lý.
Người dùng có thể được chia thành các nhóm và các nhóm có thể được cấp các quyền riêng biệt.
Nên tuân thủ các quy tắc kinh doanh và chức năng quản trị.
Phần mềm được phát triển để giữ nguyên khả năng tương thích xuống.

Những yêu cầu phi lý

Các yêu cầu, không liên quan đến khía cạnh chức năng của phần mềm, thuộc loại này. Chúng là những đặc điểm tiềm ẩn hoặc được mong đợi của phần mềm mà người dùng đưa ra giả định.

Các yêu cầu phi chức năng bao gồm:

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Khôi phục thảm họa
Accessibility

Các yêu cầu được phân loại hợp lý như

Must Have : Không thể nói phần mềm hoạt động nếu không có chúng.
Should have : Nâng cao chức năng của phần mềm.
Could have : Phần mềm vẫn có thể hoạt động bình thường với các yêu cầu này.
Wish list : Các yêu cầu này không liên quan đến bất kỳ mục tiêu nào của phần mềm.

Trong khi phát triển phần mềm, "Phải có" phải được thực hiện, "Nên có" là một vấn đề tranh luận với các bên liên quan và phủ định, trong khi "có thể có" và "danh sách mong muốn" có thể được giữ để cập nhật phần mềm.

Yêu cầu về giao diện người dùng

Giao diện người dùng là một phần quan trọng của bất kỳ phần mềm hoặc phần cứng hoặc hệ thống lai nào. Một phần mềm được chấp nhận rộng rãi nếu nó -

dễ dàng hoạt động
phản hồi nhanh chóng
xử lý hiệu quả các lỗi vận hành
cung cấp giao diện người dùng đơn giản nhưng nhất quán

Sự chấp nhận của người dùng chủ yếu phụ thuộc vào cách người dùng có thể sử dụng phần mềm. Giao diện người dùng là cách duy nhất để người dùng cảm nhận hệ thống. Một hệ thống phần mềm hoạt động tốt cũng phải được trang bị giao diện người dùng hấp dẫn, rõ ràng, nhất quán và đáp ứng. Nếu không, các chức năng của hệ thống phần mềm không thể được sử dụng một cách thuận tiện. Một hệ thống được cho là tốt nếu nó cung cấp các phương tiện để sử dụng nó một cách hiệu quả. Các yêu cầu về giao diện người dùng được đề cập ngắn gọn bên dưới:

Nội dung trình bày
Điều hướng dễ dàng
Giao diện đơn giản
Responsive
Các phần tử giao diện người dùng nhất quán
Cơ chế phản hồi
Thiết lập mặc định
Bố cục có mục đích
Sử dụng màu sắc và kết cấu có chiến lược.
Cung cấp thông tin trợ giúp
Phương pháp lấy người dùng làm trung tâm
Cài đặt chế độ xem dựa trên nhóm.

Nhà phân tích hệ thống phần mềm

Nhà phân tích hệ thống trong một tổ chức CNTT là người phân tích yêu cầu của hệ thống được đề xuất và đảm bảo rằng các yêu cầu được hình thành và lập thành văn bản một cách hợp lý & chính xác. Vai trò của một nhà phân tích bắt đầu trong Giai đoạn Phân tích Phần mềm của SDLC. Người phân tích có trách nhiệm đảm bảo rằng phần mềm được phát triển đáp ứng các yêu cầu của khách hàng.

Nhà phân tích hệ thống có các trách nhiệm sau:

Phân tích và hiểu các yêu cầu của phần mềm dự định
Hiểu dự án sẽ đóng góp như thế nào trong các mục tiêu của tổ chức
Xác định các nguồn yêu cầu
Xác thực yêu cầu
Xây dựng và thực hiện kế hoạch quản lý yêu cầu
Tài liệu về yêu cầu kinh doanh, kỹ thuật, quy trình và sản phẩm
Phối hợp với khách hàng để ưu tiên các yêu cầu và loại bỏ và sự mơ hồ
Hoàn thiện các tiêu chí chấp nhận với khách hàng và các bên liên quan khác

Các thước đo và số liệu phần mềm

Các biện pháp phần mềm có thể được hiểu là một quá trình định lượng và ký hiệu các thuộc tính và khía cạnh khác nhau của phần mềm.

Số liệu phần mềm cung cấp các thước đo cho các khía cạnh khác nhau của quy trình phần mềm và sản phẩm phần mềm.

Các biện pháp phần mềm là yêu cầu cơ bản của kỹ thuật phần mềm. Chúng không chỉ giúp kiểm soát quá trình phát triển phần mềm mà còn giúp giữ cho chất lượng của sản phẩm cuối cùng xuất sắc.

Theo Tom DeMarco, một (Kỹ sư phần mềm), “Bạn không thể kiểm soát những gì bạn không thể đo lường.” Qua câu nói của ông, có thể thấy rất rõ các biện pháp phần mềm quan trọng như thế nào.

Hãy cho chúng tôi xem một số chỉ số phần mềm:

Size Metrics - LOC (Dòng mã), hầu hết được tính bằng hàng nghìn dòng mã nguồn được phân phối, được ký hiệu là KLOC.

Số điểm chức năng là thước đo chức năng được cung cấp bởi phần mềm. Chức năng Số điểm xác định kích thước của khía cạnh chức năng của phần mềm.
Complexity Metrics - Độ phức tạp Cyclomatic của McCabe định lượng giới hạn trên của số lượng đường dẫn độc lập trong một chương trình, được coi là độ phức tạp của chương trình hoặc các mô-đun của nó. Nó được biểu diễn dưới dạng các khái niệm lý thuyết đồ thị bằng cách sử dụng đồ thị luồng điều khiển.
Quality Metrics - Các khuyết tật, dạng và nguyên nhân của chúng, hậu quả, mức độ nghiêm trọng và tác động của chúng xác định chất lượng của sản phẩm.

Số lượng khuyết tật được tìm thấy trong quá trình phát triển và số lượng lỗi được khách hàng báo cáo sau khi sản phẩm được lắp đặt hoặc giao hàng tại khách hàng, xác định chất lượng của sản phẩm.
Process Metrics - Trong các giai đoạn khác nhau của SDLC, các phương pháp và công cụ được sử dụng, tiêu chuẩn công ty và hiệu suất phát triển là các thước đo quy trình phần mềm.
Resource Metrics - Nỗ lực, thời gian và các nguồn lực khác nhau được sử dụng, đại diện cho các số liệu đo lường nguồn lực.