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 mục tiêu. Yêu cầu truyền đạt 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 tiềm ẩn, đã biết hoặc chưa biết, được mong đợi hoặc không mong muốn 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
Đó là một quy trình gồm 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 quá 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ọ sẽ nảy ra ý tưởng sơ bộ về 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 cụ thể hóa trên thực tế về mặt triển khai, đóng góp của dự án cho tổ chức, hạn chế về chi phí và theo các giá trị và mục tiêu của tổ chức hay không. 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 phải là một báo cáo nghiên cứu khả thi bao gồm 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 tích cực đối với việc thực hiện dự án, giai đoạn tiếp theo sẽ bắt đầu với việc thu thập các yêu cầu từ người 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 sẽ 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 nhiều nền tảng khác nhau, khả năng bảo trì, tốc độ phục hồi sau 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. Nhà 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 và sử dụng chúng.
SRS sẽ đưa ra các tính năng sau:
- Yêu cầu 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ã giả.
- Định dạng của Biểu mẫu và bản in màn hình GUI.
- Các ký hiệu có đ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 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 đượ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 sự gia tăng lớn về chi phí nếu không được cắt giảm từ trong trứng nước. Các yêu cầu có thể được kiểm tra đối với các điều kiện sau –
- Nếu chúng có thể được thực hiện 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 khơi gợi yêu cầu
Quá trình khơi gợi yêu cầu có thể được mô tả bằng sơ đồ sau:
- Thu thập yêu cầu – 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 những kỳ vọng của họ từ phần mềm.
- Tổ chức các yêu cầu – 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.
- Đàm phán & thảo luận – Nếu các yêu cầu không rõ ràng hoặc có một số mâu thuẫn trong yêu cầu của các bên liên quan khác nhau, nếu có, thì sẽ được đàm phán 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à mâu thuẫn, chúng được thảo luận cho rõ ràng và đúng đắn. Những yêu cầu phi thực tế được thỏa hiệp một cách hợp lý.
- Tài liệu hóa – 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 ghi lại và cung cấp cho giai đoạn xử lý tiếp theo.
Kỹ thuật khơi gợi yêu cầu
Đánh giá yêu cầu là quá trình tìm ra các yêu cầu cho một hệ thống phần mềm dự định 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ó lợi ích 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 hiệu quả để thu thập các yêu cầu. Tổ chức có thể tiến hành một số loại phỏng vấn như:
- Các cuộc phỏng vấn có cấu trúc (đóng), trong đó mọi thông tin đơn lẻ cần thu thập đều được quyết định trước, chúng 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 phi cấu trúc (mở), trong đó thông tin cần 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 bằng văn bản
- Các cuộc phỏng vấn một đối một đượ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. Chúng giúp phát hiện ra 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ọ đối với hệ thống sắp tới.
bảng câu hỏi
Một tài liệu với bộ câu hỏi khách quan được xác định trước và các tùy chọn tương ứng được chuyển 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, thì vấn đề đó có thể bị bỏ ngỏ.
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 được đề xuất.
Phân tích tên miền
Mỗi phần mềm rơi vào một số loại miền. Những chuyên gia trong lĩnh vực này có thể giúp ích rất nhiều để 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 tiếp theo.
nguyên mẫu
Tạo mẫu là xây dựng giao diện người dùng mà không cần 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 nhận thức được các yêu cầu của riêng mình, thì 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 đề 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ài đặt hiện có. Họ quan sát quy trình làm việc ở cuối máy khách 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à:
- Thông thoáng
- Chính xác
- Nhất quán
- mạch lạc
- dễ hiểu
- có thể sửa đổi
- có thể kiểm chứng
- ưu tiên
- rõ ràng
- có thể theo dõi
- nguồn đáng tin cậy
Yêu cầu phần mềm
Chúng ta nên cố gắng hiểu loại yêu cầu nào có thể phát sinh trong giai đoạn khơi gợi yêu cầu và loại yêu cầu nào được mong đợi từ hệ thống phần mềm.
Nói 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 cho 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 trao 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 hướng 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à các đặc điểm tiềm ẩn hoặc được mong đợi của phần mềm mà người dùng giả định.
Các yêu cầu phi chức năng bao gồm –
- Bảo vệ
- ghi nhật ký
- Kho
- Cấu hình
- Hiệu suất
- Trị giá
- khả năng tương tác
- Uyển chuyển
- khắc phục thảm họa
- khả năng tiếp cận
Các yêu cầu được phân loại một cách logic thành
- Phải có : Phần mềm không thể hoạt động mà không có chúng.
- Nên có : Nâng cao chức năng của phần mềm.
- Có thể có : Phần mềm vẫn có thể hoạt động đúng với các yêu cầu này.
- Danh sách mong muốn : Những yêu cầu này không ánh xạ tới 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 triển khai, ‘Phải có’ là vấn đề tranh luận giữa 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ữ lại để cập nhật phần mềm.
Yêu cầu 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
- nhanh chóng trong phản ứ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. UI 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. Mặt khác, 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 phương tiện để sử dụng nó một cách hiệu quả. Yêu cầu giao diện người dùng được đề cập ngắn gọn bên dưới –
- trình bày nội dung
- Điều hướng dễ dàng
- giao diện đơn giản
- Phản ứng nhanh nhẹn
- Các yếu tố UI nhất quán
- cơ chế phản hồi
- Thiết lập mặc định
- Bố cục có mục đích
- Chiến lược sử dụng màu sắc và kết cấu.
- Cung cấp thông tin trợ giúp
- Cách tiếp cận 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à ghi lại đúng cách & chính xác. Vai trò của nhà phân tích bắt đầu trong Giai đoạn Phân tích Phần mềm của SDLC. Nhà 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.
Chuyên viên phân tích hệ thống có các nhiệm vụ 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 nguồn yêu cầu
- Xác thực yêu cầu
- Xây dựng và triển khai kế hoạch quản lý yêu cầu
- Tài liệu về các 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
Số liệu và biện pháp 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à tượng trưng cho 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 biện pháp 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 công nghệ 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 hỗ trợ duy trì chất lượng tuyệt vời của sản phẩm cuối cùng.
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 anh ấy, rất rõ ràng 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ố số liệu phần mềm:
- Số liệu kích thước – 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.
- Độ phức tạp 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.
- Các thước đo chất lượng – Các khuyết tật, loại 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ỗi được tìm thấy trong quá trình phát triển và số lỗi được khách hàng báo cáo sau khi sản phẩm được cài đặt hoặc giao cho khách hàng, xác định chất lượng của sản phẩm.
- Số liệu quy trình – 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, các tiêu chuẩn của công ty và hiệu suất phát triển là các số liệu quy trình phần mềm.
- Số liệu tài nguyên – Nỗ lực, thời gian và các tài nguyên khác nhau được sử dụng, đại diện cho các số liệu để đo lường tài nguyên.