Phân tích yêu cầu phần mềm với ví dụ
Charles Moore
Ví dụ: trong bối cảnh ứng dụng ngân hàng, yêu cầu chức năng sẽ là khi khách hàng chọn “Xem số dư”, họ phải có khả năng 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, nó có thể là yêu cầu về hiệu suất. Ví dụ: yêu cầu phi chức năng là mọi trang của hệ thống sẽ hiển thị 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. Yêu cầu phần mềm thường được thể hiện dưới dạng một tuyên bố.
Các loại yêu cầu
- Yêu cầu kinh doanh: Chúng là các yêu cầu cấp cao được lấy từ trường hợp kinh doanh của các 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 Đông Nam Á. Yêu cầu kinh doanh được quyết định cho Ấn Độ là tóm tắt tài khoản và chuyển tiền trong khi đối với Trung Quốc, tóm tắt tài khoản và thanh toán hóa đơn được quyết định là yêu cầu kinh doanh
| Quốc gia | 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 kinh doanh. Nó xác định thiết kế tổng thể cần thiết để triển khai yêu cầu kinh doanh. Đối với tổ chức giáo dục của chúng tôi, các trường hợp sử dụng kiến trúc và thiết kế sẽ là đăng nhập, chi tiết khóa học, v.v. Yêu cầu sẽ như được hiển thị bên dưới.
| Trường hợp sử dụng ngân hàng | Yêu cầu |
|---|---|
| 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 Cơ sở thanh toán.
Khách hàng có thể xem bảng thông tin về các hóa đơn chưa thanh toán của người lập hóa đơn đã đăng ký. Khách hàng có thể thêm, sửa đổi và xóa chi tiết người lập hóa đơn. Khách hàng có thể cấu hình tin nhắn SMS, cảnh báo qua email cho các hành động lập hóa đơ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 ca sử dụng này là khách hàng của ngân hàng hoặc nhân viên hỗ trợ. |
- Yêu cầu hệ thống và tích hợp: Ở mức thấp nhất, chúng ta có các yêu cầu về hệ thống và tích hợp. Đó là mô tả chi tiết về từng yêu cầu. Nó có thể ở dạng các câu chuyện của người dùng thực sự mô tả ngôn ngữ kinh doanh hàng ngày. Các yêu cầu được trình bày chi tiết để các nhà phát triển có thể bắt đầu viết mã. Dưới đây là ví dụ về Bill Mô-đun thanh toán trong đó yêu cầu sẽ được đề cập để thêm Biller
| Bill THANH TOÁN | Yêu cầu |
|---|---|
| Thêm Billers |
|
Đôi khi đối với một số 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. Tuy nhiên, vẫn có những nguồn yêu cầu khác mà bạn có thể xem xét về yêu cầu hoặc thông tin để bạn có thể đặt phần mềm hoặc thiết kế thử nghiệm của mình dựa trên những yêu cầu này. Vì vậy, các nguồn yêu cầu khác mà bạn có thể dựa vào là
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 đó
- Trao đổi về dự án với nhà phân tích kinh doanh, giám đốc sản phẩm, trưởng dự án và nhà phát triển
- Phân tích phiên bản hệ thống trước đó đã được triển khai vào hệ thống
- Phân tích tài liệu yêu cầu cũ của dự án
- Xem xét các báo cáo Lỗi trước đây, một số báo cáo lỗi được chuyển thành yêu cầu nâng cao và có thể được triển khai trong phiên bản hiện tại
- Xem hướng dẫn cài đặt nếu có để biết yêu cầu cài đặt là gì
- Phân tích kiến thức về lĩnh vực hoặc ngành mà nhóm đang cố gắng triển khai
Bất kể nguồn yêu cầu nào bạn nhận được, hãy đảm bảo ghi lại chúng dưới một số hình thức, để chúng được xem xét từ các thành viên nhóm có kinh nghiệm và hiểu biết khác.
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 nơi sinh viên có thể đăng ký các khóa học khác nhau.
Hãy nghiên cứu cách phân tích các yêu cầu. Các yêu cầu phải duy trì chất lượng tiêu chuẩn theo yêu cầu của nó, các loại chất lượng yêu cầu khác nhau bao gồm
- Atomic
- Được xác định duy nhất
- Hoàn thành
- Nhất quán và rõ ràng
- Có thể truy nguyên
- Được ưu tiên
- Có thể kiểm tra
Hãy hiểu điều này bằng một ví dụ, có ba cột trong bảng hiển thị ở đây,
- 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 giống như cột thứ hai nhưng – “chuyển thành 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 |
|
|
| Được xác định duy nhất | 1- Sinh viên sẽ có thể đăng ký các khóa học đại học1- Sinh viên sẽ có thể đăng ký các khóa họ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 |
| Có thể truy nguyên | 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 | Sinh viên đã đăng ký-Ưu tiên 1Duy trì thông tin người dùng-Ưu tiên 1Đăng ký khóa học-Ưu tiên 1Xem Phiếu điểm-Ưu tiên 1 | Đăng ký Sinh viên-Ưu tiên 1Duy trì thông tin người dùng-Ưu tiên 2Đăng ký khóa học-Ưu tiên 1Xem Phiếu điểm-Ưu tiên3 |
| 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 |
Bây giờ chúng ta hãy hiểu từng yêu cầu này một cách chi tiết bắt đầu bằng Atomic.
Atomic
Vì vậy, mỗi yêu cầu bạn có phải là nguyên tử, nghĩa là nó phải ở mức độ chi tiết rất thấp, không thể tách thành các thành phần. Ở đây chúng ta sẽ xem hai ví dụ về yêu cầu, tại Atomic và các mức yêu cầu được xác định duy nhất.
Vậy chúng ta hãy tiếp tục với ví dụ về xây dựng hệ thống cho 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 phải là nguyên tử vì nó nói về hai thực thể khác nhau là khóa học đại học và sau đại học. Vì vậy, rõ ràng đây không phải là một yêu cầu tốt mà là yêu cầu không tốt, vì vậy yêu cầu tốt tương ứng sẽ là tách nó thành hai yêu cầu. Vì vậy, một yêu cầu nói về việc đăng ký các khóa học đại học trong khi yêu cầu kia nói về việc đăng ký các khóa học sau đại học.
Được xác định duy nhất
Tương tự, chất lượng yêu cầu tiếp theo là kiểm tra xem có xác định duy nhất hay không, ở đây chúng tôi có hai yêu cầu riêng biệt nhưng cả hai đều có cùng ID#1. Vì vậy, nếu chúng tôi đang đề cập đến yêu cầu của mình bằng cách tham chiếu đến ID#, nhưng không rõ yêu cầu chính xác nào thì chúng tôi đang đề cập đến tài liệu hoặc phần khác của hệ thống vì cả hai đều có cùng ID#1. Vì vậy, tách ra bằng các id duy nhất, vì vậy yêu cầu tốt sẽ được trả lại dưới dạng đăng ký khóa học phần 1 và nó có hai yêu cầu 1.1 id là đăng ký các khóa học đại học trong khi 1.2 id là đăng ký các khóa học sau đại học.
Hoàn thành
Ngoài ra, mọi yêu cầu đều phải đầy đủ. Ví dụ, ở đây yêu cầu xấu nói rằng “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”. Ở đây, các thông tin liên quan khác không rõ ràng, vì vậy các thông tin liên quan khác cần được trình bày rõ ràng trong yêu cầu để hoàn thiện yêu cầu.
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, vì vậy, ví dụ ở đây chúng tôi có các yêu cầu “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” đây là một yêu cầu, có một số yêu cầu khác nói rằng “Một số khóa học sẽ mở cửa cho cả sinh viên đại học và sau đại học”.
Vấn đề trong yêu cầu này là ở chỗ từ yêu cầu đầu tiên, dường như các khóa học được chia thành hai loại theo các khóa học sau đại học và các khóa học sau đại học và sinh viên có thể chọn một trong hai nhưng không được chọn cả hai. Nhưng khi bạn đọc yêu cầu khác, nó xung đột với yêu cầu đầu tiên và nó cho biết rằng một số khóa học sẽ mở cho cả sau đại học và đại học.
Vì vậy, việc chuyển yêu cầu xấu này thành yêu cầu tốt là điều hiển nhiên, đó là “Sinh viên sẽ học các khóa đạ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 đánh dấu là khóa học đại học hoặc khóa học sau đại học
Có thể truy nguyên
Mỗi yêu cầu đều phải có thể theo dõi được vì đã có nhiều cấp độ yêu cầu khác nhau, chúng ta đã thấy rằng ở cấp cao nhất, chúng ta có các yêu cầu về kinh doanh, sau đó là các yêu cầu về kiến trúc và thiết kế, tiếp theo là các yêu cầu về tích hợp hệ thống.
Bây giờ khi chúng ta 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 chúng ta chuyển đổi yêu cầu kiến trúc và thiết kế thành yêu cầu tích hợp hệ thống thì phải có khả năng truy xuất nguồn gốc. Điều đó có nghĩa là chúng ta phải có thể lấy từng yêu cầu kinh doanh và ánh xạ chúng đến một hoặc nhiều yêu cầu kiến trúc và thiết kế phần mềm tương ứng. Vì vậy, đây là một ví dụ về yêu cầu không tốt có nội dung là "Duy trì thông tin sinh viên - ánh xạ đến ID yêu cầu BRD?" ID yêu cầu không được cung cấp ở đây.
Vì vậy, việc chuyển đổi nó thành một yêu cầu tốt, nó cũng có nội dung tương tự nhưng nó được ánh xạ với id yêu cầu 4.1. Vì vậy, việc lập bản đồ phải có sẵn cho từng yêu cầu. Tương tự như cách chúng ta có yêu cầu ánh xạ cấp cao và cấp thấp, ánh xạ cũng có giữa yêu cầu hệ thống và tích hợp với mã thực hiện yêu cầu đó và cũng có ánh xạ giữa hệ thống và yêu cầu tích hợp với trường hợp thử nghiệm kiểm tra yêu cầu cụ thể đó .
Vì vậy khả năng truy xuất nguồn gốc này được thực hiện xuyên suốt toàn bộ dự án
Được ưu tiên
| Được ưu tiên | Sinh viên đã đăng ký-Ưu tiên 1 Duy trì thông tin người dùng-Ưu tiên 1 Đăng ký khóa học-Ưu tiên 1 Xem Phiếu Báo Cáo-Ư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 Đăng ký khóa học-Ưu tiên 1 Xem Thẻ Báo Cáo-Ưu Tiên3 |
Sau đó, mỗi yêu cầu phải được ưu tiên, do đó nhóm có hướng dẫn về yêu cầu nào có thể triển khai trước và yêu cầu nào có thể thực hiện sau. Ở đây, bạn có thể thấy mức ưu tiên xấu là đăng ký sinh viên, duy trì thông tin người dùng và mỗi yêu cầu đều được ưu tiên-1. Mọi thứ không thể có cùng mức ưu tiên, do đó yêu cầu có thể được ưu tiên. Vì vậy, ví dụ về yêu cầu tốt ở đây là đăng ký sinh viên và ghi danh khóa học được ưu tiên cao nhất là 1, trong khi duy trì thông tin người dùng được ưu tiên ở mức 2 và sau đó chúng ta có xem bảng điểm ở mức ưu tiên-3
Có thể kiểm tra
| 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 |
Mỗi yêu cầu đều phải có thể kiểm tra được, ở đây yêu cầu xấu là “mỗi trang của hệ thống sẽ tải trong khung thời gian có thể chấp nhận được”. Bây giờ có hai vấn đề với yêu cầu này trước tiên là mỗi trang có nghĩa là có thể có nhiều trang, điều này sẽ làm bùng nổ nỗ lực thử nghiệm. Vấn đề khác là nó cho biết trang sẽ tải trong khung thời gian chấp nhận được, bây giờ khung thời gian chấp nhận được là bao nhiêu? Có thể chấp nhận được với ai Vì vậy, chúng ta phải chuyển đối số không thể kiểm tra thành đối số có thể kiểm tra, trong đó cho biết cụ thể về trang mà chúng ta đang nói về “trang đăng ký sinh viên và đăng ký khóa học” và khung thời gian chấp nhận được cũng được đưa ra là 5 giây.
Kết luận
Vì vậy, đây là cách chúng ta phải xem xét từng yêu cầu ở mức độ phù hợp. Ví dụ, nếu chúng ta sẽ xây dựng một phần mềm liên quan đến các yêu cầu về hệ thống và tích hợp. Chúng ta phải xem xét các yêu cầu về hệ thống và tích hợp được đưa ra trong các thông số kỹ thuật yêu cầu phần mềm hoặc các câu chuyện của người dùng và áp dụng cho từng yêu cầu về chất lượng. Sau đó, hãy kiểm tra xem từng yêu cầu có nguyên tử, được xác định duy nhất và đầy đủ hay không, v.v.