Chương 4 các yêu cầu của phần mềm

Các kiểu yêu cầu khác nhauCác yêu cầu của người sử dụng lược đồ diễn tả các dịch vụ mà hệ thống sẽ cung cấp và những ràng buộc khi vận hành của hệ thống.. Các yêu cầu chức năng và không-

Chương 4 Các yêu cầu của phần mềm

Công nghệ xác định yêu cầu

Qui trình thiết lập các dịch vụ do khách hàng yêu cầu hệ thống phải thoả mãn với các ràng buộc

mà trong đó hệ thống này sẽ hoạt động và sẽ được phát triển.

Bản thân các yêu cầu chính là các mô tả của các dịch vụ và những ràng buộc hệ thống phát sinh trong quá trình công nghệ xác định yêu cầu.

Một yêu cầu là gì?

Nó có thể là một mô tả tóm tắt ở mức cao một dịch vụ hoặc một ràng buộc hệ thống đối với đặc

tả toán học chi tiết.

Rõ ràng là các yêu cầu có thể có chức năng kép

Ví dụ:

phải được mở ra để tìm hiểu;

phải được định nghĩa chi tiết;

Mô tả tóm tắt các yêu cầu

c u c a h th ng ầ ủ ệ ố

Các kiểu yêu cầu khác nhau

Các yêu cầu của người sử dụng

lược đồ diễn tả các dịch vụ mà hệ thống sẽ cung cấp

và những ràng buộc khi vận hành của hệ thống

Những yêu cầu này phải được cung cấp cho khách hàng

Các yêu cầu hệ thống

các chức năng, các dịch vụ và các ràng buộc khi vận hành của hệ thống

Các yêu cầu chức năng và không-chức năng

Các yêu cầu chức năng

• Các mô tả dịch vụ mà hệ thống sẽ cung cấp, hệ thống sẽ phản

ứng lại những inputs đặc biệt như thế nào và hệ thống sẽ cư

xử như thế nào trong các tình huống đặc biệt.

Các yêu cầu không-chức năng

• Những ràng buộc trên các dịch vụ hoặc các chức năng do hệ

thống cung cấp chẳng hạn như những hạn chế về thời gian, những ràng buộc về qui trình phát triển, về các tiêu chuẩn v.v.

Các yêu cầu lĩnh vực ứng dụng

• Những yêu cầu xuất phát từ lĩnh vực ứng dụng của hệ thống

phản ánh các đặc trưng của lĩnh vực này.

Các yêu cầu chức năng

Mô tả các dịch vụ chức năng hoặc hệ thống.

Phụ thuộc vào kiểu phần mềm, những người sẽ

sử dụng và kiểu của hệ thống nơi phần mềm sẽ được cài đặt và sử dụng.

Những yêu cầu chức năng của người sử dụng

có thể là những trình bày tóm tắt công việc mà

hệ thống phải làm nhưng các yêu cầu chức năng

hệ thống thì phải mô tả chi tiết các dịch vụ của

hệ thống.

Tính không chính xác của các yêu cầu

Các vấn đề sẽ xuất hiện khi các yêu cầu không được đặt ra một cách chính xác.

Những yêu cầu mập mờ sẽ làm cho người phát triển và người sử dụng hiểu theo các cách khác nhau.

Hãy xem xét thuật ngữ ‘các cách nhìn thích hợp’

đối với từng kiểu tài liệu khác nhau

nhìn văn bản để hiện nội dung của tài liệu

Tính đầy đủ và nhất quán của các yêu cầu

Về nguyên tắc, các yêu cầu phải vừa đầy đủ và vừa nhất quán

Đầy đủ

ích cần thiết

Nhất quán

thuẫn trong các mô tả về các tiện ích hệ thống

Trong thực tế, không thể đưa ra được một tài liệu các yêu cầu vừa đầy đủ lại vừa nhất quán

Các yêu cầu không-chức năng

Những yêu cầu này định nghĩa các đặc tính và các ràng buộc của hệ thống, ví dụ độ tin cậy, thời gian đáp ứng

và những yêu cầu về bộ nhớ Các ràng buộc là khả năng của thiết bị I/O, cách trình diễn của hệ thống, v.v

Các yêu cầu về qui trình cũng có thể được đặc tả bằng một hệ thống CASE, một ngôn ngữ lập trình hoặc một phương pháp phát triển nào đó

Các yêu cầu không-chức năng có thể đòi hỏi phải bàn đến nhiều hơn những yêu cầu chức năng Nếu những yêu cầu này không được đáp ứng thì hệ thống có thể không dùng được

Phân loại các yêu cầu không-chức năng

Các yêu cầu về sản phẩm

• Những yêu cầu chỉ rõ sản phẩm được chuyển giao phải vận

hành theo một tiêu chuẩn riêng nào đó, ví dụ về tốc độ thực hiện, độ tin cậy, v.v.

Các yêu cầu về tổ chức

• Những yêu cầu là hệ quả của các chính sách và thủ tục tổ

chức, ví dụ như các chuẩn qui trình đang được sử dụng, các yêu cầu về quá trình thực hiện, v.v.

Các yêu cầu ngoại lai

• Những yêu cầu xuất phát từ những nhân tố bên ngoại hệ thống

và qui trình phát triển của nó, ví dụ như những yêu cầu liên kết với bên ngoài, những yêu cầu về luật pháp, v.v.

Các kiểu yêu cầu không-chức năng

re quir e me nts

Mục đích và yêu cầu

Các yêu cầu không-chức năng có thể sẽ rất khó đặt ra một cách chính xác và các yêu cầu mơ hồ có thể sẽ rất khó kiểm chứng

Mục đích

• Một mong muốn chung của người sử dụng ví dụ như dễ sử

dụng.

Yêu cầu không-chức năng có thể kiểm chứng được

• Một mô tả bằng một biện pháp nào đó mà có thể được kiểm tra

lại một cách khách quan.

Các mục đích rất hữu ích cho người phát triển vì chúng chứa đựng những điều mong muốn của người sử dụng

hệ thống

Các ví dụ

Một mục đích hệ thống

• Hệ thống phải dễ sử dụng và phải được tổ chức theo một cáhc

nào đó mà người sử dụng ít mắc lỗi nhất.

Một yêu cầu không-chức năng có thể kiểm chứng được

• Những người sử dụng có kinh nghiệm phải có khả năng sử dụng

tất cả các chức năng hệ thống sau khi được huấn luyện sử dụng

2 tiếng đồng hồ Sau đợt huấn luyện này, số lỗi trung bình mà những người này mắc phải khi sử dụng hệ thống sẽ không quá 2 lỗi trong một ngày.

Đo lường các yêu cầu

Property Measure

Speed Processed transactions/second

User/Event response time Screen refresh time

Robustness Time to restart after failure

Percentage of events causing failure Probability of data corruption on failure

Sự ảnh hưởng lẫn nhau của các yêu cầu

Trong các hệ thống phức tạp, các yêu cầu không-chức năng thường xung đột lẫn nhau.

Hệ thống tàu vũ trụ

riêng biệt phải giảm

thì phải sử dụng các chips công suất thấp hơn

nghĩa là phải sử dụng nhiều chips hơn Yêu cầu nào

là quan trọng hơn?

Các yêu cầu lĩnh vực ứng dụng

Phát sinh từ lĩnh vực ứng dụng và mô tả những đặc trưng và tính năng hệ thống phản ánh lĩnh vực ứng dụng này.

Nếu các yêu cầu lĩnh vực không được xác định thì hệ thống có thể sẽ không thể vận hành được.

Các vấn đề đối với yêu cầu lĩnh vực

Tính có thể hiểu được

lĩnh vực ứng dụng;

khăn để hiểu được những yêu cầu về lĩnh vực ứng dụng

Tính ẩn ý

lĩnh vực của họ đến mức cho rằng không cần phải nêu rõ những yêu cầu về lĩnh vực ứng dụng

Các yêu cầu của người sử dụng

Nên mô tả các yêu cầu chức năng và không- chức năng theo một cách nào đó mà những người sử dụng hệ thống không có kiến thức đầy

đủ về kỹ thuật cũng có thể hiểu được.

Các yêu cầu của người sử dụng cần được định nghĩa bằng ngôn ngữ tự nhiên, bằng các bảng

và các biểu đồ vì làm như vậy thì bất cứ người

sử dụng nào cũng có thể hiểu rõ được.

Chỉ dẫn cho việc viết các yêu cầu

Sáng chế ra một format chuẩn và sử dụng nó cho tất cả các yêu cầu

Sử dụng ngôn ngữ theo một phong cách nhất quán.

In đậm những phần chìa khoá của các yêu cầu Tránh dùng những thuật ngữ riêng của máy tính.

Các yêu cầu hệ thống

Đặc tả của các chức năng, các dịch vụ và các ràng buộc của hệ thống cần phải chi tiết hơn so với các yêu cầu của người sử dụng.

Chúng sẽ là cơ sở cho việc thiết kế hệ thống.

Chúng có thể được đưa vào hợp đồng phát triển

hệ thống.

Các yêu cầu hệ thống có thể được định nghĩa hoặc minh hoạ bằng các mô hình hệ thống

Các yêu cầu và thiết kế

Về nguyên tắc, các yêu cầu cần xác đinh rõ hệ thống cần làm gì và thiết kế cần mô tả hệ thống

sẽ làm như thế nào.

Trong thực tế, các yêu cầu và thiết kế không thể tách rời nhau.

Các vấn đề với đặc tả bằng ngôn ngữ tự nhiên

Tính mơ hồ

• Người đọc và người viết các yêu cầu phải hiểu cùng một từ

theo cùng một cách Bản thân ngôn ngữ tự nhiên thường mang tính mơ hồ và vì vậy sẽ rất khó để có thể luôn hiểu nhau.

Những thay thế cho đặc tả bằng ngôn ngữ tự nhiên

N otation D escri ption

Mathematical

specifications

These are notations based on mathematical concepts such as finite-state machines or sets These unambiguous specifications reduce the arguments between customer and contractor about system functionality However, most customers don’t understand

Đặc tả bằng form

Định nghĩa chức năng hoặc thực thể.

Mô tả các đầu vào và nơi mà từ đó chúng đến.

Mô tả các đầu ra và nơi mà chúng sẽ đến.

Chỉ dẫn về những thực thể cần thiết.

Các điều kiện trước và sau (nếu thích hợp).

Các hiệu ứng phụ (nếu có) của chức năng.

Đặc tả dạng bảng

Được sử dụng để hỗ trợ cho ngôn ngữ tự nhiên Đặc biệt hữu ích khi phải định nghĩa một số quá trình diễn biến có thể thay thế của một hành

động.

Đặc tả dạng bảng

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of

increase decreasing ((r2-r1)<(r1-r0))

CompDose = 0

Sugar level increasing and rate of

increase stable or increasing ((r2-r1)

(r1-r0))

CompDose = round ((r2-r1)/4)

If rounded result = 0 then CompDose = MinimumDose

Các mô hình đồ hoạ

Các mô hình đồ hoạ hữu dụng nhất khi cần phải chỉ ra những thay đổi trạng thái sẽ như thế nào hoặc nơi mà chúng ta cần mô tả một dãy các hành động.

Lược đồ chuỗi của máy ATM

ATM Database

Card

Card n u m ber Card OK PIN requ est

PIN Option m en u

< < exception > >

in valid card With draw requ est

Validate card

Han dle requ est

Com plete tran saction

Đặc tả giao diện

Hầu hết các hệ thống đều phải hoạt động cùng với các

hệ thống khác và các giao diện hoạt động phải được đặc

tả như một phần của các yêu cầu

Ba kiểu giao diện có thể phải định nghĩa

• Các giao diện thủ tục;

• Các cấu truc dữ liệu phải chuyển đổi;

• Các biểu diễn dữ liệu.

Các ký hiệu hình thức là một kỹ thuật để đặc tả cádc giao diện

Đặ tả giao diện máy phục vụ in tài liệu

interface PrintServer {

// defines an abstract printer server

// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ; void cancelPrintJob (Printer p, PrintDoc d) ; void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer

Tài liệu các yêu cầu

Tài liệu các yêu cầu là những mô tả chính thức của những gì được yêu cầu đối với người phát triển hệ thống.

Cần phải bao gồm cả định nghĩa của các yêu cầu từ người sử dụng và các đặc tả về các yêu cầu hệ thống.

Đây không phải là một tài liệu thiết kế Càng chi tiết càng tốt, tài liệu các yêu cầu cần phải xác

định hệ thống phải làm gì chứ không đề cập đến phải làm như thế nào.

Người sử dụng tài liệu yêu cầu

U se the requirements to develop validation tests for

the system

U se the requirements document to plan a bid for the system and to plan the system development process

U se the requirements to understand what system is to

be developed

System test eng ineers

Managers

System eng ineers

Specify the requirements and read them to check that they meet their needs T hey specify changes to the requirements

System customers

U se the requirements to help System

Cấu trúc tài liệu yêu cầu

Lời nói đầuGiới thiệuCác thuật ngữĐịnh nghĩa các yêu cầu của người sử dụng Kiến trúc hệ thống

Đặc tả các yêu cầu hệ thống Các mô hình hệ thống

Cải tiến hệ thống Các phụ lục

Bảng chỉ dẫn (index)

Các điểm chìa khoá

Các yêu cầu đặt ra những gì hệ thống phải làm và xác định những ràng buộc về vận hành và thực hiện của nó.Các yêu cầu chức năng trình bày các dịch vụ mà hệ

Các điểm chìa khoá

Các yêu cầu hệ thống là sự truyền tải những

chức năng mà hệ thống cần cung cấp.

Một tài liệu các yêu cầu phần mềm là những mô

tả về các yêu cầu của hệ thống.