Kỹ thuật yêu cầu

Kỹ thuật yêu cầu

Chương 3

Kỹ thuật yêu cầu ( R equirement E ngineering)

1 Kỹ thuật yêu cầu là gì

(Requirement Engineering)

• Ta dùng R equirement E ngineering thay cho R equirement Analysis

• RE là quá trình lặp bao gồm 3 hoạt động:

– Rút ra yêu cầu từ thực tế (Elicitation)

– Đặc tả yêu cầu (Specification)

– Xác thực (Validation)

• Kết quả của quá trình RE là những đặc tả về hệ thống phần mềm

2 Yêu cầu (Requirement ) là gì?

Requirements described the “what” of a system,

not the “how”

Mô tả cái gì cần cho hệ thống

Yêu cầu phần mềm

• Phản ánh sự hiểu biết lẫn nhau về vấn đề giữa người phân tích

và khách hàng

• Nền tảng để xây dựng hợp đồng

• Là sự chuẩn bị cho giai đoạn tiếp theo (giai đoạn phân tích)

• Là tài liệu để kiểm tra hệ thống khi được phát hành

Input/ Output của xác định yêu cầu

Mức độ mô tả yêu cầu

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

– Chủ yếu dành cho người dùng

– Viết bằng ngôn ngữ tự nhiên và biểu đồ

– Mô tả dịch vụ và ràng buộc hoạt động

• Yêu cầu hệ thống:

– Tài liệu có cấu trúc mô tả chức năng, dịch vụ và ràng buộc hoạt động của hệ thống

– Có thể là một phần của hợp đồng

Người đọc

3 Các loại yêu cầu hệ thống

• Các yêu cầu của hệ thống phần mềm thường được chia thành ba loại:

– Yêu cầu chức năng

– Yêu cầu phi chức năng

• Thực tế khó phân biệt ba loại yêu cầu này một cách rõ ràng

Yêu cầu chức năng

• Yêu cầu chức năng mô tả hệ thống sẽ làm gì Nó mô tả các

chức năng hoặc các dịch vụ của hệ thống một cách chi tiết

• Đặc điểm của yêu cầu chức năng:

– Tính mập mờ, không rõ ràng của các yêu cầu:

• Vấn đề này xảy ra khi các yêu cầu không được xác định một cách cẩn thận

– Tính hoàn thiện và nhất quán:

• Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết

và không có sự xung đột hoặc đối ngược giữa các yêu cầu

Ví dụ

• Trong hệ thống quản lý thư viện:

– Người dùng được cấp tài khoản riêng

– Người dùng có thể tìm kiếm; download; in các bài báo

– Người dùng có thể được cấp một vùng riêng để lưu dữ liệu

Yêu cầu phi chức năng

• Yêu cầu phi chức năng không đề cập trực tiếp tới các chức

năng cụ thể của hệ thống

• Yêu cầu phi chức năng thường định nghĩa các thuộc tính như:

– độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ …

– các ràng buộc của hệ thống (khả năng của thiết bị vào/ra, giao diện …)

• Một số yêu cầu phi chức năng còn có liên quan đến quy trình

xây dựng hệ thống (các chuẩn được sử dụng, các công cụ

CASE, ngôn ngữ lập trình …)

• Các yêu cầu phi chức năng có thể hạn chế những yêu cầu chức năng Nhưng nếu nó không được thoả mãn thì hệ thống sẽ

không sử dụng được

3 yêu cầu phi chức năng cơ bản

– Cơ cấu tổ chức; Chính sách của tổ chức

– Thời gian bàn giao

– Tương thích với hệ thống cũ

• Yêu cầu ngoài:

– Do các tác nhân ngoài hệ thống

– Tính pháp lý

Lý do xuất hiện yêu cầu phi chức năng

• Yêu cầu của người sử dụng

• Ràng buộc về ngân sách

• Các chính sách của tổ chức sử dụng hệ thống

• Yêu cầu tương thích giữa phần cứng và phần mềm

• Các tác nhân ngoài khác

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

• Xác định các yêu cầu phi chức năng của Hệ thống đặt vé tàu trước

– Yêu cầu về sản phẩm: phải xây dựng website

– Yêu cầu về mặt tổ chức: mạng máy tính nối tất cả các trạm

xe lửa với nhau

– Yêu cầu ngoài: Hệ thống phải bảo mật

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

• Các mục tiêu và yêu cầu phi chức năng có thể thẩm định được của Hệ thống đặt vé tàu trước

– Mục tiêu của hệ thống là dễ sử dụng đối với nhân viên cũng như hành khách và được tổ chức để sao cho tối thiểu hoá được lỗi

– Các yêu cầu phi chức năng có thể thẩm định được: Những người nhân viên sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi người sử dụng là không quá hai lỗi một ngày

Yêu cầu miền ứng dụng

• Yêu cầu miền ứng dụng được xác định từ miền ứng dụng của

hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng dụng

• Nó có thể là yêu cầu chức năng hoặc phi chức năng

• Nếu yêu cầu miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được

• Một số vấn đề liên quan đến yêu cầu miền ứng dụng:

– Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng

– Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng

họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật

Một số ràng buộc

• Ràng buộc trước sau

• Ràng buộc cấu trúc

• Ràng buộc suy diễn

• Ràng buộc thời gian

Môn học loại cơ sở phải học trước môn học loại chuyên ngành

Điểm giữa kỳ <4 thì thi lại, nếu thi lại <4 thì học lại, nếu >=4 thì

được thi cuối kỳ

Dựa vào luậtLương kỳ 1 phải trả trước ngày 5 hàng tháng

Khi người dùng nhấn Enter thì chỉ trong 2 giây thì hệ thống phải

4 Quy trình RE

• Thu thập yêu cầu (Requirement Elicitation)

• Phân tích yêu cầu (Requirement Analysis)

• Tạo tài liệu đặc tả yêu cầu (Requirement Documentation)

• Đánh giá yêu cầu (Requirement Review)

Bước 1: Thu thập yêu cầu

Nội dung cần thu thập

• Đánh giá tính khả thi về nghiệp vụ và kỹ thuật của hệ thống

• Nhận biết xem ai sẽ giúp xác định yêu cầu và hiểu biết thực chất của tổ chức

– Operation manager, product manager

– Makerting people

– Internal/external customer

– End-users

– Consultant

– Product engineer, Software engineer

• Xác định môi trường kỹ thuật

• Nhận biết các ràng buộc nghiệp vụ (domain constraint)

Những khó khăn thường gặp

1 Khó khăn về phạm vi (Problems of scope): đường biên hệ

thống thường mập mờ, hay khách hàng chỉ nhắm đến các yếu tố

kỹ thuật hơn là mục tiêu tổng thể của hệ thống

2 Khó khăn về hiểu biết khách hàng: khách hàng không biết họ cần gì, có ý kiến trái ngược nhau về hệ thống cần xây dựng, ít hiểu biết về kỹ thuật, thời gian giao tiếp với kỹ sư hệ thống

thường rất hạn chế

3 Khó khăn về tính ổn định: yêu cầu thường thay đổi theo thời gian

Các kỹ thuật thu thập yêu cầu

• Các kỹ thuật thu thập yêu cầu:

– Phỏng vấn (Interview)

• Chọn lựa stakeholder để phỏng vấn – Phiếu điều tra (questionnaire)

– Thu thập tài liệu : biểu mẫu, báo cáo, thống kê, số liệu,…

– Phiên họp động não ( brainstorm session): kỹ thuật thảo luận nhóm giúp tìm ra nhanh chóng những ý tưởng mới

– Sử dụng kịch bản (scenario) để phát hiện các yêu cầu của hệ thống.

• Tạo các kịch bản (scenario) để giúp khách hàng/người dùng xác định tốt hơn các yêu cầu chính của hệ thống

• Một tập hợp các use case sẽ mô tả tất cả các tương tác có thể trong hệ thống.

Bước 2: Phân tích yêu cầu

• Các bước phân tích yêu cầu theo hướng dòng dữ liệu

• Nội dung chính của RSC

Mục đích

• Phân tích yêu cầu nhằm phân loại và tổ chức các yêu cầu thành các tập con có liên quan nhau

• Xếp loại các yêu cầu theo nhu cầu của người dùng

• Tổng hợp, điều chỉnh yêu cầu theo hướng tổng quan nhất

• Chỉ ra được hệ thống làm việc gì, làm với dữ liệu nào

Nguyên lý phân tích

• Nguyên lý 1: Miền dữ liệu

– Xác định đối tượng dữ liệu

– Mô tả thuộc tính dữ liệu

– Thiết lập quan hệ dữ liệu

• Nguyên lý 2: Miền chức năng

– Xác định chức năng biến đổi dữ liệu

– Chỉ ra luồng dữ liệu trong hệ thống

– Biểu diễn chức năng, luồng dữ liệu, kho dữ liệu

• Nguyên lý 3: Xác định các trạng thái

– Chỉ ra những trạng thái của hệ thống

– Chỉ ra những sự kiện gây biến đối trạng thái

• Nguyên lý 4: Phân tách mô hình

– Tinh chế đối tượng, dữ liệu

– Tạo hệ thống ở cấp bậc chức năng

– Biểu diễn hành vi ở mức chi tiết

• Nguyên lý 5: Sự thiết yếu

– Chú trọng vấn đề thiết yếu

– Loại bỏ những vấn đề chi tiết

Nguyên lý davis

• Hiểu vấn đề trước khi tạo mô hình phân tích

• Tạo bản mẫu (prototype) cho phép người dùng hiểu được tương tác giữa người và máy

• Ghi nhận nguồn gốc và lý do của mỗi yêu cầu

• Dùng nhiều khung nhìn

• Phân loại mức độ ưu tiên của yêu cầu

• Loại bỏ những sự mơ hồ

Hướng phân tích

• Phân tích hướng cấu trúc

– Dữ liệu, quá trình biến đổi dữ liệu

– Sử dụng các biểu đồ: chức năng, DFD, ERD, RDM, chuẩn hóa dữ liệu, từ điển dữ liệu

• Phân tích hướng đối tượng

– Tập trung vào đối tượng, sự tương tác giữa các đối tượng– Sử dụng UML

Flow-oriented Element Data Flow Diagram Control-Flow diagram

Behavioral Element State diagram Sequence diagram

Behavioral Element State diagram Sequence diagram

Use case diagram

• Là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể

• Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội

bộ bên trong hệ thống

• Use case bao gồm:

– Actor (tác nhân)

– Use case (hành động)

Ví dụ

Data Flow diagram

• Flow-oriented modeling vẫn là 1 trong những cách thông dụng nhất hiện nay để phân tích hệ thống Tên gọi khác lược đồ dòng dữ liệu (Data Flow Diagram – DFD)

• DFD dùng để mô hình hóa các yêu cầu hệ thống

• DFD biểu diễn các bước mà luồng dữ liệu phải trải qua trong hệ thống từ điểm đầu tới điểm cuối.

• DFD mô hình hoá hệ thống từ góc độ một chức năng Việc tìm vết và tư liệu hoá quan hệ giữa dữ liệu với một quy trình rất có ích đối với việc tìm hiểu toàn bộ hệ thống.

Ví dụ

State diagram

• Tất cả các đối tượng đều có trạng thái;

• Tạng thái là một kết quả của các hoạt động trước đó đã được đối tượng thực hiện và nó thường được xác định qua giá trị của các thuộc tính cũng như các nối kết của đối tượng với các đối tượng khác

• Một lớp có thể có một thuộc tính đặc biệt xác định trạng thái, hoặc trạng thái cũng có thể được xác định qua giá trị của các thuộc tính “bình thường" trong đối tượng

• Một đối tượng sẽ thay đổi trạng thái khi có một việc nào đó xảy

ra, thứ được gọi là sự kiện;

• Miêu tả một đối tượng có thể có những trạng thái nào trong hệ thống

Ví dụ

Ví dụ

Ví dụ

Mô hình hóa dữ liệu (Data Modeling)

• Mô hình dữ liệu gồm 3 thành phần chính:

– Đối tượng dữ liệu (Data object)

– Thuộc tính (attribute): mô tả đối tượng dữ liệu

– Mối liên hệ (relationship) giữa các đối tượng dữ liệu

Mô hình hóa dữ liệu (Data Modeling)

• Lược đồ Entity-Relationship (ERD)

• Lược đồ Relational Data Model (RDM)

• Chuẩn hóa dữ liệu

• Từ điển dữ liệu

Các bước phân tích yêu cầu theo hướng

dòng dữ liệu (Flow oriented)

Develop Prototypes (optional)

Model the requirements

Model the requirements

Finalise the

Finalise the requirements

Phát triển prototype (Development of protoype)

• Xây dựng prototype tương tự như hệ thống cần xây dựng,

khách hàng sẽ xem xét cho cho ý kiến phản hồi, prototype sẽ liên tục được điều chỉnh để thỏa mãn yêu cầu khách hàng

• Prototype là cách giúp tìm hiểu hiệu quả mong muốn thực sự của khách hàng

• Prototype thường được xây dựng nhanh, chi phí thấp, nên sẽ có nhiều hạn chế và thiếu xót so với hệ thống cuối  Prototype chỉ là 1 tùy chọn (optional)

Nội dung chính của SRS

1 Functionality: phần mềm được dùng để làm gì?

2 External interfaces: phần mềm giao diện với người dùng như

thế nào? Với phần cứng và các phần mềm khác ra sao?

3 Performance: tốc độ, thời gian đáp ứng, thờigian hồi phục,…

của mỗi chức năng phần mềm thế nào?

4 Attributes: khả năng bảo trì, độ chính xác, độ tin cậy, khả năng

bảo mật, …

5 Design constraints: Phần mềm bị ràng buộc bởi các tiêu chuẩn

nào? Ngôn ngữ thực thi, chính sách bảo toàn cSDL, hạn chế về tài nguyên, hệ điều hành sử dụng,…

Yêu cầu của SRS

1 Nên xác định đúng tất cả yêu cầu phần mềm

2 Không nên mô tả bất kỳ chi tiết nào liên quan đến thiết kế hay

thực thi

3 Không nên đưa các ràng buộc dư thừa vào SRS Một số ràng

buộc về chất lượng nên đưa vào kế hoạch bảo đảm chất lượng phần mềm

Nghiên cứu tính thực thi

Feasibility study

• Feasibility study là 1 bước quan trọng trong bất kỳ quy trình phát triển phần mềm nào Nghiên cứu này nhằm phân tích chi phí (cost), thời gian (time) cần thực hiện trong mỗi giai đoạn

• Feasibility study là một trong các kết quả của phân tích yêu cầu phần mềm

Thuận lợi của feasibility study

• Được xem như bước khởi đầu của chu kỳ phát triển

phần mềm (SDLC) dùng để phân tích toàn diện các yêu cầu của hệ thống

• Giúp nhận biết các thừa số rủi ro (risk factor) ảnh hưởng đến việc phát triển và triển khai hệ thống.

• Là cơ sở để phân tích chi phí/lợi nhuận của hệ thống

• Giúp lập kế hoạch đào tạo đội ngũ phát triển hệ thống.

• Là báo cáo giúp ban lãnh đạo dựa vào đó ra quyết định

Bước 3: Đặc tả yêu cầu(Requirement Documentation)

• Tạo tư liệu về yêu cầu (requirement documentation) là một hoạt động rất quan trọng sau khi thu thập và phân tích yêu cầu hệ thống Đây là cách để biểu diễn yêu cầu theo một định dạng

• Đặc tả yêu cầu bằng ngôn ngữ cấu trúc

– Tuân thủ các chuẩn về từ ngữ, về cấu trúc

– Duy trì ngôn ngữ tự nhiên

• Đặc tả bằng biểu mẫu

• Đặc tả dạng bảng

• Đặc tả theo ngôn ngữ PDL (Program Design Language)

• Đặc tả theo mô hình

Bước 4: Đánh giá yêu cầu

Kỹ thuật đánh giá yêu cầu

• Kiểm tra yêu cầu

Ước tính quy mô dự án

• Là bước quan trọng khi bắt đầu dự án

• Rất khó để ước tính phạm vi của 1 hệ thống phần mềm vì:

– Phần mềm là sản phẩm trừu tượng

– Xây nhà, cầu đường là sản phẩm cụ thể, có thể nhìn thấy và

sờ mó được

• Hai phương pháp thông dụng:

– Tính số dòng lệnh (Lines Of Code – LOC)

– Tính Function Point (FP)

Lines Of Code (LOC)

• Chưa có sự thống nhất trong quy ước đếm LOC

• Trước đây: không tính đến các dòng khai báo dữ liệu, chú thích,

• Gần đây: tính cả dòng khai báo, chú thích

• Lý do: chương trình mới chứa hơn 50% dòng dữ liệu, và các

dòng này cũng thường xuyên gây lỗi như các dòng lệnh thông thường

3 int i,j, save, im1;

4 /* this function sorts array x

Lines Of Code (LOC)

• LOC của chương trình? 17, 18 hay 13

• Theo định nghĩa của Conte: Dòng mã là bất kỳ dòng nào (tiêu

đề, khai báo, lệnh khả thi và không khả thi) trong chương trình, không kể dòng chú thích (comment), bất kể có bao nhiêu dòng

mã hay khối mã trên cùng 1 dòng”

• LOC của chương trình là 17

Lines Of Code (LOC)

• Ưu điểm: đơn giản, cụ thể

• Nhược điểm:

– Phụ thuộc vào ngôn ngữ, không chỉ ra được tổng thể dự án– Đếm dòng lệnh tương tự như đếm số gạch để xây nhà cao tầng, chỉ cho biết số gạch cần dùng nhưng không chỉ ra được số phòng, tổng diện tích xây dựng, tổng diện tích đất,

…

• Ứng dụng: dùng LOC để ước tính thời gian lập trình

– Người dùng chỉ quan tâm đến việc mua phần mềm kế toán,

mà không cần quan tâm đến nó chứa bao nhiêu dòng lệnh, viết bằng ngôn ngữ nào

– Internal logical files

– External interface files

Tính Function Point (FP)

• Các đơn vị chức năng được phân loại dựa vào độ phức tạp: Low, Average, High

Low Average High

Tính Function Point (FP)

• Trình tự tính FP của hệ thống:

– Phân loại theo năm loại chức năng

– Tính UFP (Unadjusted Function Points) – Tính FP

Tính UFP (Unadjusted Function Points)

i là chỉ số hàng, j là chỉ số cột của bảng 1

wij là giá trị của hàng i cột j bảng 1

Zij là kết quả đếm của loại chức năng i với độ phức tạp tương ứng với cột j

Bảng 2: Các thừa số Fi

1 Does the system require reliable backup and recovery?

2 Is data communication required?

3 Are there distributed processing functions?

4 Is performance critical?

5 Will the system run in an existing heavily utilized oprational

environment?

6 Does the system require on line data entry?

7 Does the on line data entry require the input transaction to be

built over multiple screens or operations?

8 Are the master files updated on line?

9 Is the inputs, outputs, files or inquiries complex?