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 bài tập tuần 3 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 3 ) 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 Mục lục 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. Tính đúng đắn (correct) - Một đặc tả yêu cầu phần mềm tốt là mọi yêu cầu được xác định đều phải được phần mềm đáp ứng. Mỗi yêu cầu cần mô tả chính xác chức năng được xây dựng. Sự đảm bảo cho tính đúng đắn đó là tham chiếu đến nguồn của yêu cầu, đó có thể là khách hàng hoặc một đặc tả yêu cầu hệ thống mức cao hơn. Một yêu cầu phần mềm mà xung đột với một yêu cầu hệ thống tương ứng thì là không đúng đắn. Chỉ sự trình bày của người dùng mới có thể xác định tính đúng đắn của yêu cầu người dùng, điều đó cho biết tại sao khi rà soát yêu cầu ta cần sự có mặt của chính người dùng hoặc người đại diện của 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ác đặc tả yêu cầu phần mềm. Đây cũng là tiêu chí để đánh giá phần mềm có đáp ứng được các yêu cầu của người dùng hay không. Tính hoàn chỉnh (complete) - Mỗi yêu cầu cần mô tả đầy đủ chức năng được chuyển giao. Nó phải chứa tất cả các thông tin cần thiết để nhà phát triển thiết kế và thực thi chức năng này. Nếu yêu cầu phần mềm nào đó còn chưa rõ ràng, và ai đó có cảm giác còn thiếu khi nói về yêu cầu đó, họ sẽ đánh dấu yêu cầu đó là "TBD - To Be Determined" - đây là ký hiệu chuẩn trong IEEE 830. Như vậy khi rà soát toàn bộ tài liệu SRS, chúng ta tìm các yêu cầu bị đánh dấu TBD để tiếp tục hoàn thiện SRS. - Phải xác định được kết quả của các dữ liệu đầu vào, đặc biệt là phải xác định được kết quả của những dữ liệu đầu vào hợp lệ và dữ liệu đầu vào không hợp lệ. - Phải có đầy đủ nhãn và tài liệu tham khảo cho tất cả các số liệu, bảng biểu, sơ đồ trong SRS và định nghĩa của tất cả các điều khoản và đơn vị đo lường. - 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 mỗi yêu cầu đã được mô tả đầy đủ. Tính nhất quán (consistent) -Các yêu cầu phần mềm không xung đột với các yêu cầu phần mềm khác hoặc các yêu cầu cấp cao hơn (hệ thống hoặc kinh doanh). Tất cả các mâu thuẫn trong yêu cầu cần phải được phân giải trước khi quá trình phát triển diễn ra. Bạn có thể không biết một yêu cầu đơn nhất (single requirement) nào đó là đúng đắn cho đến tận khi bạn tiến hành một số nghiên cứu nào đó về yêu cầu nà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 để đảm bảo các yêu cầu của phần mềm không xung đột lẫn nhau, đảm bảo được tính nhất quán của các yêu cầu phần mềm. Tính khả thi (Feasible) - Khả thi có nghĩa là có thể thực thi mỗi yêu cầu trong các khả năng và giới hạn đã biết của hệ thống và môi trường hoạt động của 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 nhưng 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 các yêu cầu không khả thi, cần một thành viên của nhóm dự án làm việc với những nhân viên bán hàng hoặc các nhà phân tích yêu cầu trong quá trình xử lý yêu cầu (elicitation process). Người này sẽ đánh giá về tính khả thi của các yêu cầu về mặt kỹ thuật hoặc chỉ ra các yêu cầu có thể thực thi nhưng với một 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 ra có thể thực hiện được trong 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 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. Tính có thể thay đổi (Modifiable) - Một SRS có thể thay đổi cần đảm bảo mỗi khi 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 được của yêu cầu phần mềm, viết các yêu cầu thật rõ ràng, mạch lạc (fine grain fashion), gán nhãn khác nhau cho mỗi yêu cầu. Người đọc không thích nhìn thấy các dấu chấm đầu hàng trong tài liệu, vì khi dò tìm các yêu cầu, phải dò qua từng yêu cầu cụ thể một - tốn thời gian và không rõ ràng (vì không có nhãn). Một trong những cách để loại bỏ các dấu chấm, đó là sắp xếp các yêu cầu theo bảng chữ cái - như thế dùng chữ cái để gán nhãn. - SRS có thể được nghiên cứu lại khi cần thiết và cần phải duy trì thông tin diễn biến thay đổi của mỗi yêu cầu. Điều này đòi hỏi mỗi yêu cầu được dán nhãn duy nhất và được diễn giải riêng rẽ với các yêu cầu khác sao cho mỗi yêu cầu đều được tham chiếu chính xác. Mỗi yêu cầu chỉ được xuất hiện duy nhất 1 lần trong SRS để tránh sự không nhất quán giữa các thể hiện (instance) của cùng 1 yêu cầu tại những nơi khác nhau. Một bảng nội dung (table of contents), một index, một danh sách tham chiếu chéo (cross – reference listing) sẽ làm SRS dễ sửa chữa hơn. - 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 đó. Tính cần thiết (Necessary) - Mỗi yêu cầu cần phải tài liệu hoá một cái gì đó mà khách hàng thật sự cần hoặc một hệ thống khác bên ngoài cần. Một cách khác để xác nhận “tính cần thiết” là yêu cầu đó được đề xuất từ một bên mà bạn biết rất rõ rằng người đó có thầm quyền đề ra 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 ra trong 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. Có độ ưu tiên (Prioritized) - Gán mỗi thứ tự ưu tiên cho mỗi yêu cầu, tính năng (feature), hoặc use case để có thể hình dung lịch trình phát triển các phiên bản phần mềm. Nếu tất cả các yêu cầu được coi là quan trong như nhau thì quản trị dự án sẽ không xác định được cách thức thi công khi một yêu cầu mới phát sinh trong quá trình thi công của dự án, anh ta sẽ không kiểm soát được ngân sách, lịch biểu và nhân lục của sự á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á được chính xác mức độ quan trong của mỗi yêu cầu. Tù đó có sự đánh giá, kiểm soát được tất cả các yêu cầu hiện có và các yêu cầu phát sinh thêm. Người quản trị sẽ đầu tư đúng mức với từng yêu cầu tương ứng với mức độ ưu tiên của nó. Có thể truy vết (Traceable) - Bạn cần phải liên kết các yêu cầu tới nguồn phát sinh của nó, tới các phần tử thiết kế, mã nguồn, các test cases thực thi và kiểm tra sự đúng đắn trong việc thi công các yêu cầu. Các yêu cầu có thể theo vết được gán nhãn duy nhất và được viết theo một cách có cấu trúc, chi tiết và được 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 được đường đi của mỗi yêu cầu phần mềm từ nguyên nhân phát sinh đến lúc thiết kế để đáp ứng được yêu cầu đó trong phần mềm. Mỗi yêu cầu cần xác định một cách rõ ràng nguồn phát sinh, vị trí của nó trong khâu thiết kế. Truy viết được giúp người làm dự án tìm ra lỗi sai hay những thiếu sót của yêu cầu một cách nhanh chóng nhất do đã biết được vết đi của yêu cầu đó. Không nhập nhằng (Unambiguous). - Tất cả những ai khi đọc bản báo cáo yêu cầu đều có cùng một cách hiểu, một cách diễn giải nhất quán về nội dung của các yêu cầu. Do ngôn ngữ tự nhiên là có tính nhập nhằng cao nên viết một yêu cầu rõ ràng, cụ thể, đơn nghĩa không phải là dễ. Cách hiệu quả để loại bỏ tính nhập nhằng là mô tả các báo cáo yêu cầu bằng các ngôn ngữ hình thức như use-case chẳng hạn, qua các kịch bản 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 nhất. Tất cả các yêu cầu không có sự trùng lặp hay trùng ý nghĩ với nhau vì nếu điều này có trong SRS thì dự án rất dễ dẫn đến thất bại. Một phần mềm không thể trùng lặp các chức năng với nhau đó là một phần mềm tồi. Kiểm tra được (Verifiable) - Hãy kiểm tra mỗi yêu cầu để xem liệu bạn có thể nghĩ ra một số lượng nhỏ các phép tests hoặc sử dụng một cách tiếp cận kiểm tra khác như thanh tra (inspection) hoặc chứng minh (demonstration) để biết liệu yêu cầu đó đã được cài đặt hợp lệ trong sản phẩm hay không. Nếu một yêu cầu không thể kiểm tra thì xác định liệu nó có được cài đặt đúng đắn hay không sẽ trở thành vấn đề gây tranh cãi. Các yêu cầu không nhất quán, không khả thi hoặc nhập nhằng thì cũng không thể kiểm tra được. - 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 hoặc chưa tối ưu nhất. Một SRS kiểm tra được sẽ nhanh phát hiện lỗi của mỗi yêu cầu trong quá trình triển khai dự án giúp giảm chi phí về tiền bạc và nhân lực để sửa chữa. Các Tips để viết đặc tả yêu cầu phần mềm Đưa ra các đánh giá dựa trên góc nhìn của nhà phát triển. Bất kể phía đối tác đưa ra yêu cầu nào, quan điểm nào, nên đứng trên quan điểm của nhà phát triển để đánh giá yêu cầu đó. Bản thân phía đối tác khi đưa ra yêu cầu phần mềm nào, đã mang góc nhìn và quan điểm của họ. Thông thường, họ không phải là người trong ngành công nghệ thông tin, và vì thế sẽ không hiểu hết rõ đặc thù của công việc phát triển phần mềm cũng như những khả năng của máy tính. Do đó, luôn phải đánh giá, nhận xét các yêu cầu phần mềm trên góc nhìn của nhà phát triển. Làm nổi bật các yêu cầu bằng cấu trúc phân cấp. Và cũng nên suy nghĩ, đánh giá dựa theo cấu trúc phân cấp này. Bởi bản thân cấu trúc phân cấp đã mang trong nó ít nhiều những thông tin về mối quan hệ logic giữa yêu cầu: Yêu cầu lớn, yêu cầu nhỏ, yêu cầu cha – con, các yêu cầu cùng mức phân cấp Chính cấu trúc này giúp việc đánh giá trở nên chính xác, hợp lý, và sát hơn. Đặc biệt đánh giá dựa trên hình ảnh trực quan bao giờ cũng dễ dàng hơn là chỉ suy nghĩ vấn đề trong đầu mà không có hình ảnh hỗ trợ. Và thực tế cũng chứng minh, hầu hết mọi người đối mặt với các vấn đề phức tạp bằng cấu trúc phân cấp (nó phân rã vấn đề lớn thành các vấn đề nhỏ - hiểu và có thể giải quyết được). Nếu không biểu diễn theo cấu trúc phân cấp, khó có thể nhận ra mối quan hệ logic giữa các yêu cầu/mục yêu cầu, khó nhận ra đâu là yêu cầu lớn, đâu là yêu cầu nhỏ, Cố gắng viết các câu và đoạn ngắn - đơn giản (write concisely): Tránh các đoạn văn nói dài. Bởi đôi khi một đoạn văn dài, với nhiều ý, cuối cùng lại không chốt được yêu cầu mà nó nói tới chính xác là cái gì! Dùng ngữ pháp, chính tả, và ngắt câu phù hợp (nên để người thông thạo ngôn ngữ được sử dụng để viết SRS) Dùng từ vựng trong lĩnh vực kinh doanh (đôi khi việc không sử dụng chính xác từ cũng làm thay đổi toàn bộ ý nghĩa mà yêu cầu muốn diễn đạt)  Trong một đoạn nói về một yêu cầu phần mềm nào đó, có thể có rất nhiều thông tin quan trọng, nhưng lại không chỉ rõ ra yêu cầu này cần xây dựng cái gì! Thay vì đó, đừng để yêu cầu về một chức năng được viết trong một đoạn quá dài, đưa các mô tả nền tảng (additional descriptive background), context của chức năng ra ngoài, tách bạch với mô tả chức năng. Đừng yêu cầu người khác rà soát lại một tài liệu chưa được kiểm tra ngữ pháp - chính tả. Sẽ tốt hơn nếu có 1 ai đó giỏi ngôn ngữ rà soát lại SRS, tìm ra các vấn đề về dùng từ và câu, để cho ra được 1 tài liệu tốt về mặt diễn đạt yêu cầu phần mềm. Phải có văn bản mô tả cho cả các hành vi được mong muốn lẫn các ngoại lệ - Chúng ta mong đợi hệ thống hoạt động theo đúng những hành vi mà ta mong muốn, tuy nhiên, 1 chương trình được viết cùng với rất nhiều những đoạn mã để xử lý lỗi, ngoại lệ. Và nếu chúng ta không xác định các lỗi, ngoại lệ cũng như cách xử lý chúng trong quá trình xây dựng yêu cầu phần mềm, sẽ có 2 vân đề! 1 là developers sẽ chỉ ra ngoại lệ đó và cố gắng thiết kế xử lý ngoại lệ đó theo 1 cách mà kém lý tưởng hơn từ quan điểm của người dùng. 2 là sẽ không ai nghĩ về lỗi/ngoại lệ đó. Và lần đầu tiên chương trình gặp lỗi, ngoại lệ đó, nó crash!  Công việc chỉ ra các ngoại lệ bị thiếu nên được thực hiện bởi tester, bởi họ sẽ nghĩ về mọi điều tồi tệ có thể xảy ra với chương trình. Tránh các ràng buộc thiết kế (design constraints) không cần thiết. Tránh việc đưa vào SRS quá nhiều ý tưởng giải quyết (solution ideas). Có nghĩa là đừng đưa quá nhiều ràng buộc thiết kế vào tài liệu SRS bằng cách kết hợp quá nhiều ý tưởng giải pháp trong tài liệu hướng dẫn, trừ khi có 1 lý do đặc biệt thỏa đáng. Viết các yêu cầu ở mức chi tiết hợp lý Khó để xác định xem tài liệu SRS cần được viết chi tiết đến mức nào, một trong những hướng dẫn, đó là chia các yêu cầu phần mềm ra thành các bộ phận mà có thể độc lập kiểm tra. Các từ "and" và "or" xác định các yêu cầu phần mềm có được kết hợp với nhau hay không. Ví dụ khi gặp 1 từ "and" trong yêu cầu phần mềm, ta sẽ đặt ra câu hỏi, phải chăng 2 vế của từ "and" là của cùng 1 yêu cầu? Hay chúng về mặt logic là 2 yêu cầu khác nhau và cần chia ra (split)? Viết các yêu cầu một cách chính xác, cụ thể, không mơ hồ và gây nhầm lẫn.  Một số lập trình viên đôi khi thích các yêu cầu phần mềm mơ hồ, gây nhầm lẫn, để khi bắt tay vào xây dựng, họ có thể xây dựng cái gì mà họ muốn ? Và thậm chí người dùng cũng thích các yêu cầu mơ hồ, gây nhầm lẫn, bởi nó cho phép họ định nghĩa lại yêu cầu đó theo ý mà họ muốn tại thời điểm cụ thể! Điều này không tốt một chút nào cho việc xây dựng một phần mềm chất lượng tốt!  Có một số từ nên được sử dụng để viết yêu cầu, và một số từ nên tránh. Nên sử dụng các từ "sẽ", "phải" thay vì 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 1 số thuật ngữ và sử dụng nó một cách nhất quán từ đầu đến cuối SRS khi nói về các chức năng hệ thống. Một người bạn của tác giả gợi ý là thay thế từ should bằng cụm từ "probably won't (có lẽ sẽ không)", và hỏi ý kiến người dùng có đồng ý với yêu cầu (phần mềm) đó không, và thông thường, người dùng nói không (tức là bản thân cụm từ probably won't cũng đã 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 năng được yêu cầu trong hệ thống, might - chức năng được mong muốn có trong hệ thống, và may - chức năng tùy chọn; điều này thực sự không tốt, bởi chính bản thân những từ này trong giao tiếp hàng ngày đã ít nhiều được sử dụng thay thế nhau. Chính điều đó sẽ khiến cho việc sử dụng chúng làm văn bản trở nên thiếu tính nhất quán, các yêu cầu thiếu tính đơn nghĩa! Như vậy cần tránh sử dụng các từ gây nhầm lẫn và mang tính chủ quan.