TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.

HCM

MÔN HỌC
CÔNG NGHỆ PHẦN MỀM

Chương 3
Kỹ thuật yêu cầu RE
(Requirements Engineering)

CNPM/NN 1
 Kỹ thuật yêu cầu RE
1. Yêu cầu
2. Quy trình xác định yêu cầu
2.1 Phân tích khả thi
2.2 Phát hiện và phân tích yêu cầu
 Các kỹ thuật phát hiện yêu cầu
2.3 Đặc tả yêu cầu
2.4 Đánh giá yêu cầu
3. Quản lý yêu cầu

CNPM/NN 2
 1. Yêu cầu (Requirement - IEEE)
 Yêu cầu là gì? (1 hoặc 2)
 Yêu cầu là điều kiện hay khả năng mà người dùng cần
để hoàn thành mục tiêu của mình
 Một điều kiện hay một khả năng mà một hệ thống hay
một thành phần hệ thống đáp ứng hay sở hữu nhằm
thỏa mãn một hợp đồng, một tiêu chuẩn, một đặc tả
hay một tài liệu hình thức cần tuân thủ khác (formally
imposed document)
 Yêu cầu:
 Có những yêu cầu ngầm định (implicit)
 Một yêu cầu có thể được nhận biết (known, spoken)/
không nhận biết (forgotten, unspoken…)
CNPM/NN 3
 Kỹ thuật yêu cầu (Requirements Engineering)?

 Dùng kỹ thuật yêu cầu (Requirements engineering)

thay cho phân tích yêu cầu (Requirement Analysis)
 Nhấn mạnh tới tính cộng tác và lặp lại.
 Tạo tài liệu cho những kết quả khảo sát.
 Kiểm tra.
 Nó còn nhấn mạnh tới vai trò của kinh nghiệm và
tính xã hội.

CNPM/NN 4
CNPM/NN 5
 Sử dụng tài liệu yêu cầu

CNPM/NN 6
 Phân loại yêu cầu
 Có 3 loại yêu cầu:
 Yêu cầu chức năng: chức năng dịch vụ hệ thống cung cấp
 Yêu cầu phi chức năng: những ràng buộc về tiêu chuẩn,
thời gian, qui trình phát triển…, chủ yếu là những yêu cầu
về chất lượng.
 Yêu cầu miền ứng dụng: phản ảnh những đặc trưng của
miền ứng dụng

CNPM/NN 7
 Yêu cầu chức năng
 Yêu cầu chức năng chỉ ra những gì hệ thống làm,
chúng thường quan hệ với những nguồn đặc trưng,
thường là các use-case hay những qui tắc nghiệp vụ
(business rule)
 Một số yêu cầu chức năng
 Chức năng tính toán
 Chức năng lưu trữ
 Chức năng tìm kiếm
 Chức năng kết xuất
 Chức năng backup, restore
 Chức năng đa người dùng
 Chức năng đa phương tiện…

CNPM/NN 8
 Ví dụ

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

 Người dùng có thể tìm kiếm, download những bài báo
 Người dùng được cấp một vùng lưu trữ riêng để có thể
copy để lưu trữ tài liệu lâu dài…

CNPM/NN 9
 Yêu cầu phi chức năng
Non-functional
requir ements

Product Organisational External

requir ements requir ements requir ements

Efficiency Reliability Portability Inter oper ability Ethical

requir ements requir ements requir ements requir ements requir ements

Usability Delivery Implementa tion Standar ds Legislative

requir ements requir ements requir ements requir ements requir ements

Perfor mance Space Privacy Safety

requir ements requir ements requir ements requir ements

CNPM/NN 10
 Yêu cầu phi chức năng
 Một số yêu cầu phi chức năng
 Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ…
 Yêu cầu của người sử dụng: dễ sử dụng, thân thiện
 Phù hợp với các chính sách của tổ chức sử dụng hệ thống:
ngân sách
 Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập
trình…
 Yêu cầu tương thích với hệ thống khác
 Các yêu cầu từ các tác nhân ngoài khác…

CNPM/NN 11
 Phân loại yêu cầu phi chức năng

 Các yêu cầu về sản phẩm: hiệu năng, độ tin cậy…

 Các yêu cầu của tổ chức (khách hàng hay người phát triển):
thời gian bàn giao, yêu cầu phù hợp với hệ thống cũ…
 Các yêu cầu ngoài: được xác định từ các tác nhân từ bên ngoài
như các yêu cầu về luật pháp, yêu cầu tôn trọng tính riêng tư,
tương tác với hệ thống bên ngoài…

CNPM/NN 12
 Yêu cầu phi chức năng
YÊU CẦU CỦA SẢN PHẨM
 MHC-PMS sẽ có sẵn cho tất cả các phòng khám trong giờ làm
việc bình thường (Thứ Hai – Thứ Sáu, 08.30–17.30). Thời gian
ngừng hoạt động trong giờ làm việc bình thường không được
vượt quá năm giây trong một ngày bất kỳ.
YÊU CẦU CỦA TỔ CHỨC
 Người sử dụng hệ thống MHC-PMS sẽ tự xác thực bằng
chứng minh thư của cơ quan y tế.
YÊU CẦU BÊN NGOÀI
 Hệ thống sẽ thực hiện các điều khoản về quyền riêng tư của
bệnh nhân như được nêu trong HStan-03-2006-priv.

CNPM/NN 13
 Yêu cầu miền ứng dụng
 Yêu cầu miền ứng dụng được xác định từ lãnh vực
ứng dụng của hệ thống, nó phản ánh các thuộc tính
và ràng buộc của lãnh vực ứng dụng.
 Nó có thể là yêu cầu chức năng hoặc phi chức năng.
VD:
 Trong hệ thống Quản lý thư viện, do vấn đề bản quyền vài
tài liệu phải được xóa ngay sau khi in

CNPM/NN 14
 Dư thừa thông tin,
rối rắm cho người sử dụng.
 Nguồn yêu cầu
 Time to market
 Function
 Time to fill orders
 Performance
 Inventory turns
 Cost
 Accident reports
 Schedule
 Effects of aging
 Risk
 User friendly
 Interface
 Security, as in
 Service and government
maintenance classification
 Need to provide  Security, as in data
training transmission
 Competitive strategic  Culture might
advantage require foreign
languages… 16
CNPM/NN
 Plan-driven && Agile

CNPM/NN 17
 2. Quy trình RE

 Phân tích khả thi (Feasibility analysis)

 Phát hiện yêu cầu (Requirement Elicitation) và
phân tích
 Một số kỹ thuật
 Đặc tả yêu cầu (specification)
 Thẩm định yêu cầu (validation)

CNPM/NN 18
 Quy trình RE

Requir ements
Feasibility elicitation and
stud y anal ysis
Requir ements
specification
Feasibility Requir ements
repor t validation

System
models

User and system

requirements

Requir ements
document

CNPM/NN 19
 2.1. Phân tích khả thi
 Phân tích khả thi cho biết hệ thống với những yêu
cầu xác định có thể thực hiện trong những điều kiện
về kỹ thuật, tài nguyên, ngân sách… Một số vấn đề:
 Hệ thống có đóng góp vào mục tiêu của tổ chức hay
không?
 Hệ thống có thể được xây dựng bằng cách sử dụng công
nghệ hiện tại, trong tiến độ và ngân sách cho phép?
 Hệ thống có được tích hợp với các hệ thống khác đang sử
dụng hay không?...

CNPM/NN 20
 Phân tích khả thi
 Những câu hỏi đặt ra để phân tích
khả thi:
 Vấn đề xử lý hiện tại như thế nào?
 Hệ thống đề nghị cung cấp những
tiện ích gì?
 Nếu hệ thống không được cài đặt
thì sao?
 Hệ thống đề xuất sẽ trợ giúp nghiệp
vụ theo cách thức nào?
 Những rắc rối về việc tích hợp là gì?
 Có cần kỹ thuật mới không?
 Cần có những kỹ năng gì để thực
hiện và sử dụng?

CNPM/NN 21
 2.2. Phát hiện yêu cầu
 Nhân viên kỹ thuật và khách hàng cùng hợp tác để xác định:
các dịch vụ mà hệ thống cung cấp, các ràng buộc vận hành của
hệ thống…
 Nguồn thông tin: tài liệu, stakeholders, đặc tả của hệ thống
tương tự…
 Phải bao gồm những người có liên quan (Stakeholder) là:
 Người sử dụng cuối
 Người quản lý
 Người phụ trách kỹ thuật
 Chuyên gia lĩnh vực…

CNPM/NN 22
 Stakeholder – Vấn đề
 Stakeholder không rõ những gì họ thật sự muốn
 Stakeholder diễn đạt yêu cầu theo những thuật ngữ riêng của
họ
 Những stakeholder có thể có những yêu cầu tranh chấp
 Nhân tố quyền lực và tổ chức ảnh hưởng tới yêu cầu hệ thống
 Những yêu cầu có thể thay đổi trong quá trình phân tích, có
thể xuất hiện những nhân tố mới, những thay đổi về môi
trường nghiệp vụ

CNPM/NN 23
 Nhập nhằng
Requirement:

Create a means to transport a single

individual from home to place of work.

Management IT User
Interpretation Interpretation Interpretation
 Rich Picture

CNPM/NN 25
 Các kỹ thuật thường dùng
 Khung nhìn (Viewpoint)
 Phỏng vấn (Interview)
 Triển khai chức năng chất lượng QFD (Quality Function
Deployment)
 Phiên làm việc Brainstorm

CNPM/NN 26
 Khung nhìn (View - Viewpoint)
 Khung nhìn được dùng trong xác định yêu cầu hệ
thống, nó biểu diễn hệ thống dưới những góc nhìn
khác nhau của các stakeholder
 Các khung nhìn giúp cho việc phân tích yêu cầu
được toàn diện hơn

CNPM/NN 27
 Phân loại khung nhìn
 Khung nhìn tương tác
 Người và những hệ thống khác tương tác trực tiếp với hệ thống
 Khung nhìn gián tiếp
 Những người có thể không dùng hệ thống nhưng ảnh hưởng tới
hệ thống
 Khung nhìn miền
 Những đặc trưng và ràng buộc của miền mà ảnh hưởng tới yên
cầu

CNPM/NN 28
 VD: Khung nhìn trong hệ thống quản lý thư viện

All VPs

Indirect Interactor Domain

Library Article Library UI Classification

Finance Users
manager providers staff standards system

System
Students Staff External Cataloguers
managers

CNPM/NN 29
 Viewpoint

Services are inherited

top-down (common services) All VPs

Services
Query balance
Withdraw cash Customer Bank staff

Services Account Foreign

Teller Manager Engineer
holder customer
Order cheques
Send message
Transaction list
Order statement
Transfer funds
 Phỏng vấn
 Phỏng vấn hình thức (formal) hoặc phi hình thức (informal) là
một trong những phần quan trọng nhất của quy trình xác định
yêu cầu.
 Phỏng vấn được chia thành hai loại:
 Phỏng vấn đóng: tập các câu hỏi đã được định trước và có nhiều
đáp án để stakeholder lựa chọn trả lời.
 Phỏng vấn mở: tất cả các câu hỏi không được định trước và
stakeholder phải tự giải thích và phát biểu theo quan điểm của
mình.

CNPM/NN 31
 Các bước phỏng vấn
 Bước 1: Những câu hỏi căn bản, ngữ cảnh bất kỳ
 Ai là người đưa ra những yêu cầu?
 Ai là người sử dụng giải pháp?
 Giải pháp thành công sẽ mang đến những lợi ích gì?
 Có thể có cách khác để thực hiện giải pháp?
 Bước 2: Nhằm hiểu sâu hơn vấn đề
 Giải pháp tốt sẽ có output như thế nào?
 Những vấn đề của giải pháp cần giải quyết?
 Hãy cho biết môi trường của giải pháp?
 Những vấn đề về thực thi và các ràng buộc ảnh hưởng?

CNPM/NN 32
 Các bước phỏng vấn
 Bước 3: Những câu hỏi về hiệu quả của việc gặp gỡ (meta –
question)
 Bạn là người được quyền trả lời những câu hỏi nhằm xây dựng
giải pháp?
 Câu trả lời của bạn có chính thức không?
 Câu hỏi của tôi có phù hợp với vấn đề mà bạn đang gặp?
 Tôi đã hỏi quá nhiều câu hỏi?
 Những ai có thể cung cấp những thông tin thêm?
 Tôi có nên tham khảo bạn những điều gì khác?

CNPM/NN 33
 Phỏng vấn: đánh giá
Thuận tiện Bất tiện
1. Cho phép người phỏng vấn 1. Tốn thời gian và chi phí
có cơ hội thúc đẩy người 2. Người phỏng vấn phải có
được phỏng vấn nhằm nắm kỹ năng quan hệ
bắt thông tin tốt nhất 3. Vấn đề về địa điểm của
2. Cho phép nhận nhiều hồi người phỏng vấn
đáp có giá trị

CNPM/NN 34
 Định hướng cho phỏng vấn

Nên làm Nên tránh

 Phải nhã nhặn  Tiếp tục một cuộc phỏng vấn
 Lắng nghe không hứa hẹn thành công
 Kiểm soát phiên làm việc  Lộ vẻ lúng túng

Thăm dò  Lộ ra những ý kiến riêng của

 Thu nhận thông tin từ việc

mình
quan sát và những thông tin  Nói thay vì nghe
không bằng lời  Không áp đặt ý kiến chủ
 Kiên nhẫn quan của mình
Tự chủ

 Tạo sự dễ dàng cho buổi

phỏng vấn
CNPM/NN 35
 Triển khai chức năng chất lượng [QFD]
 QFD (Quality Function Deployment ) là một kỹ thuật
quản lý chất lượng mà chuyển những nhu cầu của khách
hàng thành những yêu cầu kỹ thuật cho phần mềm
 QFD tập trung vào việc tối đa sự thỏa mãn của khách
hàng về qui trình kỹ nghệ phần mềm
 QFD nhấn mạnh tới sự hiểu biết những gì là giá trị với
khách hàng và triển khai những giá trị này qua qui trình
kỹ nghệ
 QFD dùng phỏng vấn, quan sát, nghiên cứu và kiểm tra
các dữ liệu trong quá khứ. Áp dụng nhiều biện pháp, đồ
hình, phương pháp đánh giá… (customer voice table)

CNPM/NN 36
 Ba loại yêu cầu
 Yêu cầu thông thường (Normal Requirements): không có thì không đáp
ứng yêu cầu
 Yêu cầu mong đợi (Expected Requirements): có thì sản phẩm tốt hơn
 Yêu cầu kỳ thú (Exciting Requirements): ngay cả khách hàng cũng nghĩ
đến.

CNPM/NN 37
 Nhà chất lượng

CNPM/NN 38
CNPM/NN 39
 Phiên làm việc Brainstorm

 Các phiên giao tiếp này thường được dẫn dắt bởi 1
người điều khiển có kinh nghiệm, mỗi phiên làm việc
thường kéo dài tối đa 1 hay 2 ngày.
 Mục tiêu của phiên làm việc Brainstorm là đưa ra các ý
tưởng mới hay các tính năng của sản phẩm trong 1 thời
gian rất ngắn.

40
 Phiên động não tập thể - Brainstorming
 Mở đầu
 Lịch biểu
 Cho biết những gì được mong đợi
 Mục tiêu
 Đưa ra mục tiêu:
 Sản phẩm hay dich vụ mới
 Đặc trưng mới
 Tên sản phẩm hay các dặc trưng
 Những ý tưởng cải tiến
 Qui trình làm việc mới
 Xác định những yêu cầu và những hạn chế hàng đầu

CNPM/NN 41
 Brainstorming
 Luật
 Không có ý tưởng là ý tưởng tồi
 Phải sáng tạo
 Chấp nhận rủi ro
 Không được phê phán
 Hoạt động
 Tạo ý tưởng
 Làm nóng
 Làm tươi mới đầu óc khi chùng xuống
 Phân chia các nhóm nhỏ
 Ghi nhận các ý tưởng (máy tính)

CNPM/NN 42
 Brainstorming
 Tổng kết
 Kiểm tra lại các ý tưởng
 Chọn các ý tưởng hàng đầu
 Kiểm tra cac yêu cầu và ràng buộc
 Chọn lại còn 5-10 ý tưởng hàng đầu
 Các bước kế tiếp
 Nghiên cứu ý tưởng được tạo
 Mở rộng nhóm lớn hơn
 Đưa ý tưởng vào hiện thực

CNPM/NN 43
 2.3. Đặc tả yêu cầu

CNPM/NN 44
 Đặc tả yêu cầu phần mềm

 Kết quả của quá trình SE là Đặc tả (Specification) về hệ thống

phần mềm
 Đặc tả yêu cầu phản ánh việc hiểu biết lẫn nhau về các vấn đề
cần được giải quyết giữa người phân tích và khách hàng
 Nó là một nền tảng cho hợp đồng giữa khách hàng và tổ chức
phát triển
 Đặc tả yêu cầu được dùng để xem xét việc thỏa mãn của hệ
thống với các yêu cầu phần mềm (kiểm thử)

CNPM/NN 45
 Cấp độ đặc tả yêu cầu
 Yêu cầu nghiệp vụ:
 Yêu cầu người dùng:
 Viết chủ yếu cho người dùng
 Thường bằng ngôn ngữ tự nhiên cộng với các biểu đồ
 Mô tả các dịch vụ và những 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ả chi tiết chức năng, dịch vụ và
ràng buộc
 Có thể là một phần của hợp đồng, xác định những gì cần
phải thực hiện

CNPM/NN 46
 Yêu cầu người dùng  yêu cầu hệ thống

CNPM/NN 47
 Yêu cầu người dùng  yêu cầu hệ thống
 1. MHC-PMS sẽ lập báo cáo quản lý hàng tháng thể hiện chi
phí thuốc theo quy định của từng phòng khám trong tháng
đó.
 1.1 Vào ngày làm việc cuối cùng của mỗi tháng, bảng tổng hợp
các loại thuốc được kê đơn, chi phí của chúng và phòng khám kê
đơn sẽ được lập.
 1.2 Hệ thống sẽ tự động tạo báo cáo để in sau 17h30 của ngày
làm việc cuối cùng của tháng.
 1.3 Một báo cáo sẽ được lập cho mỗi phòng khám và liệt kê các
tên thuốc riêng lẻ, tổng số đơn thuốc, số liều được kê đơn và
tổng chi phí của các loại thuốc được kê đơn.
 1.4 Nếu thuốc có sẵn với các đơn vị liều khác nhau (ví dụ, 10 mg,
20 mg), các báo cáo riêng biệt phải được tạo cho từng đơn vị liều.
 1.5 Quyền truy cập vào tất cả các báo cáo chi phí sẽ bị hạn chế
đối với những người dùng được ủy quyền được liệt kê trong
danh sách kiểm soát truy cập quản lý.
CNPM/NN 48
Đọc đặc tả yêu cầu
 Vd: xác định và đặc tả
User requirement definition

1. The software must provide a means of representing and

1. accessing external files cr
eated by other tools.

System requirements specification

1.1 The user should be provided with facilities to define the type of
1.2 external files
.
1.2 Each external file type ma y have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type ma y be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be pr
ovided of r the icon representing an
1.2 external file type to be defined yb the user.
1.5 When a user selects an iconepresenting
r an external file
, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.

CNPM/NN 50
 Hướng dẫn viết yêu cầu

 Đưa ra một định dạng mẫu

 Dùng ngôn ngữ một cách nhất quán
 Phải đánh dấu làm nổi bật phần chính của yêu cầu
 Tránh dùng thuật ngữ máy tính

CNPM/NN 51
CNPM/NN 52
 Đặc tả bằng ngôn ngữ tự nhiên

 Không rõ ràng: Ngôn ngữ tự nhiên có thể diễn đạt phong phú
nhưng thiếu chính xác
 Quá mềm dẻo: với cùng một vấn đề nhưng có nhiều cách khác
nhau để đặc tả
 Thiếu tính cấu trúc

CNPM/NN 53
 Đặc tả theo mô hình

Article search

Library Article printing

User

User administration Library

Staff

Supplier Catalogue services

CNPM/NN 54
 Use case

CNPM/NN 55
 Tài liệu đặc tả theo IEEE
 1. Giới thiệu
 1.1. Mục đích của tài liệu yêu cầu
 1.2. Phạm vi của sản phẩm
 1.3. Các định nghĩa, từ viết tắt
 1.4. Các tham chiếu
 1.5. Tổng quan về tài liệu yêu cầu
 2. Mô tả chung
 2.1. Giới thiệu chung về sản phẩm
 2.2. Các chức năng của sản phẩm
 2.3. Đặc điểm của người sử dụng
 2.4. Các ràng buộc
 2.5. Giả định và các phụ thuộc
 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền
ứng dụng
 4. Phụ lục
 5. Chỉ mục

CNPM/NN 56
 2.4. Đánh giá yêu cầu
 Xác định những yêu cầu được trình bày có phù hợp với
những gì khách hành thật sự muốn
 Chi phí cho những lỗi về yêu cầu rất cao: Chi phí cho việc sửa
chữa lỗi yêu cầu sau khi xuất xưởng cao hơn nhiều lần chi phí
sửa lỗi lúc cài đặt (implementation)

CNPM/NN 57
 Tiêu chí kiểm tra yêu cầu
 Validity – Giá trị. Hệ thống có cung cấp các chức năng hỗ trợ
tốt nhất cho nhu cầu của khách hàng không?
 Consistency – Toàn vẹn. Có tranh chấp yêu cầu không?
 Completeness – Đầy đủ. Có bao gồm tất cả yêu cầu của khách
hàng không?
 Realism - Hiện thực. Các yêu cầu có thể được thực hiện với
ngân sách và công nghệ có sẵn không?
 Verifiability – Kiểm chứng được. Yêu cầu có thể kiểm tra
được?
 Kỹ thuật đánh giá yêu cầu
 Kiểm tra yêu cầu (Review)
 Phân tích thủ công có tính hệ thống
 Tạo mẫu (Prototyping)
 Dùng mô hình có thể thực thi
 Tạo tình huống kiểm tra (Test-case)
 Những tình huống kiểm tra khó hay không thể thiết kế tốt thì
Khó đánh giá

CNPM/NN 59
 3. Quản lý yêu cầu
 Quản lý yêu cầu là quy trình quản lý sự thay đổi của
các yêu cầu
 Các yêu cầu thường không đầy đủ và không đồng
nhất là do:
 Những yêu cầu mới xuất hiện khi các yêu cầu nghiệp vụ thay
đổi và khi chúng ta có hiểu biết sâu hơn về hệ thống sẽ xây
dựng.
 Các yêu cầu thường xuất hiện các mâu thuẫn do khung nhìn
khác nhau, khách hàng thường đặc tả sai về yêu cầu của
stakeholder
 Thứ tự ưu tiên của yêu cầu thay đổi trong quá trình phát triển
hệ thống.
 Môi trường nghiệp vụ và môi trường kỹ thuật của hệ thống thay
đổi trong quá trình xây dựng…

CNPM/NN 60
 Baseline: yêu cầu đã đưa vào quản lý

CNPM/NN 61
 Lần vết yêu cầu

Là công việc cần thiết trong quản lý

yêu cầu Stakeholder
 Lần vết nguồn: là những liên kết từ
các yêu cầu tới stakeholder.
 Lần vết yêu cầu: là mối liên hệ giữa
các yêu cầu độc lập với nhau.
 Lần vết thiết kế: là những liên kết từ
Requirement
Change
Request
yêu cầu cho tới thiết kế.

Design

CNPM/NN 62