Đặc Tả Yêu Cầu Là Gì | Các Thành Phần Của Tài Liệu Đặc Tả Yêu Cầu

1.Thu thập yêu cầu

Là giai đoạn đầu tiên trong việc xây dựng sự hiểu biết về sản phẩm phần mềm và các vấn đề cần thiết phải giải quyết (ví dụ cần hiểu biết về các chức năng của phần mềm). Đây cũng là giai đoạn mà các bên liên quan (stakeholders) được xác định. Thiết lập các mối quan hệ giữa các nhóm phát triển và khách hàng.

Một trong những nguyên tắc cơ bản của quá trình thu thập yêu là sự trao đổi giữa các bên liên quan. Sự trao đổi liên tục qua toàn bộ vòng đời phát triển phần mềm (SDLC), quá trình trao đổi với các bên liên quan khác nhau tại mỗi các thời điểm khác nhau. Trước khi bắt đầu phát triển, các chuyên gia thu thập yêu cầu có thể tạo ra các kênh cho sự giao tiếp này. Họ sẽ là trung gian giữa khách hàng và kỹ sư phần mềm.Một số lợi ích của thu thập yêu cầu:

• Tạo được niềm tin của khách hàng khi họ được tham gia vào giai đoạn thu thập yêu cầu.
• Giảm việc phải làm lại trong quá trình phát triển
• Quá trình phát triển sẽ nhanh hơn, giảm được những chi phí cho những yêu cầu không cần thiết.
• Hạn chế phạm vi hệ thống bị phình rộng (scope creep).

1.3.Nguồn yêu cầu – Requirements Sources

Các yêu cầu có rất nhiều nguồn trong đặc thù phần mềm và điều quan trọng là tất cả các nguồn tiềm năng cần được xác minh và đánh giá. Phần này nhằm nâng cao nhận thức của các nguồn khác nhau của yêu cầu phần mềm và những framework để quản lý chúng.Những điểm chính của nguồn yêu cầu bao gồm:

• Mục tiêu – Goal: Các mục tiêu về giá trị và giá thành thường mơ hồ, không rõ ràng. Kĩ sư phần mềm cần chú ý để xác định rõ các mục tiêu đó. Nghiên cứu tính khả thi là sẽ giúp giảm giá thành của quá trình phát triển. Ví dụ kỹ sư phần mềm cần xác định chi phí xây dựng server với chi phí đi mua cái nào sẽ tối ưu hơn để lựa chọn.
• Hiểu biết về các lĩnh vực: Các kỹ sư phần mềm cần có kiến thức về các lĩnh vực như: mua sắm, ngân hàng, chăm sóc sức khỏe,… lĩnh vực mà phần mềm được sử dụng. Việc hiểu biết về các lĩnh vực sẽ giúp cho người thu thập yêu cầu thu thập được những thông tin chính xác cao.
• Các bên liên quan (Stakeholders): Nhiều phần mềm đã được chứng minh không đạt yêu cầu vì nó chỉ tập trung vào yêu cầu của một số bên mà bỏ qua các bên khác. Do đó phần mềm đã giao rất khó để sử dụng hoặc phá vỡ văn hóa hoặc tổ chức chính trị của tổ chức khách hàng. Các kỹ sư phần mềm cần phải xác định, miêu tả và quản lý các yêu cầu của các bên liên quan. Ví dụ phần mềm cho người không chuyên thì sử dụng chuột và các menu chọn, nhưng với người thành thạo thì cần có các hot-key để rút ngắn thời gian tương tác
• Nguyên tắc kinh doanh (Business Rules): Là những điều kiện hoặc các ràng buộc được xác định để các doanh nghiệp hoạt động được. “Một sinh viên không thể đăng ký vào các khóa học học kỳ tiếp theo nếu vẫn còn một số môn chưa thanh toán học phí” sẽ là một ví dụ của nguyên tắc kinh doanh đó cho các phần mềm đăng ký môn học của trường đại học.
• Môi trường vận hành: Các yêu cầu sẽ được bắt nguồn từ môi trường mà trong đó phần mềm sẽ được thực thi. Ví dụ như ràng buộc thời gian trong phần mềm thời gian thực hoặc ràng buộc hiệu năng trong môi trường kinh doanh.
• Môi trường tổ chức: Phần mềm thường có thể bị ràng buộc bởi cấu trúc, văn hóa và tổ chức chính trị, nói dân dã ở môi trường thực tiễn Việt Nam thì “dự án khó triển khai hoặc tiến độ khó đáp ứng do vướng nghị định ABC, thiếu văn bản chỉ dẫn…”. Do vậy các kỹ sư hay quản lý dự án cần phải nắm rất rõ về yếu tố này, phần mềm không nên ép buộc thay đổi ngoài ý muốn trong quá trình kinh doanh.

1.3.Kỹ thuật thu thập – Elicitation Techniques

Một khi các nguồn yêu cầu được xác định, các kỹ sư phần mềm có thể bắt đầu thu thập thông tin yêu cầu từ chúng. Phần này tập trung vào các kỹ thuật để thu thập các thông tin cần thiết từ các bên liên quan.

Các kỹ sư phần mềm cần phải linh hoạt với các sự việc xảy ra ví dụ: người dùng gặp khó khăn trong việc mô tả yêu cầu của họ, có thể thông tin quan trọng không được nói ra hoặc có thể không muốn hoặc không thể hợp tác.

Thu thập không phải là hoạt động thụ động, ngay cả khi các bên liên quan sẵn sàng hợp tác các kỹ sư phần mềm phải cố gắng để thu thập thông tin chính xác nhất.Một số kỹ thuật thu thập yêu cầu như:

• Phỏng vấn: Phỏng vấn là cách truyền thống để thu thập yêu cầu.
  • Ưu điểm: Thu thập được được những thông tin trực tiếp các thông tin có chất lượng cao, tính chân thực và độ tin cậy có thể kiểm nghiệm được trong quá trình phỏng vấn.
  • Nhược điểm: Đòi hỏi người phỏng vấn phải có trình độ cao, am hiểu, có kỹ năng xử lý các tình huống. Khó triển khai được trên quy mô rộng. Tiếp cận khách hàng là việc tương đối khó vì cần hẹn trước.
• Kịch bản: Kỹ sư phần mềm cung cấp một hệ thống các câu hỏi bằng việc sử sụng các câu hỏi như “What if” và “How is this done”. Các loại kịch bản phổ biến được sử dụng là mô tả các trường hợp sử dụng. Ví dụ: Điều gì sẽ xảy ra với phần mềm khi bị mất kết nối mạng,…
• Các bản mẫu: Kỹ thuật này sẽ làm rõ các yêu cầu không rõ ràng. Có thể sử dụng mockup, prototypes (bản vẽ thô), wireframes (bản vẽ có workflows rõ ràng) hoặc màn hình thiết kế hoặc các bản thử nghiệm để xác minh những yêu cầu từ khách hàng. Ví dụ: Thu thập các yêu cầu về thiết kế hoặc chức năng của phần mềm.
• Cuộc hội họp: Một nhóm người sẽ mang lại nhiều cái nhìn sâu sắc hơn vào các yêu cầu phần mềm. Mọi người sẽ cùng suy nghĩ, tinh chỉnh các yêu cầu. Lợi thế của phương pháp này là các yêu cầu mâu thuẫn sẽ dễ dàng xử lý hơn.

Người phân tích

Người phân tích đóng vai trò đặc biệt quan trọng trong tiến trình phân tích. Ngoài kinh nghiệm, một người phân tích tốt cần có các khả năng sau:

– Khả năng hiểu thấu các khái niệm trừu tượng, có khả năng tổ chức lại thành các phân tích logic và tổng hợp các giải pháp dựa trên từng dải phân chia.

– Khả năng rút ra các sự kiện thích đáng từ các nguồn xung khắc và lẫn lộn.

– Khả năng hiểu được môi trường người dùng/khách hàng.

– Khả năng áp dụng các 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ả năng giao tiếp tốt ở dạng viết và nói.

– Khả năng trừu tượng hóa/tổng hợp vấn đề từ các sự kiện riêng lẻ.

Xác định và đặc tả yêu cầu

Thẩm định yêu cầu

Một khi các yêu cầu đã được thiết lập thì cần thẩm định xem chúng có thỏa mãn các nhu cầu của khách hàng hay không. Nếu thẩm định không được tiến hành chặt chẽ thì các sai sót có thể lan truyền sang các giai đoạn thiết kế và mã hóa khiến cho việc sửa đổi hệ thống trở nên rất tốn kém. Mục tiêu của thẩm định là kiểm tra xem yêu cầu mà người phân tích xác định có thỏa mãn 4 yếu tố sau không:

1. Thỏa mãn nhu cầu của người dùng: cần phải thỏa mãn được các nhu cầu bản chất của người dùng (khách hàng).
2. Các yêu cầu không được mâu thuẫn nhau: với các hệ thống lớn các yêu cầu rất đa dạng và có khả năng sẽ mâu thuân nhau. Khi đó người phân tích phải loại bớt các yêu cầu (không chủ chốt) để sau cho các yêu cầu được mô tả trong tài liệu yêu cầu không mâu thuẫn nhau.
3. Các yêu cầu phải đầy đủ: cần chứa mọi chức năng và ràng buộc mà người dùng đã nhắm đến.
4. Các yêu cầu phải hiện thực: yêu cầu phải hiện thực về các khía cạnh kỹ thuật, kinh tế và pháp lý.

Làm bản mẫu trong quá trình phân tích

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

Cách viết đặc tả yêu cầu phần mềm

Xác định mục tiêu và yêu cầu của phần mềm

Đó là các yêu cầu liên quan đến phần mềm do người dùng (Khách hàng đưa ra): chức năng, hiệu năng, giao diện của phần mềm, và một số các yêu cầu khác…

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

Phân tích yêu cầu

Phân loại các yêu cầu phần mềm, sau đó nhóm và sắp xếp chúng với nhau dựa trên yêu cầu.

Kiểm tra các yêu cầu phần mềm để xác định khả năng thực hiện yêu cầu đó được hay không. Đồng thời xác định rủi ro để có phương án xử lý và tính giá thành, thời gian thực hiện các yêu cầu.

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

Biểu đồ luồng dữ liệu là một kỹ thuật để biểu diễn luồng thông tin đầu vào đầu ra của một chức năng có trong hệ thống.

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

Mô hình quan hệ – thực thể ER (Entity Relationship Model) được sử dụng để thiết kế cơ sở dữ liệu ở mức khái niệm, là công cụ để trao đổi ý tưởng giữa người dùng cuối cùng trong giai đoạn phân tích và người thiết kế.

Xác định phương pháp đặc tả

• Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ bình thường, tự nhiên.
• Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ có quy định về cú pháp và ý nghĩa rất chặt chẽ.
• Đặ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 đồ luồng dữ liệu (Data Flow Diagrams-DFD), Biểu đồ phân rã chức năng (Functional Decomposition Diagram – FDD), 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 (Entity Relationship Diagrams – ERD), Đặc tả đại số (Algebraic Specifications), Đặc tả logic , để mô tả các đặc tính đặc trưng của phần mềm.

Thẩm định yêu cầu

Các yêu cầu có đáp ứng nhu cầu người dùng hay không?

Các yêu cầu có bị mâu thuẫn không đồng nhất với nhau hay không?

Yêu cầu có thể hiện đầy đủ tất cả các ràng buộc và chức năng của phần mềm hay không?

Yêu cầu có đảm bảo các mặt về kinh tế kỹ thuật, và pháp lý hay không?

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

Đối với những hệ thống phức tạp để nắm chắc được yêu cầu thì nên xây dựng bản mẫu. Bản mẫu sẽ dùng để phân tích yêu cầu đồng thời tiến hóa thành sản phẩm cuối.

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

Bản đặc tả yêu cầu phần mềm được tạo ra phải chỉ rõ được phạm vi của sản phẩm, đối tượng sử dụng, chức năng và yêu cầu vận hành.

Như vậy qua phần giới thiệu về cách viết đặc tả yêu cầu phần mềm bạn thấy rằng để đưa ra được bản đặc tả hiệu quả cần phải tuân thủ theo các nguyên tắc và phương pháp đặc tả. Qua đó tạo được bản đặc tả yêu cầu phần mềm để đảm bảo rằng cả khách hàng và developer có cùng nhận biết về hệ thống cần phát triển.

Các bước làm bản mẫu

Xây dựng bản mẫu bao gồm 6 bước sau:

1. Đánh giá yêu cầu phần mềm và xác định liệu phần mềm cần xây dựng có xứng đáng để làm bản mẫu không Không phải tất cả các phần mềm đều có thể đưa tới làm bản mẫu. Ta có thể xác định một số nhân tố làm bản mẫu: lĩnh vực ứng dụng, độ phức tạp ứng dụng, đặc trưng khách hàng và đặc trưng dự án. Để đảm bảo tính tương tác giữa khách hàng với bản mẫu, chúng ta cần đảm bảo các điều kiện:
   • Khách hàng phải cam kết dùng tài nguyên để đánh giá và làm mịn bản mẫu (chi tiết hóa yêu cầu)
   • Khách hàng phải có khả năng đưa ra những quyết định về yêu cầu một cách kịp thời
2. Với một dự án chấp thuận được, người phân tích xây dựng một cách biểu diễn vắn tắt cho yêu cầu. Trước khi có thể bắt đầu xây dựng một bản mẫu, người phân tích phải biểu diễn miền thông tin và các lĩnh vực, hành vi và chức năng của vấn đề rồi xây dựng một cách tiếp cận hợp lý tới việc phân hoạch. Có thể ứng dụng các nguyên lý phân tích nền tảng (phân tích topưdown) và các phương pháp phân tích yêu cầu.
3. Sau khi đã duyệt xét mô hình yêu cầu, phải tạo ra một đặc tả thiết kế vắn tắt cho bản mẫu Việc thiết kế phải xuất hiện trước khi bắt đầu làm bản mẫu. Tuy nhiên thiết kế tập trung chủ yếu vào các vấn đề thiết kế dữ liệu và kiến trúc mức đỉnh chứ không tập trung vào thiết kế thủ tục chi tiết.
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 cách tiếp cận làm bản mẫu. Chính ở đây mà khách hàng có thể xem xét cách biểu diễn được cài đặ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.

1.Tiến trình yêu cầu phần mềm

Vị trí trong mô hình tiến trình

• Xuất phát từ giai đoạn khởi tạo dự án, cho tới khi hoàn thiện các tiến trình trong vòng đời phát triển của phần mềm. Không chỉ là các hoạt động bề nổi nhìn thấy được.
• Được nhận biết như phần cấu hình của mọi việc, và được quản lý như việc quản lý các cấu hình; hoặc là sản phẩm của các quá trình trong vòng đời phát triển.
• Được thiết kế theo từng tổ chức và hoàn cảnh của từng dự án.

Các nhân tố tham gia

• Người dùng: vận hành phần mềm.
• Khách hàng: gồm những người được hưởng mục tiêu cuối cùng của phần mềm, những giá trị thương mại mà phần mềm hướng đến.
• Nhà phân tích thị trường: phân tích nhu cầu thị trường và tương tác với bên đại diện khách hàng.
• Đại diện pháp lý: kiểm soát việc tuân thủ quy định, quy ước chung, quy định pháp lý.
• Kỹ sư phần mềm: thu lợi nhuận hợp pháp từ việc phát triển phần mềm.

Quản lý và Hỗ trợ quy trình

• Quản lý nguồn tài nguyên được sử dụng trong các tiến trình.
• Cân đối nguồn nhân lực, tài chính, đào tạo và công cụ.

Chất lượng và cải tiến

• Xác định vai trò của tiến trình xây dựng yêu cầu về các mặt chi phí, thời gian và sự thoả mãn của khách hàng với sản phẩm.
• Định hướng tiến trình theo các chuẩn chất lượng và xây dựng mô hình cải tiến cho phần mềm và hệ thống.
• Bao gồm:
  • Độ bao phủ theo các mô hình và chuẩn cải tiến.
  • Việc đo đạc và đánh giá tiến trình.
  • Việc thực hiện và lên kế hoạch cải tiến.
  • Việc cài đặt và lên kế hoạch cho an ninh.

1.Khảo sát hiện trạng

Thực trạng có rất nhiều thay đổi, do đó quản lý những thay đổi và duy trì những yêu cầu là chìa khóa quyết định sự thành công của phần mềm. Ví dụ : không phải tổ chức nào cũng có thói quen làm tài liệu cũng như quản lý yêu cầu đặc biệt với những công ty mới thành lập hoặc những công ty có nguồn nhân lực hạn chế. Khi những công ty này mở rộng, số lượng khách hàng trở lên lớn hơn, sản phẩm của họ bắt đầu phát triển, thì lúc này việc tìm lại những yêu cầu và thúc đẩy thêm nhiều tính năng để đáp ứng nhu cầu thị trường và sự thay đổi của môi trường là rất cần thiết. Do đó, tài liệu yêu cầu và quản lý những thay đổi là chìa khóa cho sự thành công của bất kì quá trình yêu cầu nào.

1.7.Quản lý thay đổi

Quản lý thay đổi là trung tâm của quản lý yêu cầu. Yêu cầu phần mềm luôn luôn thay đổi: Môi trường doanh nghiệp và kĩ thuật thay đổi. Phần cứng mới cũng có thể dẫn thay đổi giao diện mới. Ví dụ: Màn hình thay đổi, sắc nét hơn nên giao diện cũng phải chăm chút hơn. Luật thay đổi, nhu cầu doanh nghiệp thay đổi, dẫn đến thay đổi chức năng. Ví dụ: Luật doanh nghiệp không cho tiết lộ thông tin người dùng. Do đó hệ thống quản lý user cần phải bảo mật hơn

• Khách hàng, người sử dụng thay đổi dẫn đến thay đổi chức năng. Ví dụ: Khách hàng muốn tạo chức năng đặt lịch gửi mail. Do đó phần mềm cần phải có chức năng email scheduler.
• Xung đột giữa các yêu cầu mới nảy sinh, và giữa yêu cầu mới với yêu cầu cũ. Dẫn đến quản lý thay đổi là trung tâm và đặc biệt quan trọng của quản lý các yêu cầu.

1.7.Định danh yêu cầu

• Yêu cầu bao gồm không chỉ đặc tả hệ thống mà còn những thông liên quan, giúp dễ dàng quản lý và diễn giải yêu cầu
• Đinh danh yêu cầu cần được định nghĩa, ghi nhân và cập nhật như phần phần mềm trong quá trình phát triển và bảo trì.
• Bao gồm:
  • Việc phân loại yêu cầu. Ví dụ: Functional Requirement (FR) and Non-Functional Requirement (NRF).
  • Phương pháp xác minh Ví dụ: .Xác minh bằng cách xem lại yêu cầu . xác minh bằng sử dụng phiên bản mẫu, thử nghiệm
  • Thẩm định mô hình (Validation)
  • Kiểm thử chấp thuận (UAT)
  • Kế hoạch kiểm thử (Verification)
  • Thuộc tính duy nhất để thuận tiện cho việc tham chiếu giữa các yêu cầu và lần vết. Ví dụ: thông tin của yêu cầu duy nhất để tiện cho việc thêm và chỉnh sửa sau khi có sự thay đổi.

1.7.Lần vết yêu cầu

• Lần vết yêu cầu có liên quan với việc khôi phục nguồn của yêu cầu và dự đoán những ảnh hưởng của các yêu cầu.
• Truy vết để thực hiện phân tích những ảnh hưởng khi yêu cầu thay đổi.
• Một yêu cầu nên được truy về những yêu cầu khác và các bên liên quan để thúc đẩy nó (ví dụ: từ yêu cầu phần mềm về yêu cầu hệ thống)
• Ngược lại. một yêu cầu nên được truy đến những yêu cầu khác nhằm thỏa mãn nó (ví dụ: từ yêu cầu hệ thống đến yêu cầu phần mềm)

1.7.Ðánh giá yêu cầu

• Đánh giá kích thước của sự thay đổi yêu cầu.
  • Ví dụ: Đánh giá độ khó khăn của việc triển khai thay đổi yêu cầu, đánh giá xem nó ảnh hưởng tới những phân hệ nào trong hệ thống.
• Đánh giá chi phí cho việc phát triển hoặc duy trì một yêu cầu
  • Ví dụ: Đánh giá nguồn lực, chi phí, man-day cho việc thay đổi yêu cầu.

Mô hình hóa

Chúng ta tạo ra các mô hình để thu được hiểu biết rõ hơn về thực thể thực tế cần xây dựng. Khi thực thể là một vật vật lý (như toà nhà, máy bay, máy móc) thì ta có thể xây dựng một mô hình giống hệt về hình dạng, nhưng nhỏ hơn về qui mô. Tuy nhiên, khi thực thể cần xây dựng là phần mềm, thì mô hình của chúng ta phải mang dạng khác. Nó phải có khả năng mô hình hóa thông tin mà phần mềm biến đổi, các chức năng (và chức năng con) làm cho phép biến đổi đó thực hiện được, và hành vi của hệ thống khi phép biến đổi xảy ra.

Trong khi phân tích các yêu cầu phần mềm, chúng ta tạo ra các mô hình về 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 chú ý đến cách thức nó thực hiện. Trong nhiều trường hợp, các mô hình chúng ta tạo ra có dùng kí pháp đồ hoạ mô tả cho thông tin, xử lý, hành vi hệ thống, và các đặc trưng khác thông qua các biểu tượng phân biệt và dễ nhận diện. Những phần khác của mô hình có thể thuần túy văn bản. Thông tin mô tả có thể được cung cấp bằng cách dùng một ngôn ngữ tự nhiên hay một ngôn ngữ chuyên dụng cho mô tả yêu cầu. Các mô hình được tạo ra trong khi phân tích yêu cầu còn đóng một số vai trò quan trọng:

• Mô hình trợ giúp cho người phân tích trong việc hiểu về thông tin, chức năng và hành vi của hệ thống, do đó làm cho nhiệm vụ phân tích yêu cầu được dễ dàng và hệ thống hơn.
• Mô hình trở thành tiêu điểm cho việc xem xét và do đó, trở thành phần mấu chốt cho việc xác định tính đầy đủ, nhất quán và chính xác của đặc tả.
• Mô hình trở thành nền tảng cho thiết kế, cung cấp cho người thiết kế một cách biểu diễn chủ yếu về phần mềm có thể được “ánh xạ” vào hoàn cảnh cài đặt.

Dưới đây là một số mô hình (phương pháp) hay được dùng trong phân tích:

1. Biểu đồ luồng dữ liệu

Khi thông tin đi qua phần mềm nó bị thay đổi bởi một loạt các phép biến đổi. Biểu đồ luồng dữ liệu (Data Flow Diagram – DFD) là một kỹ thuật vẽ ra luồng dữ liệu di chuyển trong hệ thống và những phép biến đổi được áp dụng lên dữ liệu. Ký pháp cơ bản của biểu đồ luồng dữ liệu được minh họa trên hình 2.

Biểu đồ luồng dữ liệu có thể được dùng để biểu diễn cho một hệ thống hay phần mềm ở bất kì mức trừu tượng nào. Trong thực tế, DFD có thể được phân hoạch thành nhiều mức biểu diễn cho chi tiết chức năng và luồng thông tin ngày càng tăng. Do đó phương pháp dùng DFD còn được gọi là phân tích có cấu trúc. Một DFD mức 0, cũng còn được gọi là biểu đồ nền tảng hay biẻu đồ ngữ cảnh hệ thống, biểu diễn cho toàn bộ phần tử phần mềm như một hình tròn với dữ liệu vào và ra được chỉ ra bởi các mũi tên tới và đi tương ứng. Một DFD mức 1 cụ thể hóa của DFD mức 0 và có thể chứa nhiều hình tròn (chức năng) với các mũi tên (luồng dữ liệu) nối lẫn nhau. Mỗi một trong các tiến trình được biểu diễn ở mức 1 đều là chức năng con của toàn bộ hệ thống được mô tả trong biểu đồ ngữ cảnh. Hình 3 minh họa một DFD cho hệ thống bán vé tầu.

2. Biểu đồ thực thể quan hệ

Ký pháp nền tảng cho mô hình hóa dữ liệu là biểu đồ thực thể – quan hệ (Entity – Relation Diagram). Tất cả đều xác định một tập các thành phần chủ yếu cho biểu đồ EưR: thực thể, thuộc tính, quan hệ và nhiều chỉ báo kiểu khác nhau. Mục đích chính của biểu đồ EưR là biểu diễn dữ liệu và mối quan hệ của các dữ liệu (thực thể).

Ký pháp của biểu đồ EưR cũng tương đối đơn giản. Các thực thể được biểu diễn bằng các hình chữ nhật có nhãn. Mối quan hệ được chỉ ra bằng hình thoi. Các mối nối giữa sự vật dữ liệu và mối quan hệ được thiết lập bằng cách dùng nhiều đường nối đặc biệt (hình 4).

Các nguyên lý phân tích

Trên hai thập kỉ qua, người ta đã xây dựng ra một số phương pháp phân tích và đặc tả phần mềm. Những người nghiên cứu đã xác định ra các vấn đề và nguyên nhân của chúng, và đã xây dựng ra các qui tắc và thủ tục để vượt qua chúng. Mỗi phương pháp đều có kí pháp và quan điểm riêng. Tuy nhiên, tất cả các phương pháp này đều có quan hệ với một tập hợp các nguyên lý cơ bản:

1. Miền thông tin của vấn đề phải được biểu diễn lại và hiểu rõ.
2. Các mô hình mô tả cho thông tin, chức năng và hành vi hệ thống cần phải được xây dựng.
3. Các mô hình (và vấn đề) phải được phân hoạch theo cách để lộ ra các chi tiết theo kiểu phân tầng (hay cấp bậc).
4. Tiến trình phân tích phải đi từ thông tin bản chất hướng tới chi tiết cài đặt. Bằng cách áp dụng những nguyên lý này, người phân tích tiếp cận tới vấn đề một cách hệ thống.

Miền thông tin cần được xem xét sao cho người ta có thể hiểu rõ chức năng một cách đầy đủ. Các mô hình được dùng để cho việc trao đổi thông tin được dễ dàng theo một cách ngắn gọn. Việc phân hoạch vấn đề được sử dụng để làm giảm độ phức tạp. Những cách nhìn nhận cả từ góc độ bản chất và góc độ cài đặt về phần mềm đều cần thiết để bao hàm được các ràng buộc logic do yêu cầu xử lý áp đặt nên cùng các ràng buộc vật lý do các phần tử hệ thống khác áp đặt nên.

Xác định yêu cầu

Xác định yêu cầu là mô tả trừu tượng về các dịch vụ mà hệ thống cần cung cấp và các ràng buộc mà hệ thống cần tuân thủ khi vận hành. Nó chỉ mô tả các hành vi bên ngoài của hệ thống mà không liên quan tới các chi tiết thiết kế. Yêu cầu nên được viết sao cho có thể hiểu mà không cần một kiến thức chuyên môn đặc biệt nào.

Các yêu cầu được chia thành hai loại:

1. Các yêu cầu chức năng: các dịch vụ mà hệ thống cần cung cấp
2. Các yêu cầu phi chức năng: các ràng buộc mà hệ thống cần tuân thủ.

Các yêu cầu phi chức năng có thể chia làm 3 kiểu:

1. Yêu cầu sản phẩm: các yêu cầu về tốc độ, bộ nhớ, độ tin cậy, về tính khả chuyển và tái sử dụng…
2. Yêu cầu về quá trình: yêu cầu đối với quá trình xây dựng sản phẩm như các chuẩn phải tuân theo, các phương pháp thiết kế, ngôn ngữ lập trình…
3. Yêu cầu khác: các yêu cầu không thuộc hai nhóm trên như về tính pháp lý, về chi phí, về thành viên nhóm phát triển…

Các yêu cầu phi chức năng thường rất đặc thù với từng khách hàng và do đó khó phân tích và đặc tả một cách đầy đủ và chính xác.

Về nguyên tắc, yêu cầu của hệ thống phải vừa đầy đủ vừa không được mâu thuẫn nhau. Đối với các hệ thống lớn phức tạp thì chúng ta khó đạt được hai yếu tố này trong các bước phân tích đầu. Trong các 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.

1.Kiến thức cơ bản

Tổng quan

Định nghĩa

• Yêu cầu cho 1 phần mềm cụ thể là tổng hợp những yêu cầu từ nhiều người khác nhau về tổ chức, mức độ chuyên môn và mức độ tham gia, tương tác với phần mềm trong môi trường hoạt động của nó.
• Có thể kiểm chứng một cách riêng rẽ ở mức chức năng (yêu cầu chức năng) hoặc mức hệ thống (yêu cầu phi chức năng).
• Cung cấp các chỉ số đánh giá độ ưu tiên về các mặt khi cân nhắc về nguồn tài nguyên.
• Cung cấp các giá trị trạng thái để theo dõi tiến độ của dự án.

Phân loại

• Theo sản phẩm và tiến trình
  • Yêu cầu sản phẩm: là những đòi hỏi hay ràng buộc mà phần mềm phải thực hiện.
  • Yêu cầu tiến trình: là những ràng buộc liên quan đến việc phát triển phần mềm đó (quy trình, đối tác kiểm thử, phân tích, kĩ thuật sử dụng,…).

Ví dụ:

Trong Project A:

Yêu cầu sản phẩm là xây dựng trang Web trường học điện tử với các tính năng như Giáo viên quản lý câu hỏi, đề thi; Học sinh tham gia làm bài; Admin duyệt câu hỏi của giáo viên trước khi đăng,…

Yêu cầu tiến trình: Phải thực hiện theo mô hình Agile. Sản phẩm cuối cùng bao gồm cả sản phẩm và backlog cho từng Sprint.

• Theo chức năng

  • Yêu cầu chức năng: đặc tả các chức năng mà phần mềm phải thực hiện.
  • Yêu cầu phi chức năng: là các ràng buộc về giải pháp và chất lượng (hiệu năng, việc bảo trì, độ an toàn, bảo mật,…).
  • Yêu cầu đặc tả các thuộc tính nổi bật: là đặc tả cho các thuộc tính phụ thuộc vào sự vận hành, đặc biệt là kiến trúc hệ thống. Các thuộc tính này không thể xác định được cho từng thành phần đơn lẻ.

• Theo tính kiểm định (Verification)

  • Mơ hồ, không thể kiểm định (verify)
  • Rõ ràng, định lượng và có thể kiểm định được.
• Theo phạm vi đặc tả
  • Yêu cầu hệ thống: đặc tả các cấu hình, cơ sở hạ tầng, phần cứng, phần mềm, con người, kỹ thuật,… của toàn bộ hệ thống.
  • Yêu cầu phần mềm: đặc tả các chức năng, giao diện,… của các cấu phần phần mềm.

Đặc tả yêu cầu

Tài liệu xác định yêu cầu là mô tả hướng khách hàng và được viết bởi ngôn ngữ của khách hàng. Khi đó có thể dùng ngôn ngữ tự nhiên và các 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) là mô tả hướng người phát triển, là cơ sở của hợp đồng làm phần mềm. Nó không được phép mơ hồ, nếu không sẽ dẫn đến sự hiểu nhầm bởi khách hàng hoặc người phát triển. Với một yêu cầu mơ hồ thì người phát triển sẽ thực hiện nó một cách rẻ nhất còn khách hàng thì không muốn vậy. Do đó khách hàng có thể đòi hỏi sửa đổi chức năng phần mềm khi nó đã gần hoàn thiện khiến cho chi phí tăng và chậm thời điểm bàn giao. Chi phí cho sửa các sai sót trong phát biểu yêu cầu là rất lớn, đặc biệt là khi các sai sót này được phát hiện khi đã bắt đầu xây dựng hệ thống. Theo một số thống kê thì 85% mã phải viết lại do thay đổi yêu cầu và 12% lỗi phát hiện trong 3 năm đầu sử dụng là do đặc tả yêu cầu không chính xác. Do đó, việc đặc tả chính xác yêu cầu là mối quan tâm được đặt lên hàng đầu. Có hai phương pháp đặc tả là

1. Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ tự nhiên
2. Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ nhân tạo (ngôn ngữ đặc tả), các công thức và 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 nhưng nhiều khi không thích hợp với đặc tả yêu cầu vì:

1. Không phải lúc nào người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên cũng hiều các từ như nhau.
2. Ngôn ngữ tự nhiên quá mềm dẻo do đó các yêu cầu liên quan đến nhau có thể được biểu diễn bằng các hình thức hoàn toàn khác nhau và người phát triển không nhận ra các mối liên quan này.
3. Các yêu cầu khó được phân hoạch một cách hữu hiệu do đó hiệu quả của việc đổi thay chỉ có thể xác định được bằng cách kiểm tra tất cả các yêu cầu chứ không phải một nhóm các yêu cầu liên quan.

Các ngôn ngữ đặc tả (đặc tả hình thức) khắc phục được các hạn chế trên, tuy nhiên đa số khách hàng lại không thông thạo các ngôn ngữ này. Thêm nữa mỗi ngôn ngữ đặc tả hình thức thường chỉ phục vụ cho một nhóm lĩnh vực riêng biệt và việc đặc tả hình thức là một công việc tốn kém thời gian.

Một cách tiếp cận là bên cạnh các đặc tả hình thức người ta viết các chú giải bằng ngôn ngữ tự nhiên để giúp khách hành dễ hiểu.

1.Phân tích yêu cầu

Nhằm mục đích:

• Phát hiện và giải quyết xung đột giữa các yêu cầu.
• Tìm ra những giới hạn của phần mềm và cách phần mềm tương tác với tổ chức và môi trường hoạt động của nó.
• Nghiên cứu các yêu cầu hệ thống để lấy được các yêu cầu phần mềm.

1.4.Mô hình hóa khái niệm

Xây dựng các mô hình trong một vấn đề thực tế là chìa khóa của phân tích yêu cầu phần mềm. Mục đích là để hiểu rõ về những vấn đề xảy ra cũng như miêu tả được giải pháp của vấn đề.Do dó mô hình khái niệm báo gồm các mô hình của các thực thể từ miền vấn đề, cấu hình để phản ánh các mối quan hệ trong thế giới thực và ràng buộc.Có rất nhiều loại mô hình có thể được phát triển bao gồm biểu đồ use case, mô hình luồng dữ liệu (data flow), mô hình trạng thái (state diagram), mô hình dựa trên mục tiêu (objectives), tương tác người dùng (activity diagram), mô hình dữ liệu (data model), mô hình đối tượng (business model)…Các yếu tố ảnh hưởng đến sự lựa chọn mô hình bao gồm:

• Vấn đề tự nhiên: Một số loại phần mềm đòi hỏi một số khía cạnh được phân tích đặc biệt nghiêm ngặt. ví dụ mô hình trạng thái và mô hình tham số của phần mềm thời gian thực quan trọng hơn so với hệ thống thông tin.
• Sự thành thạo của kỹ sư phần mềm: Kỹ sư phần mềm có kinh nghiệm sẽ lựa chọn các mô hình hay phương pháp để được kết quả tốt hơn.
• Các yêu cầu về quy trình của khách hàng: Khách hàng có thể áp đặt các ký hiệu ưa thích của họ hoặc phương pháp hoặc ngăn cản bất cứ cái gì mà họ thấy không quen thuộc. Nhân tố này có thể xung đột với các nhân tố trước đó.

1.4.Thiết kế kiến trúc và phân bổ yêu cầu

Thiết kế kiến trúc là điểm mà tại đó quá trình yêu cầu trùng lặp với phần mềm hoặc các hệ thống thiết kế. Trong nhiều trường hợp, các hành vi kỹ sư phần mềm như là kiến trúc sư phần mềm bởi vì quá trình phân tích và xây dựng các yêu cầu đòi hỏi rằng các thành phần kiến trúc / thiết kế đó sẽ chịu trách nhiệm đáp ứng các yêu cầu được xác định.Phân bổ là quan trọng để cho phép phân tích chi tiết các yêu cầu. Do đó, ví dụ, khi một bộ các yêu cầu đã được phân bổ cho một thành phần, các yêu cầu cá nhân có thể được phân tích thêm để khám phá thêm các yêu cầu về cách thành phần tương tác với thành phần khác để đáp ứng các yêu cầu được giao.Trong các dự án lớn, phân bổ thúc đẩy một vòng mới của phân tích cho mỗi hệ thống. Thiết kế kiến trúc được xác định chặt chẽ với các mô hình khái niệm.

1.4.Đàm phán, giải quyết các xung đột giữa các yêu cầu

Điều này liên quan đến việc giải quyết vấn đề giữa hai yêu cầu của các bên liên quan cùng các tính năng không tương thích, giữa các yêu cầu và nhân lực hoặc giữa yêu cầu chức năng và yêu cầu phi chức năng.Trong tất cả các trường hợp kỹ sư phần mềm không được tự đưa ra các quyết định mà cần thiết tham khảo từ các bên liên quan để đạt được một sự đồng thuận trên sự thỏa hiệp thích hợp.

Tuy nhiên, thường rất khó khăn để có được thông tin thực. Ngoài ra, các yêu cầu thường phụ thuộc vào nhau, và có ưu tiên tương đối. Trong thực tế, các kỹ sư phần mềm thực hiện các yêu cầu ưu tiên thường xuyên mà không biết về tất cả các yêu cầu. Nó cũng bao gồm một phân tích từ các kỹ sư phần mềm ước tính chi phí thực hiện từng yêu cầu hoặc liên quan đến các yêu cầu khác.

1.4.Phân tích hình thức – Formal Analysis

Formal Analysis đã có một tác động trên một số lĩnh vực ứng dụng, đặc biệt là các hệ thống toàn vẹn cao. Các hình thức thể hiện của các yêu cầu đòi hỏi một ngôn ngữ với ngữ nghĩa định nghĩa chính thức (ví dụ: Ngôn ngữ Z).Việc sử dụng một phân tích hình thức cho các yêu cầu biểu hiện có hai lợi ích. Đầu tiên, nó cho phép các yêu cầu thể hiện bằng ngôn ngữ được xác định một cách chính xác và rõ ràng, do vậy tránh được khả năng hiểu sai.Thứ hai, yêu cầu có thể được lý giải trên, cho phép đặc tính mong muốn của phần mềm cụ thể để chứng minh.Phân tích hình thức nhất là tập trung vào giai đoạn khá muộn của phân tích yêu cầu.

Đặc tả yêu cầu phần mềm là gì?

Đặc tả yêu cầu là tập hợp bao gồm các mô tả của hệ thống phần mềm được phát triển, đưa ra các yêu cầu chức năng và phi chức năng, và có thể bao gồm một tập hợp các case sử dụng (use cases) để thông qua đó mô tả tương tác giữa phần mềm và người dùng.

Qua bản đặc tả yêu cầu tạo cơ sở hình thành thỏa thuận giữa nhà cung cấp và khách hàng về những gì phần mềm đã làm được tốt cũng như những gì chưa hoàn thành được những yêu cầu của phần mềm. Nó cũng cung cấp một cơ sở thực tế để dự đoán trước rủi do đem lại, lịch trình và ước tính giá thành sản phẩm.

Đối với các sản phẩm phần mềm có hệ thống phức tạp có 3 loại tài liệu được tạo ra là: định nghĩa hệ thống, yêu cầu hệ thống và các yêu cầu phần mềm. Đối với sản phẩm phần mềm đơn giản thì chỉ cần 1 trong 3 tài liệu trên.

>>> SRS là gì?

Các yếu tố cấu thành đặc tả yêu cầu

Tài liệu đặc tả hệ thống

Là bộ tài liệu yêu cầu người dùng hoặc tài liệu vận hành ghi lại những yêu cầu của hệ thống. Nó xác định yêu cầu hệ thống ở mức cao với cách nhìn từ domain. Khách hàng và người cần dùng đến bộ tài liệu sẽ là độc giả. Vì vậy nội dung của đặc tả phải được diễn đạt bằng những từ ngữ của những lĩnh vực riêng. Tài liệu sẽ liệt kê các thông tin cơ bản về đối tượng và yêu cầu hệ thống, môi trường mục tiêu của nó, giả định và các yêu cầu phi chức năng.

Khái niệm được mô tả bằng mô hình, thiết kế để minh họa cho ngữ cảnh hệ thống, các miền thực thể chính, sử dụng kịch bản, cũng như luồng công việc.

Đặc tả yêu cầu hệ thống

Các lập trình viên có những thành phần thuần túy là software và những phần non-software. Theo quan điểm này, các yêu cầu phần mềm có nguồn gốc từ các yêu cầu hệ thống, và dựa vào yêu cầu của hệ thống dần hình thành các yêu cầu của phần mềm.

Đặc tả yêu cầu phần mềm

Đặc tả yêu cầu phần mềm tạo cơ sở hình thành các thỏa thuận giữa khách hàng và nhà thầu hoặc các nhà cung cấp về những gì sản phẩm phần mềm có hoạt động theo đúng. Nó cho phép một đánh giá nghiêm ngặt các yêu cầu trước khi có thể bắt đầu vào việc thiết kế và làm giảm việc thiết kế lại. Nó cũng cần cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro, và lịch trình.

Các tổ chức cũng có thể sử dụng một tài đặc tả yêu cầu phần mềm làm cơ sở để phát triển kế hoạch xác minh và kiểm tra. Đặc tả yêu cầu phần mềm cung cấp một cơ sở thông báo cho việc chuyển một sản phẩm phần mềm cho người dùng mới hoặc các nền tảng phần mềm. Cuối cùng, nó cung cấp một cơ sở để nâng cao phần mềm. Đặc tả yêu cầu phần mềm có thể được bổ sung bằng các mô tả chính thức hoặc gần chính thức. Lựa chọn các ký hiệu thích hợp và các khía cạnh của kiến trúc phần mềm cụ thể được mô tả chính xác hơn so với ngôn ngữ tự nhiên.

Các nguyên tắc chung

Ký hiệu nên được sử dụng cho phép các yêu cầu để được mô tả là chính xác càng tốt nó rất quan trọng đối với các phần mềm đáng tin cậy và có độ an toàn cao. Tuy nhiên việc lựa chọn các kí hiệu thường được hạn chế bởi việc đào tạo, sở thích và kỹ năng của tác giả và khách hàng.

Một số chỉ tiêu chất lượng như: Chi phí, mức độ hài lòng, hiệu quả, đúng tiến độ, và khả năng tái sản xuất đã được phát triển có thể được sử dụng đối với đặc tả yêu cầu phần mềm. Ngoài ra có các đặc tả yêu cầu của cá nhân bao gồm mệnh lệnh, chỉ thị, các pha yếu, tùy chọn, và sự duy trì. Các chỉ số cho các tài liệu đặc tả yêu cầu phần mềm bao gồm kích thước, dễ đọc, đặc tả kỹ thuật, chiều sâu và cấu trúc văn bả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 người sử dụng phần mềm có thể được nhận thấy rõ khi các chức năng của hệ thống được trình diễn.
• Sự thiếu hụt các dịch vụ người dùng có thể được phát hiện.
• Sự khó sử dụng hoặc sự nhầm lẫn các 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ủ 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ệ thống. Kết quả khác nhau có nghĩa là có sai sót.

Tạo bản mẫu là một kỹ thuật giảm bớt rủi ro. Một rủi ro lớn trong việc phát triển phần mềm là các sai sót mà đến giai đ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à:

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, người dùng có thể không dùng bản mẫu y như cách dùng một hệ thống thực đang hoạt động. Do đó, chất lượng đánh giá của khách hàng nhiều khi không cao.

Định 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).

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 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 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.

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

Bài đăng này đã không được cập nhật trong 2 năm

Để mang đến một sản phẩm phần mềm chất lượng đáng tin cậy thì việc phân tích yêu cầu là khâu vô cùng quan trọng trong quá trình xây dựng phần mềm. Hoạt động này đòi hỏi sự phố kết hợp rất chặt chẽ giữa khách hàng và người phân tích để vạch ra được xem chúng ta phải phát triển 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 các 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 đối với chất lượng phần mềm là phần mềm phải thỏa mãn được các yêu cầu và mong muốn của người dùng. Người dùng thường chỉ đưa ra những ý tưởng, nhiều khi rất mơ hồ về phần mềm mà họ mong muốn xây dựng. Và việc của các kỹ sư phát triển phần mềm đó là phải giúp họ đưa những ý tưởng mơ hồ đó thành hiện thực và xây dựng được một phần mềm có đầy đủ các tính năng cần thiết thỏa mãn yêu cầu của người dùng. Hơn thế nữa, ý tưởng của người dùng thường xuyên thay đổi và việc của nhà phát triển là phải nắm bắt và đáp ứng được các yêu cầu thay đổi đó một cách 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 giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển. Tài liệu mô tả yêu cầu phải vừa dễ hiểu với người dùng vừa chặt chẽ để làm cơ sở cho việc lập kế hoạch. Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau, nhiều giai đoạn 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 phương pháp để tìm hiểu các yêu cầu của phần mềm bao gồm:

• 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 được các yêu cầu của phần mềm, 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ố phương pháp hay dùng để mô hình hóa yêu cầu đó là:

a – Biểu đồ luồng dữ liệu Biể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 dữ liệu bao gồm:

• 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 dữ liệu như sau:

Biểu đồ luồng dữ liệu có thể được dùng để biểu diễn cho một 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. Trong thực tế, DFD có thể được phân chia thành nhiều mức biểu diễn. Sau đây là minh họa một DFD cho 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 để thiết kế cơ sở dữ 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 ý tưởng giữa nhà thiết kế và người dùng cuối trong giai đoạn phân tích

Mô hình quan hệ – thực thể bao gồm ba phần tử 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 mô hình 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ó các phương pháp đặ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 giá qua các tiêu chí 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 thẩm định là xác định xem yêu cầu có thỏa mãn 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 các hệ thống phức tạp, nhiều khi chúng ta không nắm chắc được yêu cầu của khách hàng, chúng ta cũng khó đánh giá được tính khả thi cũng như hiệu quả của hệ thống. Một giải pháp được đưa ra là xây dựng bản mẫu. Bản mẫu vừa được dùng để phân tích yêu cầu vừa có thể tiến hóa thành sản phẩm cuối cùng. Bản mẫu phần mềm không phải nhằm vào việc thẩm định thiết kế (thiết kế của nó thường là hoàn toàn khác với hệ thống được phát triển cuối cùng), mà là để 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 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).

Trên đây là khái quát về bước phân tích và đặc tả yêu cầu trong quá trình phát triển phần mềm. 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. Trong các bài viết sau, tôi sẽ mô tả chi tiết hơn về các phương pháp để mô hình 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

All rights reserved

Đặc tả yêu cầu

Science and Technology

Khi đã xác định rõ bài toán thì bước tiếp theo là tìm hiểu xem hệ thống dự kiến sẽ yêu cầu làm cái gì. Điều quan trọng ở đây là phải xây dựng được danh sách các yêu cầu của người sử dụng. Dựa trên những yêu cầu của người sử dụng, người phát triển đưa ra các đặc tả cho hệ thống.

Người xây dựng hệ thống phải trả lời được các yêu cầu sau đây:

Đầu ra của hệ thống là cái gì

Hệ thống sẽ phải làm cái gì để có kết quả mong muốn, nghĩa là phải xử lý những cái gì

Những tài nguyên mà hệ thống yêu cầu là gì

Hiểu rõ nguồn gốc, các dạng thông tin cần cung cấp cho hệ thống hoạt động. Hệ thống sẽ phải giải quyết những vấn đề gì, những kết quả cần phải có là gì. Xác định được mối quan hệ giữa cái vào và cái ra cho quá trình hoạt động của hệ thống. Các đặc tả chi tiết phục vụ cho việc xây dựng và trắc nghiệm về hệ thống để kiểm tra xem những nhiệm vụ đã đặt ra có hoàn tất được hay không.

Ở đây, chúng ta cần chú ý là trong một số trường hợp, sẽ nảy sinh những yêu cầu mới mà có thể là ta phải xây dựng lại hệ thống, tất nhiên điều này sẽ làm chậm tiến trình xây dựng và làm tăng giá thành do một vài lý do để không thể hoàn chỉnh các đặc tả đối với các hệ thống như:

Các hệ thống phần mềm lớn luôn đòi hỏi cải tiến từ hiện trạng. Mặc dù các khó khăn của hệ thống hiện tại có thể xác định được nhưng các ảnh hưởng và hiệu ứng của hệ thống mới khó có thể dự đoán trước được.

Hệ thống lớn thường có nhiều cộng đồng sử dụng khác nhau. Họ có các yêu cầu và ưu tiên khác nhau. Các yêu cầu hệ thống cuối cùng không tránh khỏi các thỏa hiệp.

Người trả tiền cho hệ thống và người sử dụng thường khác nhau. Các yêu cầu đưa ra do ràng buộc của các tổ chức và tài chính có thể tranh chấp với yêu cầu của người sử dụng.

Do các đặc tả yêu cầu thêm các thông tin vào định nghĩa yêu cầu nên các đặc tả thường được biểu diễn cùng với các mô hình hệ thống được phát triển trong quá trình phân tích yêu cầu. Nó cần bao gồm mọi thông tin cần thiết về yêu cầu chức năng và ràng buộc của hệ thống. Phân tích yêu cầu được tiếp tục xác định và đặc tả khi các yêu cầu mới nảy sinh. Đây là tài liệu thường xuyên thay đổi và nên được kiểm soát chặt chẽ.

Ngôn ngữ tự nhiên không hoàn toàn thuận tiện cho các thiết kế viên hoặc các hợp đồng giữa các khách hàng và cán bộ phát triển hệ thống vì có một số lý do như sau:

Nhầm lẫn do cách hiểu các khái niệm khác nhau giữa hai bên.

Đặc tả yêu cầu ngôn ngữ tự nhiên quá mềm dẻo. Một vấn đề có thể được mô tả bằng quá nhiều cách khác nhau.

Các yêu cầu không được phân hoạch tốt, khó tìm các mối quan hệ,… Do vậy người ta thường dùng các thay thế khác để đặc tả các yêu cầu như:

Ngôn ngữ tự nhiên có cấu trúc,

Ngôn ngữ mô tả thiết kế, giống ngôn ngữ lập trình nhưng có mức trừu tượng cao hơn,

Ngôn ngữ đặc tả yêu cầu,

Ghi chép graphic,

Đặc tả toán học,…

Có thể chia đặc tả yêu cầu ra làm hai loại: đặc tả phi hình thức (ngôn ngữ tự nhiên) và đặc tả hình thức (dựa trên kiến trúc toán học).

1. Đặc tả phi hình thức

Đặc tả phi hình thức là đặc tả sử dụng ngôn ngữ tự nhiên. Tuy nó không được chặt chẽ bằng đặc tả hình thức nhưng được nhiều người biết và có thể dùng để trao đổi với nhau để làm chính xác hóa các điểm chưa rõ, chưa thống nhất giữa các bên phát triển hệ thống.

2 . Đ ặ c tả hình thức

Đặc tả hình thức là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa hình thức dựa vào toán học. Đặc tả hình thức có thể coi là một phần của hoạt động đặc tả phần mềm. Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức năng chương trình có thể được tạo ra để làm rõ yêu cầu.

Đặc tả phần mềm hình thức là một đặc tả được trình bày trên một ngôn ngữ bao gồm: từ vựng, cú pháp và ngữ nghĩa được định nghĩa. Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ đặc tả không phải là ngôn ngữ tự nhiên mà dựa trên toán học. Các chức năng nhận các đầu vào trả lại các kết quả. Các chức năng có thể định ra các điều kiện tiền tố và hậu tố. Điều kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần thỏa mãn sau khi có kết quả.

Có hai hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp.

+ Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ.

+ Tiếp cận mô hình, mô hình hệ thống được câú trúc sử dụng các thực thể toán học như là các tập hợp và các thứ tự.

Sử dụng đặc tả hình thức, ta có các thuận lợi:

Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công việc thiết kế được thuận lợi.

Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống.

Đặc tả hình thức, bản thân nó cho chúng ta một cách thức cho việc kiểm tra hệ thống sau này.

Tuy vậy, đặc tả hình thức cũng bộc lộ một vài khó khăn:

Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các kỹ thuật mới.

Chi phí cho việc đặc tả hình thức thường cao hơn so với các đặc tả khác (tuy phần cài đặt sẽ thấp hơn), nên khó để chứng minh rằng chi phí tương đối cao cho đặc tả sẽ làm giảm tổng chi phí dự án.

Phần lớn, những người đặc tả hệ thống không được đào tạo một cách chính quy về việc sử dụng đặc tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen của họ.

Thông thường, nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn ngữ hình thức. Thêm vào đó là khách hàng không thể hiểu được nó.

Khách hàng không thích các đặc tả toán học.

Nguyên lý đặc tả

Nguyên lý 1: Phân tách chức năng với cài đặt: đặc tả là mô tả điều mong muốn chứ không phải cách thức thực hiện (cài đặt). Kết quả thu được theo dạng cái gì chứ không phải là thế nào.

Nguyên lý 2: Cần tới ngôn ngữ đặc tả hệ thống hướng tiến trình: cần thiết đặc biệt trong trường hợp môi trường là động và sự thay đổi của nó ảnh hưởng tới hành vi của thực thể nào đó tương tác với môi trường nào đó.

Nguyên lý 3: Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần: vì hệ thống bao gồm các thành phần tương tác với nhau, chỉ bên trong hoàn cảnh của toàn bộ hệ thống và tương tác giữa các thành phần của nó thì hành vi của một thành phần mới có thể xác định.

Nguyên lý 4: Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành.

Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức: không phải là mô hình thiết kế hay cài đặt. Nó phải mô tả một hệ thống như cộng đồng người sử dụng cảm nhận thấy. (Các sự vật mà nó thao tác phải tương ứng với các sự vật của lĩnh vực đó; các tác nhân phải mô hình cho các cá nhân, tổ chức, trang thiết bị; các hành động họ thực hiện thì mô hình cho những hoạt động thực tế xuất hiện trong lĩnh vực;…)

Nguyên lý 6: Đặc tả phải vận hành: phải đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một cài đặt được đề nghị có thỏa mãn đặc tả trong những trường hợp kiểm thử tùy ý hay không.

Nguyên lý 7: Đặc tả hệ thống phải dung sai về tính không đầy đủ và tính nâng cao. Đặc tả không thể hoàn toàn đầy đủ do môi trường phức tạp

+ Đặc tả là mô hình – sự trừu tượng hóa – của tình huống thực nên không đầy đủ.

+ Đặc tả sẽ tồn tại ở nhiều mức chi tiết

+ Các công cụ phân tích được sử dụng để giúp cho đặc tả và kiểm thử đặc tả

phải có khả năng xử lý với tính không đầy đủ.

Nguyên lý 8: Đặc tả phải được cục bộ hóa và được ghép lỏng lẻo: Đặc tả làm cơ sở cho thiết kế và cài đặt, không phải tĩnh mà là một sự vật động, đang trải qua thay đổi đáng kể nên nội dung và cấu trúc phải phù hợp. Sự thay đổi khi cần sửa đổi là tối thiểu, chỉ một phần nhỏ các thành phần có thể thâm vào hay loại bớt một cách dễ dàng.

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to upgrade your browser.

VNU Journal of Science: Legal Studies

Phân cấp, phân quyền và thực tiễn triển khai theo Hiến pháp 2013

2018 •

2011 •

Bài tập toán cao cấp.Tập 3,Phép giải tích nhiều biến số. DSpace/Manakin Repository. …

cdyteninhbinh.vn

Chọn Đề Tài Nghiên Cứu Khoa Học Xã Hội

2021 •

TÓM TẮT: Rút gọn thuộc tính là bài toán quan trọng trong bước tiền xử lý dữ liệu của quá trình khai phá dữ liệu và khám phá tri thức. Trong mấy năm gần đây, các nhà nghiên cứu đề xuất các phương pháp rút gọn thuộc tính trực tiếp trên bảng quyết định gốc theo tiếp cận tập thô mờ (Fuzzy Rough Set FRS) nhằm nâng cao độ chính xác mô hình phân lớp. Tuy nhiên, số lượng thuộc tính thu được theo tiếp cận FRS chưa tối ưu do ràng buộc giữa các đối tượng trong bảng quyết định chưa được xem xét đầy đủ. Trong bài báo này, chúng tôi đề xuất phương pháp rút gọn thuộc tính trực tiếp trên bảng quyết định gốc theo tiếp cận tập thô mờ trực cảm (Intuitionistic Fuzzy Rough Set IFRS) dựa trên các đề xuất mới về hàm thành viên và không thành viên. Kết quả thử nghiệm trên các bộ dữ liệu mẫu cho thấy, số lượng thuộc tính của tập rút gọn theo phương pháp đề xuất giảm đáng kể so với các phương pháp FRS và một số phương pháp IFRS khác.

Journal of Science and Technology

Xây Dựng Đặc Tính Trao Đổi Công Suất Giữa Nhà Máy Điện Gió Với Lưới Điện

2015 •

2014 •

FAIR – NGHIÊN CỨU CƠ BẢN VÀ ỨNG DỤNG CÔNG NGHỆ THÔNG TIN – 2016

Kỹ Thuật Phân Đoạn Chùm Trong Mạng Chuyển Mạch Chùm Quang

2017 •

FAIR – NGHIÊN CỨU CƠ BẢN VÀ ỨNG DỤNG CÔNG NGHỆ THÔNG TIN 2015

Một Kỹ Thuật Xây Dựng Hệ Bao Tự Động Cho Đối Tượng 3D

2016 •

Loading Preview

Sorry, preview is currently unavailable. You can download the paper by clicking the button above.

2012 34th International Conference on Software Engineering (ICSE)

GraPacc: A graph-based pattern-oriented, context-sensitive code completion tool

2012 •

Journal of Clinical Microbiology

Transfer and Evaluation of an Automated, Low-Cost Real-Time Reverse Transcription-PCR Test for Diagnosis and Monitoring of Human Immunodeficiency Virus Type 1 Infection in a West African Resource-Limited Setting

2005 •

Annals of gastroenterology : quarterly publication of the Hellenic Society of Gastroenterology

Risk factors for therapeutic ERCP-related complications: an analysis of 2,715 cases performed by a single endoscopist

2014 •

International Review on Public and Nonprofit Marketing

The impact of entrepreneurship education in European universities: an intention-based approach analyzed in the Spanish area

American journal of hypertension

The effect of alcohol and gender on ambulatory blood pressure: results from the Baseline Double Exposure study

2006 •

Estudios pedagógicos (Valdivia)

(Trans)formar docentes, (trans)formar personas: Una experiencia interdisciplinar para democratizar el aula universitaria

2012 •

Developmental Dynamics

Annual Drosophila Research Conference, 2008

2008 •

Mukt Shabd Journal

डिजिटल चलने आणि पैशाचे भविष्य

2022 •

Obstetrics & Gynecology

Stab scissors as an aid to performing endometrial biopsy

2002 •

Advances in Science, Technology and Engineering Systems Journal

Aviation Navigation with Use of Polarimetric Technologies

2017 •

IRA International Journal of Education and Multidisciplinary Studies (ISSN 2455-2526)

Influence of Academics’ Designation and Experience on their Job Satisfaction in Universities in Rift Valley Region of Kenya

2017 •

International Journal of Computer Applications in Technology

Applying a service-oriented approach for developing a distributed multi-agent system for healthcare

2010 •

Российский гуманитарный журнал

Configurations of reading as a constitutive aspect of consciousness

2016 •

DeReMa (Development Research of Management): Jurnal Manajemen

Peran Praktik Lean, Strategi Manajemen Inovasi Dan Orientasi Lingkungan Pada Keberlanjutan Organisasi Melalui Manajemen Rantai Pasokan Hijau Pada Industri E-Commerce DI Indonesia [The Role of Lean Practices, Innovation Management Strategies and Environmental Orientation in Organizational Sustaina…

Journal of Hyperbolic Differential Equations

On some singular limits in damped radiation hydrodynamics

2016 •

2018 •

The Professional Medical Journal

Neonatal Resuscitation

2017 •

Cellular and Molecular Neurobiology

The Effects of Tag-1 on the Maturation of Mouse Cerebellar Granule Neurons

2010 •

Tài liệu đặc tả SRS trong phân tích yêu cầu

• May 26, 2022
• Posted by: codestar
• Category: Uncategorized

Như trong nội dung bài viết về tầm quan trọng của việc phân tích yêu cầu phần mềm, chúng ta đã nhận thấy vai trò cần thiết của việc phân tích tài liệu yêu cầu trong 1 dự án. Là một công việc khởi đầu nên vai trò của phân tích yêu cầu có ảnh hưởng xuyên suốt tới cả quá trình phát triển, xây dựng phần mềm đó. Vậy với Tester, là 1 trong những người trực tiếp tham gia vào quá trình phân tích yêu cầu dự án, chúng ta cần chú ý ngay từ những bước tiền đề quan trọng này.

Trong bài viết hôm nay, hãy cùng tìm hiểu 1 loại tài liệu đặc tả dự án rất phổ biến trong ngành phần mềm của chúng ta – Software Requirement Specification (SRS).

1.Đặc tả yêu cầu

Đặc tả yêu cầu là một mô tả của hệ thống phần mềm được phát triển, đưa ra các yêu cầu chức năng và phi chức năng, và có thể bao gồm một tập hợp các ca sử dụng (use cases) để mô tả tương tác giữa người dùng với phần mềm.Đặc tả yêu cầu tạo cơ sở cho một thỏa thuận giữa khác hàng và nhà cung cấp về những gì phần mềm đã làm được tốt cũng như những gì chưa được như mong đợi. Nó cũng cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro và lịch trình.Đối với các hệ thống phức tạp có 3 loại tài liệu được tạo ra là: định nghĩa hệ thống, yêu cầu hệ thống và các yêu cầu phần mềm. Đối với sản phẩm phần mềm đơn giản chỉ cần 1 trong 3 tài liệu.

1.5.Tài liệu đặc tả hệ thống

Còn được biết như là tài liệu yêu cầu người dùng hay là tài liệu vận hành ghi lại những yêu cầu hệ thống. Nó xác định yêu cầu hệ thống ở mức cao với cách nhìn từ “domain” (vùng nghiệp vụ đặc thù của từng khách hàng). Độc giả của tài liệu bao gồm hệ thống người dùng cuối hoặc khách hàng. Vì vậy nội dung của nó phải được diễn đạt bằng những từ ngữ của những lĩnh vực riêng. Tài liệu sẽ liệt kê các yêu cầu hệ thống cùng với các thông tin cơ bản về đối tượng hệ thống, môi trường mục tiêu của nó, giả định và các yêu cầu phi chức năng.Nó có thể bao gồm mô hình khái niệm được thiết kế để minh họa cho ngữ cảnh hệ thống, sử dụng kịch bản, và các miền thực thể chính, cũng như luồng công việc.

1.5.Đặc tả yêu cầu hệ thống

Phát triển những dự án phần mềm có những thành phần thuần túy là software và những phần non-software. Ví dụ như máy bay hiện đại thường tách biệt yêu cầu hệ thống với yêu cầu phần mềm. Theo quan điểm này, yêu cầu hệ thống được quy định, các yêu cầu phần mềm có nguồn gốc từ các yêu cầu hệ thống, và sau đó các yêu cầu đối với các thành phần phần mềm được xác định.

1.5.Đặc tả yêu cầu phần mềm

Đặc tả yêu cầu phần mềm tạo cơ sở cho việc thỏa thuận giữa khách hàng và nhà thầu hoặc các nhà cung cấp về những gì sản phẩm phần mềm có làm việc đúng như mong muốn không. Nó cho phép một đánh giá nghiêm ngặt các yêu cầu trước khi có thể bắt đầu vào việc thiết kế và làm giảm việc thiết kế lại. Nó cũng cần cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro, và lịch trình.Các tổ chức cũng có thể sử dụng một tài đặc tả yêu cầu phần mềm làm cơ sở để phát triển kế hoạch kiểm tra và xác minh. Đặc tả yêu cầu phần mềm cung cấp một cơ sở thông báo cho chuyển một sản phẩm phần mềm cho người dùng mới hoặc các nền tảng phần mềm. Cuối cùng, nó có thể cung cấp một cơ sở để nâng cao phần mềm. Yêu cầu phần mềm thường được viết bằng ngôn ngữ tự nhiên, nhưng đặc tả yêu cầu phần mềm có thể được bổ sung bằng các mô tả chính thức hoặc gần chính thức. Lựa chọn các ký hiệu thích hợp và các khía cạnh của kiến trúc phần mềm cụ thể được mô tả chính xác hơn so với ngôn ngữ tự nhiên.Các nguyên tắc chung là ký hiệu nên được sử dụng cho phép các yêu cầu để được mô tả là chính xác càng tốt. Điều này đặc biệt quan trọng đối với các phần mềm an toàn cao và một số loại phần mềm đáng tin cậy khác. Tuy nhiên, sự lựa chọn của các kí hiệu thường được hạn chế bởi việc đào tạo, kỹ năng, và sở thích của các tác giả và độc giả.Một số chỉ tiêu chất lượng đã được phát triển có thể được sử dụng liên quan đến chất lượng của đặc tả yêu cầu phần mềm như chi phí, hài lòng, hiệu quả, đúng tiến độ, và khả năng tái sản xuất. Chỉ tiêu chất lượng cho đặc tả yêu cầu của cá nhân bao gồm mệnh lệnh, chỉ thị, các pha yếu, tùy chọn, và sự duy trì. Các chỉ số cho các tài liệu đặc tả yêu cầu phần mềm bao gồm kích thước, dễ đọc, đặc tả kỹ thuật, chiều sâu và cấu trúc văn bản.

1.6. Thẩm định yêu cầu (Validation)

Tất cả tài liệu yêu cầu cần được thông qua quá trình thẩm định và kiểm duyệt. Vậy thẩm định yêu cầu là gì?

Khái niệm

• Thẩm định yêu cầu quan tâm đến việc chứng tở rằng các yêu cầu định nghĩa được hệ thống mà khách hàng thực sự muốn. Các yêu cầu phải được thẩm định để đảm bảo rằng người thực thi, người lập trình hiểu được yêu cầu.
• Việc thẩm định phải đảm bảo dễ hiểu, nhất quán và hoàn thiện.
• Thẩm định yêu cầu được quan tâm đến quá trình kiểm tra tài liệu yêu cầu có đảm bảo đầu ra là 1 phần mềm hoàn chỉnh, đúng đắn.

Các kĩ thuật thẩm định yêu cầu

1. Xem lại yêu cầu
2. Sử dụng phiên bản mẫu, thử nghiệm
3. Thẩm định mô hình
4. Kiểm thử chấp thuận

1.6.Xem lại yêu cầu

Có lẽ phương tiện phổ biến nhất của việc thẩm định là sự kiểm tra hoặc xem lại các tài liệu yêu cầu. Một nhóm người được giao nhiệm vụ tìm các lỗi, sai sót, thiếu sự rõ ràng, và độ lệch so với tiêu chuẩn. Thành phần của nhóm này đặc biệt quan trọng (ít nhất cần có đại diện khách hàng để có được định hướng đúng đắn), và họ có thể cung cấp sự hướng dẫn trong việc tìm kiếm thông tin chuẩn xác. Việc nhận xét có thể được thành lập sau khi hoàn thành các tài liệu định nghĩa hệ thống, các tài liệu đặc tả hệ thống, đặc tả cơ bản cho 1 phiên bản mới sắp phát hành, hoặc bất kì bước nào khác trong quá trình làm yêu cầu. Ví dụ. Công ty đưa ra 1 tiêu chuẩn chung khi làm tài liệu, các kí hiệu, mô hình đối tượng, cần phải được thống nhất, Nhưng một nhân viên mới vào chưa nắm rõ được các tiêu chuẩn này nên làm sai một số chỗ. Phương pháp xem lại yêu cầu sẽ giúp tìm ra sai sót này giúp đồng nhất trong quá trình viết tài liệu.

1.6.Sử dụng phiên bản mẫu, thử nghiệm

Sử dụng phiên bản mẫu, thử nghiệm là dùng một mô hình chạy được của hệ thống để kiểm tra các yêu cầu. Ưu điểm của phương pháp này nhằm giúp dễ dàng trong việc giải thích những yêu cầu của phần mềm, giúp khách hàng có những phản hồi kịp thời để làm rõ hệ thống đang sai ở đâu, cũng như phát hiện ra những yêu cầu mới. Ví dụ Việc sử dụng mô hình giao diện người dùng (Mockup,..) giúp nguời lập trình cũng như khách hàng dẽ hiểu, tiết kiệm hon việc miêu tả đơn thuần dùng văn bản hoặc mô hình đồ họa. Sự biến động hay sự thay đổi yêu cầu sau khi dùng bản thử nghiệm là rất thấp bởi vì có sự thống nhất giữa người lập trình, khách hàng và các bên liên quan. Bên cạnh những ưu điểm đó, phương pháp dùng phiên bản mẫu cũng có một số nhược điểm như sau. Dùng phiên bản thử nghiệm làm phân tán sự tập trung của người dùng. Ví dụ, Phiên bản mẫu là phiên bản chưa hoàn thiện về mặt thẩm mĩ cũng như chức năng. Điều đó khiến người dùng nhầm tưởng rằng chất lượng sản phẩm có chất lượng không tốt. Dùng phiên bản mẫu có thể tốn kém hơn cho việc phát triển. Ví dụ, khách hàng quá tập trung vào chức năng của phiên bản mẫu sẽ dẫn đến lỗi phát sinh, người làm yêu cầu lại phải sửa lỗi đó. Do đó việc giải thích đây chỉ là bản mẫu, thử nghiệm là đặc biệt quan trọng. vì vậy sẽ tránh lãng phí nguồn nhân lực.

1.6.Thẩm định mô hình

Thẩm định model là thẩm định lại chất lượng các model information model, behavior model, structure model) đã được phát triển trong suốt quá trình phân tích. Ví dụ trong mô hình đối tượng, chúng ta phải kiểm tra xem liên kết giữa các đối tượng, giữa sự trao đổi dữ liệu giữa các đối tượng có chuẩn xác không. Các model phải đủ các tiêu chí: Hoàn thiện, nhất quán và chuẩn xác.

1.6.Kiểm thử chấp thuận (Verification Testing)

Một đặc điểm quan trọng của yêu cầu phần mềm là nó có thể kiểm định rằng sản phẩm cuối cùng phải thỏa mãn các yêu cầu. Viết các Test Case dành cho các yêu cầu để kiểm tra khả năng đáp ứng được các yêu cầu end-user. Sản phẩm cuối cùng phải thỏa mãn các Test Case.

1.Công cụ sử dụng trong việc làm yêu cầu phần mềm

• Công cụ cho việc vẽ model: CASE tool, starUML, Visio Excel…
• Công cụ cho việc quản lý yêu cầu: Jira, Redmine, Trelllo, Odoo Tasks…

Thuật ngữ thường dùng:

• SRS: Software Requirement Specifications (Đặc tả yêu cầu phần mềm)
• UC: User Case (Kịch bản sử dụng phần mềm được phân chia theo những cách nhằm nắm bắt những yêu cầu chức năng của hệ thống một cách hiệu quả nhất, từ đó dễ dàng nghiệm thu và điều chỉnh, bảo trì)
• FR: Functional Requirement (là những yêu cầu mà giải pháp có thể làm được, còn gọi là khả thi, trong phạm vi chi phí và thời gian cho trước)
• NFR: Non- Function Requirement ( là tập hợp các thuộc tính giúp nâng cao chất lượng của một hệ thống phần mềm)
• CASE: Computer-Aided Software Engineering (Các công cụ hỗ trợ thiết kế vàmô hình hóa phần mềm)
• UAT: User Acceptance Testing (Giai đoạn kiểm thử chấp nhận nghiệm thu toàn bộ dự án)
• UML: Unified Modeling Language (Ngôn ngữ mô hình hóa)
• SysML: Systems Modeling Language (Ngôn ngữ mô hình hóa hệ thống)
• CIA: Confidentiality, Integrity, and Availability (Độ tin cậy, Tính toàn vẹn, tính khả dụng)

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

Science and Technology

Đại cương về phân tích và đặc 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. Công việc ở bước này là tìm hiểu xem chúng ta phải phát triển cái gì, chứ không phải là phát triển như thế nào. Đích cuối cùng của khâu phân tích là tạo ra đặc tả yêu cầu, là tài liệu ràng buộc giữa khách hàng và người phát triển và là cơ sở của hợp đồng.

Hoạt động phân tích là hoạt động phối hợp giữa khách hàng và người phân tích (bên phát triển). Khách hàng phát biểu yêu cầu và người phân tích hiểu, cụ thể hóa và biểu diễn lại yêu cầu. Hoạt động phân tích giữ một vai trò đặc biệt quan trọng trong phát triển phần mềm, giúp cho đảm bảo chất lượng của phần mềm (phần mềm đáng tin cậy). Phần mềm đáng tin cậy có nghĩa là phải thực hiện được chính xác, đầy đủ yêu cầu của 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 thì việc sửa chữa sẽ trở nên rất tốn kém. Chi phí để sửa chữa sai sót về yêu cầu sẽ tăng lên gấp bội nếu như sai sót đó được phát hiện muộn, ví dụ như ở 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 các khó khăn như

• 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 có chuẩn biểu diễn
• Các hệ thống thông tin lớn có nhiều người sử dụng thì 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 phát biểu yêu cầu thường không chính xác

Trong phân tích cần phân biệt giữa yêu cầu và mục tiêu của hệ thống. Yêu cầu là một đòi hỏi mà chúng ta có thể kiểm tra được còn mục tiêu là cái trừu tượng hơn mà chúng ta hướng tới. Ví dụ, giao diện của hệ thống phải thân thiện với người sử dụng là một mục tiêu và nó tương đối không khách quan và khó kiểm tra. Có nghĩa là với một phát biểu chung chung như vậy thì khách hàng và nhà phát triển khó định ra được một ranh giới rõ ràng để nói rằng phần mềm đã thỏa mãn được đòi hỏi đó. Với một mục tiêu như vậy, một yêu cầu cho nhà phát triển có thể là giao diện đồ họa mà các lệnh phải được chọn bằng menu.

Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của 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 cơ sở cho hợp đồng và để cho 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 được mô tả ở nhiều mức chi tiết khác nhau phục vụ cho các đối tượng đọc khác nhau. Các mức đó có thể là:

• Định nghĩa (xác định) yêu cầu: mô tả một cách dễ hiểu, vắn tắt về yêu cầu, hướng vào đối tượng người đọc là người sử dụng, người quản lý…
• Đặc tả yêu cầu: mô tả chi tiết về các yêu cầu, các ràng buộc của hệ thống, phải chính xác sao cho người đọc không hiểu nhầm yêu cầu, hướng vào đối tượng người đọc là cá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 được thẩm định để đảm bảo thỏa mãn nhu cầu người dùng. Đây là công việc bắt buộc để đảm bảo chất lượng phần mềm. Đôi khi việc xác định đầy đủ yêu cầu trước khi phát triển hệ thống là không thực tế và khi đó việc xây dựng các bản mẫu để nắm bắt yêu cầu là cần thiết.

Nghiên cứu khả thi

Đây là giai đoạn có tầm quan trọng đặc biệt, vì nó liên quan đến việc lựa chọn giải pháp. Trong giai đoạn này người phân tích phải làm rõ được các điểm mạnh và điểm yếu của hệ thống cũ, đánh giá được mức độ, tầm quan trọng của từng vấn đề, định ra các vấn đề cần phải giải quyết (ví dụ: những dịch vụ mới, thời hạn đáp ứng, hiệu quả kinh tế). Sau đó người phân tích phải định ra một vài giải pháp có thể (sơ bộ) và so sánh cân nhắc các điểm tốt và không tốt của các giải pháp đó (như tính năng của hệ thống, giá cả cài đặt, bảo trì, việc đào tạo người sử dụng…). Đó là việc tìm ra một điểm cân bằng giữa nhu cầu và khả năng đáp ứng. Mọi dự án đều khả thi khi nguồn tài nguyên vô hạn và 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 sự hạn hẹp về tài nguyên và khó (nếu không phải là không hiện thực) bảo đảm đúng ngày bàn giao. Phân tích khả thi và rủi ro có liên quan với nhau theo nhiều cách. Nếu rủi ro của dự án là lớn thì tính khả thi của việc chế tạo phần mềm có chất lượng sẽ bị giảm đi.

Trong giai đoạn nghiên cứu khả thi, chúng ta tập trung vào bốn lĩnh vực quan tâm chính:

1. Khả thi về 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 được xây dựng đem lại. Tính khả thi về kinh tế thể hiện trên các nội dung sau:
   • Khả năng tài chính của tổ chức cho phép thực hiện dự án.
   • Lợi ích mà dự án phát triển HTTT mang lại đủ bù đắp chi phí phải bỏ ra xây dựng nó.
   • Tổ chức chấp nhận được những chi phí thường xuyên khi hệ thống hoạt động

   Một thuật ngữ hay dùng để chỉ tài liệu nghiên cứu khả thi về kinh tế là luận chứng kinh tế. Luận chứng kinh tế nói chung được coi như nền tảng cho hầu hết các hệ thống (các ngoại lệ là hệ thống quốc phòng, hệ thống luật, các hệ thống phục vụ cho các nghiên cứu đặc biệt). Luận chứng kinh tế bao gồm:

   • các mối quan tâm, nhất là phân tích chi phí/lợi ích
   • chiến lược phát triển dài hạn của công ty
   • sự ảnh hưởng tới các 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 và phát triển thị trường tiềm năng
2. Khả thi về kỹ thuật: khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng tới khả năng đạt tới một hệ thống chấp nhận được. Nói cách khác, khả thi kỹ thuật là xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự định áp dụng hay không.

   Khả thi kỹ thuật thường là lĩnh vực khó thâm nhập nhất tại giai đoạn phân tích. Điều thực chất là tiến trình phân tích và xác định nhu cầu cần được 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 được gắn với tính khả thi kỹ thuật bao gồm:

   • Rủi ro xây dựng: liệu các phần tử hệ thống có thể được thiết kế sao cho đạt được chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích không?
   • Có sẵn tài nguyên: có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang xét không? Các tài nguyên cần thiết khác (phần cứng và 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?
3. Khả thi về pháp lý: nghiên cứu và đưa ra phán quyết về có hay không sự 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à vận hành hệ thống. Tính khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, nghĩa vụ pháp lý, sự vi phạm và vô số các bẫy pháp lý khác mà thường là các nhân viên kỹ thuật không biết tới. Trong nước, vấn đề khả thi về pháp lý vẫn chưa được coi trọng một cách đúng mức mặc dù đã có một số luật liên quan đến CNTT và bảo hộ bản quyền.
4. Tính khả thi về hoạt động: đánh giá tính khả thi của việc vận hành hệ thống. Trong mỗi phương án người ta cần xem xét hệ thống có thể vận hành trôi chảy hay không trong khuôn khổ tổ chức và điều kiện quản lý mà tổ chức đó (người dùng, khách hàng) có. Mức độ các phương án được xem xét tới trong nghiên cứu khả thi thường bị giới hạn bởi các ràng buộc về chi phí và thời gian.

Nền tảng của phân tích yêu cầu

Keywords searched by users: đặc tả yêu cầu là gì

Categories: Phát hiện thấy 18 Đặc Tả Yêu Cầu Là Gì

See more here: kientrucannam.vn

See more: https://kientrucannam.vn/vn/