Phân tích và đặc tả yêu cầu

Phân tích đặc tả yêu cầu Phân tích đặc tả yêu cầu Bởi: Nguyễn Việt Hà Đại cương phân tích đặc tả Phân tích định rõ yêu cầu bước kỹ thuật tiến trình kỹ nghệ phần mềm Công việc bước tìm hiểu xem phải phát triển gì, phát triển Đích cuối khâu phân tích tạo đặc tả yêu cầu, tài liệu ràng buộc khách hàng người phát triển sở hợp đồng Hoạt động phân tích hoạt động phối hợp khách hàng người phân tích (bên phát triển) Khách hàng phát biểu yêu cầu người phân tích hiểu, cụ thể hóa biểu diễn lại yêu cầu Hoạt động phân tích giữ vai trò đặc biệt quan trọng phát triển phần mềm, giúp cho đảm bảo chất lượng phần mềm (phần mềm đáng tin cậy) Phần mềm đáng tin cậy có nghĩa phải thực xác, đầy đủ yêu cầu người sử dụng Nếu phân tích không tốt dẫn đến hiểu lầm yêu cầu việc sửa chữa trở nên tốn Chi phí để sửa chữa sai sót yêu cầu tăng lên gấp bội sai sót phát muộn, ví dụ bước thiết kế hay mã hóa Việc phân tích, nắm bắt yêu cầu thường gặp khó khăn • Các yêu cầu thường mang tính đặc thù tổ chức đặt hàng nó, thường khó hiểu, khó định nghĩa chuẩn biểu diễn • Các hệ thống thông tin lớn có nhiều người sử dụng yêu cầu thường đa dạng có mức ưu tiên khác nhau, chí mâu thuẫn lẫn • Người đặt hàng nhiều nhà quản lý, người dùng thực việc phát biểu yêu cầu thường không xác Trong phân tích cần phân biệt yêu cầu mục tiêu hệ thống Yêu cầu đòi hỏi mà kiểm tra mục tiêu trừu tượng mà hướng tới Ví dụ, giao diện hệ thống phải thân thiện với người sử dụng mục tiêu tương đối không khách quan khó kiểm tra Có nghĩa với phát biểu chung chung khách hàng nhà phát triển khó định ranh giới rõ ràng để nói phần mềm thỏa mãn đòi hỏi Với mục tiêu vậy, yêu cầu cho nhà phát triển giao diện đồ họa mà lệnh phải chọn menu 1/14 Phân tích đặc tả yêu cầu Mục đích giai đoạn phân tích xác định rõ yêu cầu phần mềm cần phát triển Tài liệu yêu cầu nên dễ hiểu với người dùng, đồng thời phải chặt chẽ để làm sở cho hợp đồng người phát triển dựa vào để xây dựng phần mềm Do yêu cầu thường mô tả nhiều mức chi tiết khác phục vụ cho đối tượng đọc khác Các mức là: • Định nghĩa (xác định) yêu cầu: mô tả cách dễ hiểu, vắn tắt yêu cầu, hướng vào đối tượng người đọc người sử dụng, người quản lý • Đặc tả yêu cầu: mô tả chi tiết yêu cầu, ràng buộc hệ thống, phải xác cho người đọc không hiểu nhầm yêu cầu, hướng vào đối tượng người đọc kỹ sư phần mềm (người phát triển), kỹ sư hệ thống (sẽ làm việc bảo trì) Các tài liệu yêu cầu cần thẩm định để đảm bảo thỏa mãn nhu cầu người dùng Đây công việc bắt buộc để đảm bảo chất lượng phần mềm Đôi việc xác định đầy đủ yêu cầu trước phát triển hệ thống không thực tế việc xây dựng mẫu để nắm bắt yêu cầu cần thiết Quá trình hình thành yêu cầu Nghiên cứu khả thi Đây giai đoạn có tầm quan trọng đặc biệt, liên quan đến việc lựa chọn giải pháp Trong giai đoạn người phân tích phải làm rõ điểm mạnh điểm yếu hệ thống cũ, đánh giá mức độ, tầm quan trọng vấn đề, định vấn đề cần phải giải (ví dụ: dịch vụ mới, thời hạn đáp ứng, hiệu kinh tế) Sau 2/14 Phân tích đặc tả yêu cầu người phân tích phải định vài giải pháp (sơ bộ) so sánh cân nhắc điểm tốt không tốt giải pháp (như tính hệ thống, giá cài đặt, bảo trì, việc đào tạo người sử dụng ) Đó việc tìm điểm cân nhu cầu khả đáp ứng Mọi dự án khả thi nguồn tài nguyên vô hạn thời gian vô hạn Nhưng việc xây dựng hệ thống lại phải làm với hạn hẹp tài nguyên khó (nếu không thực) bảo đảm ngày bàn giao Phân tích khả thi rủi ro có liên quan với theo nhiều cách Nếu rủi ro dự án lớn tính khả thi việc chế tạo phần mềm có chất lượng bị giảm Trong giai đoạn nghiên cứu khả thi, tập trung vào bốn lĩnh vực quan tâm chính: Khả thi kinh tế: chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống xây dựng đem lại Tính khả thi kinh tế thể nội dung sau: ◦ Khả tài tổ chức cho phép thực dự án ◦ Lợi ích mà dự án phát triển HTTT mang lại đủ bù đắp chi phí phải bỏ xây dựng ◦ Tổ chức chấp nhận chi phí thường xuyên hệ thống hoạt động Một thuật ngữ hay dùng để tài liệu nghiên cứu khả thi kinh tế luận chứng kinh tế Luận chứng kinh tế nói chung coi tảng cho hầu hết hệ thống (các ngoại lệ hệ thống quốc phòng, hệ thống luật, hệ thống phục vụ cho nghiên cứu đặc biệt) Luận chứng kinh tế bao gồm: ◦ ◦ ◦ ◦ mối quan tâm, phân tích chi phí/lợi ích chiến lược phát triển dài hạn công ty ảnh hưởng tới sản phẩm lợi nhuận khác chi phí cho tài nguyên cần cho việc xây dựng phát triển thị trường tiềm Khả thi kỹ thuật: khảo cứu chức năng, hiệu suất ràng buộc ảnh hưởng tới khả đạt tới hệ thống chấp nhận Nói cách khác, khả thi kỹ thuật xem xét khả kỹ thuật có đủ đảm bảo thực giải pháp công nghệ dự định áp dụng hay không Khả thi kỹ thuật thường lĩnh vực khó thâm nhập giai đoạn phân tích Điều thực chất tiến trình phân tích xác định nhu cầu cần tiến hành song song với việc xác nhận tính khả thi kỹ thuật Các xem xét thường gắn với tính khả thi kỹ thuật bao gồm: ◦ Rủi ro xây dựng: liệu phần tử hệ thống thiết kế cho đạt chức hiệu suất cần thiết thỏa mãn ràng buộc phân tích không? 3/14 Phân tích đặc tả yêu cầu ◦ Có sẵn tài nguyên: có sẵn nhân viên cho việc xây dựng phần tử hệ thống xét không? Các tài nguyên cần thiết khác (phần cứng phần mềm) có sẵn cho việc xây dựng hệ thống không ? ◦ Công nghệ: công nghệ liên quan đạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chưa? Khả thi pháp lý: nghiên cứu đưa phán có hay không xâm phạm, vi phạm pháp luật hay khó khăn pháp lý từ việc xây dựng vận hành hệ thống Tính khả thi pháp lý bao gồm phạm vi rộng mối quan tâm kể hợp đồng, nghĩa vụ pháp lý, vi phạm vô số bẫy pháp lý khác mà thường nhân viên kỹ thuật tới Trong nước, vấn đề khả thi pháp lý chưa coi trọng cách mức có số luật liên quan đến CNTT bảo hộ quyền Tính khả thi hoạt động: đánh giá tính khả thi việc vận hành hệ thống Trong phương án người ta cần xem xét hệ thống vận hành trôi chảy hay không khuôn khổ tổ chức điều kiện quản lý mà tổ chức (người dùng, khách hàng) có Mức độ phương án xem xét tới nghiên cứu khả thi thường bị giới hạn ràng buộc chi phí thời gian Nền tảng phân tích yêu cầu Các nguyên lý phân tích Trên hai thập kỉ qua, người ta xây dựng số phương pháp phân tích đặc tả phần mềm Những người nghiên cứu xác định vấn đề nguyên nhân chúng, xây dựng qui tắc thủ tục để vượt qua chúng Mỗi phương pháp có kí pháp quan điểm riêng Tuy nhiên, tất phương pháp có quan hệ với tập hợp nguyên lý bản: Miền thông tin vấn đề phải biểu diễn lại hiểu rõ Các mô hình mô tả cho thông tin, chức hành vi hệ thống cần phải xây dựng Các mô hình (và vấn đề) phải phân hoạch theo cách để lộ chi tiết theo kiểu phân tầng (hay cấp bậc) Tiến trình phân tích phải từ thông tin chất hướng tới chi tiết cài đặt Bằng cách áp dụng nguyên lý này, người phân tích tiếp cận tới vấn đề cách hệ thống Miền thông tin cần xem xét cho người ta hiểu rõ chức cách đầy đủ Các mô hình dùng việc trao đổi thông tin dễ dàng theo cách ngắn gọn Việc phân hoạch vấn đề sử dụng để làm giảm độ phức tạp Những cách nhìn nhận từ góc độ chất góc độ cài đặt phần mềm cần thiết để bao hàm ràng buộc logic yêu cầu xử lý áp đặt nên ràng buộc vật lý phần tử hệ thống khác áp đặt nên 4/14 Phân tích đặc tả yêu cầu Mô hình hóa Chúng ta tạo mô hình để thu hiểu biết rõ thực thể thực tế cần xây dựng Khi thực thể vật vật lý (như nhà, máy bay, máy móc) ta xây dựng mô hình giống hệt hình dạng, nhỏ qui mô Tuy nhiên, thực thể cần xây dựng phần mềm, mô hình phải mang dạng khác Nó phải có khả mô hình hóa thông tin mà phần mềm biến đổi, chức (và chức con) làm cho phép biến đổi thực được, hành vi hệ thống phép biến đổi xảy Trong phân tích yêu cầu phần mềm, tạo mô hình hệ thống cần xây dựng Các mô hình tập trung vào điều hệ thống phải thực hiện, không ý đến cách thức thực Trong nhiều trường hợp, mô hình tạo có dùng kí pháp đồ hoạ mô tả cho thông tin, xử lý, hành vi hệ thống, đặc trưng khác thông qua biểu tượng phân biệt dễ nhận diện Những phần khác mô hình túy văn Thông tin mô tả cung cấp cách dùng ngôn ngữ tự nhiên hay ngôn ngữ chuyên dụng cho mô tả yêu cầu Các mô hình tạo phân tích yêu cầu đóng số vai trò quan trọng: • Mô hình trợ giúp cho người phân tích việc hiểu thông tin, chức hành vi hệ thống, làm cho nhiệm vụ phân tích yêu cầu dễ dàng hệ thống • Mô hình trở thành tiêu điểm cho việc xem xét đó, trở thành phần mấu chốt cho việc xác định tính đầy đủ, quán xác đặc tả • Mô hình trở thành tảng cho thiết kế, cung cấp cho người thiết kế cách biểu diễn chủ yếu phần mềm “ánh xạ” vào hoàn cảnh cài đặt Dưới số mô hình (phương pháp) hay dùng phân tích: Biểu đồ luồng liệu Khi thông tin qua phần mềm bị thay đổi loạt phép biến đổi Biểu đồ luồng liệu (Data Flow Diagram - DFD) kỹ thuật vẽ luồng liệu di chuyển hệ thống phép biến đổi áp dụng lên liệu Ký pháp biểu đồ luồng liệu minh họa hình Ký pháp DFD 5/14 Phân tích đặc tả yêu cầu Biểu đồ luồng liệu dùng để biểu diễn cho hệ thống hay phần mềm mức trừu tượng Trong thực tế, DFD phân hoạch thành nhiều mức biểu diễn cho chi tiết chức luồng thông tin ngày tăng Do phương pháp dùng DFD gọi phân tích có cấu trúc Một DFD mức 0, gọi biểu đồ tảng hay biẻu đồ ngữ cảnh hệ thống, biểu diễn cho toàn phần tử phần mềm hình tròn với liệu vào ra mũi tên tới tương ứng Một DFD mức cụ thể hóa DFD mức chứa nhiều hình tròn (chức năng) với mũi tên (luồng liệu) nối lẫn Mỗi tiến trình biểu diễn mức chức toàn hệ thống mô tả biểu đồ ngữ cảnh Hình minh họa DFD cho hệ thống bán vé tầu Biểu đồ luồng liệu hệ thống bán vé tầu Biểu đồ thực thể quan hệ Ký pháp tảng cho mô hình hóa liệu biểu đồ thực thể - quan hệ (Entity Relation Diagram) Tất xác định tập thành phần chủ yếu cho biểu đồ 6/14 Phân tích đặc tả yêu cầu EưR: thực thể, thuộc tính, quan hệ nhiều báo kiểu khác Mục đích biểu đồ EưR biểu diễn liệu mối quan hệ liệu (thực thể) Ký pháp biểu đồ EưR tương đối đơn giản Các thực thể biểu diễn hình chữ nhật có nhãn Mối quan hệ hình thoi Các mối nối vật liệu mối quan hệ thiết lập cách dùng nhiều đường nối đặc biệt (hình 4) Mô hình thực thể quan hệ người - phương tiện giao thông Người phân tích Người phân tích đóng vai trò đặc biệt quan trọng tiến trình phân tích Ngoài kinh nghiệm, người phân tích tốt cần có khả sau: - Khả hiểu thấu khái niệm trừu tượng, có khả tổ chức lại thành phân tích logic tổng hợp giải pháp dựa dải phân chia - Khả rút kiện thích đáng từ nguồn xung khắc lẫn lộn - Khả hiểu môi trường người dùng/khách hàng - Khả áp dụng phần tử hệ thống phần cứng và/hoặc phần mềm vào môi trường người sử dụng/khách hàng - Khả giao tiếp tốt dạng viết nói - Khả trừu tượng hóa/tổng hợp vấn đề từ kiện riêng lẻ 7/14 Phân tích đặc tả yêu cầu Xác định đặc tả yêu cầu Xác định yêu cầu Xác định yêu cầu mô tả trừu tượng dịch vụ mà hệ thống cần cung cấp ràng buộc mà hệ thống cần tuân thủ vận hành Nó mô tả hành vi bên hệ thống mà không liên quan tới chi tiết thiết kế Yêu cầu nên viết cho hiểu mà không cần kiến thức chuyên môn đặc biệt Các yêu cầu chia thành hai loại: Các yêu cầu chức năng: dịch vụ mà hệ thống cần cung cấp Các yêu cầu phi chức năng: ràng buộc mà hệ thống cần tuân thủ Các yêu cầu phi chức chia làm kiểu: Yêu cầu sản phẩm: yêu cầu tốc độ, nhớ, độ tin cậy, tính khả chuyển tái sử dụng Yêu cầu trình: yêu cầu trình xây dựng sản phẩm chuẩn phải tuân theo, phương pháp thiết kế, ngôn ngữ lập trình Yêu cầu khác: yêu cầu không thuộc hai nhóm tính pháp lý, chi phí, thành viên nhóm phát triển Các yêu cầu phi chức thường đặc thù với khách hàng khó phân tích đặc tả cách đầy đủ xác Về nguyên tắc, yêu cầu hệ thống phải vừa đầy đủ vừa không mâu thuẫn Đối với hệ thống lớn phức tạp khó đạt hai yếu tố bước phân tích đầu Trong bước duyệt lại yêu cầu cần phải bổ sung, chỉnh lý tư liệu yêu cầu Đặc tả yêu cầu Tài liệu xác định yêu cầu mô tả hướng khách hàng viết ngôn ngữ khách hàng Khi dùng ngôn ngữ tự nhiên khái niệm trừu tượng Tài liệu dặc tả yêu cầu (đặc tả chức năng) mô tả hướng người phát triển, sở hợp đồng làm phần mềm Nó không phép mơ hồ, không dẫn đến hiểu nhầm khách hàng người phát triển Với yêu cầu mơ hồ người phát triển thực cách rẻ khách hàng không muốn Do khách hàng đòi hỏi sửa đổi chức phần mềm gần hoàn thiện khiến cho chi phí tăng chậm thời điểm bàn giao Chi phí cho sửa sai sót phát biểu yêu cầu lớn, đặc biệt sai sót phát bắt đầu xây dựng hệ thống Theo số thống kê 85% mã phải viết lại thay đổi yêu cầu 12% lỗi phát 8/14 Phân tích đặc tả yêu cầu năm đầu sử dụng đặc tả yêu cầu không xác Do đó, việc đặc tả xác yêu cầu mối quan tâm đặt lên hàng đầu Có hai phương pháp đặc tả Đặc tả phi hình thức: cách đặc tả ngôn ngữ tự nhiên Đặc tả hình thức: cách đặc tả ngôn ngữ nhân tạo (ngôn ngữ đặc tả), công thức biểu đồ Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định yêu cầu nhiều không thích hợp với đặc tả yêu cầu vì: Không phải lúc người đọc người viết đặc tả ngôn ngữ tự nhiên hiều từ Ngôn ngữ tự nhiên mềm dẻo yêu cầu liên quan đến biểu diễn hình thức hoàn toàn khác người phát triển không nhận mối liên quan Các yêu cầu khó phân hoạch cách hữu hiệu hiệu việc đổi thay xác định cách kiểm tra tất yêu cầu nhóm yêu cầu liên quan Các ngôn ngữ đặc tả (đặc tả hình thức) khắc phục hạn chế trên, nhiên đa số khách hàng lại không thông thạo ngôn ngữ Thêm ngôn ngữ đặc tả hình thức thường phục vụ cho nhóm lĩnh vực riêng biệt việc đặc tả hình thức công việc tốn thời gian Một cách tiếp cận bên cạnh đặc tả hình thức người ta viết giải ngôn ngữ tự nhiên để giúp khách hành dễ hiểu Thẩm định yêu cầu Một yêu cầu thiết lập cần thẩm định xem chúng có thỏa mãn nhu cầu khách hàng hay không Nếu thẩm định không tiến hành chặt chẽ sai sót lan truyền sang giai đoạn thiết kế mã hóa khiến cho việc sửa đổi hệ thống trở nên tốn Mục tiêu thẩm định kiểm tra xem yêu cầu mà người phân tích xác định có thỏa mãn yếu tố sau không: Thỏa mãn nhu cầu người dùng: cần phải thỏa mãn nhu cầu chất người dùng (khách hàng) Các yêu cầu không mâu thuẫn nhau: với hệ thống lớn yêu cầu đa dạng có khả mâu thuân Khi người phân tích phải loại bớt yêu cầu (không chủ chốt) để sau cho yêu cầu mô tả tài liệu yêu cầu không mâu thuẫn Các yêu cầu phải đầy đủ: cần chứa chức ràng buộc mà người dùng nhắm đến 9/14 Phân tích đặc tả yêu cầu Các yêu cầu phải thực: yêu cầu phải thực khía cạnh kỹ thuật, kinh tế pháp lý Làm mẫu trình phân tích Đối với hệ thống phức tạp, nhiều không nắm yêu cầu khách hàng, khó đánh giá tính khả thi hiệu hệ thống Một cách tiếp cận trường hợp xây dựng mẫu Bản mẫu vừa dùng để phân tích yêu cầu vừa tiến hóa thành sản phẩm cuối Bản mẫu phần mềm hoàn toàn khác với mẫu phần cứng Khi phát triển hệ thống phần cứng, thực tế người ta phát triển mẫu hệ thống để thẩm định thiết kế hệ thống Một mẫu hệ thống điện tử thực thử nghiệm cách dùng thành phần chưa lắp ráp vào vỏ trước đầu tư vào mạch tích hợp chuyên dụng đắt tiền để thực đời sản phẩm hệ thống Bản mẫu phần mềm nhằm vào việc thẩm định thiết kế (thiết kế thường hoàn toàn khác với hệ thống phát triển cuối cùng), mà để thẩm định yêu cầu người sử dụng Các bước làm mẫu Xây dựng mẫu bao gồm bước sau: Đánh giá yêu cầu phần mềm xác định liệu phần mềm cần xây dựng có xứng đáng để làm mẫu không Không phải tất phần mềm đưa tới làm mẫu Ta xác định số nhân tố làm mẫu: lĩnh vực ứng dụng, độ phức tạp ứng dụng, đặc trưng khách hàng đặc trưng dự án Để đảm bảo tính tương tác khách hàng với mẫu, cần đảm bảo điều kiện: ◦ Khách hàng phải cam kết dùng tài nguyên để đánh giá làm mịn mẫu (chi tiết hóa yêu cầu) ◦ Khách hàng phải có khả đưa định yêu cầu cách kịp thời Với dự án chấp thuận được, người phân tích xây dựng cách biểu diễn vắn tắt cho yêu cầu Trước bắt đầu xây dựng mẫu, người phân tích phải biểu diễn miền thông tin lĩnh vực, hành vi chức vấn đề xây dựng cách tiếp cận hợp lý tới việc phân hoạch Có thể ứng dụng nguyên lý phân tích tảng (phân tích topưdown) phương pháp phân tích yêu cầu Sau duyệt xét mô hình yêu cầu, phải tạo đặc tả thiết kế vắn tắt cho mẫu Việc thiết kế phải xuất trước bắt đầu làm mẫu Tuy nhiên thiết kế tập trung chủ yếu vào vấn đề thiết kế liệu kiến trúc mức đỉnh không tập trung vào thiết kế thủ tục chi tiết 10/14 Phân tích đặc tả yêu cầu Phần mềm mẫu tạo ra, kiểm thử làm mịn Bản mẫu nên xây dựng cách nhanh chóng với chi phí nhỏ Một cách lý tưởng, mẫu nên lắp ráp từ khối chức (thư viện ) có Có thể dùng ngôn ngữ bậc cao hay công cụ tự động để xây dựng mẫu Khách hàng đánh giá làm mịn yêu cầu Bước cốt lõi cách tiếp cận làm mẫu Chính mà khách hàng xem xét cách biểu diễn cài đặt cho yêu cầu phần mềm, gợi ý thay đổi làm cho phần mềm đáp ứng tốt với nhu cầu thực tế Lặp lại bước tất yêu cầu hình thức hóa đầy đủ hay mẫu tiến hóa thành phần mềm hoàn thiện Lợi ích hạn chế phát triển mẫu Phát triển mẫu đem lại lợi ích sau: • Sự hiểu lầm người phát triển phần mềm người sử dụng phần mềm nhận thấy rõ chức hệ thống trình diễn • Sự thiếu hụt dịch vụ người dùng phát • Sự khó sử dụng nhầm lẫn dịch vụ người dùng thấy rõ sửa lại • Đội ngũ phát triển phần mềm tìm đựơc yêu cầu không đầy đủ không kiên định họ phát triển mẫu • Một hệ thống hoạt động (mặc dầu hạn chế) chứng thuyết minh cho tính khả thi tính hữu ích ứng dụng cho nhà quản lý • Bản mẫu dùng làm sở cho việc viết đặc tả sản phẩm Mặc dù mục tiêu chủ yếu việc tạo mẫu để phát triển, thẩm định yêu cầu phần mềm, có lợi ích khác như: Dùng để huấn luyện người sử dụng từ trước hệ thống phân phối Dùng trình thử nghiệm hệ thống Điều nghĩa trường hợp thử vừa dùng cho thử mẫu vừa cho thử hệ thống Kết khác có nghĩa có sai sót Tạo mẫu kỹ thuật giảm bớt rủi ro Một rủi ro lớn việc phát triển phần mềm sai sót mà đến giai đoạn cuối phát việc chỉnh sửa vào thời điểm tốn Kinh nghiệm cho thấy việc tạo mẫu giảm bớt số vấn đề đặc tả yêu cầu giá tổng cộng việc phát triển thấp ta phát triển mẫu Hạn chế cách tiếp cận tạo mẫu là: 11/14 Phân tích đặc tả yêu cầu Để đơn giản hóa việc tạo mẫu người ta bỏ qua yêu cầu phức tạp Sự thật tạo mẫu vài phần quan trọng hệ thống đặc điểm an toàn - nguy kịch Các yêu cầu phi chức độ tin cậy, độ an toàn hay hiệu thường không biểu thị đầy đủ mẫu Do tính chưa hoàn thiện chức năng/hiệu năng, người dùng không dùng mẫu y cách dùng hệ thống thực hoạt động Do đó, chất lượng đánh giá khách hàng nhiều không cao Định dạng đặc tả yêu cầu Kết bước phân tích tạo đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS) Đặc tả yêu cầu phải rõ phạm vi sản phẩm, chức cần có, đối tượng người sử dụng ràng buộc vận hành sản phẩm Có nhiều chuẩn khác xây dựng tài liệu, định dạng RSR thông dụng (theo chuẩn IEEE 830-1984) 12/14 Phân tích đặc tả yêu cầu 13/14 Phân tích đặc tả yêu cầu Tổng kết: Phân tích định rõ yêu cầu bước kỹ thuật tiến trình kỹ nghệ phần mềm Tại bước phát biểu chung phạm vi phần mềm làm mịn thành đặc tả cụ thể để trở thành tảng cho hoạt động kỹ nghệ phần mềm sau Việc phân tích phải tập trung vào miền thông tin, chức hành vi vấn đề Để hiểu rõ yêu cầu, người ta tạo mô hình, phân hoạch vấn đề tạo biểu diễn mô tả cho chất yêu cầu sau vào chi tiết Trong nhiều trường hợp, đặc tả đầy đủ vấn đề giai đoạn đầu Việc làm mẫu thường giúp cách tiếp cận khác để từ làm mịn thêm yêu cầu Để tiến hành đắn việc làm mẫu, cần tới công cụ kỹ thuật đặc biệt Kết việc phân tích tạo đặc tả yêu cầu phần mềm Đặc tả cần xét duyệt để đảm bảo người phát triển khách hàng có nhận biết hệ thống cần phát triển 14/14 [...]... đặc tả yêu cầu 13/14 Phân tích và đặc tả yêu cầu Tổng kết: Phân tích và định rõ yêu cầu là bước kỹ thuật đầu tiên trong tiến trình kỹ nghệ phần mềm Tại bước này các phát biểu chung về phạm vi phần mềm được làm mịn thành một bản đặc tả cụ thể để trở thành nền tảng cho mọi hoạt động kỹ nghệ phần mềm sau đó Việc phân tích phải tập trung vào các miền thông tin, chức năng và hành vi của vấn đề Để hiểu rõ yêu. .. dạng đặc tả yêu cầu Kết quả của bước phân tích là tạo ra bản đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS) Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm, các chức năng cần có, đối tượng người sử dụng và các ràng buộc khi vận hành sản phẩm Có nhiều chuẩn khác nhau trong xây dựng tài liệu, dưới đây là một định dạng RSR thông dụng (theo chuẩn IEEE 830-1984) 12/14 Phân tích và đặc. .. đoạn cuối mới phát hiện và việc chỉnh sửa vào thời điểm đó là rất tốn kém Kinh nghiệm cho thấy việc tạo bản mẫu sẽ giảm bớt số các vấn đề của đặc tả yêu cầu và giá cả tổng cộng của việc phát triển có thể là thấp hơn nếu ta phát triển bản mẫu Hạn chế của cách tiếp cận tạo bản mẫu là: 11/14 Phân tích và đặc tả yêu cầu 1 Để đơn giản hóa việc tạo bản mẫu người ta có thể bỏ qua các yêu cầu phức tạp Sự thật... yêu cầu, người ta tạo ra mô hình, phân hoạch vấn đề và tạo ra những biểu diễn mô tả cho bản chất của yêu cầu rồi sau đó đi vào các chi tiết Trong nhiều trường hợp, không thể nào đặc tả được đầy đủ mọi vấn đề tại giai đoạn đầu Việc làm bản mẫu thường giúp chỉ ra cách tiếp cận khác để từ đó có thể làm mịn thêm yêu cầu Để tiến hành đúng đắn việc làm bản mẫu, có thể cần tới các công cụ và kỹ thuật đặc. . .Phân tích và đặc tả yêu cầu 4 Phần mềm bản mẫu được tạo ra, kiểm thử và làm mịn Bản mẫu nên được xây dựng một cách nhanh chóng và với một chi phí nhỏ Một cách lý tưởng, bản mẫu nên được lắp ráp từ các khối chức năng (thư viện ) đã có Có thể dùng các ngôn ngữ bậc cao hay các công cụ tự động để xây dựng bản mẫu 5 Khách hàng đánh giá và làm mịn yêu cầu Bước này là cốt lõi của... khác để từ đó có thể làm mịn thêm yêu cầu Để tiến hành đúng đắn việc làm bản mẫu, có thể cần tới các công cụ và kỹ thuật đặc biệt Kết quả của việc phân tích là tạo ra bản đặc tả các yêu cầu phần mềm Đặc tả cần được xét duyệt để đảm bảo rằng người phát triển và khách hàng có cùng nhận biết về hệ thống cần phát triển 14/14 ... đặt cho yêu cầu phần mềm, gợi ý những thay đổi làm cho phần mềm đáp ứng tốt hơn với các nhu cầu thực tế 6 Lặp lại các bước 4 và 5 cho tới khi tất cả các yêu cầu đã được hình thức hóa đầy đủ hay cho tới khi bản mẫu đã tiến hóa thành một phần mềm hoàn thiện Lợi ích và hạn chế của phát triển bản mẫu Phát triển bản mẫu đem lại các lợi ích sau: • Sự hiểu lầm giữa những người phát triển phần mềm và những... dịch vụ người dùng có thể được thấy rõ và được sửa lại • Đội ngũ phát triển phần mềm có thể tìm ra đựơc các yêu cầu không đầy đủ hoặc không kiên định khi họ phát triển bản mẫu • Một hệ thống hoạt động được (mặc dầu là hạn chế) là bằng chứng thuyết minh cho tính khả thi và tính hữu ích của ứng dụng cho các nhà quản lý • Bản mẫu đó được dùng làm cơ sở cho việc viết đặc tả một sản phẩm Mặc dù mục tiêu chủ... là: 11/14 Phân tích và đặc tả yêu cầu 1 Để đơn giản hóa việc tạo bản mẫu người ta có thể bỏ qua các yêu cầu phức tạp Sự thật hẳn là không thể tạo bản mẫu một vài phần quan trọng nhất của hệ thống như các đặc điểm về sự an toàn - nguy kịch 2 Các yêu cầu phi chức năng như độ tin cậy, độ an toàn hay hiệu năng thường không được biểu thị đầy đủ trong bản mẫu 3 Do tính chưa hoàn thiện về chức năng/hiệu năng,... Bản mẫu đó được dùng làm cơ sở cho việc viết đặc tả một sản phẩm Mặc dù mục tiêu chủ yếu của việc tạo bản mẫu là để phát triển, thẩm định các yêu cầu phần mềm, nó cũng có các lợi ích khác như: 1 Dùng để huấn luyện người sử dụng ngay từ trước khi hệ thống được phân phối 2 Dùng trong quá trình thử nghiệm hệ thống Điều đó nghĩa là cùng các trường hợp thử như nhau vừa dùng cho thử bản mẫu vừa cho thử hệ