Chapter 3: Công nghệ yêu cầu
Requirements engineering (RE)
Requirements Elicitation
Or
Requirement gathering
Các d ự lu ật trang 34


Nôị dung
Công nghệ yêu cầu (Requirements
engineering (RE) là gì ?
 Thu thập yêu cầu (Requirement
elicitation) là gì?
 Các kỹ thuật thu thập yêu cầu
 Chọn lựa kỹ thuật thu thập yêu cầu
 Quy tắc nghiệp vụ và chính sách
 Quản lý mối quan hệ khách hàng



Requirements engineering (RE)
Công nghệ yêu cầu
Requirements engineering (RE)
Tập hợp các tác vụ và kỹ thuật để dẫn đến
việc hiểu rõ các yêu cầu được gọi là công
nghệ yêu cầu.
Đứng ở góc độ quy trình phần mềm, công
nghệ yêu cầu là hoạt động chính bắt đầu
trong suốt hoạt động giao tiếp và tiếp tục
trong các hoạt động mô hình hóa.

Requirements engineering (RE)
Công nghệ yêu cầu


Requirements engineering (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
◦ Input: Các yêu cầu từ khách hàng (Problem statement
prepared the customers)
◦ Output: tài liệu đặc tả yêu cầu (Software requirements
specifification-SRS)


Requirement elicitation
Thu thập yêu cầu


Elicitation là quá trình xác định yêu cầu và
làm giảm sự khác biệt giữa các nhóm có
liên quan để rút ra các yêu cầu đáp ứng
được nhu cầu của tổ chức hay dự án trong
khi vẫn giữ được các ràng buộc.



Requirement elicitation
Phát hiện yêu cầu


Mục đích:
◦ Nhận diện các cá nhân liên quan
(stakeholders) tới dự án
◦ Tập hợp các yêu cầu mà hệ thông phải thực
hiện.
◦ Sắp thứ tự ưu tiên các yêu cầu.


Phân biêṭ giữa elicitation và
analysis
Elicitation là sự tương tác với
stakeholders để nắm bắt được nhu cầu
của họ.
 Analysis là tinh chỉnh (refinement) nhu
cầu của stakeholder thành các đặc tả
sản phẩm chính thức.



Khó khăn khi phát hi ện yêu
c ầu

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.
 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 về hệ thống cần xây dựng, 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ế.
 Khó khăn về tính ổn định: yêu cầu thường
thay đổi theo thời gian



Trước khi phát hiện yêu cầu yêu cầu





Đã viết “vision and scope”
Vẽ lược đồ ngữ cảnh (context diagram)
Xác định stakeholder
Xác định người dùng và đại diện người dùng


Lược đồ ngữ cảnh
Context Diagram


Phạm vi (scope) dùng để xác định đường biên
(boundary) và các mối nối kết giữa hệ thống đang phát

triển và mọi thứ khác bên ngoài.



Lược đồ ngữ cảnh dùng để minh họa đường biên giữa
hệ thống và môi trường bên ngoài.
Sơ đồ bối cảnh xác định các thực thể (entities) bên ngoài
hệ thống có giao tiếp với hệ thống theo một cách nào đó
(được gọi là terminators hoặc external entities), xác
định luồng dữ liệu và luồng vật chất (flow of data or
material) giữa mỗi thực thể bên ngoài và hệ thống.




Lược đồ ngữ cảnh
Luồng dữ liệu

Thực thể
Terminators

Terminators có thể biểu diễn cho các lớp người dùng (user classes)
(“Chemists”), hoặc tổ chức (“Purchasing Department”) hoặc các hệ
thống máy tính khác (“Training Database”).


Lược đồ ngữ cảnh







Lược đồ dòng dữ liệu (Datat Flow Diagram-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 hóa hệ thống từ góc độ 1 chức năng. Việc
tìm vết và tư liệu hóa quan hệ giữa dữ liệu với 1 qui
trình rất có ích đối với việc tìm hiểu toàn bộ hệ thống.
DFD bao gồm:
◦ Mức ngữ cảnh: Là mức 0 (top level) của lược đồ dòng dữ liệu
(data flow diagram) theo cách phân tích hướng cấu trúc
◦ Mức 1, 2,…



DFD được dùng rộng rãi cho bất kỳ phương pháp phát
triển nào. Có thể nằm trong tài liệu vision, trong phục
vụ đặc tả yêu cầu (SRS)


Lược đồ ngữ cảnh
Quản lý
thông tin độc giả

Người quản lý
Nhân viên

Độc giả


Sách

Hệ thống
quản lý
thư viện

Quản lý việc
mượn/trả sách

Báo cáo
thống kê

Tài khoả n
Quản lý sách
Nhà cung cẤp


Lược đồ ngữ cảnh


Keeping Scope in Focus
Nắm chắc phạm vi






Các yêu cầu kinh doanh (business requirements) được

ghi lại trong tài liệu tầm nhìn và phạm vi (vision and
scope) là cơ sở để xử lý tất cả các rắc rối liên quan đến
phạm vi của dự án.
Khi có ai đó kiến nghị 1 yêu cầu mới thì RA phải làm gì?
Cần xem xét yêu cầu mới có nằm trong scope hay
không?
Nếu yêu cầu kiến nghị nằm trong scope thì có thể hợp
nhất yêu cầu mới vào dự án nếu có độ ưu tiên cao so với
yêu cầu hiện cócó thể phải trì hoãn hay hủy bỏ các yêu
cầu hiện tại


Keeping Scope in Focus


Nếu yêu cầu kiến nghị nằm ngoài scope thì có thể có 1
trong các phương án sau:
◦ Nên đưa vào phiên bản sau hay trong dự án khác.
◦ Scope của dự án có thể thay đổi để đáp ứng yêu cầu
mới  cần có phản hồi từ phía người dùng và cần cập
nhật lại tài liệu vision and scope (nếu đã phê duyệt thì
cần giám sát mọi thay đổi)
◦ Khi phạm vi dự án tăng, thường phải thỏa thuận lại
ngân sách(budget), tài nguyên (resource), thời gian
(schedule)


Xác định StakeHolder







StakeHolder là các cá nhân có ảnh hưởng tới
kết quả của dự án, và là các đối tượng chúng ta
sẽ làm việc để thu thập thông tin.
Những tính chất mà người dùng đưa ra lúc đầu
thường không đủ để trở thành chức năng của
hệ thống.
Để có cái nhìn chính xác hơn nhu cầu người
dùng, RA phải tập hợp các yêu cầu người dùng,
phân tích và xác định chỉ nên xây dựng cái gì để
người dùng làm tốt được công việc của họ.


Phân loại StakeHolder
1.
2.
3.
4.
5.

Customers (người tài trợ dự án hay mua sản phẩm)
Users (người tương tác trực tiếp hay gián tiếp sản
phẩm)
Requiremements analysts (người viết yêu cầu và làm
việc với đội phát triển phần mềm)
Developers (người thiết kế, thực thi và bảo trì sản
phẩm)

Testers (người kiểm tra xem sản phẩm có thực thi như
mong muốn)


Phân loại StakeHolder
1.
2.
3.
4.
5.

Documentation writers (người tạo ra sổ tay người
dùng, hệ thống trợ giúp)
Project managers (người lập kế hoạch cho dự án, quản
lý đội phát triển phần mềm)
Legal staff (người bảo đảm sản phẩm phù hợp với luật
và quy chế)
Manaufacturing people (người phải xây dựng sản
phẩm có chứa phần mềm)
Sales, marketing, field support, help desk, và những
người khác sẽ làm việc với sản phẩm và khách hàng.


Ví dụ: ATM stakeholder











Khách hàng của ngân hàng (người sử dụng dịch vụ)
Đại diện của các ngân hàng khác (ATM của ngân hàng này
có thể dùng để giao dịch với ngân hàng khác)
Quản lý ngân hàng (dùng thông tin quản lý từ hệ thống
ATM)
Nhân viên lại các chi nhánh ngân hàng (vận hành hệ thống)
Quản trị cơ sở dữ liệu (tích hợp hệ thống với CSDL của
ngân hàng)
Quản lý an ninh
Phòng marketing (muốn dùng ATM để quảng cáo)
Kĩ sư bảo trì phần mềm và phần cứng
Những người điều phối hệ thống ngân hàng quốc gia (đảm
bảo hệ thống tuân theo nguyên tắc chung)


Phát hiện yêu cầu


Các bước thực hiện:
◦ Xác định nguồn của các yêu cầu
◦ Thu thập thông tin
◦ Hội thảo để phát hiện yêu cầu (Conduct
Requirements Workshops)
◦ Prototyping
◦ Đánh giá kết quả.



Xác định nguồn yêu cầu
Từ các Stakeholder
 Một nguồn thông tin quan trọng khác là
các tài liệu đang tồn tại của tổ chức mô
tả hoạt động của hệ thống đang sử dụng


◦ Có thể là các mô hình nghiệp vụ (business
models)
◦ Hoặc các biểu mẫu thương mại khác.


Xác định và sắp thứ tự ưu tiên các nguồn
thông tin yêu cầu.


Thu thập thông tin


Mục đích:
◦ Xác định các câu hỏi nào cần được trả lời.
◦ Thu thập và viết tài liệu cho thông tin thu
thập được.


Các kỹ thuâṭ thu thâp̣ yêu cầu
Document Sampling
 Interviewing
 Survey and observation

 Questionaires
 Workshop and Brainstorming
 JAD (Joint Application Development)
sessions
Ba kỹ thuật phổ biến nhất là Document
sampling, interviewing và questionaires



Các kỹ thuâṭ thu thâp̣ yêu cầu