Các yêu cầu phần mềm pot

Mục tiêu● Giới thiệu các khái niệm về yêu cầu người dùng và yêu cầu hệ thống ● Mô tả các yêu cầu chức năng và các yêu cầu phi chức năng ● Giải thích cách thức các yêu cầu phần mềm được

Các yêu cầu phần mềm

Mục tiêu

● Giới thiệu các khái niệm về yêu cầu người dùng và yêu cầu hệ

thống

● Mô tả các yêu cầu chức năng và các yêu cầu phi chức năng

● Giải thích cách thức các yêu cầu phần mềm được tổ chức trong

tài liệu yêu cầu

Các chủ đề

Yêu cầu là gì?

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

Các yêu cầu người dùng

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

Đặc tả giao diện

Tài liệu yêu cầu phần mềm

Kỹ nghệ yêu cầu (RE)

Yêu cầu là gì?

● Yêu cầu có thể giới hạn từ một phát biểu trừu tượng mức cao

về một dịch vụ hoặc một ràng buộc hệ thống đến một đặc tả chức năng toán học chi tiết.

● Giới hạn này là không tránh khỏi vì các yêu cầu có thể:

cho mọi đối tượng người đọc

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

Sự trừu tượng hóa yêu cầu (Davis)

“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs Once a contract has been awarded, the contractor must write a system definition for the client

in more detail so that the client understands and can validate what the software will

do Both of these documents may be called the requirements document for the

system.”

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

• Là các phát biểu bằng ngôn ngữ tự nhiên và các biểu đồ về

các dịch vụ mà hệ thống cung cấp và các ràng buộc vận hành của nó Được viết cho các khách hàng

• Là các mô tả chi tiết về các chức năng của hệ thống, các dịch

vụ và các ràng buộc vận hành, được trình bày trong một tài liệu

có cấu trúc Tài liệu này phải định nghĩa chính xác những gì nên được cài đặt và có thể là một phần của bản hợp đồng giữa khác hàng và nhà thầu

Các định nghĩa và các đặc tả

1 The software mu st pr ovide a m eans of representing and

1 accessing e xtern al files cr eated by other tools

1.1 The user sh ould be pr ovided with facilities to defin e the type of 1.2 external files

1.2 Each e xternal fi le type m a y ha ve an associa ted tool wh ich m a y be 1.2 applied to th e file

1.3 Each e xternal fi le type m a y be represented as a specific icon on 1.2 the u ser’ s displa y.

1.4 Facilities sh ould be pr ovided f or the icon r epresenting an 1.2 external fi le type to be defi ned b y the u ser

1.5 Wh en a u ser selects an icon r epresentin g an e xternal fi le , the 1.2 effect of th at selection is to apply the tool associated with th e type of 1.2 the extern al file to the fi le represented by th e selected icon.

U ser requir em ent definition

System requirem ents specifi cation

Những người đọc yêu cầu

Client m ana gers System end-users Client eng ineers Con tractor m an a gers System ar chitects

System end-users Client eng ineers System ar chitects Software developers

Client eng ineers (perha ps)

U ser requirem ents

System requirem ents

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

• Là các phát biểu về các dịch vụ mà hệ thống sẽ cung cấp, cách

thức hệ thống phản ứng với các đầu vào đặc biệt và cách thức

hệ thống ứng xử với các tình huống đặc biệt

• Là các ràng buộc trên các dịch vụ hoặc các chức năng được

yêu cầu bởi hệ thống như các ràng buộc về thời gian, các ràng buộc về tiến trình phát triển, các chuẩn, …

• Là các yêu cầu đến từ miền ứng dụng của hệ thống, thay vì

đến từ người dùng và phản ứng các đặc tính của miền đó

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

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

● Phụ thuộc vào:

● Các yêu cầu chức năng của người dùng có thể:

yêu cầu chức năng hệ thống

Ví dụ: Xét hệ thống LIBSYS

● LIBSYS:

CSDL bài báo trong các thư viện khác nhau.

báo này cho các nghiên cứu cá nhân.

Ví dụ: các yêu cầu chức năng của

LIBSYS

● Người dụng có thể tìm kiếm trên toàn bộ các CSDL hoặc một

tập nhỏ các CSDL.

● Hệ thống sẽ cung cấp các hiển thị phù hợp cho người dùng đọc

các tài liệu trong kho tài liệu.

● Mọi đơn đặt hàng phải có một định danh duy nhất (ORDER_ID)

mà người dùng có thể copy đến vùng lưu trữ thường trực của

tài khoản.

Sự mơ hồ của các yêu cầu

● Các vấn đề phát sinh khi các yêu cầu không được phát biểu

chính xác.

● Các yêu cầu mập mờ có thể được hiểu theo các cách khác

nhau bởi những người phát triển và người dùng.

● Xét thuật ngữ ‘appropriate viewers’:

thể cho mỗi kiểu tài liệu khác nhau;

bản mà chỉ ra các nội dung của tài liệu.

Tính đầy đủ & tính phù hợp của các yêu

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

ràng buộc của hệ thống Ví dụ yêu cầu về độ tin cậy, các yêu cầu về thời gian phản hồi, yêu cầu về lưu trữ Các ràng buộc như khả năng của thiết bị vào/ra, các biểu diễn hệ thống, …

các yêu cầu chức năng Nếu chúng không được thỏa mãn, hệ thống có thể trở nên vô ích.

cậy => không được phê chuẩn, không được sử dụng.

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

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

• Các yêu cầu đặc tả rằng sản phẩm được phát hành phải ứng

xử theo cách đặc biệt, ví dụ: tốc độ thực thi, độ tin cậy, etc

● Các yêu cầu tổ chức

• Các yêu cầu nẩy sinh từ các chính sách và các thủ tục của tổ

chức, ví dụ các chuẩn tiến trình được sử dụng, các yêu cầu cài đặt, etc

● Các yêu cầu bên ngoài

• Các yêu cầu nẩy sinh từ các nhân tố nằm ngoài hệ thống và

tiến trình phát triển nó, ví dụ: Các yêu cầu về khả năng tương tác, các yêu cầu tương thích, etc

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

Performance

requi rements

Space requi rements

Us abi l i ty

requi rements

Effici ency requi rements

Rel i abi l i ty requi rements

Portabi l i ty requi rements

I nteroperabi l i ty requi rements

Ethi cal requi rements

Legi s l a tive requi rements

I mpl ementati on requi rements

Standards requi rements

Del ivery requi rements

Safety requi rements

Privacy requi rements

Product requi rements

Organi s ati onal requi rements

External requi rements Non-functi onal

requi rements

Các VD về yêu cầu phi chức năng

● Yêu cầu về sản phẩm

8.1 Giao diện người dùng cho LIBSYS nên được cài đặt bởi

HTML mà không chứa các frame hoặc Java applets.

● Yêu cầu tổ chức

9.3.2 Tiến trình phát triển hệ thống và các tài liệu phát hành phải

theo những gì được định nghĩa trong XYZCo-SP-STAN-95.

● Yêu cầu ngoài

7.6.5 Hệ thống không được lộ thông tin cá nhân của các khách

hành như họ tên và số tham chiếu đến các thao tác của hệ thống.

Các mục tiêu và các yêu cầu

chính xác và các yêu cầu không chính xác rất khó để thẩm định

• Mục tiêu phổ biến/chung của người dùng là dễ sử dụng.

• Một phát biểu sử dụng một số phép đo có thể được kiểm thử

một cách khách quan

chúng truyền tải được các ý định/mong muốn của những người dùng hệ thống.

Các ví dụ

• Hệ thống nên dễ sử dụng bởi những người điều khiển có kinh

nghiệm và nên được tổ chức theo cách tối thiểu hóa các lỗi người dùng

• Những người điểu khiển hệ thống có kinh nghiệm có thể sử

dụng mọi chức năng của hệ thống sau 2 tiếng huấn luyện Sau thời gian huấn luyện này, số lỗi được tạo bởi họ không vượt quá 2 lỗi/1 ngày

Các phép đo 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 Portability Percentage of target dependent statements

Bất cứ khi nào có thể bạn nên chuyển các yêu cầu phi chức năng thành các yêu cầu có định lượng.

Tương tác các yêu cầu

nhau thường phổ biến trong các hệ thống phức tạp.

• Để giảm thiểu trọng lượng, số chips trong hệ thống nên giảm

thiểu

• Để giảm thiểu năng lượng tiêu thụ, các chips nguồn điện thấp

hơn nên được sử dụng

Tuy nhiên sử dụng các chips nguồn điện thấp có nghĩa răng nhiều chips hơn phải được sử dụng => Yêu cầu nào là then chốt nhât?

Các yêu cầu miền

● Nẩy sinh từ miền ứng dụng hơn là từ các yêu cầu của người

dùng Nó mô tả các đặc tính và các đặc trưng của hệ thống phản ánh miền ứng dụng.

● Các yêu cầu miền là các yêu cầu chức năng mới, các ràng buộc

lên các yêu cầu đang tồn tại hoặc định nghĩa các tính toán cụ thể.

● Nếu các yêu cầu này không thỏa mãn, hệ thống không thể làm

việc.

Các yêu cầu miền của hệ thống LIBSYS

● Phải có một giao diện người dùng chuẩn cho mọi CSDL, nên

dựa trên chuẩn Z39.50.

● Vì các hạn chế bản quyền, một số tài liệu phải được xóa ngay

sau khi đến Phụ thuộc vào các yêu cầu người dùng, các tài liệu này sẽ được in cục bộ trên server hệ thống và chuyển bằng tay đến người dùng hoặc in trên máy in mạng.

Hệ thống bảo vệ tầu

● Sự giảm tốc độ của tầu được tính như sau:

D train = D control + D gradient where D gradient is 9.81ms 2 * compensated gradient/alpha and where the values of 9.81ms 2 /alpha are known for different types

of train.

Các vấn đề về yêu cầu miền

● Khả năng hiểu

ứng dụng;

đang phát triển hệ thống không hiểu được chúng

● Hàm ý

Các chuyên gia miền ứng dụng hiểu rất rõ về miền dẫn đến họ không nghĩ đến việc làm cho các yêu cầu miền được rõ ràng.

Các yêu cầu người dùng

● Nên mô tả các yêu cầu chức năng và các yêu cầu phi chức

năng theo cách mà người dùng có thể hiểu mà không cần có các kiến thức về kỹ thuật

● Các yêu cầu người dùng được định nghĩa sử dụng ngôn ngữ

tự nhiên (NL) , các bảng và các biểu đồ sao cho chúng có thể được hiểu bởi người dùng.

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

● Thiếu tính trong sáng

đọc.

● Sự lộn xộn các yêu cầu

● Sự pha trộn các yêu cầu

nhau.

Ví dụ: Yêu cầu LIBSYS

4 5 LIBSYS nên cung c p m t h th ng tài kho n tài

chính mà l u t t c các báo cáo v các chi tr c t o

b i ng i dùng h th ng Nh ng ng i qu n lý h th ng

có th c u hình h th ng này sao cho các ng i dùng

Vấn đề về yêu cầu

● Xét yêu của của LIBSYS:

Yêu cầu lưới Editor

2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, v ia an

option on the control panel Initially, the grid is off The grid may be

turned on and off at any time during an editing session and can be

toggled between inches and centimetres at any time A grid option

will be prov ided on the reduce-to-fit v iew but the number of grid

lines shown will be reduced to av oid filling the smaller diagram

with grid lines.

Các vấn đề yêu cầu

Xét yêu cầu Grid;

• Conceptual functional requirement (the need for a grid);

• Non-functional requirement (grid units);

• Non-functional UI requirement (grid switching)

=> Sự lộn xộn của các yêu cầu

Biểu diễn có cấu trúc

2.6.1 Grid facilities

The editor shall provide a grid facility where a m atrix of horizontal and

vertical lines provide a background to the editor window This grid shall be a

passive grid where the alignment of entities is the user's responsibility.

Rationale: A grid helps the user to create a tidy diagram with well-spaced

entities Although an active grid, where entities 'snap-to' grid lines can be useful, the positioning is imprecise The user is the best person to decide where entities should be positioned.

Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6

Source: Ray Wilson, Glasgow Office

Các hướng dẫn cho việc viết các yêu cầu

● Đưa ra một form chuẩn và sử dụng nó cho mọi yêu cầu

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

● Là các đặc tả chi tiết hơn về các chức năng, các dịch vụ và các

ràng buộc của hệ thống so với các yêu cầu người dùng.

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

● Chúng có thể được kết hợp vào bản hợp đồng hệ thống.

● Các yêu cầu hệ thống có thể được định nghĩa hoặc minh họa

sử dụng các mô hình hệ thống được chỉ ra trong chương 4.

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

• các yêu cầu nên phát biểu những gì hệ thống nên làm

• và thiết kế nên mô tả cách thực nó thực hiện các yêu cầu

• Hệ thống có thể tương tác bên trong với các hệ thống

khác mà sinh ra các yêu cầu thiết kế;

• Sử dụng một thiết kế cụ thể có thể là yêu cầu miền ứng

dụng.

Các vấn đề về việc đặc tả bằng NL

● Mập mờ

giống nhau theo các cách khác nhau

● Quá linh hoạt

Các thay thế đối với đặc tả yc hệ

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

Các đặc tả ngôn ngữ có cấu trúc

● Tính tự do của người viết các yêu cầu được hạn chế bởi mẫu

đã định nghĩa cho các yêu cầu.

● Mọi yêu cầu được viết theo một cách chuẩn.

● Thuật ngữ được sử dụng trong mô tả có thể bị hạn chế

● Lợi ích là tính hiệu quả nhất của NL được duy trì như mức độ

đồng nhất bị áp đặt lên đặc tả.

Các đặc tả Form-based

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

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

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

● Chỉ rõ các thực thể khác được yêu cầu.

● Các điều kiện Pre và post (if appropriate).

● Các hiệu ứng lề của chức năng (if any).

Đặc tả node dựa trên Form

Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level

Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units.

Inputs Current sugar reading (r2), the previous two readings (r0 and r1)

Source Current sugar reading from sensor Other readings from memory.

Outputs CompDose Š the dose in insulin to be delivered

Destination Main control loop

Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of

increase is decreasing If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result If the result, is rounded to zero then CompDose is set to the minimum dose that can

be delivered.

Requires Two previous readings so that the rate of change of sugar level can be computed.

Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin

Post-condition r0 is replaced by r1 then r1 is replaced by r2

Side-effects None

Đặc tả Tabular/bảng

● Được sử dụng để bổ xung cho NL.

● Đặc biệt hữu ích khi bạn phải định nghĩa một số tiến trình thay

thế có thể của hành động.

Đặc tả Tabular

Sugar level falling (r2 < r1) CompDose = 0

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 đồ thị

● Các mô hình đồ thị hữu ích nhất khi bạn cần chỉ ra các thay đổi

trạng thái như thế nào hoặc khi bạn cần mô tả một chuỗi các hoạt động.

● Các mô hình đồ thị được trình bày trọng chương 4.

Các biểu đồ tuần tự

● Các biểu đồ này chỉ ra một chuỗi các sự kiện xảy ra khi người

dùng tương tác với hệ thống.

● Bạn đọc chúng từ trên xuống dưới để biết được trình tự các

hoạt động diễn ra.

● Rút tiền qua thẻ từ ATM

Biểu đồ tuần tự của ca rút tiền qua

thẻ với ATM

AT M Database

Card

Card n u m ber Card OK PIN requ est

PIN Option m enu

< < exception> >

in valid card With draw requ est

Am ou n t requ est

Am ou n t

Balance request Balan ce

< < exception > >

in sufficient cash

Debit (am ou n t) Debit respon se Card

Card rem oved

Validate card

Han dle requ est