Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm

Phần 1 Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm I. Giới thiệu 1. Mục đích Đưa ra các kĩ thuật phát hiện và tổng hợp các yêu cầu phần mềm. 2. Phạm vi Trong các dự án phần mềm 3. Tài liệu tham khảo • Managing Software RequirementsDean Leffingwell - Don Widrig II. Các kỹ thuật phát hiện và tổng hợp phần mềm 1. Kỹ thuật Phỏng vấn 1.1 Những điểm chính • Phỏng vấn là một kĩ thuật đơn giản và trực tiếp • Các câu hỏi về phạm vi tự do sẽ giúp đạt được xu hướng của cuộc vấn • Nó có thể thích hợp để tìm ra những yêu cầu chưa được phát hiện • Sự hội tụ trong một vài yêu cầu phổ biến sẽ tạo ra một kho các yêu cầu sử dụng trong suốt dự án. • Một sự nghi ngờ sẽ không được thay thế cho 1 cuộc phỏng vấn. 1.2 Các câu hỏi phạm vi tự do Làm sao để tránh sự định kiến của người sử dụng khi đáp ứng yêu cầu của các câu hỏi? Chúng ta dùng các câu hỏi về các vấn đề tự nhiên của người sử dụng mà không liên quan đến bất cứ phạm vi công việc nào. ví dụng như: • Ai là người sử dụng? • Ai là khách hàng? • Họ có cần một sự thay đổi? • Ở đâu khác có thể tìm một giải pháp cho vấn đề này? 1.3 Tạo thêm nội dung câu hỏi Trong quá trình tìm kiếm mà các yêu cầu chưa được phát hiện, chúng ta cũng có thể chuyển câu hỏi sang chủ đề khác , không nhất thiết bó buộc nội dung câu hỏi.Hãy tạo cảm giác thoải mái, cởi mở khi nói chuyện. 1.4 Một vài lời khuyên khi phỏng vấn Một vài lời khuyên cho một cuộc phỏng vấn thành công: • Sửa chữa các cuộc phỏng vấn tự do, và ghi nó vào một cuốn sách. • Trước khi phỏng vấn, tìm kiếm lại các tổ chức của nhà đầu tư và công ty được phỏng vấn. Đừng làm phiền người được phỏng vấn. • Nên ghi lại các câu trả lời vào trong sách. • Tham khảo các template trong suốt quá trình phỏng vấn. 1.5 Biên soạn lại các dữ liệu cần thiết 1.6 Chú ý vào những sự đáng ngờ 2. Kỹ thuật Hội thảo 2.1 Tổng quát • Những yêu câu hội thảo có lẽ là một kĩ thuật mạnh mẽ nhất để có thể phát hiện ra yêu cầu. • Nó tập hợp lại tất cả các nhà đầu tư chính cùng nhau trong một khoảng thời gian ngắn nhưng lại là giai đoạn tập trung nhất. • Sử dụng một tài liệu bên ngoài có kinh nghiệm trong việc quản lý yêu cầu và giúp đỡ cho một hội thảo thành công. • Thảo luận, góp ý là phần quan trọng nhất của hội thảo 2.2 Đẩy nhanh quá trình giải quyết Hỏi tất cả mọi người xem vấn đề chúng ta vừa đưa ra có đặc điểm nào cần bổ sung không trước khi đưa ra vấn đề tiếp theo. Các yêu cầu của một hội thảo có rất nhiều điểm phải phù hợp • Nó phải giúp đỡ xây dựng một đội hiệu quả, tận tâm cho một mục đích chung: thành công trong dự án này. • Tất cả mọi người đều được phát biểu. • Phải tiến tới một sự đồng thuận giữa nhà đầu tư và đội ngũ phát triển về việc ứng dụng này phải làm gì. • Có thể trình bày và giải quyết các vấn đề có thể gây trở ngại cho dự án thành công. • Đưa ra định nghĩa sơ bộ cho hệ thống. 2.3 Sửa chữa cho hội thảo • Đưa ra các khái niệm • Đảm bảo sự đóng góp của mọi người. • Hậu cần • Làm nóng bầu không khí. 2.4 Vai trò của sự thuận tiện Để đảm bảo thành công, chúng ta cần lời khuyên của những người bên ngoài, những người đã có kinh nghiệm trong quá trình quản lý các yêu cầu. Một vài điểm liên quan đến các sự thuận tiện: • Thiết lập một cuộc gặp mặt • Bắt đầu và kết thục đúng thời gian. • Thiết lập và đảm bảo quy tắc của cuộc họp. • Giới thiệu mục đích và lịch công tác của cuộc họp • Quản lý cuộc họp và giữ đội ngũ đi đúng hướng. • Sự thuận tiện trong quá trình quyết định và sự đồng lòng, tránh các nội dung khác biệt. • Đảm bảo lịch công tác đúng hướng. • Tất cả sự khác biệt giữa các nhà đầu tư phải được lắng nghe. • Kiểm soát các hành vi gây đổ vỡ và không mang lại giá trị. 2.5 Thiết lập nhật kí công tác Đảm bảo rằng tất cả thành viên liên quan đến dự án phải được nhận được lịch họp. Cố gắng sắp xếp sao cho mọi người có thể đến được. 2.6 Bắt đầu hội thảo - Thảo luận góp ý và các ý tưởng đưa ra. - Đưa ra các vấn đề và theo sau đó. 3. Kỹ thuật BrainStorming 3.1 Giới thiệu Brainstorming là một phương pháp đặc sắc dùng để phát triển nhiều giải pháp sáng tạo cho một vấn đề đặt ra. Ban đầu brainstroming được tạo ra để tìm ý tưởng trong làm việc theo nhóm. Alex F. Osborn đưa ra kỹ thuật này lần đầu tiên năm 1941, trong cuốn sách Applied Imagination.Alex F. Osborn đã miêu tả động não như là Một kĩ thuật hội ý bao gồm một nhóm người nhằm tìm ra lời giải cho vấn đề đặc trưng bằng cách góp nhặt tất cả ý kiến của nhóm người đó nảy sinh trong cùng một thời gian theo một nguyên tắc nhất định.Ngày nay phương pháp này đã được sử dụng rất phổ biến trong giảng dạy và sản xuất. Máy tính và các phần mềm hỗ trợ cũng được sử dụng cho brainstroming được hữu hiệu hơn. 3.2 Áp dụng 3.2.1 Định nghĩa vấn đề Vấn đề muốn giải quyết phải được xác định thật rõ ràng phải đưa ra được các chuẩn mực cần đạt được của một lời giải đáp. 3.2.2 Tập trung vào vấn đề Tránh các ý kiến hay các điều kiện bên ngoài có thể làm lạc hướng buổi làm việc. Trong giai đoạn này người ta thu thập tất cả các ý kiến và ngay cả các từ chuyên môn có liên quan trực tiếp đến vấn đề cần giải quyết (thường có thể viết lên giấy hoặc bảng tất cả). Những ý kiến này đều được xem là có vai trò ngang nhau không phân biệt chi tiết lớn nhỏ. Việc ghi chép ra bảng cũng không nhất thiết phải liệt kê hay sắp xếp theo trình tự nào hết. Không được phép đưa bất kì một bình luận hay phê phán gì về các ý kiến trong lúc thu thập. Những ý tưởng thoáng qua trong đầu nếu bị các thành kiến hay phê bình sẽ dễ bị gạt bỏ và như thế sẽ làm mất sự tổng quan . 3.2.3 Khuyến khích tình thần tích cực Mỗi thành viên đều cố gắng dóng góp và phát triển các ý kiến tùy theo trình độ, khía cạnh nhìn thấy riêng và không giới hạn cách nhìn của mỗi thành viên. Đưa ra càng nhiều ý càng tốt về mọi mặt của vấn đề kể cả những ý kiến không thực tiễn, ý kiến hoàn toàn lạ lẫm hay sáng tạo 3.3 Tiến hành Trong nhóm lựa ra một người đầu nhóm và một người thư kí để ghi lại tất cả ý kiến (cả hai công việc có thể do cùng một người thực hiện nếu tiện). Xác định vấn đề hay ý kiến .Phải làm cho mọi thành viên hiểu thấu đáo về đề tài sẽ được tìm hiểu. Thiết lập các quy định cho buổi họp,bao gồm: • Người đầu nhóm có nhiệm vụ điều khiển buổi làm việc. • Không một thành viên nào có quyền đòi hỏi hay cản trở, đánh giá, phê bình hay thêm bớt vào ý kiến, từ vựng nêu ra, hay giải đáp của thành viên khác. • Cần xác định rằng không có câu trả lời nào là sai! • Tất cả câu trả lời, các ý, các cụm từ, ngoại trừ nó đã được lập lại đều sẽ được thu thập ghi lại (cách ghi có thể tóm gọn trong một chữ hay một câu cho mỗi ý riêng rẽ). • Vạch định thời gian cho buổi làm việc và ngưng khi hết giờ. Bắt đầu brainstroming: Người lãnh đạo chỉ định hay lựa chọn thành viện chia sẻ ý kiến trả lời .Người thư kí phải viết xuống tất cả các câu trả lời, nếu có thể công khai hóa cho mọi người thấy (viết lên bảng chẳng hạn). Không cho phép bất kì một ý kiến đánh giá hay bình luận nào về bất kì câu trả lời nào cho đến khi chấm dứt buổi thảo luận. Sau khi kết thúc, hãy lượt lại tất cả và bắt đầu đánh giá các câu trả lời. Một số lưu ý về chất lượng câu trả lời bao gồm: • Tìm những câu ý trùng lặp hay tương tự để thu gọn lại. • Góp các câu trả lời có sư tương tự hay tương đồng về nguyên tắc hay nguyên lí.Xóa bỏ những ý kiến hoàn toàn không thích hợp. • Sau khi đã cô lập được danh sách các ý kiến, hãy bàn cãi thêm về câu trả lời chung. Trong khi áp dụng brainstroming tất cả các ý tưởng xuất hiện trong đầu của các thành viên trong nhóm sẽ được viết hay vẽ ra, thông thường là bút chì và giấy trắng. Người ta viết bất cứ thứ gì có trong đầu ra mặt giấy (brain dumping), không cần phải suy nghĩ nó là một ý tưởng tốt hay chỉ là một suy nghĩ thoảng qua trong đầu. Người ta cũng chẳng cần bận tâm đến việc thẩm mỹ của việc trình bày đó. Nếu cần diễn tả một hình ảnh, nó sẽ được phác họa thật nhanh chóng. Khi phát hiện ra mình viết sai thì cũng chẳng cần phải quay lại để sửa chữa, mà sẽ để suy nghĩ của mình được liên tục. Brainstroming không suy nghĩ về chỉ 1 thứ mà suy nghĩ đến tất cả những thứ có liên quan đến nó. Người ta cứ viết hay vẽ mà không cần dừng bút để suy nghĩ. Nếu bạn dừng bút trong khoảng thời gian dài hơn 10 giây, điều đó có nghĩa là bạn đã khai thác quá nhiều về ý tưởng đó, hãy lập tức bỏ qua một bên và quay sang những thứ liên quan khác, và rồi sẽ quay lại với nó ở giai đoạn sau. Mục đích của quá trình Brainstorming không phải là tìm được chính xác một ý tưởng hoàn thiện mà là đưa ra được càng nhiều ý tưởng càng tốt, do đó không nên e ngại khi viết ra những điều mà bình thường bạn nghĩ.Ngoài việc đưa ra thật nhiều ý tưởng, brainstorming còn giúp ta phân tích kỹ vấn đề, tự xem xét tất cả vấn đề có thể xảy ra khi trong khi ta liên tục đặt ra những câu hỏi. Ứng dụng: Brainstorming được sử dụng trong các công việc sau đây như phát triển sản phẩm mới; quảng cáo; giải quyết vấn đề; quá trình quản trị; quản trị dự án; xây dựng nhóm; xây dựng kế hoạch kinh doanh. Một vài nhận xét Phương pháp này có thể tiến hành bởi một hay nhiều người. Số lượng người tham gia nhiều sẽ giúp cho phương pháp tìm ra lời giải được nhanh hơn hay toàn diện hơn nhờ vào nhiều góc nhìn khác nhau bởi các trình độ, trình tự khác nhau của mỗi người.Ngày nay, người ta có thể tiến hành bằng cách nối các máy tính cá nhân vào chung một mạng làm cùng tiến hành brainstroming. Bằng cách này những người ở xa nhau cùng có thể tham gia và brainstroming còn được giúp đỡ bởi các phương tiện và tài nguyên hiện đại 4. Kỹ thuật StoryBoarding 4.1 Những điểm chính • Mục đích là đưa ra các phản ứng sớm “yes, but” • Kỹ thuật này có thể là thụ động, chủ động hay là kết hợp cả 2 yếu tố trên. • Kỹ thụât này nhận diện người chơi, giải thích những gì xảy ra với họ, xảy ra như thế nào • Tạo ra storyboard sơ sài, dễ sửa chữa. 4.2 Các loại StoryBoards • Storyboards dạng thụ động: là dạng storyboard để kể cho người dùng một kịch bản. Chúng có thể bao gồm các bản phác thảo, tranh ảnh, hình chụp màn hình, bản thuyết trình powerpoint, hoặc các mẫu đầu ra thử nghiệm. • Storyboards dạng chủ động: Storyboards chủ động là các hoạt cảnh hoặc tự động, có thể bằng một slide trình chiếu được sắp xếp tự dộng sẵn hoặc một công cụ tạo hoạt cảnh hay thậm chí là cả một thước phim. • Storyboards tương tác: để cho người dùng trải nghiệm hệ thống trong một cách thức giống với thực tế. Cách này đỏi hỏi phải có sự tham gia của người sử dụng để thực hiện được. Storyboards tương tác có thể giả lập hoặc tạo dựng mô hình hay có thể nâng cao tới mức mã dùng một lần (throwaway code). 4.3. StoryBoards làm những gì? Trong phần mềm, Storyboards được sử dụng thường xuyên để làm việc thông qua các chi tiết của giao diện tương người máy. Trong Lĩnh vực này, mỗi người có thể có ý kiến khác nhau về cách thức giao diện làm việc. Storyboards cho hệ thống người dùng xử lý với ba yêu tố của hoạt động • Người chơi là ai? • Điều gì xảy ra với họ? • Nó xảy ra như thế nào? 4.4. Công cụ và kỹ thuật cho StoryBoarding 5. Kỹ thuật Use Case Use cases là một biểu diễn UML cho các yêu cầu của một hệ thống. Để ghi nhận các yêu cầu cho hệ thống, use cases phát triển trong quá trình phát hiện sẽ có giá trị hơn nữa ngay cả trong quá trình phân tích và thiết kế. Phương pháp use-case rất mạnh mẽ trong suốt quá trình phát triển phần mềm, ví dụ như use cases đóng một vai trò quan trọng trong quá trình kiểm thử.Use cases miêu tả sự tương tác giữa user và hệ thống, và tập trung vào những gìhệ thống tương tác với user. Hơn nữa, khi các hành động được miêu tả theo một trình tự nối tiếp, sẽ là dễ dàng để theo dõi hành động và thu thập được sự hiểu biết về những gì hệ thống tương tác với user. Trong biểu đồ UML, use case được biểu diễn bằng một hình oval chứa tên của use case. 5.1 Xây dựng Use Case Mô hình use-case cho một hệ thống bao gồm tất cả actor của hệ thống và tất cả các use cases khác nhau mà theo đó các actor tương tác với hệ thống, theo cách đó miêu tả một cách toàn bộ hành vi chức năng của hệ thống. Mô hình use-case cũng biểu diễn mối quan hệ giữa các use cases, mà nằm ngoài sự hiểu biết của chúng ta về hệ thống. Đầu tiên là tạo biểu đồ mô tả ranh giới hệ thống và xác định các actor của hệ thống. Việc này tiến hành song song với việc xác định stakeholders và ranh giới hệ thống. Ví dụ một hệ thống quản lý kho hàng có thể có ranh giới hệ thống như hình sau: Hệ thống kho hành ban đầu với các actor được xác định.Việc phân tích hệ thống sâu hơn xác định những luồng nhất định của hành vi hệ thống là cần cho việc hỗ trợ nhu cầu người dùng. Những luồng này là các use cases, hoặc những trình tự cụ thể mà users tương tác với hệ thống để thực hiện một mục tiêu cụ thể. Các ví dụ của use cases cho hệ thống này có thể bao gồm: • Phân phối thủ công các mục trong kho hàng. • Nhập một mục mới trong kho hàng. • Kiểm tra các mục trong kho hàng. 5.2 Áp dụng Use Case vào phân tích yêu cầu phần mềm Use cases được viết theo ngôn ngữ tự nhiên của user nên rất dễ dàng để miêu tả vàlàm tài liệu. Use cases cung cấp một định dạng đơn giản và có cấu trúc xoay quanh việc nhóm phát triển và user có thể làm việc cùng nhau để mô tả hành vi của một hệ thống có sẵn hoặc định nghĩa hành vi của một hệ thống mới. Và mỗi user độc lập sẽ tự nhiên tập trung vào những khả năng hệ thống cần để thực hiện công việc tốt hơn. Ngoài ra, nếu các hành vi được phát hiện đầy đủ với tất cả các user tiềm năng, nhóm làm việc đã đi được một đường dài hướng tới mục tiêu của sự hiểu biết đầy đủ của các hành vi mong muốn. Ở đây có thể có một vài chức năng chưa được khám phá ở cuối quá trình. Chúng ta cũng phải hiểu rằng users của hệ thống chỉ biểu diễn một lớp của stakeholders, và chúng ta có thể cần phải áp dụng các kĩ thuật khác để thu thập yêu cầu từ những stakeholder khác như các khách hàng không phải người dùng, quản lý, nhà thầu phụ … Ngoài ra, use cases không hữu ích trong việc xác định các khía cạnh phi chức năng của yêu cầu hệ thống, như yêu cầu cho tính khả dụng, tính tin cậy, hiệu năng và tương tự. Chúng ta cần những kĩ thuật khác để giải quyết những vấn đề này. Sau khi tất cả use cases, actors và objects trong hệ thống được xác định, bước tiếp theo là cải tiến hành vi chức năng chi tiết của mỗi use-case. Đặc tả use-case này bao gồm miêu tả bằng văn bản và đồ họa của use-case, được viết từ góc nhìn của user. Đặc tả này có thể xem như là một container miêu tả một chuỗi các sự kiện lien quan, do đó có thể được dùng để bao hàm các yêu cầu khác sẽ được phát triển hơn nữa vào thời gian sau.Vì use cases định nghĩa tương tác hệ thống với user, đây là thời điểm thích hợp để định nghĩa, ít nhất là ở mức khái niệm, màn hình, các hiển thị, front panels … mà tương tác với user. Các thiết kế đồ họa chi tiết có thể để tới bước tiếp theo. Đặc tả use-case cho “Phân phối thủ công các mục trong kho hàng” 5.3 Role Playing Mặc dùng đúng là việc quan sát và đặt câu hỏi giúp chúng ta hiểu, nhưng sẽ là không đầy đủ nếu cho rằng, chỉ thông qua việc quan sát, các nhà phát triển và phân tích có thể đạt được một sự hiểu biết đúng đắn và sâu sắc của vấn đề được giải quyết, do đó, một sự hiểu biết rõ ràng về các yêu cầu của một hệ thống có thể giải quyết vấn đề này. • Chúng ta cần hiểu rằng rất nhiều người dùng không thể hiểu rõ các thủ tục họ làm theo hoặc yêu cầu cần được giải quyết. • Rất nhiều user không có tự do để thừa nhận rằng họ không theo những thủ tục được quy định, do đó những gì họ nói có thể không phải những gì họ thực sự làm. • Các cá nhân có những mẫu của hoạt động công việc đã ăn sâu và áp dụng cách giải quyết hoặc con đường duy nhất của việc thực thi công việc đó có thể che đậy vấn đề thực từ người quan sát. • Là không thể cho bất kì người phát triển nào để đự đoán tất cả các câu hỏi cần được hỏi hoặc cho bất kì user nào biết câu trả lời cho các câu hỏi của nhà phát triển. Để giải quyết các nguyên nhân riêng biệt này, một hoạt động đơn giản “role playing” có thể có hiệu quả mạnh mẽ. 5.3.1 How to Role Play Trong dạng đơn giản nhất của role playing, các nhà phát triển, nhà phân tích và có thể mọi thành viên của nhóm phát triển đơn giản là đảm nhiệm vị trí của user và thực thi hoạt động công việc của khách hàng. Có ít nhất hai cách để tìm thấy nguyên nhân cốt lõi: • Sử dụng kĩ thuật fishbone, cùng với phỏng vấn khách hàng, và phân tích các đơn đặt hàng có lỗi. Định lượng lỗi theo loại và giải quyết những lỗi có số lượng cao nhất trong thiết kế của hệ thống mới. Việc này có thể cung cấp một sự hiểu biết có định lượng cho vấn đề và có lẽ là khá hiệu quả.Tuy vậy, nếu không hiệu quả, bạn nên thay đổi cả quan điểm của bạn và chiến lược giải pháp của bạn. Để làm được điều đó, nên có một cách đơn giản và hiệu quả hơn để hiểu một cách rõ ràng về vấn đề. • Nhà phát triển, phân tích có thể trải nghiệm vấn đề và sai sót cố hữu trong hệ thống bằng việc thâm nhập vào một vài đơn hàng thực. 5.3.2 Các kĩ thuật khác tương tự 6. Kỹ thuật Prototyping 6.1 Các điểm chính • Prototyping (làm mẫu) cực kỳ hiệu quả trong việc xác định vị trí các hội chứng “Có,nhưng” (không chắc chắn, không bền, không đảm bảo tính lâu dài .) và “những thất bại vẫn chưa được phát hiện” (rủi ro tiềm tàng). • Một mẫu các yêu cầu phần mềm là một sự thi hành riêng lẻ của hệ thống phần mềm, được xây dựng để giúp đỡ các developers, người dùng và khách hàng hiểu tốt hơn về yêu cầu hệ thống. • Thực hiện làm mẫu các yêu cầu còn “mờ”, còn chưa rõ ràng: nhờ đó, mặc dù những điều đã biết hoặc còn “ẩn ý” vẫn chưa được định nghĩa hoặc còn được hiểu chưa rõ ràng. Các mẫu phần mềm là hiện thân sớm của hệ thống phần mềm, cho chúng ta ta một phần chức năng của một hệ thống mới.Mẫu thử cho phép người dùng có thể chạm, cảm nhận và tương tác với một hệ thống mẫu theo cách mà không một công nghệ nào khác có thể làm được. 6.2 Các kiểu mẫu thử Các mẫu thử có thể được phân loại theo nhiều cách (throwaway, evolutionary, operational, vertical, horizonal, userinterface algorithmic .). Tùy vào vấn đề cần giải quyết mà chúng ta xây dựng các mấu thử khác nhau. • Architectural prototype (mẫu thử hướng kiến trúc) – cho chúng ta thấy khả năng có thể thực thi được của công nghệ. • Throwaway prototype (mẫu thử dùng một lần) – sử dụng bất cứ công nghệ, sự mô phỏng . hay bất cứ cái gì để hoàn thiện kết quả của bạn. Mẫu chỉ dùng cho một mục đích, sau khi hoàn thành, mẫu sẽ được bỏ đi Nếu điểm yếu của dự án là giao diện người dùng, ngược lại bạn sẽ phát triển một mẫu thử yêu cầu (requirements prototype), sử dụng bất cứ công nghệ gì cho phép bạn làm mẫu giao diện nhanh nhất có thể. Sử dụng cây quyết định để chọn loại mẫu thử tốt nhất cho hệ thống phần mềm. Figure Decision tree for prototype selection: (a) requirements prototypes; (b) architectural prototypes Requirements Prototypes – Các mẫu thử yêu cầu [...]...Mẫu thử yêu cầu phần mềm (software requirements prototype) là sự thi hành cục bộ (riêng lẻ) của hệ thống phần mềm, được xây dựng để giúp các nhà phát triển (developers), người dùng (users) và khách hàng (customers) hiểu tốt hơn về yêu cầu của hệ thống Vì mục đích phát hiện ra các yêu cầu phần mềm, chúng ta thường chọn cách xây dựng các mẫu thử như “throwaway, horizonal(rộng),... dùng, do đó, những nhu cầu trước kia chưa biết sẽ “lộ ra” (become known) Đơn giản nhìn một tập các hành vi sẽ giúp người dùng hiểu những yêu cầu khác phải được đảm đương trong hệ thống Trong bất cứ trường hợp nào, Prototyping luôn luôn đưa ra được kết quả Do đó, bạn nên làm mẫu bất cứ ứng dụng mới nào • • III Sử dụng EA trong phát hiện và Tổng hợp yêu cầu 1 Sử dụng EA với kĩ thuật BrainStorming Sử... Horizonal prototypes (các mẫu thử rộng) ám chỉ rằng chúng ta sẽ thử xây dựng một dải khá rộng chức năng của hệ thống, ngược lại, vertical prototype xây dựng chỉ một vài yêu cầu nhưng theo một số phương pháp khá chất lượng User interface prototype ngụ ý rằng chúng ta sẽ xây dựng hầu hết các giao diện của hệ thống hơn là để người dùng thi hành các giải thuật và các logic xung quanh phần mềm hoặc làm cả mẫu... hoặc làm cả mẫu thử giao diện cho các hệ thống khác, thiết bị khác Khi là một công cụ khai thác, một mẫu thử giữ vai trò của nó theo vài cách khác nhau : Được xây dựng bởi người phát triển, nó có thể chứa sự xác nhận của khách hàng rằng người dùng đã hiểu yêu cầu • Được làm bởi người phát triển, nó có thể được dùng như xúc tác khuyến khích khách hàng nghĩ thêm các yêu cầu khác • Được làm bởi khách hàng,... đôi khi là miễn phí hỗ trợ việc xây dựng giao diện rất nhanh • Với các hệ thống có tương tác người dùng khá nhiều, một giao diện người dùng được làm mẫu sẽ khám phá ra rất nhiều các yêu cầu khác, như các chức năng đã được cung cấp tới cho người dùng, khi nào các chức năng sẵn sàng cho người sử dụng và khi nào các chức năng chưa xuất hiện với người dùng • Tuy nhiên, chúng ta cần chắc chắn rằng tính khả... phát triển Trong cả ba trường hợp, kết quả sẽ là xây dựng mẫu theo phương pháp tiêu tốn ít tài nguyên nhất Nếu nó quá đắt để xây dựng, nó có thể có hiệu quả hơn khi áp dụng vào hệ thống thật • Nhiều mẫu thử phần mềm xoay sang hướng mẫu thử yêu cầu và được sử dụng chủ yếu để nắm được diện mạo của giao diện hệ thống cần xây dựng Có hai lý do cho việc này : Có nhiều công cụ, có chi phí không quá đắt và. .. người dùng và kinh nghiệm của đội với một hệ thống cũng kiểu (Unknown requirements)Những yêu cầu chưa biết, mặc dù, là những rủi ro chưa được phát hiện (“Undiscovered Ruins”) mà chúng ta thường mong là sẽ biết đến sau đó Nhưng không may thay,chúng ta không thể làm những mẫu thế này, nếu có thể, chúng sẽ không còn là chưa biết tới nữa (unknown) Chính việc này đã đặt vị trí cho việc làm mẫu thử các phần “mờ”... cho các phần của hệ thống không có rủi ro cao nhất khi bắt đầu • Làm mẫu thử cho cái gì (What to prototype): Trong một tình huống cụ thể, chúng ta hiểu về những nhu cầu của người dùng sẽ có phạm vi từ hiễu rõ và dễ dàng diễn đạt tới không hiểu gì: Figure Continuum of understanding user needs (Well-understood requirements) Hiểu rõ yêu cầu có hiển nhiên nhận thấy được từ ngữ cảnh của miền ứng dụng và. .. hợp yêu cầu 1 Sử dụng EA với kĩ thuật BrainStorming Sử dụng Mind Mapping Diagram để phát triển các ý tưởng trong những lần BrainStorming 2 Sử dụng EA với kĩ thuật Prototyping (Mẫu : GUI) Ví dụ một số mẫu GUI Xây dựng một số mẫu GUI có sẵn lấy ý kiến người dùng hay kiếm tra yêu cầu của các chức năng 3 Sử dụng EA với kĩ thuật Use Case ... việc này đã đặt vị trí cho việc làm mẫu thử các phần “mờ” (fuzzy part) ở giữa Những yêu cầu này (Fuzzy) có thể được biết tới hoặc được ngầm hiểu nhưng chúng thường được định nghĩa khá nghèo nàn và tiếp thu được rất ít thông tin Xây dựng mẫu thử Sự lựa chọn công nghệ sử dụng trong khi xây dựng mẫu thử phụ thuộc vào các quyết định trong tương lai (ở phía bên phải cây quyết định) Đánh giá kết quả (Evaluating . Phần 1 Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm I. Giới thiệu 1. Mục đích Đưa ra các kĩ thuật phát hiện và tổng hợp các yêu cầu phần mềm. . Trong các dự án phần mềm 3. Tài liệu tham khảo • Managing Software RequirementsDean Leffingwell - Don Widrig II. Các kỹ thuật phát hiện và tổng hợp phần mềm