Bài 2 Xác định Yêu cầu

Những yêu cầu chức năng và phi chức năngFunctional and non-functional requirements 12  Yêu cầu chức năng Functional requirements  Những tuyên bố statements về dịch vụ hệ thống nên cung

Công nghệ Phần mềm

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

Giảng viên: Lê Nguyễn Tuấn Thành

Nguyễn Văn Đồng Email: thanhlnt@tlu.edu.vn

nvdong@tlu.edu.vn

Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT

Trường Đại Học Thủy Lợi

Nội dung

2

 Quy trình Kỹ thuật tạoYêu cầu

Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007”

Yêu cầu của Phần mềm

(Software Requirements)

3

Những chủ đề được đề cập

(Topics covered)

5

 Yêu cầu chức năng và phi chức năng

 Yêu cầu người dùng

 Yêu cầu hệ thống

 Đặc tả giao diện (interface specification)

 Tài liệu yêu cầu phần mềm (the software requirementsdocument)

Kỹ thuật yêu cầu

(Requirements engineering)

6

 Là quá trình thành lập những dịch vụ mà khách hàng yêucầu từ một hệ thống và những rằng buộc trong đó hệthống vận hành và được phát triển

 Những yêu cầu tự bản thân chúng là những miêu tả vềnhững dịch vụ hệ thống và rằng buộc được sinh ra trongquá trình kỹ thuật yêu cầu (requirements engineeringprocess)

 Điều này là không tránh khỏi do những yêu cầu có thể

miêu tả một chức năng kép (dual function):

 Nó có thể là cơ sở cho việc đấu thầu một hợp đồng – do đó phải dễ diễn giải (interpretation);

 Bản thân nó có thể là cơ sở cho một hợp đồng – do đó phải được định nghĩa cụ thể;

 Cả hai phát biểu này đều có thể được gọi là những yêu cầu

Yêu cầu trừu tượng

(Requirements abstraction )

8

“ Nếu một công ty mong muốn ký một hợp đồng (contract)

cho một dự án phát triển phần mềm lớn, nó phải định nghĩa những yêu cầu của nó theo một cách đủ trừu tượng rằng một giải pháp không được định nghĩa trước Những yêu cầu đó phải được viết sao cho nhiều nhà thầu có thể đấu thầu hợp đồng, cung cấp, có thể, những cách khác nhau

để đáp ứng nhu cầu của tổ chức khách hàng Khi hợp đồng

đã được ký kết, nhà thầu phải soạn thảo một định nghĩa hệ thống cho khách hàng chi tiết hơn để khách hàng hiểu và có thể xác nhận điều mà phần mềm sẽ làm Cả hai tài liệu này đều có thể được gọi là tài liệu yêu cầu (requirements document) cho hệ thống ”

Kiểu yêu cầu

(Types of requirement)

9

 Yêu cầu người dùng

 Những phát biểu bằng ngôn ngữ tự nhiên cộng với sơ đồ (diagram) về những dịch vụ hệ thống cung cấp và những rằng buộc vận hành của nó Được viết cho khách hàng.

 Yêu cầu hệ thống

 Một tài liệu có cấu trúc đưa ra những mô tả chi tiết về chức năng hệ thống, dịch vụ và rằng buộc vận hành Định nghĩa những gì nên được thực thi, có thể là một phần trong hợp đồng giữa khách hàng (client) và nhà thầu (contractor)

Định nghĩa và Đặc tả

(Definitions and Specifications)

10

 Định nghĩa yêu cầu người dùng

1 Phần mềm phải cung cấp một cách thức để biểu diễn và truy cập

những tệp bên ngoài được tạo bởi những công cụ khác

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

1 Người dùng nên được cung cấp các phương tiện (facilities) để

định nghĩa kiểu của những tệp tin ngoài (external files)

2 Mỗi kiểu tệp tin ngoài nên có một công cụ đi kèm có thể áp dụng

cho kiểu tệp tin đó

3 Mỗi kiểu tệp tin ngoài nên được biểu diễn bằng một biểu tượng

cụ thể (specific icon) trên màn hình của người dùng

4 Các phương tiện nên được cung cấp cho biểu tượng biểu diễn

một kiểu tệp tin ngoài được định nghĩa bởi người dùng

5 Khi người dùng chọn một biểu tượng biểu diễn tệp tin ngoài, hiệu

ứng của việc lựa chọn đó là sử dụng công cụ liên kết với kiểu tệp ngoài đó cho tệp tin được biểu diễn bởi công cụ lựa chọn

Người đọc của yêu cầu

(Requirements readers)

11

Yêu cầu người dùng

(User requirements)

• Nhà quản lý phía khách hàng (Client managers)

• Người dùng cuối của hệ thống (System end-users)

• Kỹ sư phía khách hàng (Client engineers)

• Nhà quản lý phía nhà thầu (Contractor managers)

• Kỹ sư hệ thống (System architects)

Yêu cầu hệ thống

(System requirements)

• Người dùng cuối của hệ thống (System end-users)

• Kỹ sư phía khách hàng (Client engineers)

• Kỹ sư hệ thống (System architects)

• Lập trình viên phần mềm (Software developers)

Đặc tả thiết kế phần

mềm (Software design

specification)

• Kỹ sư phía khách hàng (Client engineers) [có thể]

• Kỹ sư hệ thống (System architects)

• Lập trình viên phần mềm (Software developers)

Những yêu cầu chức năng và phi chức năng

(Functional and non-functional requirements)

12

 Yêu cầu chức năng (Functional requirements)

 Những tuyên bố (statements) về dịch vụ hệ thống nên cung cấp, cách hệ thống nên phản ứng với những đầu vào cụ thể và cách hệ thống nên hành xử trong những tình huống cụ thể

 Yêu cầu phi chức năng (Non-functional requirements)

 Những rằng buộc trên những dịch vụ hoặc chức năng được cung cấp bởi hệ thống như rằng buộc về thời gian, rằng buộc

về tiến trình phát triển, về các chuẩn, …

 Yêu cầu miền (Domain requirements)

 Những yêu cầu đến từ miền ứng dụng của hệ thống và phản ánh các đặc tính của miền đó

Những yêu cầu chức năng

(Functional requirements)

13

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

 Phụ thuộc vào kiểu phần mềm, người dùng mong muốn

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

 Những yêu cầu chức năng người dùng có thể là nhữngtuyên bố (statements) ở mức cao về điều mà hệ thốngnên làm

 Những yêu cầu chức năng hệ thống nên miêu tả chi tiếtdịch vụ hệ thống

 Người dùng có thể tìm kiếm, tải về hoặc in những bàibáo này cho mục đích học tập cá nhân

Ví dụ về yêu cầu chức năng của LIBSYS

15

 Người dùng sẽ có thể tìm kiếm hoặc tất cả các bộ cơ

sở dữ liệu ban đầu hoặc chỉ chọn một tập con

 Hệ thống sẽ cung cấp chế độ hiển thị (viewer) thích hợpcho người dùng để đọc tài liệu trong kho tài liệu

 Mỗi đơn hàng sẽ được cấp một số nhận dạng duy nhất(ORDER_ID) mà người dùng sẽ có thể sử dụng để saochép vào khu vực lưu trữ dài hạn (permanent) của tàikhoản đó

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

(Requirement imprecision)

16

 Nhiều vấn đề phát sinh khi những yêu cầu không đượcphát biểu chính xác

 Những yêu cầu không rõ ràng (ambiguous requirements)

có thể được diễn dịch theo những cách khác nhau bởingười phát triển và người dùng

 Hãy xem xét thuật ngữ “chế độ hiển thị thích hợp”(appropriate viewers)

 Về phía người dùng (user intention) – chế độ hiển thị với mục đích đặc biệt cho từng kiểu tài liệu khác nhau

 Theo diễn dịch của người phát triển (developer interpretation) – cung cấp một trình xem văn bản (text viewer) để hiển thị nội dung của tài liệu

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

(Requirements completeness & consistency)

17

 Về nguyên tắc, những yêu cầu nên phải hoàn thiện vànhất quán

 Hoàn thiện (complete)

 Chúng nên bao gồm miêu tả về tất cả các phương tiện cần thiết

 Nhất quán (consistent)

 Không nên có xung đột (conflicts) hoặc mâu thuẫn (contradictions) trong những miêu tả về phương tiện hệ thống

 Trên thực tế, không thể tạo ra một tài liệu yêu cầu hoànthiện và nhất quán

Những yêu cầu phi chức năng

(Non-functional requirements)

18

 Những yêu cầu này định nghĩa những thuộc tính và rằngbuộc, ví dụ: độ tin cậy, thời gian phản ứng, yêu cầu lưutrữ Những rằng buộc là khả năng thiết bị vào/ra (I/O),những biểu diễn hệ thống, …

 Những yêu cầu tiến trình cũng có thể được xác địnhbằng cách ủy nhiệm (mandate) một hệ thống CASE, ngônngữ lập trình hoặc phương pháp phát triển cụ thể

 Những yêu cầu phi chức năng có thể quan trọng hơnnhững yêu cầu chức năng Nếu những yêu cầu này khôngđược đáp ứng, hệ thống sẽ là vô dụng (useless)

Những phân loại phi chức năng

(Non-functional classifications)

19

 Những yêu cầu sản phẩm (product requirements)

 Những yêu cầu xác định rằng sản phẩm được phân phối phải hoạt động theo một cách cụ thể, ví dụ: tốc độ chạy (execution speed),độ tin cậy (reliability),v.v.

 Những yêu cầu tổ chức (organizational requirements)

 Những yêu cầu là hệ quả của những chính sách (policies) và thủ tục (procedures) tổ chức, ví dụ: những tiêu chuẩn quy trình được sử dụng, những yêu cầu thực thi (implementation), v.v.

 Những yêu cầu bên ngoài (external requirements)

 Những yêu cầu phát sinh từ những yếu tố bên ngoài hệ thống

và tiến trình phát triển của nó, ví dụ: yêu cầu về khả năng tương tác (interoperability),yêu cầu pháp lý (legislative),v.v.

Những kiểu yêu cầu phi chức năng (Non-functional requirement types)

20

Ví dụ về Yêu cầu phi chức năng

(Non-functional requirements examples)

21

 Yêu cầu sản phẩm (product requirement)

 8.1 Giao diện người dùng cho LIBSYS sẽ được triển khai dưới dạng HTML đơn thuần mà không có frame hoặc Java applet

 Yêu cầu tổ chức (organizational requirement)

 9.3.2 Tiến trình phát triển hệ thống và những tài liệu chuyển giao (deliverable documents) phải phù hợp với tiến trình và sản phẩm được định nghĩa trong XYZCo-SP-STAN-95.

 Yêu cầu bên ngoài (external requirement)

 7.6.5 Hệ thống sẽ không tiết lộ bất kỳ thông tin về khách hàng ngoài tên và số tham chiếu của họ cho người vận hành

hệ thống

Mục tiêu và Yêu cầu

(Goals and Requirements)

 Yêu cầu phi chức năng có thể xác thực

 Một phát biểu sử dụng một vài đại lượng đo mà có thể được kiểm tra một cách khách quan

 Những mục tiêu là hữu ích cho các nhà phát triển dochúng truyền đạt ý định của người dùng hệ thống

 Một yêu cầu phi chức năng có thể xác thực

 Những người điều khiển có kinh nghiệm (experienced controllers) sẽ có thể sử dụng tất cả chức năng hệ thống sau

2 giờ huấn luyện Sau thời gian huấn luyện này, số lượng trung bình lỗi được tạo ra bởi người dùng kinh nghiệm sẽ không quá 2 lỗi một ngày.

Những số đo cho Yêu cầu

(Requirements measures)

24

Thuộc tính (property) Số đo (measure)

Tốc độ (speed)

Số giao dịch được xử lý / giây

Số người dùng / thời gian đáp ứng sự kiện Thời gian làm tươi màn hình

Số lượng ROM chips Tính dễ sử dụng

(ease of use)

Thời gian huấn luyện

Số lượng khung trợ giúp

Độ tin cậy (reliability)

Thời gian trung bình mà hệ thống lỗi (failure) Xác suất của trạng thái không sẵn sàng (unavailability)

Tỷ lệ xuất hiện lỗi (failure occurrence) Tính sẵn sàng (availability)

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

(Requirements interaction)

25

 Xung đột giữa những yêu cầu phi chức năng là phổ biếntrong những hệ thống phức tạp

 Hệ thống tàu vũ trụ (spacecraft system)

 Tối giản hóa trọng lượng, số lượng vi xử lý (chip) trong hệ thống nên được tối giản hóa

 Tối giản hóa việc tiêu thụ điện năng (power consumption), những vi xử lý tiêu thụ điện năng thấp nên được sử dụng

 Tuy nhiên, sử dụng vi xử lý điện năng thấp nghĩa là phải sử dụng số lượng nhiều hơn Đâu là yêu cầu quan trọng nhất?

Yêu cầu miền

(Domain requirements)

26

 Xuất phát từ ứng dụng miền và miêu tả những đặc điểm

và tính năng của hệ thống mà phản ánh miền

 Yêu cầu miền là yêu cầu chức năng mới, là những rằngbuộc trên những yêu cầu hiện có hoặc định nghĩa nhữngtính toán cụ thể

 Nếu những yêu cầu miền không được thỏa mãn, hệthống có thể không hoạt động (unworkable)

Yêu cầu miền của hệ thống thư viện

(Library system domain requirements)

27

 Sẽ có một giao diện người dùng chuẩn cho tất cả cơ sở

dữ liệu, mà sẽ dựa trên chuẩn Z39.50

 Do những hạn chế về bản quyền (copyright), một số tàiliệu phải bị xóa ngay khi đến Tùy thuộc vào yêu cầu củangười dùng, những tài liệu này

 hoặc sẽ được in cục bộ trên máy chủ hệ thống để chuyển tiếp một cách thủ công đến người dùng

 hoặc được định tuyến đến một máy in trên mạng

Những vấn đề của Yêu cầu miền

(Domain requirements problems)

Yêu cầu người dùng

(User requirements)

29

 Nên miêu tả những yêu cầu chức năng và phi chức năngtheo một cách mà chúng có thể được hiểu bởi ngườidùng hệ thống, những người không có kiến thức kỹthuật chi tiết

 Những yêu cầu người dùng được định nghĩa sử dụngngôn ngữ tự nhiên, các bảng và biểu đồ mà có thể đượchiểu bởi tất cả người dùng

Những vấn đề với ngôn ngữ tự nhiên

(Problems with natural language)

30

 Thiếu tính minh bạch (lack of clarity)

 Sự chính xác là khó mà không làm cho tài liệu trở nên khó đọc

 Sự nhầm lẫn yêu cầu (requirements confusion)

 Những yêu cầu chức năng và phi chức năng có xu hướng bị phân biệt nhầm lẫn

 Sự hợp nhất yêu cầu (requirements amalgamation)

 Nhiều yêu cầu khác nhau có thể được diễn đạt cùng nhau

Yêu cầu cho LIBSYS

(LIBSYS requirement)

31

 4.5 LIBSYS sẽ cung cấp một hệ thống kế toán tài chính

để duy trì hồ sơ của tất cả các khoản thanh toán đượcthực hiện bởi người dùng hệ thống

 Người quản lý hệ thống có thể cấu hình hệ thống saocho người dùng thông thường có thể nhận được tỷ lệchiết khấu (discounted rates)

Yêu cầu cho lưới trình soạn thảo

(Editor grid requirement)

32

 2.6 Những tính năng của lưới (grid facilities): để hỗ trợđịnh vị các thực thể (entities) trên một sơ đồ, ngườidùng có thể bật lên một lưới theo hoặc centimet hoặcinch Ban đầu, lưới này bị tắt đi Lưới có thể được bậtlên hoặc tắt đi bất kỳ lúc nào trong quá trình soạn thảo

và có thể được chuyển đổi giữa cm và inch bất kỳ lúcnào Một lựa chọn lưới sẽ được cung cấp trên mộtkhung nhìn nhỏ vừa (reduce-to-fit view) nhưng số lượngdòng hiển thị của lưới sẽ được giảm xuống để tránh làmđầy sơ đồ nhỏ hơn bởi những dòng này

Phân tích vấn đề của 2 yêu cầu vừa nêu

 Yêu cầu lưới trộn lẫn 3 kiểu yêu cầu khác nhau

 Yêu cầu chức năng mức khái niệm (sự cần thiết của một lưới trong soạn thảo)

 Yêu cầu phi chức năng (những đơn vị của lưới: cm, inch)

 Yêu cầu UI phi chức năng (sự chuyển đổi của lưới)

Một trình bày có cấu trúc

(Structured presentation)

34

2.6.1 Những tính năng của lưới

Trình soạn thảo sẽ cung cấp một tính năng lưới, là một ma trận những dòng ngang và dọc cung cấp một nền (background) cho cửa sổ trình soạn thảo Đây là

một lưới thụ động nơi mà sự sắp hàng của những thực thể là trách nhiệm của người sử dụng

Lý do cơ sở (rationale): Một lưới giúp người sử dụng tạo một

sơ đồ gọn gàng với các thực thể được sắp khoảng cách tốt Mặc dù một lưới chủ động, nơi các thực thể đính vào (snap- to) các đường của lưới, có thể hữu ích, việc sắp vị trí này có thể không chính xác Người sử dụng là người tốt nhất để quyết định vị trí của những thực thể

Đặc điểm kỹ thuật (specification): ECLIPSE / WS / Tools / DE /

FS Mục 5.6

Nguồn (source): Ray Wilson,Văn phòng Glasgow

Hướng dẫn viết yêu cầu

(Guidelines for writing requirements)

35

 Hãy phát minh ra một định dạng chuẩn và sử dụng

nó cho tất cả các yêu cầu

 Sử dụng ngôn ngữ một cách nhất quán Sử dụng cho cácyêu cầu bắt buộc (mandatory requirements), nên sửdụng cho các yêu cầu mong muốn (desirablerequirements)

 Sử dụng văn bản được làm nổi bật để xác địnhnhững phần quan trọng của yêu cầu

 Tránh sử dụng thuật ngữ máy tính (computer jargon)

 Chúng được dự định là một cơ sở để thiết kế hệthống

 Chúng có thể được đưa vào hợp đồng hệ thống

 Yêu cầu hệ thống có thể được định nghĩa hoặc minhhoạ sử dụng mô hình hệ thống (system models)

Phân biệt: Yêu cầu và Thiết kế

(Requirements and Design)

37

 Về nguyên tắc, yêu cầu nên phát biểu về CÁI (what) mà

hệ thống nên làm, còn thiết kế nên miêu tả CÁCH (how)

hệ thống làm điều đó

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

 Một kiến trúc hệ thống có thể được thiết kế để cấu trúc các yêu cầu;

 Hệ thống có thể liên kết với các hệ thống khác để tạo ra yêu cầu thiết kế;

 Việc sử dụng một thiết kế cụ thể có thể là một yêu cầu miền.

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

(Problems with NL specification)

38

 Sự mơ hồ (Ambiguity)

 Người đọc và người viết yêu cầu phải phiên dịch những

từ giống nhau theo cùng một cách Ngôn ngữ tự nhiên là không rõ ràng vì vậy điều này rất khó khăn.

 Quá linh hoạt (Over-flexibility)

 Điều tương tự có thể được nói bằng một số cách khác nhau trong đặc tả.

 Thiếu tính mô-đun hóa

 Cơ cấu ngôn ngữ tự nhiên không phù hợp để cấu trúc những yêu cầu hệ thống

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

Ký hiệu đồ

hoạ

Một ngôn ngữ đồ họa, bổ sung bằng các chú thích văn bản, được sử dụng để định nghĩa các yêu cầu chức năng cho hệ thống Một ví dụ ban đầu của một ngôn ngữ đồ họa như thế là SADT Bây giờ, những mô tả use-case sử dụng và biểu đồ trình tự thường được sử dụng.

Đặc tả toán

học

Đây là những ký hiệu dựa trên các khái niệm toán học như các máy hoặc tập hữu hạn trạng thái Những đặc tả rõ ràng này làm giảm các tham số giữa khách hàng và nhà thầu về chức năng của hệ thống Tuy nhiên, hầu hết khách hàng không hiểu những đặc tả hình thức và miễn cưỡng chấp nhận nó như một hợp đồng hệ thống.

Đặc tả ngôn ngữ được cấu trúc

(Structured language specifications)

40

 Sự tự do của người viết yêu cầu bị giới hạn bởi mộtkhuôn mẫu được định nghĩa trước cho các yêu cầu

 Tất cả các yêu cầu được viết theo một cách chuẩn

 Thuật ngữ (terminology) sử dụng trong mô tả có thể bịhạn chế

 Ưu điểm là hầu hết các biểu cảm của ngôn ngữ tựnhiên được duy trì nhưng một mức độ đồng nhất bịbắt buộc trong đặc tả