


"Hello, Phil? This is Maria in Human
Resources. We're having a problem with the
employee system you programmed for us. An
employee just changed her name to Sparkle
Starlight, and we can't get the system to
accept the name change. Can you help?"
"She married some guy named Starlight?"
"No, she didn't get married, just changed her
name," Maria replied. "That's the problem. It
looks like we can change a name only if
someone's marital status changes."

"Well, yeah, I never thought someone might
just change her name. I don't remember you
telling me about this possibility when we
talked about the system. That's why you can
get to the Change Name dialog box only
from the Change Marital Status dialog box,"
Phil said.


"I assumed you knew that people could
legally change their name anytime they like,"
responded Maria. "We have to straighten this
out by Friday or Sparkle won't be able to cash
her paycheck. Can you fix the bug by then?"
"It's not a bug!" Phil retorted. "I never knew
you needed this capability. I'm busy on the
new performance evaluation system. I think I
have some other change requests for the
employee system here, too." [sound of
rustling paper]


"Yeah, here's another one. I can probably fix
it by the end of the month, but not within a
week. Sorry about that. Next time, tell me
these things earlier and please write them
down.“
"What am I supposed to tell Sparkle?"
demanded Maria. "She's really going to be
ticked if she can't cash her check."


"Hey, Maria, it's not my fault," Phil protested.
"If you'd told me in the first place that you
had to be able to change someone's name at
any time, this wouldn't have happened. You
can't blame me for not reading your mind."
Angry and resigned, Maria snapped, "Yeah,
well, this is the kind of thing that makes me
hate computer systems. Call me as soon as
you get it fixed, will you?"

Nhiều vấn đề về phần mềm xuất hiện do thiếu
sót trong lúc thu thập, thỏa thuận, và chỉnh
sửa yêu cầu.
◦ Lỗi xảy ra trong giai đoạn thu thập yêu
cầu chiếm từ 40 – 60% tổng lỗi trong 1 dự
án phấn mềm.
◦ Có sự khác nhau giữa cái mà các
developer nghĩ và xây dựng vớ̀i cái mà
khách hàng thực sự cần.







Tầm quan trọng của Yêu cầu phần mềm
Yêu cầu phần mềm là gì?
Kỹ thuật thu thập yêu cầu là gì?
Phát triển và quản lý yêu cầu?
Lợi ích từ quy trình xác định yêu cầu chất
lượng cao
Yêu cầu theo quan điểm khách hàng
Vai trò của người phân tích yêu cầu
(requirement analyst)
Trước đây, nhiều sản phẩm thành công mà
không cần có sự tham gia của các chuyên gia
trong việc thu nhận và quản lý yêu cầu.
 Nhưng ngày nay thì requirements
engineering (RE) lại trở nên vô cùng quan
trọng.
 Tại sao?
Vì công nghệ và xã hội không ngừng thay đổi.



Sản phẩm phát triển với tốc độ chóng mặt.
Ngày nay khách hàng luôn đòi hỏi phiên bản
(version) mới của sản phẩm phải dưới 1 năm.
Ví dụ: theo Siemens thì 20 năm trước, 55%
hàng bán là từ sản phẩm tuổi <5. Ngày nay,
75% hàng bán được là từ sản phẩm có tuổi
<5.


Thay đổi không ngừng của công nghệ và
chuyển giao đã ảnh hưởng nhiểu đến mức độ
thành thạo của chuyên gia. Vài năm trước,
các kỹ sư có thể sống cả đời với nghề nghiệp
của mình trong 1 công ty nào đó, nhưng
ngày nay việc thay đổi công việc rất thường
xuyên.


Gia công phẩn mềm đã làm thay đổi nhanh
chóng chu kỳ phát triển phần mềm.
Đặc tả được tạo ra để thực thi hay sản xuất
bởi các tổ chức khác nhau nên bị nhiều hạn
chế và không có chuyên môn nghiệp vụ.
Tương tự như phải tạo đặc tả cho máy giặt
mà người thiết kế chưa từng nhìn thấy máy
giặt lần nào. Để thành công, đặc tả cần phải
chính xác và chi tiết.


Việc phát triển phần mềm thường liên kết
chặt chẽ với nghiệp vụ. e.g., phân mềm cell
phone và phần mềm về hàng không thường
được thiết kế xây dựng chặt chẽ phù hợp với
nghiệp vụ.
Công nghiệp bắt đầu dùng phần mềm để tạo
các phiên bản mới cho sản phẩm. Các sáng
kiến có thể dễ thực thi bằng phần mềm hơn
là phần cứng vì ít đầu tư kỹ thuật hơn và chi
phí sửa đổi rẻ hơn.



Misconception 1: Any Subject Matter Expert
Can Become a Requirements Engineer after a
Week or Two of Training
Misconception 2: Nonfunctional and
Functional Requirements can Be Elicited Using
Separate Teams and Processes
Misconception 3: Processes That Work for a
Small Number of Requirements Will Scale
 Assignment: nhóm??
Theo IEEE 1990, yêu cầu phần mềm là:
1. A condition or capability needed by a user to
solve a problem or achieve an objective.
2. A condition or capability that must be met or
possessed by a system or system component
to satisfy a contract, standard, specification,
or other formally imposed document.
3. A documented representation of a condition
or capability as in 1 or 2.


Requirements là đặc tả của cái gì cần được
thực thi, mô tả hệ thống sẽ hoạt động như
thế nào hay hệ thống có thuộc tính gì.
Yêu cầu cũng có thể là các ràng buộc trong
quá trình phát triển hệ thống.








Feasible
Valid
Unambiguous
Verifiable
Modifiable
Consistent
Complete
Traceable

SR bao gồm 3 mức phân biệt:
◦ business requirements,
◦ user requirements,
◦ functional requirements.



Biễu diễn các mục tiêu của tổ chức hay người
dùng yêu cầu hệ thống phải thực thi.
Yêu cầu nghiệp vụ thường do người tài trợ
cho dự án, khách mua phần mềm, người
quản lý các người dùng, bộ phận marketing.
Thường được ghi nhận trong phần vision và
scope của tài liệu, đôi khi còn được gọi là
project charter hay market requirements
document.


Mô tả mục tiêu (goal) hay nhiệm vụ (task) của
người dùng đối với hệ thống.
Các cách để biểu diễn yêu cầu người dùng:
◦ use cases, scenario descriptions,
◦ Bảng event-response.

Yêu cầu người dùng mô tả cái (what) mà
người dùng có thể làm đối với hệ thống.
◦ Ví dụ: use case "Make a Reservation" dùng trong các
website của hàng không, thuê xe, hay khách sạn.



Xác định chức năng của phần mềm mà các
nhà phát triển phải xây dựng để giúp người
dùng hoàn thành nhiệm vụ của họ, thỏa mãn
được yêu cầu nghiệp vụ.
Đôi khi còn được gọi là behavioral
requirements
Ví dụ: "The system shall e-mail a reservation
confirmation to the user.”



Mô tả yêu cầu mức cao đối 1 sản phẩm, nó
chứa các hệ thống con (subsystem) nào.
Một hệ thống có thễ là toàn bộ phần mềm
hay bao gồm các hệ thống con của phần mềm
cũng như phần cứng.
Con người cũng là 1 phần hệ thống, vì vậy
các chức năng hệ thống cũng có thể chỉ định
cả vai trò của con người.

Đội được giao nhiệm vụ viết 1 phần mềm
quản lý dụng cụ phòng thí nghiệm, tự động
bổ sung thêm 1 lượng chính xác các hóa chất
vào 1 dãy các chén thủy tinh (beaker)

Kỹ thuật thu thập yêu cầu liên quan
đến tất cả các hoạt động có chu kỳ :
◦ Xác định yêu cầu của người dùng,
◦ Phân tích yêu cầu để suy diễn thêm các
yêu cầu khác
◦ Đặc tả yêu cầu
◦ Kiểm tra xem yêu cầu vừa đặc tả có phù
hợp với nhu cầu người dùng không


Hậu quả do xác định yêu cầu không đúng là
phải rework (làm lại ) —doing over something
that you thought was already done.
Rework có thể mất 30 – 50% tổng chi phí phát
triển dự án và lỗi do yêu cầu chiếm tới 70 –
85% chi phí làm lại.
Nhận xét???

Imagine how different your life would be if
you could cut the rework effort in half! You
could build products faster, build more and
better products in the same amount of time,
and perhaps even go home occasionally.







Insufficient User Involvement
Creeping User Requirements
Ambiguous Requirements
Gold Plating
Minimal Specification
Overlooked User Classes
Inaccurate Planning
 assignment của 2 nhóm: nhóm? Nhóm ?


Giảm rework không cần thiết
Hiệu quả của yêu cầu có chất lượng thường
không hiển nhiên và nhiều người tin một
cách nhầm lẫn là tiêu tốn thời gian khi bàn
luận về yêu cầu sẽ dẫn đến làm chậm trễ việc
hoàn thành sản phẩm.



Thu thập yêu cầu cho phép đội phát triển
hiểu tốt hơn người dùng và thị trường, một
thừa số thành công quan trọng cho bất kỳ dự
án nào.
Lôi cuốn người dùng tham gia cùng trong
giai đoạn thu thập yêu cầu sẽ xây dựng được
niềm tin và lòng trung thành của khách hàng
Đội có thể tránh viết những đoạn mã thừa khi
nắm vững nhiệm vụ của người dùng.

Sự quan tâm của khách hàng giảm được
khoảng cách (expectation gap) giữa cái người
dùng cần và cái developer tạo ra.










Lỗi về yêu cầu ít hơn
Giảm được việc phải làm lại trong bước phát triển
Ít hơn các tính năng không cần thiết
Hạ thấp chi phí mở rộng
Quá trình phát triển hệ thống sẽ nhanh hơn
Giảm bớt các giao tiếp sai lầm với khách hàng
Hạn chế phạm vi hệ thống bị phình rộng
Hạn chế được những hỗn độn dự án
Các ước tính về hệ thống chính xác hơn
Mức độ thỏa mãn khách hàng và thành viên của đội
sẽ cao hơn



Phân tích thông tin thị trường, stakeholder,
và nhu cầu của người dùng để suy dẫn các
yêu cầu chức năng và phi chức năng.
Hiểu được ảnh hưởng của các yêu cầu đến
nghiệp vụ
Hợp nhất các yêu cầu này lại để hoàn thành
các đặc tả yêu cầu và hệ thống


Khách hàng (customer) là một cá nhân hay 1
tổ chức mong muốn hoặc trực tiếp hoặc gián
tiếp có lợi từ sản phẩm.
Hai loại khách hàng phần mềm (Software
customer) :
◦ Khách hàng dạng quản lý (Customer at
management level)
◦ End user


Là loại khách hàng trả tiền hay tài trợ dự án
phần mềm.
Có nhiệm vụ xác định yêu cầu nghiệp vụ
(business requirement)
◦ Mô tả mục tiêu nghiệp vụ mà khách hàng, công ty
hay các stakeholders khách muốn hoàn thành.
◦ Xác lập các thành phần chính cho phần còn lại
của dự án


Tất cả các tính chất và yêu cầu khác phải đáp
ứng theo các yêu cầu nghiệp vụ.
Nhưng các yêu cầu nghiệp vụ không đủ chi
tiết để giúp các nhà phát triển biết phải xây
dựng cụ thể cái gì


Bao gồm tầt cả những ai sẽ thực sự sử dụng
sản phẩm dù trực tiếp hay gián tiềp.
Users có thể mô tả nhiệm vụ mà họ cần thực
thi với sản phẩm và chất lượng mà họ mong
đợi từ sản phẩm

Thường cả hai loại khách hàng này đều
không tin là họ có thời gian đển làm việc với
các nhà phân tích yêu cầu. Đôi lúc họ nghĩ là
nhà phân tích sẽ hình dung ra được cái người
dùng cần mà không cần phải thảo luận cùng
nhau.


Thường xung đột (conflict) có thể xuất hiện
giữa yêu cầu nghiệp vụ và yêu cầu người
dùng.
Yêu cầu nghiệp vụ phản ánh chiến lược của
tổ chức và các hạn chề về tài chính mà người
dùng có thể không nhìn thấy được  người
dùng thất vọng về hệ thống mới, họ nghĩ
mình như “con tốt” của 1 tương lai không
như ý..


Việc giao tiếp rõ ràng về mục tiêu và các ràng
buộc của dự án có thể làm dịu đi các căng
thẳng bức xúc của người dùng.
Nhà phân tích (analyst) nên làm việc với các
đại diện chính của người dùng (key user
representative) và các nhà tài trợ để hòa giải
các xung đột.



Yêu cầu chất lượng cao có được từ sự quan
hệ giao tiếp hiệu quả giữa nhà phát triển và
khách hàng.
Thường mối quan hệ giữa người phát triển
và customers hay trở nên đối kháng
(adversarial)
Managers thường vượt quá các yêu cầu do
người dùng cung cấp để phù hợp với lịch làm
viêc̣ của chính họ.

Bảng tuyên ngôn quyền dành cho khách
hàng (Requirements Bill of Rights for
Software Customers) liệt kê 10 điều mong
đợi mà khách hàng có quyền khi tiếp xúc
với và phát triển dự án.
Assignment?

Bảng trách nhiệm dành cho khách hàng
phần mềm (Requirements Bill of
Responsibilities for Software Customers) liệt
kê 10 trách nhiệm mà khách hàng phải thực
hiện trong suốt quá trình thu thập yêu cầu
của nhà phân tích.
Assignment?
•
•
•
•
•
•
•
•
•
•
Customers
Users
Requirements analysts
Developers
Testers
Documentation writers
Project managers
Legal staff
Manufacturing people
Sales, marketing, field support, help desk, …
Assignment???
You are a product manager for a machine tool
company. The directors have asked you to
develop a new cutting machine to cut cloth
for fashionable dresses of all sizes and
patterns. The machine will be sold to clothing
makers around the world:
a. Who are your key stakeholders?
b. How will you analyse and validate your
stakeholder list?

Bốn hoạt động này có thể xen vào nhau
(interleaved), tăng tiến (incremental), và lặp
lại (iterative)

Các từ đồng nghĩa:
◦
◦
◦
◦
Systems analyst
Requirements engineer
Requirements manager
Analyst.


Analyst là người chuyển (translator) các suy
nghĩ của người nào đó thành đặc tả yêu cầu.
Analyst là người phản ánh (reflector) thông
tin đến các stakeholder, giúp các stakeholder
tìm thấy sự khác nhau giữa cái họ muốn và
cái họ thực sự cần.



Là người có nhiệm vụ cơ bản là thu thập,
phân tích, ghi chép và kiểm tra nhu cầu của
stakeholders.
Analyst như 1 cầu nối giữa cộng đồng khách
hàng và đội phát triển phần mềm.
Analyst đóng vai trò trung tâm trong việc thu
thập và phổ biến thông tin, còn project
manager giữ vai trò lãnh đạo trong việc
truyên đạt thông tin dự án.

Analyst trước tiên phải hiểu mục tiêu của
người dùng, sau đó xác định các yêu cầu
chức năng, cho phép người quản lý dự án
làm các ước tính, các developers thiết kế, xây
dựng và kiểm định sản phẩm.








Define business requirements.
Identify project stakeholders and user
classes.
Elicit requirements
Write requirements specifications
Model the requirements
Lead requirements validation
Facilitate requirements prioritization
Manage requirements
Assignment ??










Listening skill
Interviewing and questioning skill
Analytical skill,
Facilitation skills.
Observational skills.
Writing skills
Organizational skills
Modeling skills
Interpersonal skills
Creativity

Assignment ??