Các kỹ thuật thu thập và tổng hợp yêu cầu phần mềm

Function Requirements and Non-Function Requirements
Lớp công nghệ phần mềm K52-Đại học bách khoa Hà Nội
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

MÔN PHÂN TÍCH YÊU CẦU PHẦN MỀM
BÀI THU HOẠCH CÁ NHÂN
Giảng Viên Hướng Dẫn PGS.TS Huỳnh Quyết Thắng
Sinh Viên Thực Hiện
Bùi Song Toàn 20072929
Hà Nội 11/2010
Phần 1 : Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm
I. Giới thiệu
1. Mục đích
Đưa ra các kĩ thuật phát hiện và tổng hợp các yêu cầu phần mềm.
2. Phạm vi
Trong các dự án phần mềm
3. Tài liệu tham khảo
• Managing Software RequirementsDean Leffingwell - Don Widrig
II. Các kỹ thuật phát hiện và tổng hợp phần mềm
1. Kỹ thuật Phỏng vấn
1. Những điểm chính
• Phỏng vấn là một kĩ thuật đơn giản và trực tiếp
• Các câu hỏi về phạm vi tự do sẽ giúp đạt được xu hướng của cuộc vấn
• Nó có thể thích hợp để tìm ra những yêu cầu chưa được phát hiện
• Sự hội tụ trong một vài yêu cầu phổ biến sẽ tạo ra một kho các yêu cầu sử dụng
trong suốt dự án.
• Một sự nghi ngờ sẽ không được thay thế cho 1 cuộc phỏng vấn.
2. Các câu hỏi phạm vi tự do
Làm sao để tránh sự định kiến của người sử dụng khi đáp ứng yêu cầu của các
câu hỏi? Chúng ta dùng các câu hỏi về các vấn đề tự nhiên của người sử dụng

mà không liên quan đến bất cứ phạm vi công việc nào. ví dụng như:
• Ai là người sử dụng?
• Ai là khách hàng?
• Họ có cần một sự thay đổi?
• Ở đâu khác có thể tìm một giải pháp cho vấn đề này?
3. Tạo thêm nội dung câu hỏi
Trong quá trình tìm kiếm mà các yêu cầu chưa được phát hiện, chúng ta cũng có
thể
chuyển câu hỏi sang chủ đề khác , không nhất thiết bó buộc nội dung câu
hỏi.Hãy tạo cảm giác thoải mái, cởi mở khi nói chuyện.
4. Một vài lời khuyên khi phỏng vấn
Một vài lời khuyên cho một cuộc phỏng vấn thành công:
• Sửa chữa các cuộc phỏng vấn tự do, và ghi nó vào một cuốn sách.
• Trước khi phỏng vấn, tìm kiếm lại các tổ chức của nhà đầu tư và công ty được
phỏng vấn. Đừng làm phiền người được phỏng vấn.
• Nên ghi lại các câu trả lời vào trong sách.
• Tham khảo các template trong suốt quá trình phỏng vấn.
5. Biên soạn lại các dữ liệu cần thiết
6. Chú ý vào những sự đáng ngờ
2. Kỹ thuật Hội thảo
1. Tổng quát
• Những yêu câu hội thảo có lẽ là một kĩ thuật mạnh mẽ nhất để có thể phát hiện ra
yêu cầu.
• Nó tập hợp lại tất cả các nhà đầu tư chính cùng nhau trong một khoảng thời gian
ngắn nhưng lại là giai đoạn tập trung nhất.
• Sử dụng một tài liệu bên ngoài có kinh nghiệm trong việc quản lý yêu cầu và giúp
đỡ cho một hội thảo thành công.
• Thảo luận, góp ý là phần quan trọng nhất của hội thảo
2. Đẩy nhanh quá trình giải quyết
Hỏi tất cả mọi người xem vấn đề chúng ta vừa đưa ra có đặc điểm nào

cần bổ sung không trước khi đưa ra vấn đề tiếp theo.
Các yêu cầu của một hội thảo có rất nhiều điểm phải phù hợp
• Nó phải giúp đỡ xây dựng một đội hiệu quả, tận tâm cho một mục đích chung:
thành công trong dự án này.
• Tất cả mọi người đều được phát biểu.
• Phải tiến tới một sự đồng thuận giữa nhà đầu tư và đội ngũ phát triển về việc ứng
dụng này phải làm gì.
• Có thể trình bày và giải quyết các vấn đề có thể gây trở ngại cho dự án thành công.
• Đưa ra định nghĩa sơ bộ cho hệ thống.
3. Sửa chữa cho hội thảo
• Đưa ra các khái niệm
• Đảm bảo sự đóng góp của mọi người.
• Hậu cần
• Làm nóng bầu không khí.
4. Vai trò của sự thuận tiện
Để đảm bảo thành công, chúng ta cần lời khuyên của những người
bên ngoài, những người đã có kinh nghiệm trong quá trình quản lý các yêu
cầu.
Một vài điểm liên quan đến các sự thuận tiện:
• Thiết lập một cuộc gặp mặt
• Bắt đầu và kết thục đúng thời gian.
• Thiết lập và đảm bảo quy tắc của cuộc họp.
• Giới thiệu mục đích và lịch công tác của cuộc họp
• Quản lý cuộc họp và giữ đội ngũ đi đúng hướng.
• Sự thuận tiện trong quá trình quyết định và sự đồng lòng, tránh các nội dung khác
biệt.
• Đảm bảo lịch công tác đúng hướng.
• Tất cả sự khác biệt giữa các nhà đầu tư phải được lắng nghe.
• Kiểm soát các hành vi gây đổ vỡ và không mang lại giá trị.
5. Thiết lập nhật kí công tác

Đảm bảo rằng tất cả thành viên liên quan đến dự án phải được nhận được
lịch họp. Cố gắng sắp xếp sao cho mọi người có thể đến được.
6. Bắt đầu hội thảo
- Thảo luận góp ý và các ý tưởng đưa ra.
- Đưa ra các vấn đề và theo sau đó.
3. Kỹ thuật BrainStorming
1. Giới thiệu
Brainstorming là một phương pháp đặc sắc dùng để phát triển nhiều giải
pháp sáng tạo cho một vấn đề đặt ra. Ban đầu brainstroming được tạo ra để
tìm ý tưởng trong làm việc theo nhóm. Alex F. Osborn đưa ra kỹ thuật này
lần đầu tiên năm 1941, trong cuốn sách Applied Imagination.Alex F. Osborn
đã miêu tả động não như là Một kĩ thuật hội ý bao gồm một nhóm người
nhằm tìm ra lời giải cho vấn đề đặc trưng bằng cách góp nhặt tất cả ý kiến
của nhóm người đó nảy sinh trong cùng một thời gian theo một nguyên tắc
nhất định.Ngày nay phương pháp này đã được sử dụng rất phổ biến trong
giảng dạy và sản xuất.
Máy tính và các phần mềm hỗ trợ cũng được sử dụng cho brainstroming
được hữu hiệu hơn.
2. Áp dụng
2.1. Định nghĩa vấn đề
Vấn đề muốn giải quyết phải được xác định thật rõ ràng phải đưa ra
được các chuẩn mực cần đạt được của một lời giải đáp.
2.2. Tập trung vào vấn đề
Tránh các ý kiến hay các điều kiện bên ngoài có thể làm lạc hướng
buổi làm việc. Trong giai đoạn này người ta thu thập tất cả các ý kiến và
ngay cả các từ chuyên môn có liên quan trực tiếp đến vấn đề cần giải quyết
(thường có thể viết lên giấy hoặc bảng tất cả). Những ý kiến này đều được
xem là có vai trò ngang nhau không phân biệt chi tiết lớn nhỏ. Việc ghi chép
ra bảng cũng không nhất thiết phải liệt kê hay sắp xếp theo trình tự nào hết.
Không được phép đưa bất kì một bình luận hay phê phán gì về các ý

kiến trong lúc thu thập. Những ý tưởng thoáng qua trong đầu nếu bị các
thành kiến hay phê bình sẽ dễ bị gạt bỏ và như thế sẽ làm mất sự tổng quan .
2.3. Khuyến khích tình thần tích cực
Mỗi thành viên đều cố gắng dóng góp và phát triển các ý kiến tùy
theo trình độ, khía cạnh nhìn thấy riêng và không giới hạn cách nhìn của mỗi
thành viên.
Đưa ra càng nhiều ý càng tốt về mọi mặt của vấn đề kể cả những ý
kiến không thực tiễn, ý kiến hoàn toàn lạ lẫm hay sáng tạo
3. Tiến hành
Trong nhóm lựa ra một người đầu nhóm và một người thư kí để ghi lại tất cả
ý kiến (cả hai công việc có thể do cùng một người thực hiện nếu tiện).
Xác định vấn đề hay ý kiến .Phải làm cho mọi thành viên hiểu thấu đáo về đề
tài sẽ được tìm hiểu.
Thiết lập các quy định cho buổi họp,bao gồm:
• Người đầu nhóm có nhiệm vụ điều khiển buổi làm việc.
• Không một thành viên nào có quyền đòi hỏi hay cản trở, đánh giá, phê bình hay
thêm bớt vào ý kiến, từ vựng nêu ra, hay giải đáp của thành viên khác.
• Cần xác định rằng không có câu trả lời nào là sai!
• Tất cả câu trả lời, các ý, các cụm từ, ngoại trừ nó đã được lập lại đều sẽ được thu
thập ghi lại (cách ghi có thể tóm gọn trong một chữ hay một câu cho mỗi ý riêng
rẽ).
• Vạch định thời gian cho buổi làm việc và ngưng khi hết giờ.
Bắt đầu brainstroming:
Người lãnh đạo chỉ định hay lựa chọn thành viện chia sẻ ý kiến trả lời
.Người thư kí phải viết xuống tất cả các câu trả lời, nếu có thể công khai hóa
cho mọi người thấy (viết lên bảng chẳng hạn). Không cho phép bất kì một ý
kiến đánh giá hay bình luận nào về bất kì câu trả lời nào cho đến khi chấm
dứt buổi thảo luận.
Sau khi kết thúc, hãy lượt lại tất cả và bắt đầu đánh giá các câu trả lời.
Một số lưu ý về chất lượng câu trả lời bao gồm:

• Tìm những câu ý trùng lặp hay tương tự để thu gọn lại.
• Góp các câu trả lời có sư tương tự hay tương đồng về nguyên tắc hay nguyên lí.Xóa
bỏ những ý kiến hoàn toàn không thích hợp.
• Sau khi đã cô lập được danh sách các ý kiến, hãy bàn cãi thêm về câu trả lời chung.
Trong khi áp dụng brainstroming tất cả các ý tưởng xuất hiện trong đầu của
các thành viên trong nhóm sẽ được viết hay vẽ ra, thông thường là bút chì và
giấy trắng.
Người ta viết bất cứ thứ gì có trong đầu ra mặt giấy (brain dumping), không
cần phải suy nghĩ nó là một ý tưởng tốt hay chỉ là một suy nghĩ thoảng qua
trong đầu. Người ta cũng chẳng cần bận tâm đến việc thẩm mỹ của việc trình
bày đó. Nếu cần diễn tả một hình ảnh, nó sẽ được phác họa thật nhanh
chóng. Khi phát hiện ra mình viết sai thì cũng chẳng cần phải quay lại để sửa
chữa, mà sẽ để suy nghĩ của mình được liên tục.
Brainstroming không suy nghĩ về chỉ 1 thứ mà suy nghĩ đến tất cả những thứ
có liên quan đến nó. Người ta cứ viết hay vẽ mà không cần dừng bút để suy
nghĩ. Nếu bạn dừng bút trong khoảng thời gian dài hơn 10 giây, điều đó có
nghĩa là bạn đã khai thác quá nhiều về ý tưởng đó, hãy lập tức bỏ qua một
bên và quay sang những thứ liên quan khác, và rồi sẽ quay lại với nó ở giai
đoạn sau. Mục đích của quá trình Brainstorming không phải là tìm được
chính xác một ý tưởng hoàn thiện mà là đưa ra được càng nhiều ý tưởng
càng tốt, do đó không nên e ngại khi viết ra những điều mà bình thường bạn
nghĩ.Ngoài việc đưa ra thật nhiều ý tưởng, brainstorming còn giúp ta phân
tích kỹ vấn đề, tự xem xét tất cả vấn đề có thể xảy ra khi trong khi ta liên tục
đặt ra những câu hỏi.
Ứng dụng: Brainstorming được sử dụng trong các công việc sau đây như
phát triển sản phẩm mới; quảng cáo; giải quyết vấn đề; quá trình quản trị;
quản trị dự án; xây dựng nhóm; xây dựng kế hoạch kinh doanh.
Một vài nhận xét
Phương pháp này có thể tiến hành bởi một hay nhiều người. Số lượng người
tham gia nhiều sẽ giúp cho phương pháp tìm ra lời giải được nhanh hơn hay

toàn diện hơn nhờ vào nhiều góc nhìn khác nhau bởi các trình độ, trình tự
khác nhau của mỗi người.Ngày nay, người ta có thể tiến hành bằng cách nối
các máy tính cá nhân vào chung một mạng làm cùng tiến hành
brainstroming. Bằng cách này những người ở xa nhau cùng có thể tham gia
và brainstroming còn được giúp đỡ bởi các phương tiện và tài
nguyên hiện đại
4. Kỹ thuật StoryBoarding
1. Những điểm chính
• Mục đích là đưa ra các phản ứng sớm “yes, but”
• Kỹ thuật này có thể là thụ động, chủ động hay là kết hợp cả 2 yếu tố trên.
• Kỹ thụât này nhận diện người chơi, giải thích những gì xảy ra với họ, xảy ra như thế
nào
• Tạo ra storyboard sơ sài, dễ sửa chữa.
4.2 Các loại StoryBoards
• Storyboards dạng thụ động:
là dạng storyboard để kể cho người dùng một kịch bản. Chúng có thể
bao gồm các bản phác thảo, tranh ảnh, hình chụp màn hình, bản thuyết
trình powerpoint, hoặc các mẫu đầu ra thử nghiệm.
• Storyboards dạng chủ động:
Storyboards chủ động là các hoạt cảnh hoặc tự động, có thể bằng một
slide trình chiếu được sắp xếp tự dộng sẵn hoặc một công cụ tạo hoạt
cảnh hay thậm chí là cả một thước phim.
• Storyboards tương tác:
để cho người dùng trải nghiệm hệ thống trong một cách thức giống với
thực tế. Cách này đỏi hỏi phải có sự tham gia của người sử dụng để thực
hiện được. Storyboards tương tác có thể giả lập hoặc tạo dựng mô hình
hay có thể nâng cao tới mức mã dùng một lần (throwaway code).
3. StoryBoards làm những gì?
Trong phần mềm, Storyboards được sử dụng thường xuyên để làm việc
thông qua các chi tiết của giao diện tương người máy. Trong Lĩnh vực

này, mỗi người có thể có ý kiến khác nhau về cách thức giao diện làm
việc. Storyboards cho hệ thống người dùng xử lý với ba yêu tố của hoạt
động
• Người chơi là ai?
• Điều gì xảy ra với họ?
• Nó xảy ra như thế nào?
4. Công cụ và kỹ thuật cho StoryBoarding
5. Kỹ thuật Use Case
Use cases là một biểu diễn UML cho các yêu cầu của một hệ thống. Để ghi
nhận các yêu cầu cho hệ thống, use cases phát triển trong quá trình phát hiện sẽ
có giá trị hơn nữa ngay cả trong quá trình phân tích và thiết kế. Phương pháp
use-case rất mạnh mẽ trong suốt quá trình phát triển phần mềm, ví dụ như use
cases đóng một vai trò quan trọng trong quá trình kiểm thử.Use cases miêu tả sự
tương tác giữa user và hệ thống, và tập trung vào những gìhệ thống tương tác
với user. Hơn nữa, khi các hành động được miêu tả theo một trình tự nối tiếp, sẽ
là dễ dàng để theo dõi hành động và thu thập được sự hiểu biết về những gì hệ
thống tương tác với user. Trong biểu đồ UML, use case được biểu diễn bằng một
hình oval chứa tên của use case.
1. Xây dựng Use Case
Mô hình use-case cho một hệ thống bao gồm tất cả actor của hệ thống và tất cả
các use cases khác nhau mà theo đó các actor tương tác với hệ thống, theo cách
đó miêu tả một cách toàn bộ hành vi chức năng của hệ thống. Mô hình use-case
cũng biểu diễn mối quan hệ giữa các use cases, mà nằm ngoài sự hiểu biết của
chúng ta về hệ thống.
Đầu tiên là tạo biểu đồ mô tả ranh giới hệ thống và xác định các actor của hệ
thống. Việc này tiến hành song song với việc xác định stakeholders và ranh giới
hệ thống. Ví dụ một hệ thống quản lý kho hàng có thể có ranh giới hệ thống như
hình sau:
Hệ thống kho hành ban đầu với các actor được xác định.Việc phân tích hệ thống
sâu hơn xác định những luồng nhất định của hành vi hệ thống là cần cho việc hỗ

trợ nhu cầu người dùng. Những luồng này là các use cases, hoặc những trình tự
cụ thể mà users tương tác với hệ thống để thực hiện một mục tiêu cụ thể. Các ví
dụ của use cases cho hệ thống này có thể bao gồm:
• Phân phối thủ công các mục trong kho hàng.
• Nhập một mục mới trong kho hàng.
• Kiểm tra các mục trong kho hàng.
2. Áp dụng Use Case vào phân tích yêu cầu phần mềm
Use cases được viết theo ngôn ngữ tự nhiên của user nên rất dễ dàng để miêu
tả vàlàm tài liệu. Use cases cung cấp một định dạng đơn giản và có cấu trúc
xoay quanh việc nhóm phát triển và user có thể làm việc cùng nhau để mô tả
hành vi của một hệ thống có sẵn hoặc định nghĩa hành vi của một hệ thống mới.
Và mỗi user độc lập sẽ tự nhiên tập trung vào những khả năng hệ thống cần để
thực hiện công việc tốt hơn. Ngoài ra, nếu các hành vi được phát hiện đầy đủ
với tất cả các user tiềm năng, nhóm làm việc đã đi được một đường dài hướng
tới mục tiêu của sự hiểu biết đầy đủ của các hành vi mong muốn. Ở đây có thể
có một vài chức năng chưa được khám phá ở cuối quá trình.
Chúng ta cũng phải hiểu rằng users của hệ thống chỉ biểu diễn một lớp của
stakeholders, và chúng ta có thể cần phải áp dụng các kĩ thuật khác để thu thập
yêu cầu
từ những stakeholder khác như các khách hàng không phải người dùng, quản lý,
nhà thầu phụ … Ngoài ra, use cases không hữu ích trong việc xác định các khía
cạnh phi chức năng của yêu cầu hệ thống, như yêu cầu cho tính khả dụng, tính
tin cậy, hiệu năng và tương tự. Chúng ta cần những kĩ thuật khác để giải quyết
những vấn đề này. Sau khi tất cả use cases, actors và objects trong hệ thống
được xác định, bước tiếp theo là cải tiến hành vi chức năng chi tiết của mỗi use-
case. Đặc tả use-case này bao gồm miêu tả bằng văn bản và đồ họa của use-case,
được viết từ góc nhìn của user. Đặc
tả này có thể xem như là một container miêu tả một chuỗi các sự kiện lien quan,
do đó có thể được dùng để bao hàm các yêu cầu khác sẽ được phát triển hơn nữa
vào thời gian sau.Vì use cases định nghĩa tương tác hệ thống với user, đây là

thời điểm thích hợp để định nghĩa, ít nhất là ở mức khái niệm, màn hình, các
hiển thị, front panels … mà tương
tác với user. Các thiết kế đồ họa chi tiết có thể để tới bước tiếp theo.
Đặc tả use-case cho “Phân phối thủ công các mục trong kho hàng”
3. Role Playing
Mặc dùng đúng là việc quan sát và đặt câu hỏi giúp chúng ta hiểu, nhưng sẽ là
không đầy đủ nếu cho rằng, chỉ thông qua việc quan sát, các nhà phát triển và
phân tích có thể đạt được một sự hiểu biết đúng đắn và sâu sắc của vấn đề được
giải quyết, do đó, một sự hiểu biết rõ ràng về các yêu cầu của một hệ thống có
thể giải quyết vấn đề này.
• Chúng ta cần hiểu rằng rất nhiều người dùng không thể hiểu rõ các thủ tục họ làm
theo hoặc yêu cầu cần được giải quyết.
• Rất nhiều user không có tự do để thừa nhận rằng họ không theo những thủ tục được
quy định, do đó những gì họ nói có thể không phải những gì họ thực sự làm.
• Các cá nhân có những mẫu của hoạt động công việc đã ăn sâu và áp dụng cách giải
quyết hoặc con đường duy nhất của việc thực thi công việc đó có thể che đậy vấn đề
thực từ người quan sát.
• Là không thể cho bất kì người phát triển nào để đự đoán tất cả các câu hỏi cần được
hỏi hoặc cho bất kì user nào biết câu trả lời cho các câu hỏi của nhà phát triển.
Để giải quyết các nguyên nhân riêng biệt này, một hoạt động đơn giản “role
playing” có thể có hiệu quả mạnh mẽ.
3.1. How to Role Play
Trong dạng đơn giản nhất của role playing, các nhà phát triển, nhà phân tích
và có thể mọi thành viên của nhóm phát triển đơn giản là đảm nhiệm vị trí
của user và thực thi hoạt động công việc của khách hàng. Có ít nhất hai cách
để tìm thấy nguyên nhân cốt lõi:
• Sử dụng kĩ thuật fishbone, cùng với phỏng vấn khách hàng, và phân tích các đơn
đặt hàng có lỗi. Định lượng lỗi theo loại và giải quyết những lỗi có số lượng cao
nhất trong thiết kế của hệ thống mới. Việc này có thể cung cấp một sự hiểu biết có
định lượng cho vấn đề và có lẽ là khá hiệu quả.Tuy vậy, nếu không hiệu quả, bạn

nên thay đổi cả quan điểm của bạn và chiến lược giải pháp của bạn. Để làm được
điều đó, nên có một cách đơn giản và hiệu quả hơn để hiểu một cách rõ ràng về vấn
đề.
• Nhà phát triển, phân tích có thể trải nghiệm vấn đề và sai sót cố hữu trong hệ thống
bằng việc thâm nhập vào một vài đơn hàng thực.
3.2. Các kĩ thuật khác tương tự
6. Kỹ thuật Prototyping
1. Các điểm chính
• Prototyping (làm mẫu) cực kỳ hiệu quả trong việc xác định vị trí các hội chứng
“Có,nhưng” (không chắc chắn, không bền, không đảm bảo tính lâu dài ...) và
“những thất bại vẫn chưa được phát hiện” (rủi ro tiềm tàng).
• Một mẫu các yêu cầu phần mềm là một sự thi hành riêng lẻ của hệ thống phần mềm,
được xây dựng để giúp đỡ các developers, người dùng và khách hàng hiểu tốt hơn
về yêu cầu hệ thống.
• Thực hiện làm mẫu các yêu cầu còn “mờ”, còn chưa rõ ràng: nhờ đó, mặc dù những
điều đã biết hoặc còn “ẩn ý” vẫn chưa được định nghĩa hoặc còn được hiểu chưa rõ
ràng.
Các mẫu phần mềm là hiện thân sớm của hệ thống phần mềm, cho chúng ta
ta một phần chức năng của một hệ thống mới.Mẫu thử cho phép người dùng
có thể chạm, cảm nhận và tương tác với một hệ thống mẫu theo cách mà
không một công nghệ nào khác có thể làm được.
2. Các kiểu mẫu thử
Các mẫu thử có thể được phân loại theo nhiều cách (throwaway,
evolutionary, operational, vertical, horizonal, userinterface algorithmic ...).
Tùy vào vấn đề cần giải quyết mà chúng ta xây dựng các mấu thử khác
nhau.
• Architectural prototype (mẫu thử hướng kiến trúc) – cho chúng ta thấy khả năng có
thể thực thi được của công nghệ.
• Throwaway prototype (mẫu thử dùng một lần) – sử dụng bất cứ công nghệ, sự mô
phỏng ... hay bất cứ cái gì để hoàn thiện kết quả của bạn. Mẫu chỉ dùng cho một

mục đích, sau khi hoàn thành, mẫu sẽ được bỏ đi
Nếu điểm yếu của dự án là giao diện người dùng, ngược lại bạn sẽ phát triển
một mẫu thử yêu cầu (requirements prototype), sử dụng bất cứ công nghệ gì
cho phép bạn làm mẫu giao diện nhanh nhất có thể.
Sử dụng cây quyết định để chọn loại mẫu thử tốt nhất cho hệ thống phần
mềm.
Figure Decision tree for prototype selection: (a) requirements prototypes;
(b) architectural prototypes
Requirements Prototypes – Các mẫu thử yêu cầu
Mẫu thử yêu cầu phần mềm (software requirements prototype) là sự thi hành
cục bộ (riêng lẻ) của hệ thống phần mềm, được xây dựng để giúp các nhà
phát triển (developers), người dùng (users) và khách hàng (customers) hiểu
tốt hơn về yêu cầu của hệ thống.
Vì mục đích phát hiện ra các yêu cầu phần mềm, chúng ta thường chọn cách
xây dựng các mẫu thử như “throwaway, horizonal(rộng), user interface”
prototype (mẫu thử dùng một lần, mẫu thử rộng, mẫu thử người dùng).
Horizonal prototypes (các mẫu thử rộng) ám chỉ rằng chúng ta sẽ thử xây
dựng một dải khá rộng chức năng của hệ thống, ngược lại, vertical prototype
xây dựng chỉ một vài yêu cầu nhưng theo một số phương pháp khá chất
lượng. User interface prototype ngụ ý rằng chúng ta sẽ xây dựng hầu hết các
giao diện của hệ thống hơn là để người dùng thi hành các giải thuật và các
logic xung quanh phần mềm hoặc làm cả mẫu thử giao diện cho các hệ thống
khác, thiết bị khác. Khi là một công cụ khai thác, một mẫu thử giữ vai trò
của nó theo vài cách khác nhau :
• Được xây dựng bởi người phát triển, nó có thể chứa sự xác nhận của khách hàng
rằng người dùng đã hiểu yêu cầu.
• Được làm bởi người phát triển, nó có thể được dùng như xúc tác khuyến khích
khách hàng nghĩ thêm các yêu cầu khác.
• Được làm bởi khách hàng, nó có thể giúp trao đổi thông tin với nhà phát triển.
Trong cả ba trường hợp, kết quả sẽ là xây dựng mẫu theo phương pháp tiêu

tốn ít tài nguyên nhất. Nếu nó quá đắt để xây dựng, nó có thể có hiệu quả
hơn khi áp dụng vào hệ thống thật.
Nhiều mẫu thử phần mềm xoay sang hướng mẫu thử yêu cầu và được sử
dụng chủ yếu để nắm được diện mạo của giao diện hệ thống cần xây dựng.
Có hai lý do cho việc này :
• Có nhiều công cụ, có chi phí không quá đắt và đôi khi là miễn phí hỗ trợ việc xây
dựng giao diện rất nhanh.
• Với các hệ thống có tương tác người dùng khá nhiều, một giao diện người dùng
được làm mẫu sẽ khám phá ra rất nhiều các yêu cầu khác, như các chức năng đã
được cung cấp tới cho người dùng, khi nào các chức năng sẵn sàng cho người sử
dụng và khi nào các chức năng chưa xuất hiện với người dùng.
• Tuy nhiên, chúng ta cần chắc chắn rằng tính khả dụng của những công cụ này
không làm ảnh hưởng tới việc xây dựng mẫu thử cho các phần của hệ thống không
có rủi ro cao nhất khi bắt đầu.
Làm mẫu thử cho cái gì (What to prototype):
Trong một tình huống cụ thể, chúng ta hiểu về những nhu cầu của
người dùng sẽ có phạm vi từ hiễu rõ và dễ dàng diễn đạt tới không hiểu gì:
Figure Continuum of understanding user needs
(Well-understood requirements) Hiểu rõ yêu cầu có hiển nhiên nhận thấy
được từ ngữ cảnh của miền ứng dụng và kinh nghiệm của người dùng và
kinh nghiệm của đội với một hệ thống cũng kiểu.
(Unknown requirements)Những yêu cầu chưa biết, mặc dù, là những rủi ro
chưa được phát hiện (“Undiscovered Ruins”) mà chúng ta thường mong là sẽ
biết đến sau đó. Nhưng không may thay,chúng ta không thể làm những mẫu
thế này, nếu có thể, chúng sẽ không còn là chưa biết tới nữa (unknown).
Chính việc này đã đặt vị trí cho việc làm mẫu thử các phần “mờ” (fuzzy part)
ở giữa. Những yêu cầu này (Fuzzy) có thể được biết tới hoặc được ngầm
hiểu nhưng chúng thường được định nghĩa khá nghèo nàn và tiếp thu được
rất ít thông tin.
Xây dựng mẫu thử

Sự lựa chọn công nghệ sử dụng trong khi xây dựng mẫu thử phụ thuộc
vào các quyết định trong tương lai (ở phía bên phải cây quyết định).
Đánh giá kết quả (Evaluating the results):
Kết quả của chu trình làm mẫu có thể gói gọn trong hai ý :
• Tính “mờ” cần được hiểu rõ ràng hơn.
• Thử nghiệm mẫu chắc chắn sẽ khám phá ra một đáp ứng “Có, nhưng ...” từ phía
người dùng, do đó, những nhu cầu trước kia chưa biết sẽ “lộ ra” (become known).
Đơn giản nhìn một tập các hành vi sẽ giúp người dùng hiểu những yêu cầu khác
phải được đảm đương trong hệ thống.
Trong bất cứ trường hợp nào, Prototyping luôn luôn đưa ra được kết quả. Do
đó, bạn nên làm mẫu bất cứ ứng dụng mới nào.
III. Sử dụng EA trong phát hiện và Tổng hợp yêu cầu
1. Sử dụng EA với kĩ thuật BrainStorming
Sử dụng Mind Mapping Diagram để phát triển các ý tưởng trong những lần
BrainStorming


2. Sử dụng EA với kĩ thuật Prototyping (Mẫu : GUI)
Ví dụ một số mẫu GUI
Xây dựng một số mẫu GUI có sẵn lấy ý kiến người dùng hay kiếm tra yêu
cầu của các chức năng

3. Sử dụng EA với kĩ thuật Use Case
Phần 2 : Các kỹ thuật phân tích các yêu cầu phần mềm
I. Giới thiệu chung
1. Mục đích
Mục đích của phần báo cáo này là giúp người đọc hiểu được các kỹ thuật
phân tích yêu cầu và sử dụng EA trong phân tích yêu cầu.
• Phát hiện và giải quyết xung đột giữa các yêu cầu.
• Phát hiện ra phạm vi của phần mềm và và nó phải tương tác như thế nào với môi

trường.
• Yêu cầu hệ thống phức tạp bắt nguồn từ các yêu cầu phần mềm
2. Phạm vi
Phạm vi trong các dự án phần mềm
3. Tài liệu tham khảo
II. Các kỹ thuật phân tích yêu cầu phần mềm
1. Requirement Classification
1. Giới thiệu
2. Function Requirements
Yêu cầu chức năng nói rõ hành hệ thống hoạt động như tế nào. Những
yêu cầu thường hướng hành động
3. Non-Function Requirements
 Tính khả dụng
 Độ tin cậy
 Hiệu năng
 Hỗ trợ
4. Design Contraints
Hạn chế tối thiểu trên thiết kế của hệ thống hoặc quy trình chúng tôi sử
dụng để xây dựng hệ thống.
2. Conceptual Modeling
Mô hình phát triển của một vấn đề thực là chia khóa đến phân tích yêu cầu
phần mềm. Mục đích của chúng là giúp đỡ trong việc hiểu vấn đề hơn là
thực thi thiết kế giải pháp. Sau đây khái niệm mô hình bao gồm mô hình thực
thi từ vẫn đề cấu hình tên miền đến phản ánh các mỗi liên hệ trong thế giới
thực và sự phụ thuộc.
Một số loại mô hình có thể được phát triển, chúng bao gồm dữ liệu và các
luồng điều khiển, trạng thái của mô hình, sự kiện rằng buộc, tương tác giữa
các user, các mô hình đối tượng, các mô hình dữ liệu và nhiều cái khác.
Một vài mô hình có thể được phát triển. Nhân tố ảnh hưởng lựa chọn mô
hình bao gồm :

 Vấn đề tự nhiên. Một vài kiểu nhu cầu phần mềm mà khía cạnh chắc chắn được
phân tích chính xác các phần.
 Sự thành thạo của kĩ sư phần mềm. nó thường tạo ra nhiều hơn chấp nhận lời giải
thích mô hình hoặc phương thức với những kĩ sư phần mềm có kinh nghiệm.
 Các yêu cầu quy trình của khách hành
 Những phương thức và công cụ có giá trị.
3. Architectural Design and Requirements Allocation
• ở vài điểm này, kiến trúc của giải pháp phải được suy ra . thiết kế kiến trúc là điểm
mà ở đó các yêu cầu tiến triển chồng lên nhau với phần mềm hoặc thiết kế các hệ
thống và minh họa nó có thể xóa sự tách biệt của hai nhiệm vụ.
• Có nhiều lựa chọn, kĩ sư phần mềm hành động như kiến trúc phần mềm bởi quy
trình của phân tích và dàn dựng các yêu cầu theo yêu cầu cái mà thành phần của