HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG VIỆN KINH TẾ BƯU ĐIỆN -----🙞🙜🕮🙞🙜----- IMFORMATION SYSTEM ANALYSIS & DESIGN BÀI TẬP 1 NHÓM MÔN HỌC: 02 Giảng viên : Trần Đình Quế Sinh viên : Vũ Thị Yến Mã số sinh viên : B20DCCN754 Nhóm bài tập lớn : 15 Lớp : D20CNPM05 BÀI TẬP 1: 1. Trình bày ngắn gọn (>2 trang) 4 pha trong framework phát triển yêu cầu phần mềm. Phát triển yêu cầu là một quá trình lặp đi lặp lại. Thu thập yêu cầu (Requirements Elicitation) - Xác định tầm nhìn và phạm vi dự án: làm rõ yêu cầu kinh doanh của sản phẩm thông qua tài liệu tầm nhìn và phạm vi.
Tầm nìn mô tả kết quả sản phẩm, phạm vi xác định ranh giới cho từng phiên bản hoặc vòng lặp vụ thể - Xác định lớp người dùng và đặc điểm của họ: Để không bỏ sót nhu cầu của bất kỳ người dùng nào, chúng ta phải xác định các nhóm người dùng khác nhau cho sản phẩm và mô tả đặc điểm của họ. - Chọn người biểu trưng cho từng lớp người dùng: Xác định người đại diện có thể đại diện cho từng lớp người dùng và thể hiện nhu cầu của họ. - Tổ chức cuộc họp tập trung với người dùng điển hình: Tổ chức các cuộc họp với người dùng trước đó hoặc các sản phẩm tương tự để thu thập ý kiến về chức năng và chất lượng sản phẩm. - Làm việc cùng với đại diện người dùng để xác định yêu cầu người dùng: Thảo luận với đại diện người dùng về nhiệm vụ họ cần hoàn thành và giá trị mà họ muốn đạt được.
- Xác định sự kiện và phản hồi của hệ thống: Liệt kê các sự kiện bên ngoài mà hệ thống có thể trải qua và phản hồi mong đợi cho mỗi sự kiện. - Thực hiện cuộc phỏng vấn để thu thập yêu cầu: Cuộc phỏng vấn có thể thực hiện một cách cá nhân hoặc nhóm nhỏ để thu thập yêu cầu cụ thể từ các bên liên quan. - Tổ chức các cuộc họp tập trung để thu thập yêu cầu: Cuộc họp tập trung dẫn dắt cho phép sự hợp tác giữa các nhà phân tích và khách hàng để tạo điều kiện để khám phá nhu cầu của người dùng và lập tài liệu yêu cầu. - Quan sát người dùng thực hiện công việc của họ: Theo dõi người dùng thực hiện nhiệm vụ kinh doanh của họ để thiết lập ngữ cảnh cho việc sử dụng sản phẩm.
- Phân phát các bảng câu hỏi: Sử dụng bảng câu hỏi để khảo sát các nhóm người dùng lớn để xác định nhu cầu của họ. - Thực hiện phân tích tài liệu hiện tại: Xem xét tài liệu hiện tại để hiểu cách hệ thống hoạt động hoặc những gì nó nên làm. - Kiểm tra các báo cáo vấn đề của các hệ thống hiện tại để tìm ý tưởng yêu cầu: Sử dụng báo cáo vấn đề và yêu cầu cải tiến từ người dùng để xác định tính năng để bao gồm trong sản phẩm mới. - Tái sử dụng yêu cầu hiện có: Xem xét khả năng tái sử dụng các yêu cầu đã có nếu chức năng tương tự được yêu cầu.
Phân tích yêu cầu (Requirements Analysis) Phân tích yêu cầu đòi hỏi việc làm rõ yêu cầu để đảm bảo tất cả các bên liên quan hiểu rõ chúng và kiểm tra chúng để tìm kiếm lỗi, thiếu sót và các vấn đề khác. Phân tích bao gồm việc phân rã các yêu cầu cấp cao thành các cấp độ chi tiết thích hợp, xây dựng mẫu thử nghiệm, đánh giá khả thi, và thương lượng về ưu tiên. Mục tiêu là phát triển các yêu cầu đủ chất lượng và chính xác để quản lý có thể xây dựng các ước tính dự án thực tế và nhân viên kỹ thuật có thể tiến hành thiết kế, xây dựng và kiểm thử. Việc biểu diễn một số yêu cầu dưới nhiều hình thức khác nhau rất quan trọng - ví dụ, cả trong hình thức văn bản và hình thức hình ảnh hoặc trong hình thức yêu cầu và kiểm thử.
Những cách biểu diễn khác nhau này sẽ tiết lộ thông tin và vấn đề mà không một cách biểu diễn đơn lẻ nào có thể cung cấp. - Mô hình môi trường ứng dụng: Context diagram là một mô hình phân tích đơn giản thể hiện cách hệ thống mới phù hợp với môi trường của nó. Nó xác định ranh giới và giao diện giữa hệ thống đang được phát triển và các thực thể bên ngoài như người dùng, thiết bị phần cứng và các hệ thống khác. Một bản đồ hệ sinh thái hiển thị các hệ thống khác nhau trong không gian giải pháp tương tác với nhau và tính chất của các kết nối của chúng.
- Tạo giao diện người dùng và mẫu thử nghiệm kỹ thuật: Khi nhà phát triển hoặc người dùng không chắc chắn về yêu cầu, họ sẽ xây dựng một mẫu thử nghiệm để làm cho các khái niệm và khả năng trở nên cụ thể hơn. Mẫu thử nghiệm cho phép nhà phát triển và người dùng đạt được sự hiểu biết chung về vấn đề đang được giải quyết, cũng như giúp xác thực yêu cầu. - Phân tích khả thi về yêu cầu: BA nên làm việc cùng với nhà phát triển để đánh giá khả năng thực hiện mỗi yêu cầu với chi phí và hiệu suất chấp nhận được trong môi trường hoạt động dự định. Điều này cho phép các bên liên quan hiểu về các rủi ro liên quan đến việc thực hiện mỗi yêu cầu.
- Ưu tiên các yêu cầu: Quá trình ưu tiên yêu cầu rất quan trọng để đảm bảo nhóm triển khai các chức năng có giá trị cao nhất hoặc cần thiết nhất trước hết. Áp dụng một phương pháp phân tích để xác định sự ưu tiên tương đối trong việc triển khai các tính năng sản phẩm, các trường hợp sử dụng, câu chuyện người dùng hoặc yêu cầu chức năng. Dựa trên mức độ ưu tiên, xác định phiên bản hoặc giai đoạn nào sẽ chứa mỗi tính năng hoặc tập hợp yêu cầu. - Tạo từ điển dữ liệu: Định nghĩa các mục dữ liệu và cấu trúc liên quan đến hệ thống nằm trong từ điển dữ liệu.
Điều này cho phép tất cả mọi người làm việc trên dự án sử dụng các định nghĩa dữ liệu nhất quán. Khi yêu cầu được phát triển, từ điển dữ liệu nên xác định các mục dữ liệu từ lĩnh vực vấn đề để tạo điều kiện cho việc giao tiếp giữa khách hàng và nhóm phát triển. - Mô hình hóa yêu cầu: Một mô hình phân tích là một biểu đồ thể hiện yêu cầu một cách hình ảnh, trái ngược với biểu diễn văn bản của danh sách yêu cầu chức năng. Các mô hình có thể tiết lộ yêu cầu sai, không nhất quán, thiếu sót và thừa thải.
- Phân tích giao diện giữa hệ thống của bạn và thế giới bên ngoài: Tất cả các hệ thống phần mềm đều có kết nối với các phần khác trong thế giới bên ngoài thông qua giao diện bên ngoài. Hệ thống thông tin có giao diện người dùng và thường trao đổi dữ liệu với các hệ thống phần mềm khác. Hệ thống nhúng liên quan đến sự kết nối giữa phần mềm và các thành phần phần cứng. Ứng dụng kết nối mạng có giao diện truyền thông.
- Phân bổ yêu cầu cho các hệ thống con: Các yêu cầu cho một sản phẩm phức tạp chứa nhiều hệ thống con phải được chia phần cho các hệ thống con và các thành phần phần mềm, phần cứng và con người. Một ví dụ về sản phẩm như vậy là hệ thống truy cập vào một tòa nhà an ninh bảo mật bao gồm các thẻ từ từ tích hợp, máy quét, máy quay video và máy ghi âm, khóa cửa và người bảo vệ. Xác định yêu cầu (Requirements Specification) Yêu cầu chi tiết về chức năng và không chức năng của phần mềm được ghi lại trong một tài liệu yêu cầu phần mềm (SRS) hoặc một kho lưu trữ thay thế, như một công cụ quản lý yêu cầu. - Sử dụng mẫu tài liệu yêu cầu: Sử dụng các mẫu tiêu chuẩn cho việc ghi chép yêu cầu trong tổ chức của bạn để đảm bảo cấu trúc đồng nhất cho việc ghi chép các thông tin liên quan đến yêu cầu.
- Xác định nguồn gốc của yêu cầu: Theo dõi mỗi yêu cầu để biết tại sao mỗi yêu cầu đó cần thiết. Điều này có thể là từ một trường hợp sử dụng hoặc phản hồi từ khách hàng, một yêu cầu hệ thống cấp cao hoặc một quy tắc kinh doanh. Xác định nguồn gốc của yêu cầu giúp khi cần thay đổi. - Gán nhãn định danh duy nhất cho mỗi yêu cầu: Định nghĩa một quy ước để gán cho mỗi yêu cầu một nhãn định danh duy nhất.
Điều này giúp theo dõi yêu cầu và ghi chép các thay đổi. - Ghi chép các quy tắc kinh doanh: Quy tắc kinh doanh bao gồm các chính sách doanh nghiệp, quy định của chính phủ, tiêu chuẩn và thuật toán tính toán. Hãy tài liệu riêng về các quy tắc kinh doanh bởi vì chúng thường tồn tại ngoài phạm vi của một dự án cụ thể. Một số quy tắc sẽ dẫn đến các yêu cầu chức năng để thực thi chúng, vì vậy xác định các liên kết theo dõi giữa các yêu cầu và các quy tắc tương ứng.
- Xác định yêu cầu không chức năng: Để tránh triển khai một giải pháp chỉ đúng công việc của nó mà không đáp ứng kỳ vọng về chất lượng của người dùng, bạn cần đánh giá các đặc điểm chất lượng quan trọng. Điều này bao gồm hiệu suất, độ tin cậy, tính sử dụng, khả năng sửa đổi và nhiều yếu tố khác. Việc chỉ định các yêu cầu không chức năng là quan trọng để đảm bảo sự thành công của sản. Xác minh yêu cầu (Requirements Validation) Xác thực đảm bảo rằng các yêu cầu là chính xác, thể hiện các đặc điểm chất lượng mong muốn và sẽ đáp ứng nhu cầu của khách hàng.
Bạn cần phải sửa những vấn đề này nếu muốn các yêu cầu đóng vai trò là một nền tảng đáng tin cậy cho thiết kế, kiểm tra hệ thống cuối cùng và kiểm tra chấp nhận của người dùng. - Xem xét yêu cầu: Xem xét yêu cầu là một bước quan trọng để tìm ra các lỗi và không rõ ràng. Việc này có thể bao gồm kiểm tra yêu cầu bằng cách sử dụng kiểm tra đồng nghiệp hoặc kiểm tra cẩn thận hơn được gọi là "inspection". Đội ngũ kiểm tra nên đại diện cho các góc độ khác nhau như nhà phân tích, khách hàng, nhà phát triển và người kiểm thử.
- Kiểm tra yêu cầu: Tạo các bài kiểm tra dựa trên yêu cầu người dùng để xác định cách kiểm tra tính đúng đắn của chức năng được triển khai. Duyệt qua các bài kiểm tra với khách hàng để đảm bảo rằng chúng phản ánh mong đợi của người dùng.
