Báo cáo bài tập tuần 3 phân tích yêu cầu phần mềm

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG - - Báo cáo tập tuần Môn học: Phân tích yêu cầu phần mềm Giảng viên: PGS.TS Huỳnh Quyết Thắng Danh sách sinh viên: (nhóm ) Lê Trung Hiếu 20111568 CNTT-TT 2.3 K56 Đàm Văn Hoài 20111600 CNTT-TT 2.3 K56 Nguyễn Đức Cương 20111203 CNTT-TT 2.3 K56 Đoàn Văn Đạt 20111370 CNTT-TT 2.3 K56 Hà Nội – 4/2014 IT4460 Nhóm Mục lục Phân tích yêu cầu phần mềm Page IT4460 Nhóm I Mười đặc tính chất lượng của một bản đặc tả yêu cầu phần mềm tốt 1.1 Tính đắn (correct) - Một đặc tả yêu cầu phần mềm tốt yêu cầu xác định phải phần mềm đáp ứng Mỗi yêu cầu cần mô tả xác chức xây dựng Sự đảm bảo cho tính đắn tham chiếu đến nguồn yêu cầu, khách hàng đặc tả yêu cầu hệ thống mức cao Một yêu cầu phần mềm mà xung đột với yêu cầu hệ thống tương ứng không đắn Chỉ trình bày người dùng xác định tính đắn yêu cầu người dùng, điều cho biết rà soát yêu cầu ta cần có mặt người dùng người đại diện họ - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo phần mềm đáp ứng đầy đủ đặc tả yêu cầu phần mềm Đây tiêu chí để đánh giá phần mềm có đáp ứng yêu cầu người dùng hay không 1.2 Tính hoàn chỉnh (complete) - Mỗi yêu cầu cần mô tả đầy đủ chức chuyển giao Nó phải chứa tất thông tin cần thiết để nhà phát triển thiết kế thực thi chức Nếu yêu cầu phần mềm chưa rõ ràng, có cảm giác thiếu nói yêu cầu đó, họ đánh dấu yêu cầu "TBD To Be Determined" - ký hiệu chuẩn IEEE 830 Như rà soát toàn tài liệu SRS, tìm yêu cầu bị đánh dấu TBD để tiếp tục hoàn thiện SRS - Phải xác định kết liệu đầu vào, đặc biệt phải xác định kết liệu đầu vào hợp lệ liệu đầu vào không hợp lệ - Phải có đầy đủ nhãn tài liệu tham khảo cho tất số liệu, bảng biểu, sơ đồ SRS định nghĩa tất điều khoản đơn vị đo lường Phân tích yêu cầu phần mềm Page IT4460 Nhóm - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo yêu cầu mô tả đầy đủ 1.3 Tính quán (consistent) -Các yêu cầu phần mềm không xung đột với yêu cầu phần mềm khác yêu cầu cấp cao (hệ thống kinh doanh) Tất mâu thuẫn yêu cầu cần phải phân giải trước trình phát triển diễn Bạn yêu cầu đơn (single requirement) đắn tận bạn tiến hành số nghiên cứu yêu cầu - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo yêu cầu phần mềm không xung đột lẫn nhau, đảm bảo tính quán yêu cầu phần mềm 1.4 Tính khả thi (Feasible) - Khả thi có nghĩa có thể thực thi yêu cầu khả giới hạn biết hệ thống môi trường hoạt động hệ thống Một yêu cầu không có tính khả thi nếu nó không thể thực hiện được hoặc có thể thực hiện yêu cầu chi phí lớn (về nhân lực, về tài chính, về tài nguyên phần cứng, phần mềm, hoặc về độ phức tạp tính toán) - Để tránh yêu cầu không khả thi, cần thành viên nhóm dự án làm việc với những nhân viên bán hàng nhà phân tích yêu cầu trình xử lý yêu cầu (elicitation process) Người đánh giá tính khả thi yêu cầu mặt kỹ thuật chỉ yêu cầu thực thi với chi phí lớn - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo các yêu cầu được đưa có thể thực hiện được thực tế Nếu một yêu cầu không thể hoàn thành thì nó sẽ ảnh hưởng tới toàn bộ dự án Yêu cầu đó có thể làm lãng phí một lượng lớn công sức, tài nguyên mà đem lại lợi ích quá nhỏ cho dự án Thêm Phân tích yêu cầu phần mềm Page IT4460 Nhóm vào đó, việc không thể hoàn thành yêu cầu ảnh hưởng rất lớn tới uy tín của người phát triển phần mềm Vì vậy, một SRS tốt cần đảm bảo mọi yêu cầu đề có tính khả thi 1.5 Tính thay đổi (Modifiable) - Một SRS có thể thay đổi cần đảm bảo mỗi cần bổ sung, sửa đổi hay loại bỏ một yêu cầu nào đó thì công việc này cần được thực hiện một cách nhanh chóng, chính xác và vẫn đảm bảo tính nhất quán với các yêu cầu còn lại - Để tăng tính thay đổi yêu cầu phần mềm, viết yêu cầu thật rõ ràng, mạch lạc (fine grain fashion), gán nhãn khác cho yêu cầu Người đọc không thích nhìn thấy dấu chấm đầu hàng tài liệu, dò tìm yêu cầu, phải dò qua yêu cầu cụ thể - tốn thời gian không rõ ràng (vì nhãn) Một cách để loại bỏ dấu chấm, xếp yêu cầu theo bảng chữ - dùng chữ để gán nhãn - SRS có thể được nghiên cứu lại cần thiết cần phải trì thông tin diễn biến thay đổi yêu cầu Điều đòi hỏi yêu cầu dán nhãn diễn giải riêng rẽ với yêu cầu khác cho yêu cầu tham chiếu xác Mỗi yêu cầu xuất lần SRS để tránh không quán thể (instance) yêu cầu nơi khác Một bảng nội dung (table of contents), index, danh sách tham chiếu chéo (cross – reference listing) làm SRS dễ sửa chữa - IEEE 830-1998 hỗ trợ xây dựng SRS với đặc tính chất lượng này để có thể tiết kiệm thời gian, chi phí cho quá trình đàm phán và quản lý yêu cầu phần mềm Một SRS có đặc tính “có thể sửa đổi” sẽ giúp việc sửa đổi chỉ cần làm ở một số ít nơi của SRS, đồng thời không cần lo lắng về việc những thay đổi này mâu thuẫn với các yêu cầu trước đó Phân tích yêu cầu phần mềm Page IT4460 1.6 Nhóm Tính cần thiết (Necessary) - Mỗi yêu cầu cần phải tài liệu hoá mà khách hàng thật cần hệ thống khác bên cần Một cách khác để xác nhận “tính cần thiết” yêu cầu đề xuất từ bên mà bạn biết rõ người đó có thầm quyền đề yêu cầu - Nếu một yêu cầu phần mềm không đáp ứng nguyện vọng của bất kì khách hàng hay hệ thống nào thì nó là yêu cầu không cần thiết, cần phải loại bỏ Việc thực hiện yêu cầu này không mang lại lợi ích nào cho dự án phần mềm, chỉ làm lãng phí công sức, tài nguyên - IEEE 839-1998 hỗ trợ xây dựng SRS với đặc tính chất lượng này để đảm bảo mọi yêu cầu được đưa SRS đều cần thiết cho dự án phần mềm Chỉ các yêu cầu thật sự cần thiết mới cần đầu tư thời gian, công sức để hoàn thành 1.7 Có độ ưu tiên (Prioritized) - Gán thứ tự ưu tiên cho yêu cầu, tính (feature), use case để hình dung lịch trình phát triển phiên phần mềm Nếu tất yêu cầu coi quan quản trị dự án không xác định cách thức thi công yêu cầu phát sinh trình thi công dự án, không kiểm soát ngân sách, lịch biểu nhân lục án - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để đảm bảo người quản trị dự án đánh giá xác mức độ quan yêu cầu Tù có đánh giá, kiểm soát tất yêu cầu có yêu cầu phát sinh thêm Người quản trị đầu tư mức với yêu cầu tương ứng với mức độ ưu tiên 1.8 Có thể truy vết (Traceable) - Bạn cần phải liên kết yêu cầu tới nguồn phát sinh nó, tới Phân tích yêu cầu phần mềm Page IT4460 Nhóm phần tử thiết kế, mã nguồn, test cases thực thi kiểm tra đắn việc thi công yêu cầu Các yêu cầu theo vết gán nhãn viết theo cách có cấu trúc, chi tiết thuyết minh đầy đủ - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để người làm dự án tìm đường yêu cầu phần mềm từ nguyên nhân phát sinh đến lúc thiết kế để đáp ứng yêu cầu phần mềm Mỗi yêu cầu cần xác định cách rõ ràng nguồn phát sinh, vị trí khâu thiết kế Truy viết giúp người làm dự án tìm lỗi sai hay thiếu sót yêu cầu cách nhanh chóng biết vết yêu cầu 1.9 Không nhập nhằng (Unambiguous) - Tất đọc báo cáo yêu cầu có cách hiểu, cách diễn giải quán nội dung yêu cầu Do ngôn ngữ tự nhiên có tính nhập nhằng cao nên viết yêu cầu rõ ràng, cụ thể, đơn nghĩa dễ Cách hiệu để loại bỏ tính nhập nhằng mô tả báo cáo yêu cầu ngôn ngữ hình thức use-case chẳng hạn, qua kịch sử dụng cụ thể - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để giúp cho SRS trình bày rõ ràng nhất,tường minh Tất yêu cầu trùng lặp hay trùng ý nghĩ với điều có SRS dự án dễ dẫn đến thất bại Một phần mềm trùng lặp chức với phần mềm tồi 1.10 Kiểm tra (Verifiable) - Hãy kiểm tra yêu cầu để xem liệu bạn nghĩ số lượng nhỏ phép tests sử dụng cách tiếp cận kiểm tra khác tra (inspection) chứng minh (demonstration) để biết liệu yêu cầu Phân tích yêu cầu phần mềm Page IT4460 Nhóm cài đặt hợp lệ sản phẩm hay không Nếu yêu cầu kiểm tra xác định liệu có cài đặt đắn hay không trở thành vấn đề gây tranh cãi Các yêu cầu không quán, không khả thi nhập nhằng kiểm tra - Các biểu mẫu IEEE 830-1998 hỗ trợ xây dựng Software Requirement Specification (SRS) với đặc tính này để người làm dự án kiểm tra cài đặt yêu hợp lí hay chưa, sai chưa tối ưu Một SRS kiểm tra nhanh phát lỗi yêu cầu trình triển khai dự án giúp giảm chi phí tiền bạc nhân lực để sửa chữa II Các Tips để viết đặc tả yêu cầu phần mềm Đưa đánh giá dựa góc nhìn nhà phát triển Bất kể phía đối tác đưa yêu cầu nào, quan điểm nào, nên đứng quan điểm nhà phát triển để đánh giá yêu cầu Bản thân phía đối tác đưa yêu cầu phần mềm nào, mang góc nhìn quan điểm họ Thông thường, họ người ngành công nghệ thông tin, không hiểu hết rõ đặc thù công việc phát triển phần mềm khả máy tính Do đó, phải đánh giá, nhận xét yêu cầu phần mềm góc nhìn nhà phát triển Làm bật yêu cầu cấu trúc phân cấp Và nên suy nghĩ, đánh giá dựa theo cấu trúc phân cấp Bởi thân cấu trúc phân cấp mang nhiều thông tin mối quan hệ logic yêu cầu: Yêu cầu lớn, yêu cầu nhỏ, yêu cầu cha – con, yêu cầu mức phân cấp… Chính cấu trúc giúp việc đánh giá trở nên xác, hợp lý, sát Đặc biệt đánh giá dựa hình ảnh trực quan dễ dàng suy nghĩ vấn đề đầu mà hình ảnh hỗ trợ Và thực tế chứng minh, hầu hết người đối mặt với vấn đề phức tạp cấu trúc phân cấp (nó phân rã vấn đề lớn thành vấn đề nhỏ - hiểu giải được) Nếu không biểu diễn theo cấu trúc phân cấp, khó nhận mối quan hệ logic yêu cầu/mục yêu cầu, khó nhận đâu yêu cầu lớn, đâu yêu cầu nhỏ, … Phân tích yêu cầu phần mềm Page IT4460 Nhóm Cố gắng viết câu đoạn ngắn - đơn giản (write concisely): o Tránh đoạn văn nói dài Bởi đoạn văn dài, với nhiều ý, cuối lại không chốt yêu cầu mà nói tới xác gì! o Dùng ngữ pháp, tả, ngắt câu phù hợp (nên để người thông thạo ngôn ngữ sử dụng để viết SRS) o Dùng từ vựng lĩnh vực kinh doanh (đôi việc không sử dụng xác từ làm thay đổi toàn ý nghĩa mà yêu cầu muốn diễn đạt) Trong đoạn nói yêu cầu phần mềm đó, có nhiều thông tin quan trọng, lại không rõ yêu cầu cần xây dựng gì! Thay đó, đừng để yêu cầu chức viết đoạn dài, đưa mô tả tảng (additional descriptive background), context chức ngoài, tách bạch với mô tả chức Đừng yêu cầu người khác rà soát lại tài liệu chưa kiểm tra ngữ pháp - tả Sẽ tốt có giỏi ngôn ngữ rà soát lại SRS, tìm vấn đề dùng từ câu, tài liệu tốt mặt diễn đạt yêu cầu phần mềm Phải có văn mô tả cho hành vi mong muốn lẫn ngoại lệ - Chúng ta mong đợi hệ thống hoạt động theo hành vi mà ta mong muốn, nhiên, chương trình viết với nhiều đoạn mã để xử lý lỗi, ngoại lệ Và không xác định lỗi, ngoại lệ cách xử lý chúng trình xây dựng yêu cầu phần mềm, có vân đề! developers ngoại lệ cố gắng thiết kế xử lý ngoại lệ theo cách mà lý tưởng từ quan điểm người dùng không nghĩ lỗi/ngoại lệ Và lần chương trình gặp lỗi, ngoại lệ đó, crash! Công việc ngoại lệ bị thiếu nên thực tester, họ nghĩ điều tồi tệ xảy với chương trình Tránh ràng buộc thiết kế (design constraints) không cần thiết Tránh việc đưa vào SRS nhiều ý tưởng giải (solution ideas) Có nghĩa đừng đưa nhiều ràng buộc thiết kế vào tài liệu SRS Phân tích yêu cầu phần mềm Page IT4460 Nhóm cách kết hợp nhiều ý tưởng giải pháp tài liệu hướng dẫn, trừ có lý đặc biệt thỏa đáng Viết yêu cầu mức chi tiết hợp lý Khó để xác định xem tài liệu SRS cần viết chi tiết đến mức nào, hướng dẫn, chia yêu cầu phần mềm thành phận mà độc lập kiểm tra Các từ "and" "or" xác định yêu cầu phần mềm có kết hợp với hay không Ví dụ gặp từ "and" yêu cầu phần mềm, ta đặt câu hỏi, phải vế từ "and" yêu cầu? Hay chúng mặt logic yêu cầu khác cần chia (split)? Viết yêu cầu cách xác, cụ thể, không mơ hồ gây nhầm lẫn Một số lập trình viên thích yêu cầu phần mềm mơ hồ, gây nhầm lẫn, để bắt tay vào xây dựng, họ xây dựng mà họ muốn ? Và chí người dùng thích yêu cầu mơ hồ, gây nhầm lẫn, cho phép họ định nghĩa lại yêu cầu theo ý mà họ muốn thời điểm cụ thể! Điều không tốt chút cho việc xây dựng phần mềm chất lượng tốt! Có số từ nên sử dụng để viết yêu cầu, số từ nên tránh Nên sử dụng từ "sẽ", "phải" thay nói "nên", "có lẽ", "có thể", … (should, may, might, could, can, if possible, if you feel like, if you have time, if you get around) Nên chọn số thuật ngữ sử dụng cách quán từ đầu đến cuối SRS nói chức hệ thống Một người bạn tác giả gợi ý thay từ should cụm từ "probably won't (có lẽ không)", hỏi ý kiến người dùng có đồng ý với yêu cầu (phần mềm) không, thông thường, người dùng nói không (tức thân cụm từ probably won't mơ hồ, không rõ ràng) Một số người viết yêu cầu phần mềm sử dụng should - nói đến chức yêu cầu hệ thống, might - chức mong muốn có hệ thống, may - chức tùy chọn; điều thực không tốt, thân từ giao tiếp hàng ngày nhiều sử dụng thay Chính điều khiến cho việc sử dụng Phân tích yêu cầu phần mềm Page 10 IT4460 Nhóm chúng làm văn trở nên thiếu tính quán, yêu cầu thiếu tính đơn nghĩa! Như cần tránh sử dụng từ gây nhầm lẫn mang tính chủ quan Phân tích yêu cầu phần mềm Page 11