Các kĩ thuật phát hiện yêu cầu

Các kĩ thuật phát yêu cầu Lam Quang Vu – SE Dept HCMUS Truong Phuoc Loc Tiến trình mẫu Requirements eli citati on User needs domain i nformation, exi sti ng system i nformation, regulations, standards, etc Requirements anal ysis and negotiation Requirements documentation Requirements val idati on Requirements document System specifi cati on Agreed requirements Phát hiệnPhân tíchĐàm phán:  Đặc điểm:  Lặp  Từng bước, khơng phải bước lớn  Các tiến trình phụ thuộc lẫn  Mỗi bước phụ thuộc lẫn  Lặp lại  Mỗi bước phải lặp lại  Kết đầu mẫu  Đề cuối  Đồng ý yêu cầu  Tài liệu tầm nhìn  Đặc tả yêu cầu phần mềm  Thiết kế mơ hình cấp cao  UML  Lược đồ mạng  Mơ hình đối tượng Nguồn yêu cầu: Khách hàng  Phỏng vấn khách hàng  Người trả tiền cho bạn  Các stakeholder  Người dùng  Nhà quản lí  Các vấn đề:  Khách hàng khơng biết muốn / cần  Phần mềm thường trừu tượng phức tạp  Thường thay đổi ý định  Có thể khơng diễn đạt nhu cầu thuật ngữ kĩ thuật  Vấn đề giao tiếp nhà khoa học máy tính người thường  Các kĩ thuật  mockups, nguyên mẫu  hướng dẫn bước  so sánh khác với hệ thống khác Nguồn yêu cầu: thị trường  Đánh giá sản phẩm cạnh tranh  Chuyện làm trước đó?  Thị trường ngách cho đâu?  Cần ý không vi phạm quyền, thương hiệu hay sang chế  Đánh giá khả  Chúng ta làm tốt đối thủ điểm nào?  Chúng ta có kiến thức, kĩ gì?  Khảo sát thị trường     Phỏng vấn khách hàng Khó để làm đúng; cơng ty thăm dò thị trường Marketing quảng cáo: tạo nhu cầu Xem xét xu hướng tương lai  Vấn đề:  Người ta khơng biết muốn  Ví dụ: video telephones  Thị trường thay đổi nhanh(UMTS) Nguồn yêu cầu: Các tiêu chuẩn  Các tiêu chuẩn hệ thống liên vận hành  Các tiêu chuẩn hệ thống, định dạng tập tin, giao thức mạng  Tiêu chuẩn tính tiện dụng  Các tiêu chuẩn miền  Các tiêu chuẩn thức  Viết nội dung chuẩn  ANSI  ISO (e.g Unicode)  IEEE (e.g Posix)  Các tiêu chuẩn công nghiệp  Wintel Platform  Java, Dot-Net  Giao diện Wimp Các loại yêu cầu  Chức  Các tính  Giao diện  input / output  Phi chức  Chất lượng người dùng  Hiệu  Độ xác  Độ tin cậy  Chất lượng nhà phát triển  Tính dễ bảo trì  Tính tái sử dụng  Khả liên vận hành Các kĩ thuật phát yêu cầu  Động não: Các phiên động não sử dụng để giúp stakeholder tìm ý tưởng sáng tạo cách tiếp cận cho vấn đề  Workshops: Workshops gặp điều phối có liên quan đến nhiều stakeholder để phác thảo tạo tài liệu yêu cầu Các kĩ thuật phát yêu cầu  Phỏng vấn: Phỏng vấn gặp cá nhân nơi mà nhà phân tích nghiệp vụ hỏi câu hỏi để lấy thơng tin từ stakeholder  Khảo sát: Khảo sát sử dụng để thu thập thông tin nặc danh từ stakeholder Các kĩ thuật phát yêu cầu  Xem xét lại tài liệu: Đây tiến trình đạt yêu cầu từ tài liệu viết ví dụ hướng dẫn sử dụng  Sử dụng nguyên mẫu: Sử dụng phiên hoàn thiện phần phần mềm để xác minh yêu cầu 10 Điều hành Workshop  Cho phép người hoạt động thư giãn  Đừng “tấn công” thành viên khác  Đừng nói lâu chủ đề chán  Đừng quay lại trễ sau nghỉ  Các luật workshop  Quay lại trễ sau nghỉ  Nói q nhiều  Khơng nói hết 20 Vấn đề đề nghị giải workshop  Quản lí thời gian  Rất khó để tiếp tục sau nghỉ hay ăn trưa  Các shareholders quay trở lại muộn  Các vị trí thống trị, đứng xem  Thiếu input từ stakeholders  Các nhận xét tiêu cực, hành động nhỏ nhen, chiến ganh đua  Năng lượng giảm sút sau ăn trưa  Người hướng dẫn phải có đồng hồ tính cho thời gian nghỉ phạt người trễ  Mọi người có phút củng cố quan điểm  Khuyến khích người sử dụng phút củng cố quan điểm  Ăn trưa nhẹ, nghỉ buổi chiều xếp lại chỗ ngồi 21 Chỉ dẫn phát yêu cầu1             Đánh giá tính khả thi hệ thống Cẩn trọng với suy xét trị tầm tổ chức Xác định xin ý kiến stakeholders hệ thống Ghi lại nguồn yêu cầu Sử dụng Business concerns để định hướng việc phát yêu cầu Tìm kiếm domain constraints Ghi lại rationale yêu cầu Thu thập yêu cầu từ nhiều quan điểm khác Tạo prototype cho yêu cầu khó hiểu Sử dụng scenarios để phát yêu cầu Định nghĩa operational processes Tái sử dụng lại yêu cầu 22 Xác định xin dẫn từ stakeholder hệ thống  Nếu khơng xem xét kĩ có khả bị ảnh hưởng qua việc giới thiệu hệ thống, nhiều khả ta bỏ sót yêu cầu quan trọng  “Xác định stakeholders thảo luận hệ thống với họ giúp người cảm thấy họ phần tiến trình phát yêu cầu Thực chất, điều khiến họ trở thành phần nó” 23 Sử dụng lợi ích nghiệp vụ để định hướng việc phát yêu cầu  Một hệ thống hữu ích đóng góp nhiều lợi ích quan trọng nghiệp vụ Nếu lợi ích xác định dùng định hướng cho tiến trình phát yêu cầu, nhiều khả hệ thống đáp ứng nhu cầu tổ chức  Việc xác định rõ rang lợi ích nghiệp vụ giúp tập trung làm rõ mục đích 24 Thu thập yêu cầu từ nhiều quan điểm khác  Nếu yêu cầu thu thập từ quan điểm, có khả khơng đáp ứng u cầu stakeholder  Dùng để xác định độ ưu tiên yêu cầu  Xác định quan điểm giúp  Tổ chức cách phát yêu cầu  Tổ chức đặc tả yêu cầu 25 Tái sử dụng yêu cầu  Tiết kiệm tiền thời gian Các nghiên cứu cho thấy hệ thống tương tự sử dụng 80% yêu cầu  Giảm thiểu rủi ro Các yêu cầu sử dụng lại nhiều khả hiểu tất stakeholder  Tái sử dụng thứ khác chu trình sống hoạt động  Thiết kế thành phần  Kiểm chứng  Lập trình 26 Kĩ thuật: Động não  Bao gồm tạo ý tưởng giảm bớt ý tưởng  Các ý tưởng sáng tạo thường hệ việc kết hợp ý tưởng khơng liên quan với  Có thể dùng kĩ thuật bỏ phiếu để xếp độ ưu tiên cho ý tưởng  Có thể động não trực tiếp thơng qua mạng vài tình 27 Các qui tắc động não      Khơng trích hay tranh luận Hãy để trí tưởng tượng bay cao Tạo nhiều ý tưởng tốt Hoán đổi kết hợp ý tưởng Loại bỏ bớt ý tưởng  Tỉa nhánh ý tưởng không đáng để thảo luận xa  Gom ý tưởng tương tự thành chủ đề lớn  Lập độ ưu tiên ý tưởng lại 28 Kĩ thuật: Tạo storyboard  Mục đích storyboard phát phản ứng “Đúng, nhưng…”  Có thể tích cực, chủ động hay thụ động  Dùng xác định người liên quan, giải thích với họ mô tả làm thứ diễn  Storyboard nên dạng phác thảo, dễ thay đổi  Tạo storyboard sớm thường xuyên cho dự án có nội dung 29 Kĩ thuật: Use Cases  Use Cases, giống storyboards, xác định ai, cách hệ thống hành xử  Use Cases mô tả tương tác người dùng hệ thống, tập trung vào mà hệ thống “làm” cho người dùng  Mơ hình Use Case mơ tả tính tổng thể hành vi chức hệ thống  Ở chặng đầu tiên: Sau bạn có nhìn tổng use case, mở rộng them chi tiết 10% cho use case  Chi tiết thêm slide sau… 30 Kĩ thuật: Đóng vai – Biến thể sử dụng use cases  Cho phép stakeholder trải nghiệm giới người dùng từ khía cạnh người dùng  Một hướng dẫn bước theo kịch thay cho nhập vai vài tình huống, kịch trở thành storyboard sống (Các thẻ Class-Responsibility-Collaboration (CRC), thường dùng phân tích hướng đối tượng, dạng nhập vai) 31 Kĩ thuật: Prototyping  Prototyping đặc biệt hiệu việc triệu chứng “Đúng, nhưng” “Undiscovered Ruins”  Prototype yêu cầu phần mềm cài đặt phận hệ thống phần mềm, tạo để giúp nhà phát triển, người dùng khách hang hiểu rõ yêu cầu hệ thống  Tạo nguyên mẫu cho yêu cầu “mờ”: yêu cầu biết rõ suy được, chưa hiểu định nghĩa tốt 32 Kĩ thuật: Khảo sát  Tham khảo:  http://www.surveysystem.com/sdesign.htm  http://www.surveyworld.org/good_survey.php ?t=4  Công cụ:  Google spread  http://www.createsurvey.com/  http://www.makesurvey.net/ 33 Refs  http://en.wikipedia.org/wiki/Software_prot otyping 34 ... hướng việc phát yêu cầu Tìm kiếm domain constraints Ghi lại rationale yêu cầu Thu thập yêu cầu từ nhiều quan điểm khác Tạo prototype cho yêu cầu khó hiểu Sử dụng scenarios để phát yêu cầu Định... ứng u cầu stakeholder  Dùng để xác định độ ưu tiên yêu cầu  Xác định quan điểm giúp  Tổ chức cách phát yêu cầu  Tổ chức đặc tả yêu cầu 25 Tái sử dụng yêu cầu  Tiết kiệm tiền thời gian Các. .. lượng nhà phát triển  Tính dễ bảo trì  Tính tái sử dụng  Khả liên vận hành Các kĩ thuật phát yêu cầu  Động não: Các phiên động não sử dụng để giúp stakeholder tìm ý tưởng sáng tạo cách tiếp