Phân tích yêu cầu phần mềm với ví dụ
Charles Moore
⚡ Tóm tắt thông minh
Phân tích yêu cầu phần mềm chia nhu cầu của các bên liên quan thành các yêu cầu chức năng và phi chức năng, xếp hạng chúng ở cấp độ nghiệp vụ, kiến trúc và hệ thống, sau đó kiểm tra từng yêu cầu dựa trên các thuộc tính chất lượng để đảm bảo tính khả kiểm thử. tracThông số kỹ thuật có thể ưu tiên.
Yêu cầu phần mềm là một nhu cầu chức năng hoặc phi chức năng cần được thực hiện trong hệ thống. Chức năng có nghĩa là cung cấp một dịch vụ cụ thể cho người dùng.
Ví dụ, trong bối cảnh của một ứng dụng ngân hàng, yêu cầu chức năng là khi khách hàng chọn “Xem số dư”, họ sẽ có thể xem số dư tài khoản mới nhất của mình.
Yêu cầu phần mềm cũng có thể là yêu cầu phi chức năng, chẳng hạn như yêu cầu về hiệu suất. Ví dụ, một yêu cầu phi chức năng có thể nêu rằng mọi trang của hệ thống phải tải cho người dùng trong vòng 5 giây.
Nên về cơ bản Yêu cầu phần mềm là một
- Chức năng hoặc
- Phi chức năng
nhu cầu phải được triển khai vào hệ thống. Các yêu cầu phần mềm thường được diễn đạt dưới dạng các câu phát biểu.
Các loại yêu cầu
Yêu cầu kinh doanhĐây là những yêu cầu cấp cao được trích từ bản kế hoạch kinh doanh của dự án. Ví dụ, một hệ thống dịch vụ ngân hàng di động cung cấp dịch vụ ngân hàng cho khu vực Đông Nam Á. Yêu cầu kinh doanh được xác định cho Ấn Độ là tóm tắt tài khoản và chuyển khoản, trong khi đối với Trung Quốc là tóm tắt tài khoản và thanh toán hóa đơn.
| Địa chỉ | Công ty cung cấp các chức năng hoặc dịch vụ ngân hàng |
|---|---|
| Ấn Độ | Tóm tắt tài khoản và chuyển tiền |
| Trung Quốc | Tóm tắt tài khoản và Bill THANH TOÁN |
ArchiYêu cầu về kiến trúc và thiết kếCác yêu cầu này chi tiết hơn các yêu cầu nghiệp vụ và định hướng kiến trúc giải pháp. Chúng xác định thiết kế tổng thể cần thiết để thực hiện yêu cầu nghiệp vụ. Đối với một tổ chức giáo dục, các trường hợp sử dụng kiến trúc và thiết kế điển hình bao gồm đăng nhập, chi tiết khóa học và ghi danh. Yêu cầu sẽ được thể hiện như bên dưới.
| Trường hợp sử dụng ngân hàng | Hạng mục |
|---|---|
| Bill THANH TOÁN | Ca sử dụng này mô tả cách khách hàng có thể đăng nhập vào ngân hàng trực tuyến và sử dụng Bill Tiện ích thanh toán. Khách hàng có thể xem bảng điều khiển các hóa đơn chưa thanh toán của các nhà cung cấp dịch vụ đã đăng ký. Khách hàng có thể thêm, sửa đổi và xóa thông tin chi tiết của nhà cung cấp dịch vụ. Khách hàng có thể thiết lập cảnh báo SMS và email cho các hành động thanh toán khác nhau. Khách hàng có thể xem lịch sử các hóa đơn đã thanh toán trước đó. Các tác nhân bắt đầu trường hợp sử dụng này là khách hàng ngân hàng hoặc nhân viên hỗ trợ. |
Yêu cầu hệ thống và tích hợpỞ cấp độ thấp nhất, chúng ta có các yêu cầu về hệ thống và tích hợp. Nó cung cấp mô tả chi tiết về mọi yêu cầu. Các yêu cầu này có thể được ghi lại dưới dạng các câu chuyện người dùng được viết bằng ngôn ngữ kinh doanh thông thường. Các yêu cầu chứa nhiều chi tiết để các nhà phát triển có thể bắt đầu lập trình. Bill Ví dụ về mô-đun thanh toán bên dưới cho thấy yêu cầu thêm người lập hóa đơn.
| Bill THANH TOÁN | Yêu cầu |
|---|---|
| Thêm Billngười | Tên nhà cung cấp dịch vụ tiện ích, Mã số khách hàng, Thanh toán tự động – Có/Không, Thanh toán toàn bộ Bill – Có/Không, Giới hạn thanh toán tự động – Không thanh toán nếu Bill vượt quá số lượng quy định |
Đôi khi, trong một dự án, bạn có thể không nhận được bất kỳ yêu cầu hoặc tài liệu nào để làm việc. Ngay cả khi đó, vẫn có những nguồn thông tin yêu cầu khác mà bạn có thể dựa vào để thiết kế phần mềm hoặc kiểm thử. Các nguồn yêu cầu khác mà bạn có thể dựa vào được liệt kê bên dưới.
Các nguồn yêu cầu khác
- Chuyển giao kiến thức từ đồng nghiệp hoặc nhân viên đang làm việc trong dự án đó
- Thảo luận dự án với chuyên viên phân tích kinh doanh, quản lý sản phẩm, trưởng dự án và các nhà phát triển.
- Phân tích phiên bản trước đó của hệ thống đã được triển khai.
- Phân tích các tài liệu yêu cầu cũ hơn từ dự án.
- RevXem lại các báo cáo lỗi trước đây; một số báo cáo lỗi được chuyển đổi thành yêu cầu cải tiến có thể được triển khai trong phiên bản hiện tại.
- Nếu có, hãy kiểm tra hướng dẫn cài đặt để xem cần thực hiện những bước cài đặt nào.
- Phân tích kiến thức chuyên môn hoặc ngành nghề mà nhóm đang cố gắng áp dụng.
Bất kể bạn sử dụng nguồn yêu cầu nào, hãy ghi chép chúng theo một định dạng chung và nhờ các thành viên nhóm giàu kinh nghiệm xem xét lại.
Cách phân tích yêu cầu
Hãy xem xét ví dụ về một hệ thống phần mềm giáo dục cho phép sinh viên đăng ký các khóa học khác nhau.
Chúng ta hãy cùng nghiên cứu cách phân tích các yêu cầu. Mỗi yêu cầu phải đáp ứng một tập hợp các thuộc tính chất lượng tiêu chuẩn, bao gồm những điều sau:
- Atomic
- Được xác định duy nhất
- Hoàn thành
- Nhất quán và rõ ràng
- Traccó thể
- Được ưu tiên
- Có thể kiểm tra
Bảng sau minh họa từng thuộc tính với ba cột:
- Cột đầu tiên cho biết- “chất lượng yêu cầu”
- Cột thứ hai cho biết- “yêu cầu không tốt và có một số vấn đề”
- Cột thứ ba thể hiện cùng một yêu cầu đó “đã được chuyển đổi thành một yêu cầu tốt”.
| Yêu cầu chất lượng | Ví dụ về yêu cầu xấu | Ví dụ về yêu cầu tốt |
|---|---|---|
| Atomic | Sinh viên có thể đăng ký các khóa học đại học và sau đại học | Sinh viên có thể đăng ký các khóa học bậc đại học. Sinh viên cũng có thể đăng ký các khóa học bậc sau đại học. |
| Được xác định duy nhất | 1- Sinh viên có thể đăng ký các khóa học bậc đại học. 1- Sinh viên có thể đăng ký các khóa học bậc sau đại học. | Đăng ký khóa học. Sinh viên có thể đăng ký các khóa học bậc đại học. Sinh viên có thể đăng ký các khóa học bậc sau đại học. |
| Hoàn thành | Người dùng giáo sư sẽ đăng nhập vào hệ thống bằng cách cung cấp tên người dùng, mật khẩu và các thông tin liên quan khác | Người dùng là giáo sư sẽ đăng nhập vào hệ thống bằng cách cung cấp tên người dùng, mật khẩu và mã khoa của mình |
| Nhất quán và rõ ràng | Một sinh viên sẽ có 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 phải cả hai. Một số khóa học sẽ được mở cho cả bậc đại học và sau đại học | Một sinh viên sẽ có bằng đại học hoặc sau đại học nhưng không phải cả hai |
| Traccó thể | Duy trì ánh xạ thông tin sinh viên tới BRD req.ID? | Duy trì thông tin sinh viên-Ánh xạ tới BRD yêu cầu ID 4.1 |
| Được ưu tiên | Đăng ký sinh viên - Ưu tiên 1. Duy trì thông tin người dùng - Ưu tiên 1. Ghi danh khóa học - Ưu tiên 1. Xem bảng điểm - Ưu tiên 1 | Đăng ký sinh viên - Ưu tiên 1. Duy trì thông tin người dùng - Ưu tiên 2. Ghi danh khóa học - Ưu tiên 1. Xem bảng điểm - Ưu tiên 3. |
| Có thể kiểm tra | Mỗi trang của hệ thống sẽ tải trong khung thời gian chấp nhận được | Các trang đăng ký học viên và đăng ký khóa học của hệ thống sẽ tải trong vòng 5 giây |
Chúng ta hãy cùng tìm hiểu chi tiết hơn về từng thuộc tính này, bắt đầu từ... Atomic.
Atomic
Mỗi yêu cầu phải mang tính nguyên tử, nghĩa là nó phải ở mức độ chi tiết thấp nhất và không thể chia nhỏ hơn nữa thành các thành phần. Các ví dụ sau đây so sánh các yêu cầu nguyên tử và không nguyên tử.
Tiếp tục với ví dụ về hệ thống trong lĩnh vực giáo dục: Ở đây, yêu cầu không tốt là “Sinh viên sẽ có thể đăng ký các khóa học đại học và sau đại học”. Đây là một yêu cầu không tốt vì nó không mang tính nguyên tử — nó trộn lẫn hai thực thể khác nhau, các khóa học đại học và sau đại học. Yêu cầu tốt tương ứng sẽ tách nó thành hai yêu cầu riêng biệt. Một yêu cầu bao gồm việc đăng ký các khóa học đại học, và yêu cầu còn lại bao gồm việc đăng ký các khóa học sau đại học.
Được xác định duy nhất
Thuộc tính chất lượng tiếp theo là định danh duy nhất. Trong ví dụ không tốt, hai yêu cầu riêng biệt cùng chia sẻ một ID#1. Nếu một nhóm tham chiếu đến một yêu cầu bằng ID của nó, sẽ không rõ yêu cầu nào trong hai yêu cầu đó được đề cập. Yêu cầu tốt sẽ nhóm chúng lại dưới Mục 1 — Đăng ký Khóa học, với các yêu cầu phụ 1.1 (đăng ký các khóa học đại học) và 1.2 (đăng ký các khóa học sau đại học).
Hoàn thành
Mỗi yêu cầu cần phải đầy đủ. Ví dụ, yêu cầu không tốt ở đây nói rằng “người dùng là giáo sư sẽ đăng nhập vào hệ thống bằng cách cung cấp tên người dùng, mật khẩu và các thông tin liên quan khác”. Cụm từ “các thông tin liên quan khác” quá mơ hồ. Một yêu cầu đầy đủ sẽ liệt kê chính xác các trường thông tin mà giáo sư phải cung cấp, chẳng hạn như mã bộ môn.
Nhất quán và rõ ràng
Mọi yêu cầu cần phải nhất quán và rõ ràng. Trong ví dụ không tốt, một yêu cầu nêu rõ “Sinh viên sẽ học các môn đại học hoặc sau đại học, chứ không phải cả hai”, trong khi một yêu cầu khác lại nêu “Một số môn học sẽ dành cho cả sinh viên đại học và sau đại học”.
Yêu cầu đầu tiên ngụ ý rằng các khóa học được chia thành hai loại riêng biệt, nhưng yêu cầu thứ hai lại mâu thuẫn với điều đó bằng cách mở một số khóa học cho cả hai nhóm.
Yêu cầu hợp lý này giải quyết mâu thuẫn bằng cách nêu rõ rằng mỗi khóa học được phân loại là bậc đại học hoặc sau đại học, và sinh viên chỉ có thể đăng ký các khóa học thuộc một trong hai loại này.
Traccó thể
Mọi yêu cầu phải được tracCó thể thực hiện được vì các yêu cầu tồn tại ở nhiều cấp độ: nghiệp vụ, kiến trúc và thiết kế, và hệ thống và tích hợp.
Khi bạn chuyển đổi yêu cầu kinh doanh thành yêu cầu kiến trúc và thiết kế, hoặc chuyển đổi yêu cầu kiến trúc và thiết kế thành yêu cầu hệ thống và tích hợp, tracTính khả thi phải được bảo toàn. Mỗi yêu cầu nghiệp vụ nên tương ứng với một hoặc nhiều yêu cầu kiến trúc và thiết kế. Trong ví dụ không tốt “Duy trì thông tin sinh viên – được ánh xạ tới ID yêu cầu BRD?”, ID yêu cầu bị thiếu.
Bản ghi yêu cầu tốt ghi lại cùng một tuyên bố nhưng được ánh xạ rõ ràng đến ID yêu cầu BRD 4.1. Mỗi yêu cầu phải mang một tracbản đồ khả năngpingCác yêu cầu về hệ thống và tích hợp cũng cần phải tương ứng với mã lập trình thực hiện chúng và các trường hợp kiểm thử để xác minh chúng.
TracDo đó, tính khả thi được áp dụng xuyên suốt toàn bộ dự án.
Được ưu tiên
Mỗi yêu cầu phải được ưu tiên để nhóm biết nên thực hiện việc nào trước và việc nào có thể chờ. Trong ví dụ không tốt, các chức năng Đăng ký sinh viên, Cập nhật thông tin người dùng, Ghi danh khóa học và Xem bảng điểm đều được đặt ở mức Ưu tiên 1. Không thể mọi thứ đều là Ưu tiên 1, vì vậy các yêu cầu phải được xếp hạng một cách thực tế. Ví dụ tốt sẽ đặt Đăng ký sinh viên và Ghi danh khóa học ở mức Ưu tiên cao nhất là 1, Cập nhật thông tin người dùng là Ưu tiên 2, và Xem bảng điểm là Ưu tiên 3.
Có thể kiểm tra
Mọi yêu cầu đều phải có thể kiểm thử được. Ví dụ tồi, “mỗi trang của hệ thống sẽ tải trong một khung thời gian chấp nhận được”, không thể kiểm thử được vì hai lý do. Thứ nhất, “mỗi trang” có thể có nghĩa là hàng chục trang, điều này làm tăng đáng kể nỗ lực kiểm thử. Thứ hai, “khung thời gian chấp nhận được” không được định nghĩa – chấp nhận được đối với ai, và so với tiêu chuẩn nào? Yêu cầu tốt khắc phục cả hai vấn đề bằng cách nêu tên các trang cụ thể (“trang đăng ký sinh viên và trang ghi danh khóa học”) và đặt mục tiêu có thể đo lường được là 5 giây.
