PHÂN TÍCH YÊU CẦU VÀ ĐẶC TẢ PHẦN MỀM - Tài Liệu Text - 123doc

1. Trang chủ >
2. Công Nghệ Thông Tin >
3. Phần cứng >

PHÂN TÍCH YÊU CẦU VÀ ĐẶC TẢ PHẦN MỀM

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.05 MB, 148 trang )

Giáo trình tóm tắt Công Nghệ Phần Mềm+Thiết lập các đặc trưng giao diện+Vạch ra được những hạn chếMột khi hiểu được khách hàng muốn gì thì người phân tích mới xác định được hệ thốngmới cần phải tạo ra thông tin nào và dữ liệu nào cần được cung cấp cho hệ thống. Một khi đánhgiá được các vấn đề hiện tại và thông tin mong muốn, người phân tích mới xác định được giảipháp và xác định những bước phát triển kế tiếp.Bước thứ tư là mô hình hóa. Thông qua ước lượng và tổng hợp giải pháp, người phân tích tạora các mô hình hệ thống nhằm hiểu rõ hơn luồng dữ liệu và điều khiển xử lý chức năng, thaotác hành vi và nội dung thông tin. Mô hình này được lấy làm nền tảng cho thiết kế phần mềmBước cuối cùng là tạo ra một đặc tả phần mềm. Kết quả của công việc phân tích yêu cầu là bảnđặc tả yêu cầu phần mềm. Đó là tư liệu chính thức đầu tiên được tạo ra trong quy trình xâydựng phần mềm.48Giáo trình tóm tắt Công Nghệ Phần Mềm3.Việc hình thành các yêu cầu như thế nào ?Phân tích và định rõ yêu cầu là hướng tới đặc tả yêu cầu phần mềm được thể hiện trong cáckhuôn cảnh như sau:49Giáo trình tóm tắt Công Nghệ Phần MềmViệc phân tích và nắm bắt yêu cầu là giai đoạn đầu của quá trình thiết lập các dịch vụ (màhệ thống phải giải quyết) và các ràng buộc (mà hệ thống phải tuân theo). Các thông tin của vấnđề cần giải quyết phải được thu thập, phân tích và phải được xác định một cách rõ ràng. Khi đóthì giải pháp phần mềm mới có thể được thiết kế và thực thi. Để giải quyết vấn đề này người taphải thực hiện các bước đầu tiên của tiến trình phân tích hệ thống như xác định nhu cầu, môhình hóa hệ thống (giai đoạn tiền khả thi).- Phân tích yêu cầu là một tiến trình khám phá, làm mịn, mô hình hóa và đặc tả.Phạm vi phần mềm, ban đầu do người phân tích thiết lập sơ bộ sau đó sẽ được chi tiết thêmcác phần :•Các mô hình thông tin cần tới•Luồng thông tin•Hành vi vận hành•Nội dung dữ liệu được tạo raNgười cân bộ tin tọc làm công tác phân tích yêu cầu phải có khả năng nghe và hiểu đượckhách hàng muốn cái gì, yêu cầu cái gì, từ những phát biểu có thể là tản mạn,không ăn khớpnhau của khách hàng phải biết xâu chuỗi, ghép nối, hình thành nên những yêu cầu rõ ràng,cụthể mà máy tính điện tử có thể giải quyết được.4.Việc xác định các yêu cầuXác định yêu cầu là mô tả trừu tượng các dịch vụ (mà hệ thống được mong đợi phải cungcấp) và các ràng buộc (mà hệ thống phải tuân thủ khi vận hành). Nó chỉ đặc tả tính chất bênngoài của hệ thống mà không hề liên quan đến các đặc tính thiết kế. Nó phải được viết sao chongười ta có thể hiểu được 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 làm hai loại:1. Các yêu cầu hệ thống chức năng: các dịch vụ mà hệ thống phải cung cấp2. Các yêu cầu phi chức năng: các ràng buộc mà hệ thống phải tuân theoXác định yêu cầu thường được viết bằng ngôn ngữ tự nhiên cộng thêm việc dùng cácbảng, các biểu đồ để cho người dùng dễ hiểu (xem như người dùng không biết các khái niệmchuyên môn).Chú ý:•Vì việc xác định yêu cầu khó hoàn thiện trước khi bắt đầu phát triển hệ thống nên việcáp dụng mô hình bản mẫu sẽ thích hợp hơn là mô hình thác nước.Các báo cáo về yêu cầu phần mềm phải viết như thế nào ?1. Chỉ đặc tả tính chất bên ngoài của hệ thống2. Đặc tả các ràng buộc về sự thực hiện3. Phải là dễ thay đổi,có khả năng thích nghi với các thay đổi sẽ diễn ra4. Phải được dùng làm công cụ tham khảo cho người bảo trì hệ thống5. Phải báo cáo dự tính trước về vòng đời của hệ thốngCấu trúc của một tư liệu yêu cầu được gợi ý theo kết cấu sau:1. Phần dẫn nhập2. Phần mô hình hệ thống3. Phần tiến triển của hệ thống50Giáo trình tóm tắt Công Nghệ Phần Mềm4. Phần các yêu cầu chức năng5. Phần từ điển thuật ngữ5. Đặc tả phần mềm5.1 Cách đặc tả và biểu diễn5.1.1 Khái niệm Đặc tả - specificationĐặc tả một vấn đề là mô tả các đặc trưng của vấn đề đó. Vấn đề có thể là đối tượng, kháiniệm hoặc một thủ tục nào đó, ...Yêu cầu đầu tiên của đặc tả là tính chính xácCác đặc tả thường mang tính trừu tượng. Càng ở mức cao (những mức đầu tiên của quátrình làm mịn hoặc chính xác hóa) đặc tả càng trừu tượng,khái quát . Càng xuống các mứcthấp, đặc tả càng tiếp cận dần tới cụ thể - tức là tới một thể hiện trên một máy tính cụ thể vớimột ngôn ngữ lập trình cụ thể.-Đặc tả hình thức: là những đặc tả chính xác tức là không thể dẫn tới những cách hiểukhác nhau. Đặc tả hình thức sử dụng công cụ chủ yếu là đại số và logic (formal)-Đặc tả phi hình thức: diễn đạt bằng những ngôn ngữ, tuy không chặt chẽ nhưng đượcnhiều người biết và có thể trao đổi với nhau để chính xác hoá những điểm chưa rõ,những khái niệm mơ hồ-Đặc tả hỗn hợp: phối hợp hai kiểu đặt tả trênTrong thực tế, có nhiều loại hình đặc tả, ví dụ như: Đặc tả cấu trúc dữ liệu (mô tả các thànhphần của dữ liệu ...), đặc tả chức năng (mô tả chức năng thông qua việc mô tả tính chất củainput, output ...), đặc tả đối tượng (bao gồm đặc tả cấu trúc và đặc tả chức năng ...), đặc tả thaotác (mô tả các thao tác cần thực hiện ...), đặc tả cú pháp (mô tả cách lắp ghép các kí hiệu, cáctừ lại thành chương trình ...), đặc tả xử lý, đặc tả thuật toán...Kiểu đặc tả cần phù hợp với giải pháp. Các yêu cầu phần mềm có thể được phân tích theomột số cách khác nhau. Các kỹ thuật phân tích có thể dẫn tới những đặc tả trên giấy hay trênmáy tính (được xây dựng nhờ dùng CASE) có chứa các mô tả ngôn ngữ đồ họa và tự nhiêncho yêu cầu phần mềm. Việc làm bản mẫu đã giúp đặc tả thực hiện được, tức là bản mẫu thểhiện một biểu diễn của các yêu cầu phần mềm. Các ngôn ngữ đặc tả hình thức dẫn tới biểudiễn hình thức.5.1.2 Biểu diễnCác yêu cầu phần mềm có thể được biểu diễn theo nhiều cách. Các biểu diễn tốt nên tuântheo hướng dẫn sau:Định dạng và nội dung biểu diễn theo hướng liên quan tới vấn đề:-Theo một dàn bài chung cho nội dung của bản đặc tả các yêu cầu phần mềm.-Dạng biểu diễn có trong bản đặc tả có thể thay đổi theo lĩnh vực ứng dụng. (Chẳng hạn,đặc tả cho hệ thống tự động hóa chế tạo sẽ dùng cách kí hiệu khác, biểu đồ và ngônngữ khác với đặc tả cho trình biên dịch ngôn ngữ lập trình)Thông tin chứa trong bản đặc tả nên được lồng nhau:-Các biểu diễn nên làm lộ ra các tầng thông tin sao cho độc giả có thể di chuyển tới mứcchi tiết mình mong muốn.-Đoạn và các sơ đồ đánh dấu nên chỉ ra mức độ chi tiết đang được trình bày. Đôi khicũng nên trình bày cùng một thông tin ở các mức trừu tượng khác nhau để hiểu tốt hơn.51Giáo trình tóm tắt Công Nghệ Phần MềmCác biểu đồ và các dạng kí pháp khác nên giảm thiểu và nhất quán trong sử dụng: Chẳnghạn, cách kí hiệu như sau có thể hiểu theo nhiều cách:có thể giải thích ít nhất ba(hoặc 5 hay 6) cách khác nhau. Lẫn lộnhay không nhất quán trong kí pháp, dù là đồ họa hay kí hiệu cũng đề làm suy giảm việc hiểu vàlàm phát sinh lỗi.Biểu diễn nên thường được xem lại: Nội dung của đặc tả sẽ thay đổi. Vì vậy biểu diễn nênthường được xem lại để đảm bảo tính thống nhất. Một cách lý tưởng, các công cụ CASE nêncó sẵn để cập nhật tất cả các biểu diễn bị ảnh hưởng bởi từng thay đổi.Nên sử dụng các kí hiệu, sơ đồ quen thuộc nhưng có chọn lọc: Nguời ta đã tiến hành nhiềucuộc điều tra về nhân tố con người liên quan đến đặc tả. Dường như ít có hoài nghi rằng cáchkí hiệu và thu xếp có ảnh hưởng tới việc hiểu. Tuy nhiên các kỹ sư thích các dạng ký hiệu, cácsơ đồ riêng biệt. Sự quen thuộc thường thuận cho mọi người, nhưng các nhân tố chọn lọc nhưcách bố trí không gian, các mẫu hình dễ nhận thức và mức hợp lý của hình thức sẽ giúp choviệc đặc tả có lợi về sau.5.2 Các nguyên lý đặc tảĐặc tả có thể được xem như một tiến trình biểu diễn. Mục đích cuối cùng của đặc tả cácyêu cầu được biểu thị sao cho dẫn tới việc cài đặt phần mềm thành công. Balzer và Goldmanđề nghị 8 nguyên lý đặc tả tốt:Nguyên lý 1: Phân biệt chức năng với cài đặt- phân biệt giữa cái gì(what) – chứ kg phải làmnhư thế nào(how)Trước hết, theo định nghĩa, đặt tả là một mô tả về điều mong muốn, chứ không phải làcách thực hiện nó (cài đặt). Đặc tả có thể chấp nhận hai dạng hoàn toàn khác nhau. Dạng thứnhất là dạng của các hàm toán học: với một tập cái vào đã cho, tạo ra một tập cái ra đặc biệt.Dạng tổng quát của những đặc tả như thế là tìm ra một hoặc tất cả những kết quả ứng với P(cái vào), với P biểu thị một tân từ bất kỳ. Trong những đặc tả như thế, kết quả cần thu đượcphải hoàn toàn được diễn đạt cái gì 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ìnhXét tình huống trong đó môi trường là động và sự thay đổi của nó ảnh hưởng tới hành vicủa thực thể nào đó tương tác với môi trường đó. Hành vi của nó không thể biểu diễn được ởdạng hàm toán học của cái vào. Thay vì thế, cần phải sử dụng cách biểu diễn khác: cách mô tảhướng tiến trình, trong đó đặc tả cái gì đạt được bằng cách xác định một mô hình hành vi mongmuốn của hệ thống dưới dạng các đáp ứng chức năng đối với các kích thước khác nhau từ môitrường.Những đặt tả hướng tiến trình như vậy:1. Trình bày một mô hình về hành vi hệ thống2. Thông thường không thuộc ngôn ngữ đặc tả hình thức3. Lột tả được bản chất của nhiều tình huống phức tạp cần phải đặc tả4. Trong những tình huống cần tự động hóa, cả tiến trình lẫn môi trường tồn tại của nó đềuphải được mô tả một cách hình thức. Muốn vậy, toàn bộ hệ thống các bộ phận tươngtác phải được đặc tả chứ không chỉ đặc tả một thành phần52Giáo trình tóm tắt Công Nghệ Phần MềmNguyên lý 3: Đặc tả phải bao gồm hệ thống trong đó phần mềm là một thành phần(đảm bảotính hệ thống, thể hiện mối liên kết giữa phần mềm cần xây dựng với các thành phần khác).Một hệ thống bao gồm các thành phần tương tác nhau. Chỉ bên trong hoàn cảnh của toànbộ 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 riêng mớicó thể được xác định. Nói chung, một hệ thống được mô hình hóa như một tập hợp các mốiquan hệ giữa các thụ động. Những sự vật này có liên quan lẫn nhau và qua thời gian dẫn đếnmối quan hệ giữa các sự vật thay đổi. Mối quan hệ động này đưa ra sự kích thích cho các sựvật tích cực, còn gọi là các tác nhân, đáp ứng. Sự đáp ứng có thể gây ra những thay đổi thêmnữa, và do đó, tạo ra thêm kích thích để cho các tác nhân có thể đáp ứng lại.Nguyên lý 4: Đặc tả bao gồm cả môi trường mà hệ thống vận hành(có xét đến môi trườngxung quanh)Môi trường trong đó hệ thống vận hành và các tương tác phải được xác định.Bản thân môi trường cũng là một hệ thống bao gồm các sự vật tương tác, cả tích cực lẫnthụ động, mà trong hệ thống chúng chỉ là một tác nhân. Các tác nhân khác, theo định nghĩa làkhông thay đổi bởi vì chúng là một phần của môi trường, giới hạn phạm vi của việc thiết kế vàcài đặt về sau. Trong thực tế, sự khác nhau duy nhất giữa hệ thống và môi trường của nó là ởchỗ nỗ lực thiết kế và cài đặt về sau sẽ vận hành chỉ trong đặc tả cho hệ thống. Đặc tả môitrường làm cho "giao diện" của hệ thống được xác định theo cùng cách như bản thân hệ thốngchứ không đưa vào cách hình thức hóa khác.Đặc tả hệ thống chính là bức tranh của tập hợp các tác nhân xoắn xuýt nhau cao độ, phảnứng lại những kích thích trong môi trường (thay đổi các sự vật). Chỉ có thông qua những hànhđộng điều phối của tác nhân mà hệ thống mới đạt được các mục tiêu của nó. Thiết kế tuân theođặc tả và quan tâm đến việc phân rã một đặc tả thành các mẩu gần tách biệt để chuẩn bị chocài đặt. Tuy nhiên đặc tả phải vẽ lại chính xác bức chân dung của hệ thống và môi trường củanó như cộng đồng người dùng cảm nhận tới mức chi tiết, phục vụ cho các giai đoạn thiết kế vàcài đặt. Vì mức độ chi tiết cần thiết này là khó thấy trước, nếu không nói là không thể, nên đặctả, thiết kế và cài đặt phải được thừa nhận như một hoạt động tương tác. Do đó, điều mấu chốtlà công nghệ cần bao quát thật nhiều các hoạt động này khi bản đặc tả được soạn thảo và thayđổi (trong cả hai giai đoạn phát triển khởi đầu và bảo trì về sau)Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức- nghĩa là ngừơi đọc phải hiểuđược vấn đề thông qua đặc tả-Đặc tả hệ thống phải là một mô hình nhận thức chứ không phải là một mô hình thiết kếhay cài đặt-Mô tả một hệ thống sao cho đạt được sự cảm nhận của cộng đồng người sử dụng. Cácsự 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được mô hình hóa cho các cá nhân, tổ chức và trang thiết bị trong lĩnh vực đó; còn cáchành động họ thực hiện thì phải được mô hình hóa cho những hoạt động thực tế xuấthiện trong lĩnh vực-Phải có khả năng tổ hợp vào trong đặc tả những quy tắc hay luật bao trùm các sự vậtthuộc lĩnh vực:Một trong những luật này bài trừ những trạng thái nào đó của hệ thống (như "hai sự vậtkhông thể đồng thời cùng một chỗ và vào cùng một lúc") và do đó giới hạn hành vi củacác tác nhân hay chỉ ra nhu cầu bổ trợ để ngăn cản những trạng thái khỏi nảy sinh.Nguyên lý 6: Đặc tả phải thể hiện tính vận hành- nghĩa là đọc tài liệu đặc tả hình dung ra đượcsự vận hành của phần mềm.53Giáo trình tóm tắt Công Nghệ Phần MềmĐặc tả phải đầy đủ và mang tính hình thức để có thể được dùng trong việc xác định rằngliệu một cài đặt được đề nghị có thỏa mãn đặc tả cho những trường hợp kiểm thử tùy ý không.Tức là, với kết quả của việc cài đặt trên một tập dữ liệu được chọn một cách tùy ý, phải có thểdùng đặc tả để xác định tính hợp lệ cho những kết quả đó. Điều này kéo theo rằng đặc tả, mặcdầu không phải là một đặc tả hoàn toàn về cách thức, vẫn có thể hành động như một bộ sinhcác hành vi. Do đó theo nghĩa mở rộng, đặc tả này phải thể hiện tính vận hành …Quá trình cài đặtKết qủa cài đặtXác địnhtính hợp lệkiểmchứngđặc tảđặc tảđặc tảđặc tảđặc tảH 2.4 Quá trình cài đặtNguyên lý 7: có khả năng updateĐặc tả hệ thống chấp nhận dung sai về tính không đầy đủ và vì vậy có tính nâng caoKhông đặc tả nào có thể là đầy đủ hoàn toàn. Môi trường mà hệ thống tồn tại trong đó quáphức tạp. Một đặc tả bao giờ cũng là một mô hình - một sự trừu tượng hóa - của một tìnhhuống thực (hay được mường tượng) nào đó. Do đó nó sẽ không đầy đủ. Hơn thế nữa, nó tồntại ở nhiều mức chi tiết. Các công cụ phân tích được sử dụng để giúp đặ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ó khả năng lắp ghép- xuất phát từ lập trìnhhướng đối tượng.Các nguyên lý trước xử lý đặc tả như một thực thể tĩnh. Nguyên lý này nảy sinh từ tínhđộng của đặc tả. Cần phải thừa nhận rằng mặc dầu mục tiêu chính của một đặc tả là dùng làmcơ sở cho thiết kế và cài đặt một hệ thống nào đó, nó không phải là một sự vật tĩnh dựng sẵnmà là một vật động đang trải qua thay đổi đáng kể.Việc thay đổi (động) của đặc tả xuất hiện trong 3 hoạt động chính:-phát biểu: khi một đặc tả ban đầu đang được tạo ra-phát triển: khi đặc tả được soạn thảo trong quá trình thiết kế-lặp: để phản ánh môi trường đã thay đổi và/hoặc các yêu cầu chức năng phụ.Với nhiều thay đổi xuất hiện đối với đặc tả, điều mấu chốt là nội dung và cấu trúc của đặctả được chọn để làm phù hợp thay đổi này. Yêu cầu chính cho sự phù hợp đó là ở chỗ:-thông tin bên trong đặc tả phải được cục bộ hóa sao cho chỉ một phần nhỏ (một cách lýtưởng) cần phải sửa đổi khi thông tin thay đổi.-đặc tả cần được cấu trúc (ghép) một cách lỏng lẻo cho từng phần có thể được thêm vàohay loại bỏ một cách dễ dàng, và cấu trúc được điều chỉnh một cách tự động.54Giáo trình tóm tắt Công Nghệ Phần Mềm-5.3 Các mức trừu tượng của đặc tảCác đặc tả được thể hiện ở vài mức trừu tượng khác nhau cùng với mối tương quan giữacác mức ấy. Mỗi mức nhắm đến các đối tượng đọc khác nhau mà họ có quyền quyết định vềviệc mua sắm và thực hiện.Các mức đó là:Định ra yêu cầu:-thể hiện bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ thống sẽ phải cung cấp-phải được viết sao cho dễ hiểu đối với khách hàng và người quản lý hợp đồng, ngườisẽ mua sắm sẽ sử dụngĐặc tả yêu cầu:-tài liệu nêu ra các dịch vụ một cách chi tiết hơn. Tài liệu này (thường được gọi là đặc tảchức năng)-đòi hỏi chính xác tới mức nó có thể làm cơ sở cho hợp đồng giữa người mua sắm hệthống và người phát triển phần mềm.-được viết dễ hiểu đối với các nhân viên kĩ thuật ở cả nơi mua lẫn nơi phát triển-kỹ thuật đặc tả hình thức hẳn là thích hợp cho các đặc tả kiểu như vậy, nhưng nó cũngtùy thuộc ở trình độ kiến thức cơ bản của người mua sắm hệ thống.Đặc tả phần mềm/ đặc tả thiết kế (đây là một mô tả trừu tượng cho phần mềm):-dùng làm cơ sở cho việc thiết kế và thực thi-thể hiện một quan hệ rõ ràng giữa tư liệu này và đặc tả yêu cầu.-đối tượng đọc ở đây chủ yếu là các kĩ sư phần mềm chứ không phải là người sử dụnghoặc người quản lý-sử dụng kĩ thuật đặc tả hình thức là thích hợp cho tư liệu này.5.4 Đặc tả yêu cầuViệc định yêu cầu là việc đặc tả hướng khách hàng và được viết bởi ngôn ngữ của kháchhàng. Khi đó có thể dùng các khái niệm không chính xác, ngôn ngữ tự nhiên và các biểu đồ.Đặc tả yêu cầu (được gọi là đặc tả chức năng) là cơ sở cho hợp đồng làm hệ thống nó phảikhông được mơ hồ, mà mơ hồ đó có thể dẫn tới sự hiểu lầm bởi khách hàng hoặc bởi người kýhợp đồng.Rất nhiều vấn đề của kỹ nghệ phần mềm là khó khăn đối với đặc tả yêu cầu. Với một yêucầu mơ hồ thì người phát triển sẽ thực hiện nó sao cho rẻ nhất. Trong khi đó khách hàng lạikhông muốn như vậy. Sau các cuộc đấu khẩu kéo dài thì các yêu cầu mới sẽ được thiết lập vàcó các đổi thay đối với hệ thống. Dĩ nhiên việc đó làm trì hoàn ngày phân phát hệ thống và làmtăng chi phí.Chi phí do các sai sót trong việc phát biểu các yêu cầu có thể là rất cao, đặc biệt là nếu cácsai sót này còn vẫn chưa được phát hiện khi hệ thống được thực hiện. Bochm báo cáo rằngtrong một vài hệ thống lớn thì có đến 95% các mã đã phải viết lại để thỏa mãn cá yêu cầu củangười dùng đã thay đổi và 12% các lỗi được phát hiện trong quá trình ba năm đầu sử dụng làcác lỗi do đặc tả yêu cầu không đúng đắn.Chi phí do thay đổi một yêu cầu là đắt hơn nhiều so với chi phí sửa chữa thiết kế hoặc dolỗi mã.55Giáo trình tóm tắt Công Nghệ Phần Mềm5.4.1 Những hạn chế của việc đặc tả bằng ngôn ngữ tự nhiên1. Người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên buộc phải hiểu mỗi từ theo cùng mộtkhái niệm. Điều đó là không thể được do sự mơ hồ và bản tính cố hữu của ngôn ngữ tựnhiên và cũng vì không có một từ điển thuật ngữ máy tính chuẩn mực.2. Một đặc tả bằng ngôn ngữ tự nhiên là quá mềm dẻo: nó cho phép các yêu cầu liên quanđược biểu thị trong các cách hoàn toàn khác nhau.3. Các yêu cầu là không phân hoạch được một cách hữu hiệu: hiệu quả của việc đổi thay chỉ cóthể được xác định bởi toàn bộ các yêu cầu chứ không phải là một nhóm các yêu cầu liênquanCó người đề nghị rằng các ngôn ngữ đặc tả hình thức toán học nên được dùng để biểu thịcác yêu cầu hệ thống. Nhưng đa số các khách hàng lại không hiểu đặc tả hình thức toán học.Hall (1990) đề xuất con đường để đi vòng qua khó khăn đó là viết thêm các chú giải dài dòngngay bên cạnh cho người dùng dễ hiểu. Khi nào người dùng trở nên quen thuộc hơn với nhữngưu điểm của đặc tả hình thức và các kỹ sư phần mềm không còn miễn cưỡng dùng cácphương pháp hình thức thì sẽ có nhiều cách đặc tả yêu cầu sẽ dựa trên các mô hình hình thứccủa chức năng hệ thống5.4.2 Các yêu cầu phi chức năngMột yêu cầu phi chức năng của hệ thống là một hạn chế hoặc ràng buộc về các dịch vụcủa hệ thống. Các yêu cầu đó có thể được đưa ra:-vì nhu cầu của người dùng-vì hạn chế của kinh phí-vì chính sách của tổ chức-vì sự cần thiết tương tác giữa các phần cứng và phần mềm hoặc-vì các nhân tố bên ngoài như các quy tắc an toàn, luật lệ bí mật riêng tư, ...Có 3 kiểu yêu cầu phi chức năng chính:1. Các yêu cầu sản phẩm: đây là các yêu cầu về hệ thống được phát triển, chẳng hạn yêucầu về tốc độ, về bộ nhớ, về độ tin cậy, về tính di chuyển được và về tính dùng lại được2. Các yêu cầu về quá trình: đây là các yêu cầu về quá trình phát triển, chẳng hạn như cácchuẩn cần phải theo, các yêu cầu về sự thức hiện như các ngôn ngữ lập trình, phươngpháp thiết kế, yêu cầu về phân phát3. Các yêu cầu ngoại lai: tức là các yêu cầu không phải về sản phẩm cũng không phải vềquá trình phát triển; chẳng hạn như về giao tiếp với các hệ thống khác, về pháp lý, vềchi phí, về nhóm những người phát triển và ...Tùy theo các tổ chức cụ thể, đặc tả yêu cầu có thể được thể hiện bằng các cách khác nhaukể từ mức phát biểu bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ cần cung cấp đến mức đặctả hệ thống một cách hình thức kiểu toán học. Ranh giới giữa các yêu cầu và đặc tả hình thứclà một thứ rất tinh tế và các thuật ngữ này lại còn có thể được dùng theo nghĩa như nhau.5.4.3 Khó khăn của việc xác định đặc tả yêu cầu1. Các hệ phần mềm lớn thường được yêu cầu cải thiện dựa trên nguyên trạng: hoặckhông có hệ thống nào hoặc có một hệ thống không đầy đủ. Mặc dầu có thể biết cáckhó khăn của hệ thống hiện có nhưng lại rất khó dự đoán được hiệu quả của hệ thốngđã được cải thiện đối với tổ chức đó.56Giáo trình tóm tắt Công Nghệ Phần Mềm2. Các hệ thống lớn thường có một cộng đồng người sử dụng đa dạng, ho có những yêucầu và ưu tiên khác nhau, thậm chí là mâu thuẫn với nhau. Cuối cùng thì các yêu cầuhệ thống cũng không thể tránh được sự thỏa hiệp.3. Những người bỏ tiền ra mua sắm hệ thống và những người sử dụng hệ thống hiếm khilại là một. Những người mua sắm hệ thống đặt ra các yêu cầu theo những ràng buộccủa tổ chức cơ quan và của ngân sách. Những cái đó lại thường mâu thuẫn với các yêucầu thực sự của người dùng.5.4.4 Thẩm định yêu cầuMột khi đã thiết lập các yêu cầu thì phải thẩm định xem chúng có thỏa mãn các nhu cầu củangười mua hệ thống không. Nếu việc thẩm định không phù hợp thì các sai lầm có thể lan truyềnsang các giai đoạn thiết kế và thực hiện. Khi đó có thể cần đến các sự nâng cấp hệ thống rấttốn kém để làm cho nó đúng đắn, cần xác minh những vấn đề sau:Có 4 vấn đề liên quan đến việc thẩm định yêu cầu,1. Phải chỉ ra rằng các nhu cầu của người dùng là được thỏa mãn2. Các yêu cầu phải không gây ra mâu thuẫn nhau3. Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà ngườidùng đã nhắm đến4. Các yêu cầu phải là hiện thực.5.5 Dàn bài đặc tả yêu cầu phần mềmBản đặc tả các yêu cầu phần mềm được tạo ra tại đỉnh cao của nhiệm vụ phân tíchChức năng và hiệu năng được cấp phát cho phần mềm xem như một phần của kỹ nghệ hệthống thường được làm mịn bằng cách thiết lập phần mô tả thông tin đầy đủ như mô tả chứcnăng chi tiết, chỉ báo về các yêu cầu hiệu năng và những ràng buộc thiết kế, các tiêu chuẩnhợp lệ thích hợp và những dữ liệu khác thường cần tới. Cơ quan tiêu chuẩn quốc gia, IEEE vàBộ quốc phòng Mỹ đề nghị các định dạng cho các đặc tả yêu cầu phần mềm. Dàn bài đơn giảnhóa được trình bày trong bảng sau:Dàn bài đặc tả yêu cầu phần mềmI. Giới thiệuA. Đại cương về hệ thống(mục tiêu, mục đích)B. Mô tả chung(cấu trúc)C. Các ràng buộc dự án phần mềm(phạm vi)II. Mô tả thông tin(chi tiết)A. Biểu diễn luồng thông tin(dựa vào cấu trúc thông tin)1. Luồng dữ liệu2. Luồng điều khiển(đặc biệt chú ý đến khi xét các hệ thời gianthực)B. Biểu diễn nội dung thông tinC. Mô tả giao diện hệ thống(cho từng chức năng)III. Mô tả chức năngA. Phân hoạch chức năng(cho từng chức năng)B. Mô tả chức năng(lời giải thích)57Giáo trình tóm tắt Công Nghệ Phần Mềm1. Tường thuật về cách xử lý2. Hạn chế/giới hạn(về các mặt kinh tế, xã hội, kỹ thuật, chi phí,thời gian)3. Yêu cầu hiệu năng(theo từng modul)4. Ràng buộc thiết kế(có luận giải)5. Biểu đồ trợ giúp(cấu trúc tổng thể, tương quan với các phần tửhệ thống khác)C. Mô tả điều khiển1. Đặc tả điều khiển(có luận giải)2. Ràng buộc thiết kế(xem xét vận hành của phần mềm)IV. Mô tả hành vi(xem xét vận hành của phần mềm)A. Trạng thái hệ thống(mức toàn cảnh, mức đỉnh)B. Sự kiện và hành động(mức cụ thể, bộ phận)V. Tiêu chuẩn hợp lệA. Giới hạn hiệu năngB. Lớp các kiểm thửC. Đáp ứng phần mềm trông đợi(tiêu chuẩn hướng tới (lý tưởng))D. Các xem xét đặc biệtVI. Sách tham khảo(tài liệu kỹ nghệ phần mềm khác, tham khảokỹ thuật, ...)VII. Phụ lục(Danh sách các nhà cung cấp, các chuẩn, ...)Trong nhiều trường hợp bản đặc tả yêu cầu phần mềm còn có thể kèm theo một tài liệu sơbộ của người dùng trình bày số liệu cần đưa vào và kết quả cần đưa ra..5.6 Xét duyệt đặc tảViệc xét duyệt bản đặc tả các yêu cầu phần mềm (và hoặc bản mẫu) do cả người pháttriển phần mềm và khách hàng cùng tiến hành. Bởi vì đặc tả tạo nên nền tảng cho giai đoạnphát triển nên cần phải rất thận trọng khi tiến hành cuộc họp xét duyệt. Có 2 mức xét duyệt.5.6.1 Mức vĩ môViệc xét duyệt truớc hết được tiến hành ở mức vĩ mô. Tại mức này, người xét duyệt cốgắng đảm bảo rằng bản đặc tả được đầy đủ, nhất quán và chính xác. Cần đề cập tới các câuhỏi sau:•Các mục tiêu và mục đích được thiết lập cho phần mềm có nhất quán với mụctiêu và mục đích của hệ thống hay không?•Những giao diện quan trọng với mọi phần tử hệ thống đã được mô tả chưa?•Luồng và cấu trúc thông tin đã được mô tả thích hợp cho lĩnh vực vấn đề chưa?•Các biểu đồ có rõ ràng không? Liệu mỗi biểu đồ có thể đứng riêng không cần lờigiải thích không?•Các chức năng chính có còn bên trong phạm vi và đã được mô tả thích hợpchưa?•Liệu hành vi của phần mềm có nhất quá với thông tin nó phải xử lý và chức năngnó phải thực hiện hay không?58

Xem Thêm

Tài liệu liên quan

• Giáo trình tóm tắt Công nghệ phần mềm docx
  • 148
  • 3,582
  • 76
• Quyết định 1928/2004/QĐ-UBTDTT về Quy chế Quản lý các đoàn ra và các đoàn nước ngoài vào Việt Nam hoạt động trong lĩnh vực thể dục thể thao do Bộ trưởng Chủ nhiệm Ủy ban thể dục thể thao ban hành
  • 6
  • 0
  • 0
• Quyết định 2196/QĐ-UBND năm 2009 công bố bộ thủ tục hành chính thuộc thẩm quyền giải quyết của Sở Giáo dục và Đào tạo tỉnh Quảng Bình do Ủy ban nhân dân tỉnh Quảng Bình ban hành
  • 2
  • 0
  • 0
• Công văn số 1120/TCHQ-KTTT về việc xử lý thuế GTGT hàng nhập khẩu phục vụ quốc phòng do Tổng cục Hải quan ban hành
  • 1
  • 0
  • 0
• Quyết định 40/2002/QĐ-UB Điều chỉnh nội dung Quyết định 19/1999/QĐ-UB về việc qui định diện tích đất ở để miễn giảm tiền thuế nhà đất cho các đối tượng có công với cách mạng do Ủy ban Nhân dân Thành phố Hà Nội ban hành
  • 1
  • 0
  • 0
• Công văn số 850/BXD-KSTK của Bộ xây dựng về việc Trả lời văn bản 270/SXD-KTKT của Sở Xây dựng tỉnh Đồng Tháp
  • 1
  • 0
  • 0
• Quyết định 988/2002/QĐ-NHNN về quản lý ngoại hối đối với việc mua, bán chứng khoán của tổ chức, cá nhân nước ngoài tại trung tâm giao dịch chứng khoán do Thống đốc Ngân hàng Nhà nước ban hành
  • 6
  • 0
  • 0
• Quyết định 1506/QĐ-BNN-KHCN năm 2008 về việc ban hành quy trình thực hành chăn nuôi tốt cho chăn nuôi lợn an toàn do Bộ trưởng Bộ Nông nghiệp và Phát triển nông thôn ban hành
  • 18
  • 0
  • 0
• Nghị định 83/2006/NĐ-CP Quy định trình tự, thủ tục thành lập, tổ chức lại,giải thể tổ chức hành chính, tổ chức sự nghiệp nhà nước
  • 9
  • 0
  • 0
• Quyết định 2762/QĐ-BYT năm 2009 ban hành "Hướng dẫn chẩn đoán, điều trị và phòng lây nhiễm cúm A (H1N1)" do Bộ trưởng Bộ Y tế ban hành
  • 5
  • 0
  • 0
• Công văn số 2879TCHQ/GSQL về việc xem xét lại việc áp mã mặt hàng thu được qua quá trình xay sát ngô do Tổng cục Hải quan ban hành
  • 1
  • 0
  • 0

Tải bản đầy đủ (.doc) (148 trang)

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

(1.36 MB) - Giáo trình tóm tắt Công nghệ phần mềm docx-148 (trang) Tải bản đầy đủ ngay ×