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

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.

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