Phân tích yêu cầu phần mềm    

• Báo cáo

Bài đăng này đã không được update trong 4 nămĐể mang đến một mẫu sản phẩm phần mềm chất lượng đáng đáng tin cậy thì việc nghiên cứu và phân tích yêu cầu là khâu vô cùng quan trọng trong quy trình thiết kế xây dựng phần mềm. Hoạt động này yên cầu sự phố phối hợp rất ngặt nghèo giữa người mua và người nghiên cứu và phân tích để vạch ra được xem tất cả chúng ta phải tăng trưởng cái gì

1 – Mục tiêu và yêu cầu của phần mềm:

Yêu cầu của phần mềm là tất cả các yêu cầu về phần mềm do người dùng nêu ra bao gồm các chức năng của phần mềm, hiệu năng của phần mềm, giao diện của phần mềm và một số các yêu cầu khác

Thông thường những yêu cầu phần mềm được phân loại dựa trên 4 thành phần của phần mềm như sau :

• Các yêu cầu về phần mềm
• Các yêu cầu về phần cứng
• Các yêu cầu về dữ liệu
• Các yêu cầu về con người

Mục tiêu quan trọng nhất so với chất lượng phần mềm là phần mềm phải thỏa mãn nhu cầu được những yêu cầu và mong ước của người dùng. Người dùng thường chỉ đưa ra những sáng tạo độc đáo, nhiều khi rất mơ hồ về phần mềm mà họ mong ước thiết kế xây dựng. Và việc của những kỹ sư tăng trưởng phần mềm đó là phải giúp họ đưa những sáng tạo độc đáo mơ hồ đó thành hiện thực và thiết kế xây dựng được một phần mềm có vừa đủ những tính năng thiết yếu thỏa mãn nhu cầu yêu cầu của người dùng. Hơn thế nữa, ý tưởng sáng tạo của người dùng tiếp tục đổi khác và việc của nhà tăng trưởng là phải chớp lấy và phân phối được những yêu cầu đổi khác đó một cách hài hòa và hợp lý .

2 – Những khó khăn trong việc phân tích, nắm bắt yêu cầu:

2.1 – Những vấn đề từ phía người dùng:

• Người dùng không hiểu họ muốn gì
• Người dùng liên tục thay đổi yêu cầu ngay cả khi việc phát triển sản phẩm đã được bắt đầu
• Người dùng không hiểu về kỹ thuật
• Người dùng không hiểu về quy trình phát triển

2.2 – Những vấn đề từ phía nhà phát triển:

• Ngôn từ của người dùng và nhà phát triển không khớp nhau
• Nhà phát triển cố lái cho yêu cầu của người dùng khớp với một hệ thống hay mô hình sẵn có thay vì phát triển một hệ thống theo nhu cầu của khách hàng
• Việc phân tích có thể do các lập trình viên thực hiện thay vì các nhân viên có kỹ năng phân tích để có thể hiểu được nhu cầu của khách hàng một cách đúng đắn

2.3 – Những vấn đề khác:

• Các yêu cầu thường mang tính đặc thù của tổ chức đặt hàng nó, do đó nó thường khó hiểu, khó định nghĩa và không theo một tiêu chuẩn nào cả
• Các hệ thống thông tin lớn có rất nhiều người sử dụng, do đó các yêu cầu thường rất đa dạng và có các mức ưu tiên khác nhau, thậm chí mâu thuẫn lẫn nhau
• Người đặt hàng nhiều khi là các nhà quản lý, không phải là người dùng thực sự do đó việc đưa ra các yêu cầu thường không chính xác

3 – Các giai đoạn trong phân tích yêu cầu:

Mục đích của tiến trình nghiên cứu và phân tích là xác lập rõ những yêu cầu của phần mềm cần tăng trưởng. Tài liệu miêu tả yêu cầu phải vừa dễ hiểu với người dùng vừa ngặt nghèo để làm cơ sở cho việc lập kế hoạch. Do đó yêu cầu thường được miêu tả ở nhiều mức chi tiết cụ thể khác nhau, nhiều tiến trình khác nhau. Cụ thể như sau :

3.1 – Tìm hiểu các yêu cầu của phần mềm:

Các chiêu thức để khám phá những yêu cầu của phần mềm gồm có :

• Phỏng vấn, làm việc nhóm, họp và gặp gỡ đối tác…
• Tìm kiếm các chuyên gia, người sử dụng có hiểu biết về hệ thống cần xây dựng để thu thập được nhiều ý kiến, đóng góp khác nhau

3.2 – Phân tích yêu cầu và thương lượng:

Sau khi tìm hiểu và khám phá được những yêu cầu của phần mềm, tất cả chúng ta cần :

• Phân loại các yêu cầu phần mềm, sắp xếp chúng thành các nhóm có liên quan đến nhau dựa trên yêu cầu và đòi hỏi của người dùng
• Thẩm định từng yêu cầu phần mềm để xác định xem chúng có khả năng thực hiện được hay không
• Xác định các rủi ro có thể xảy ra với từng yêu cầu
• Đưa ra các đánh giá tương đối về  giá thành và thời gian thực hiện của từng yêu cầu
• Giải quyết các bất đồng về yêu cầu phần mềm với người dùng trên cơ sở thảo luận và thương lượng

3.3 – Mô hình hóa yêu cầu:

Một số chiêu thức hay dùng để quy mô hóa yêu cầu đó là :

a – Biểu đồ luồng dữ liệuBiểu đồ luồng dữ liệu (Data Flow Diagram – DFD) là một kỹ thuật để biểu diễn luồng thông tin vào ra của một chức năng trong hệ thống

Các thành phần biểu đồ luồng tài liệu gồm có :

• Các chức năng cần xử lý
• Luồng dữ liệu
• Kho dữ liệu
• Tác nhân: bao gồm tác nhân trong và tác nhân ngoài

Các ký hiệu được dùng trong biểu đồ luồng tài liệu như sau :Biểu đồ luồng tài liệu hoàn toàn có thể được dùng để màn biểu diễn cho một mạng lưới hệ thống hay phần mềm ở bất kể mức nào, từ tổng quát cho đến chi tiết cụ thể. Trong thực tiễn, DFD hoàn toàn có thể được phân loại thành nhiều mức màn biểu diễn. Sau đây là minh họa một DFD cho mạng lưới hệ thống bán vé tầu .

b – Biểu đồ thực thể quan hệ

Mô hình quan hệ – thực thể ER ( Entity Relationship Model ) được sử dụng để phong cách thiết kế cơ sở tài liệu ở mức khái niệm. Mô hình này được sử dụng như một công cụ để trao đổi sáng tạo độc đáo giữa nhà phong cách thiết kế và người dùng cuối trong quá trình nghiên cứu và phân tíchMô hình quan hệ – thực thể gồm có ba thành phần cơ bản :

• Kiểu thực thể
• Mối quan hệ
• Các thuộc tính

Sau đây là một ví dụ cho quy mô quan hệ – thực thể

3.4 – Đặc tả yêu cầu:

a – Phân loại yêu cầu:Yêu cầu được chia thành nhiều loại:

• Yêu cầu chức năng: Mô tả một chức năng cụ thể mà phần mềm cung cấp
• Yêu cầu phi chức năng: Các ràng buộc về chất lượng, môi trường, chuẩn sử dụng, quy trình phát triển phần mềm
• Yêu cầu về sản phẩm: Gồm tốc độ, độ tin cậy, bộ nhớ, giao diện, quy trình tác nghiệp,…
• Yêu cầu về tiến trình phát triển: Gồm các chuẩn, phương pháp thiết kế, ngôn ngữ lập trình….
• Yêu cầu khác: Gồm chi phí, thời gian, bản quyền,…

b – Đặc tả yêu cầu:Nếu như tài liệu xác định yêu cầu được viết bởi ngôn ngữ tự nhiên của khách hàng thì tài liệu đặc tả yêu cầu phải rất rõ ràng và được xây dựng theo hướng của người phát triển, tránh gây hiểu nhầm giữa khách hàng và người phát triển.

Có những chiêu thức đặc tả như sau :

• Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ tự nhiên
• Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ đặc tả, công thức và biểu đồ
• Đặc tả chức năng: Thông thường, khi đặc tả chức năng của phần mềm, người ta sử dụng các công cụ tiêu biểu sau: Biểu đồ phân rã chức năng (Functional Decomposition Diagram  FDD), Biểu đồ luồng dữ liệu (Data Flow Diagrams-DFD), Biểu đồ trạng thái,….
• Đặc tả mô tả: Sử dụng các công cụ tiêu biểu sau: Biểu đồ thực thể liên kết (EntityRelationship Diagrams – ERD), Đặc tả logic (Logic Specifications), Đặc tả đại số (Algebraic Specifications)

Chất lượng cả bản đặc tả yêu cầu được nhìn nhận qua những tiêu chuẩn sau :

• Tính rõ ràng, chính xác
• Tính phù hợp
• Tính đầy đủ, hoàn thiện

c – Thẩm định yêu cầu:Sau khi các yêu cầu được xây dựng thì chúng cần được thẩm định xem đã thỏa mãn nhu cầu của khách hàng hay chưa. Nếu việc thẩm định không được thực hiện một cách nghiêm túc, chặt chẽ thì các sai sót sẽ có thể gây ra những hậu quả lớn cho các giai đoạn về sau.

Mục tiêu của việc đánh giá và thẩm định là xác lập xem yêu cầu có thỏa mãn nhu cầu 4 yếu tố sau không :

• Yêu cầu có thỏa mãn nhu cầu người dùng hay không?
• Yêu cầu có mâu thuẫn với nhau hay không?
• Yêu cầu có mô tả đầy đủ tất cả các chức năng và ràng buộc hay không?
• Yêu cầu có đảm bảo các khía cạnh về kỹ thuật, kinh tế và pháp lý hay không?

d – Xây dựng bản mẫu:

Đối với những mạng lưới hệ thống phức tạp, nhiều khi tất cả chúng ta không nắm chắc được yêu cầu của người mua, tất cả chúng ta cũng khó nhìn nhận được tính khả thi cũng như hiệu suất cao của mạng lưới hệ thống. Một giải pháp được đưa ra là thiết kế xây dựng bản mẫu. Bản mẫu vừa được dùng để nghiên cứu và phân tích yêu cầu vừa hoàn toàn có thể tiến hóa thành loại sản phẩm ở đầu cuối. Bản mẫu phần mềm không phải nhằm mục đích vào việc đánh giá và thẩm định phong cách thiết kế ( phong cách thiết kế của nó thường là trọn vẹn khác với mạng lưới hệ thống được tăng trưởng ở đầu cuối ), mà là để đánh giá và thẩm định yêu cầu của người sử dụng .

3.5 – Định dạng đặc tả yêu cầu:

Kết quả của bước nghiên cứu và 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 khoanh vùng phạm vi của mẫu sản phẩm, những tính năng cần có, đối tượng người dùng người sử dụng và những ràng buộc khi quản lý và vận hành mẫu sản phẩm. Có nhiều chuẩn khác nhau trong thiết kế 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 ) .Trên đây là khái quát về bước nghiên cứu và phân tích và đặc tả yêu cầu trong quy trình tăng trưởng phần mềm. Kết quả của việc nghiên cứu và phân tích là tạo ra bản đặc tả những yêu cầu phần mềm. Đặc tả cần được xét duyệt để bảo vệ rằng người tăng trưởng và người mua có cùng phân biệt về mạng lưới hệ thống cần tăng trưởng. Trong những bài viết sau, tôi sẽ miêu tả chi tiết cụ thể hơn về những chiêu thức để quy mô hóa yêu cầu

Nguồn tham khảo:http://uet.vnu.edu.vn/~hungpn/class/ASE/Lec2_1.pdf https://truonganhhoang.gitbooks.io/swebok3/content/chapter_1_Software_requirements.html