bài tiểu luận các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm. sử dụng ea trong phát hiện và tổng hợp các yêu c

Trường Đại Học Bách Khoa Hà Nội
Viện Công Nghệ Thông Tin & Truyền Thông

BÀI TIỂU LUẬN SỐ 1
Giảng Viên Hướng Dẫn: Huỳnh Quyết Thắng
Sinh Viên Thực Hiện: Lê Thị Bích Thuận
Lớp: CNPM-K52
MSSV: 20073837
Hà Nội 11-2010
Mục lục
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. S> d@ng EA
trong phát hiện và tổng hợp các yêu cầu phần mềm.
TL:
Phát hiện các yêu cầu phần mềm:
- Phân tích bài toán
- Xác định quá trình phát triển các yêu cầu phần mềm
- Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm
- Xác định các nhóm người s> d@ng và đặc tính của họ và đại diện tiêu
biểu cho mỗi nhóm
- Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện của
các nhóm người s> d@ng
- Xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu
khác (yêu cầu phi chức năng)
I. Phân tích bài toán
Lê Thị Bích Thuận – CNPM-K52 Page 2
- Phân tích bài toán là quá trình tìm hiểu vấn đề thế giới thực và những
gì mà người s> d@ng cần và gợi ý cách giải quyết để gặp những điều
cần đó.
- M@c đích của phân tích vấn đề là để thu được sự hiểu biết nhanh hơn,
trước khi bắt đầu phát triên, của việc giải quyết vấn đề.
- Để nhận biết cái gốc của nguyên nhân, hoặc vấn đề ẩn giấu sau vấn đề,

hỏi mọi người trực tiếp tham gia.
- Nhận biết tác nhân của hệ thống là một bước khóa trong việc phân tích
vấn đề
5 bước c@ thể phải được thực hiện để đạt được m@c tiêu:
- Dành được sự thoản thuận trên mỗi giải thuyết vấn đề
- Hiểu được cái gốc của những nguyên nhân – vấn đề phía sau vấn đề
- Nhận biết được đối tác và người s> d@ng
- Định nghĩa được sự giải đáp cho bao quanh hệ thống
- Nhận biết giới hạn được đặt để giải quyết
- Bước 1: dành được sự thỏa thuận của giải thuyết vấn đề
• Đơn giản viết vấn đề ra và xem liệu tất cả mọi người có đồng ý?
• Trạng thái của vấn đề:
Table 4-1. Định dạng trạng thái vấn đề
Các thành phn Mô tả
Vấn đề Mô tả vấn đề
Các ảnh hưởng Nhận ra ảnh hưởng của đối tác nhờ vấn đề
Kết quả Mô tả sự đ@ng chạm của vấn đề này lên các bên
liên quan và hoạt động kinh doanh
Lợi ích Chỉ ra đề nghị gợi ý giải quyết và danh sách các
khóa lợi ích
- Bước 2: hiểu gốc của nguyên nhân – vấn đề sau vấn đề
Lê Thị Bích Thuận – CNPM-K52 Page 3
• Đội của bạn có thể s> d@ng các kí thuật khác nhau để thu được
sự hiểu biết của một vấn đề thực và nguyên nhân thực sự của nó.
Một kĩ thuật gọi là phan tích nguyên nhân gốc, với một cách có
hệ thống của vết lộ của gốc, hoặc cơ bản, nguyên nhân của việc
nhận biết vấn đề hoặc một dấu hiệu nhận biết của vấn đề.
- Bước 3: nhận biết các bên liên quan và người s> d@ng
• Ai là người s> d@ng hệ thống?
• Ai là khách hàng của hệ thống?

• Những ai sẽ bị ảnh hưởng bởi các kết quả mà hệ thống sản xuất?
• Ai sẽ phát triển và đặc biệt hóa hệ thống khi nó được giao hàng
và triển khai?
• Có phải là còn có những người s> d@ng trong hoặc ngoài khác
của hệ thống cần phải thêm địa chỉ?
• Ai sẽ duy trì hệ thống mới?
• Còn gì khác nữa không?
- Bước 4: định nghĩa được sự giải đáp cho bao quanh hệ thống
• Ai sẽ cung cấp, s> d@ng, hoặc lấy đi những thông tin từ hệ
thống?
• Ai sẽ điều khiển hệ thống
• Ai sẽ duy trì hệ thống?
• Nơi mà hệ thống có thể sẽ được s> d@ng?
• Nơi mà hệ thống nhận thông tin của nó?
• Những hệ thống bên ngoài nào sẽ tương tác với hệ thống?
- Bước 5: nhận biết giới hạn giới hạn được đặt để giải quyết:
• Giới hạn hệ thống thế năng: kinh tế, chính trị, kĩ thuật, hệ thống,
môi trường, chương trình và tài nguyên
II. Xác định quá trình phát triển các yêu cầu phần mềm
Lê Thị Bích Thuận – CNPM-K52 Page 4
- Xác định các bước tài liệu và mô tả qui trình chúng ta sẽ thực hiện quá
trình phát triển các yêu cầu phần mềm
- Mô tả phương pháp xác định các người s> d@ng trong phạm vi bài toán
của phần mềm và các kĩ thuật sẽ được s> d@ng để phát hiện các yêu
cầu phần mềm
- Mô tả các đặc tả hoặc các mô hình phân tích của phần mềm
- Các thông tin cho mỗi yêu cầu, trọn số của yêu cầu
- Các bước tiến hành phát hieenjcacs yêu cầu, phân tích yêu cầu.
III. Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm
- Khả năng và phạm vi của phần mềm tập hợp các yêu cầu phần mềm ở

mức độ cao
- Mô tả khả năng, m@c tiêu của phần mềm, các phạm vi ứng d@ng của
phần mềm,các hạn chế của phần mềm, một số đặc điểm của ứng d@ng:
ai s> d@ng, trong môi trường nào
- Thông thường tất cả các thông tin ngày được mô tả ngắn gọn trong 3-8
trang theo cấu trúc sau:
o yêu cầu phần mềm: mô tả các đặc điểm chính mà phần mềm mới sẽ
cung cấp cho khách hàng. Thông thường phần này sẽ rất khác nhau
cho những phần mềm khác nhau
• Cơ sở (background): mô tả lí do hợp lí cần phát triển phần mềm
mới: tại sao, cơ sở nào. Có thể giải thích tổng thế lịch s> hoặc
tình huống quyết định cần phải xây dựng phần mềm.
• Cơ hội (business opportunity): mô tả cơ hội trên thị trường đang
tồn tại vấn đề mà phần mềm sẽ giải quyết. Có thể mô tả ngắn
gọn một số phần mềm tương tự và các đặc tính của chúng và
giải thích tại sao cần làm phần mềm này.
• Đối tượng/ m@c tiêu: mô tả m@c tiêu mà phần mềm giải quyết
Lê Thị Bích Thuận – CNPM-K52 Page 5
• Yêu cầu khách hàng hay yêu cầu thị trường: mô tả các đối tượng
khách hàng mà phần mềm sẽ ph@c v@
• Các giá trị cung cấp cho khách hàng: mô tả chi tiết các khả năng
của phần mềm sẽ cung cấp cho khách hàng: khả năng giải quyết
công việc, khả năng tiết kiệm, khả năng tự động hóa các công
việc trước đây…
• Các rủi ro: mô tả các rủi ro của công việc khi phát triển phần
mềm, đánh giá các rủi ro và các phương pháp tránh.
o Khả năng của phần mềm (vision of solution): mô tả các khả năng
của phần mềm. ở đây sẽ không mô tả các chức năng phần mềm.
• Các khả năng: mô tả chính xác ngắn gọn các m@c đích dài hạn
của phần mềm.

• Các đặc điểm: danh sách các đặc điểm chính của phần mềm. các
đặc điểm này sẽ khác những phần mềm tương tự như thế nào
• Các ph@ thuộc và chấp nhận: ghi nhận lại các ph@ thuộc và các
chấp nhận đã thực hiện trong phần mềm.
o Phạm vi và giới hạn (scope and limitation): mô tả các giới hạn về
khả năng của phần mềm. phần mềm chỉ giải quyết bài toán ở mức
độ như vậy.
• Phạm vi của phiên bản đầu
• Phạm vi của các phiên bản tiếp theo
• Hạn chế và ngoại lệ
o Ngữ cảnh công việc (business context):
• Tiểu s> khách hàng: các đặc điểm của khách hàng, phân loại
khách hàng.
• Các trọng số dự án: chia làm 3 loại: các m@c tiêu chính của phần
mềm (objectives); các ràng buộc và hạn chế (constraint); mức độ
Lê Thị Bích Thuận – CNPM-K52 Page 6
tự do của phần mềm (khả năng cân đối giữa m@c tiêu và các
ràng buộc)
o Các yếu tố thành công của dự án:
• Các yếu tố làm dự án khả thi
• Các yếu tố chứng tỏ khả năng cạnh tranh của phần mềm.
IV. Xác định các nhóm người sử dụng và đặc tính của họ và đại diện
tiêu biểu cho mỗi nhóm
- Phân lớp người s> d@ng phần mềm:
• Phân loại theo đặc điểm:
• Phân loại theo vị trí địa lí
• Phân loại theo vai trò công việc
• Phân loại theo chức năng
• Liệt kê các phân loại (các lớp) và mô tả chi tiết các đặc điểm của người
s> d@ng ở từng lớp.

- Tìm các người s> d@ng tiêu biểu (presentative user)
- Khái niệm Product Champion: những đại diện tiêu biểu của từng nhóm người
s> d@ng. trên thực tếc các yêu cầu phần mềm sẽ được phát hiện từ những
khách hàng này.
Lê Thị Bích Thuận – CNPM-K52 Page 7
V. Phân tích và xác định các yêu cầu phần mềm dựa trên các đại diện
của các nhóm người sử dụng
Nguyên tắc của phát hiện yêu cầu phần mềm:
- Định nghĩa phạm vi và giới hạn phần mềm
- Xác định các phân nhóm người s> d@ng
- Xác định các đại diện của từng nhóm
- Xác định Product Champion của từng nhóm
- Lựa chọn kĩ thuật phát hiện yêu cầu phần mềm
- Áp d@ng kĩ thuật cho từng đại diện – Product Champion
- Xây dựng các tiêu thức chất lượng
- Chi tiết hóa (chuyển hóa) các trường hợp s> d@ng thành chức năng phần mềm
- Xem xét các trường hợp s> d@ng và chức năng
- Phát triển mô hình phân tích, giải thích và làm rõ với các khách hàng.
- Phát triển và đánh giá giao diện cho từng yêu cầu
- Phát triển các trường hợp kiểm th> cho các yêu cầu
- S> d@ng các trường hợp kiểm th> để kiểm tra
Lê Thị Bích Thuận – CNPM-K52 Page 8
- Lặp lại các bước 6-13 trước khi thiết kế.
- Phát hiện các yêu cầu phần mềm là một công việc phức tạp
- Đây chính lầ cầu nối để giải quyết bài toán
- Đây chính là cầu nối giữa phân tích viên và người s> d@ng
- Đòi hỏi rất nhiều nỗ lực và các phẩm chất của phân tích viên
- Một trong những kĩ thuật tiêu biểu để xác định và phát hiện các yêu cầu s>
d@ng là “use case – trường hợp s> d@ng”.
Các lỗi thường hoặc là những điểm nên tránh trong phát hiện yêu cầu:

- Có quá nhiều use-case
- Có các use-case trùng lặp
- Trong mô hình use-case xây dựng không được phép dựa vào giao diện với
người s> d@ng
- Định nghĩa dữ liệu trong các use-case
- Cố gắng gắn mỗi yêu cầu với một use-case
VI. Xây dựng các đặc tính xác định chất lượng yêu cầu và các yêu cầu
khác (yêu cầu phi chức năng)
Có 6 kĩ thuật phát hiện và tổng hợp các yêu cầu phần mềm(từ phía khách
hàng). Đó là:
Lê Thị Bích Thuận – CNPM-K52 Page 9
- Interview (Phỏng vấn)
- Requirements Workshops (Hội thảo)
- Brainstorming and Idea Reduction
- Storyboarding
- Applying Use Cases
- Prototyping
Sau đây ta phân tích từng kĩ thuật
1. Interview
- Phỏng vấn là một kĩ thuật đơn giản và thu được thông tin một cách trực tiếp.
- Các câu hỏi trong ngữ cảnh tự do có thể giúp cho việc phỏng vấn không bị
lệch lạc
- Có thể tiếp cận để tìm kiếm những mảng yêu cầu chưa được phát hiện bằng
cách thăm dò các tình huống.
- Hội t@ một số nhu cầu thông thường cần sẽ khởi đầu một “kho chứa các yêu
cầu” cho việc s> d@ng trong suốt dự án.
- Một bản câu hỏi không thay thế cho một buổi phỏng vấn.
Cách thức làm như thế nào?
- Lập lịch: thời gian, địa điểm.
- Thông báo m@c đích và phạm vi

- Có thể g>i trước một số câu hỏi.
- Chuẩn bị tiếp cận một cuộc phỏng vấn trong bối cảnh tự do, và ghi nhanh nó
vào một quyển sổ để xem đó là sự tham khảo trong suốt quá trình phỏng vấn.
Xem lại những câu hỏi ngay trước khi thực hiện cuộc phỏng vấn.
- Trước khi thực hiện phỏng vấn, nghiên cứu kinh nghiệm của nhà đầu tư và
công ti được phỏng vấn. Đừng đẩy cho những người được phỏng vấn những
câu hỏi mà bạn có thể đã có câu trả lời. Mặt khác, nó không gây thiệt hại cho
những câu trả lời với người phỏng vấn.
Lê Thị Bích Thuận – CNPM-K52 Page 10
- Trong suốt buổi phỏng vấn, ghi nhanh những câu trả lời vào trong sổ. (Đừng
cố gắng để đạt được một dữ liệu điện t> tại thời điểm này)
- Chuyển cho người khác những mẫu trong suốt buổi phỏng vấn để bảo đảm
rằng những câu hỏi đúng sẽ được trả lời.
Đánh giá cuộc phỏng vấn:
- Xác định mức độ đầy đủ của các thông tin thu thập.
- Xác định hiệu quả của kế hoạch đã lập và mức độ hoàn thành.
- Nếu chưa đạt yêu cầu đề ra: xem xét các giải pháp khác để bổ sung thông tin
thu thập, rút kinh nghiệm.
Ưu điểm của Interview:
- quan điểm cá nhân của người dùng th> sẽ được khai thác và ghi nhận
- Những hiểu lầm giữa người phỏng vấn và người được phỏng vấn được nhanh
chóng s>a lỗi.
- Đầu ra: có thể là những thông tin phi thống kê, những ý kiến này sẽ được
nghiên cứu, phân tích bởi các chuyên viên có kinh nghiệm.
Kĩ thuật interview được s> d@ng khi nào? Thường diễn ra trước quá trình
thiết kế nhằm thu thập các thông tin, những tri thức về lĩnh vực hoạt động hay
những yêu cầu c@ thể.
Vấn đề: đòi hỏi người phỏng vấn và phân tích có kinh nghiệm.
Lấy một ví d@ như sau: s> d@ng kĩ thuật phỏng vấn cho hệ thống máy hướng
dẫn khách tham du lịch(ở Hà Nội, chúng ta thấy khá nhiều loại máy như thế

này).
- Chuẩn bị một danh sách các câu hỏi xem mọi người thực hiện việc việc tham
khảo đường như thế nào, và điều gì họ mong muốn ở một hệ thống hướng
dẫn khách du lịch tự động?
- Phỏng vấn ít nhất 10 người xem họ mong muốn hệ thống hướng dẫn khách
du lịch tự động sẽ hoạt động như thế nào
Lê Thị Bích Thuận – CNPM-K52 Page 11
- Xác định các yêu cầu, sở thích và thái độ của người phỏng vấn về hệ thống
hướng dẫn khách du lịch tự động.
- Các yêu cầu khác từ phía người dùng: hình ảnh trực quan, gợi ý gợi nhớ…
2. Requirements Workshops
- Có lẽ đây là kĩ thuật công hiệu nhất cho việc phát hiện yêu cầu.
- Tập hợp tất cả các nhà đầu tư trong một thời gian ngắn nhưng lại thu hút
được sự tập trung mạnh mẽ
- Việc s> d@ng một người điều khiển bên ngoài có kinh nghiệp trong các quản
lí yêu cầu có thể bảo đảm thành công cho buổi meeting
- Động não là phần quan trọng nhất của meeting
3. Brainstorming and Idea Reduction
- Động não bao gồm cả ý tưởng chung và ý tưởng giảm.
- Các sáng tạo nhất, sự phát triển các ý tưởng thường là kết quả từ việc kết hợp
nhiều các ý tưởng, mà dường như chúng không liên quan đến nhau.
- Những kĩ thuật biểu quyết khác nhau có thể được s> d@ng ưu tiên cho các ý
tưởng được tạo ra
- Mặc dù kĩ thuật động não được ưa thích, web dựa trên sự động não có thể là
một sự thay thế trong một vài tính huống.
Khi tiến hành động não, cần tuân theo các nguyên tắc cơ bản:
- Loại trừ sự chỉ trích, phê bình: Những người tham gia phải từ bỏ các ý kiến
phê bình trong suốt quá trình tìm và phát triển ý tưởng của nhóm.
- Duy trì bầu không khí hoàn toàn tự do: Các ý tưởng được đưa ra trong bầu
không khí càng thoải mái tự do, cởi mở càng tốt. Đồng thời người đề xuất ý

tưởng không bị hạn chế về nội dung và không phải chứng minh tính chất
đúng đắn cũng như tính hiện thực của ý tưởng. Có nhiều ý tưởng ban đầu
trông có vẻ ngớ ngẩn, khác thường nhưng khi thực hiện lại đem lại kết quả
vượt trên sự mong đợi.
Lê Thị Bích Thuận – CNPM-K52 Page 12
- Số lượng ý tưởng càng nhiều càng tốt: khi càng có nhiều ý tưởng thì càng có
nhiều khả năng tìm được những giải pháp hữu ích.
- Kết hợp và phát huy ý tưởng của người khác: Trong quá trình phát triển ý
tưởng, thành viên có thể đưa ra các ý tưởng riêng dựa trên sự phát triển ý
tưởng của người khác. Hoặc có thể kết hợp nhiều ý tưởng thành một ý tưởng
mới
Có một số trạng thái tâm lí thường xuất hiện trong các hoạt động, cần tránh
phạm phải những trạng thái này để không cản trở sự sáng tạo của cá nhân và của
toàn nhóm, dưới đây là một số lời khuyên cần ghi nhớ và thực hiện
- Đừng cố tìm một câu trả lời đúng: Tùy theo tầm nhìn và sự hiểu biết của mỗi
người mà mỗi vấn đề có thể có nhiều câu trả lời đúng, nên đừng cố tìm một
câu trả lời đúng nhất
- Đừng luôn cố gắng tuân theo logic: Sự hợp lí không phải lúc nào cũng chiếm
ưu thế, mà thường có nhiều sự trái ngược giữa tình cảm của con người và
nguyên tắc của tổ chức
- Đừng tuân theo các nguyên tắc một cách cứng nhắc: Nếu muốn đổi mới và
cải tiến thì cần biết nghi ngờ và xem xét những giới hạn không rõ ràng đối
với tư duy
- Đừng quá lệ thuộc vào hiện thực: Có nhiều ý tưởng không thực tế có thể trở
thành nhữnh bàn đạp để sáng tạo
- Đừng cố tránh sự không rõ ràng: Sự sáng tạo có thể bị cản trở bởi sự quá
khách quan hay cá biệt hoá.
- Đừng quá lo sợ và cố tránh thất bại: Sự lo sợ thất bại có thể làm tê liệt quyết
tâm thực hiện những ý tưởng hay.
- Thêm một chút hồi tưởng: những trò chơi khôi hài thời thơ ấu sẽ có thể là

những gợi ý hay cho hiện tại, hoặc một hình tượng đã bắt gặp ở đâu đó cũng
có thể là một điểm trong ý tưởng
Lê Thị Bích Thuận – CNPM-K52 Page 13
- Tránh tình trạng quá biệt lập: Sự kết hợp chéo giữa các lĩnh vực chuyên môn
khác nhau thường rất hữu hiệu trong việc xác định tìm giải pháp.
- Đừng quá quan trọng hóa vấn đề: Sự hài hước, không khí thoải mái làm
giảm căng thẳng và thúc đẩy khả năng sáng tạo.
- Luôn luôn sáng tạo bắt đầu bằng ý tưởng mới: bằng cách nuôi dưỡng những
ý tưởng nhỏ bé bình thường và biến những ý tưởng ấy thành hiện thực, chúng
ta sẽ có thể phát triển và thực hiện những ý tưởng lớn hơn nhiều trong tương
lai.
Các qui tắc của kĩ thuật động não:
- Loại trừ sự phán xét
- Hoan nghênh sự say mê
- Cần có số lượng
- Cố gắng kết hợp và cải thiện
Ngày nay, các qui tắc này vẫn dẫn dắt các phiên họp động não. Hàng ngày,
các doanh nghiệp và các tổ chức tiến hành hàng nghìn phiên họp động não.
Không thể tính hết lợi ích mà kĩ thuật này mang lại trong việc nâng cao chất
lượng cuộc sống thông qua các sản phẩm và dịch v@ mới.
Trong những năm gần đây, người ta tiến hành nhiều nghiên cứu để đánh giá
hiệu quả của quá trình động não. Từ những nghiên cứu này chúng ta thấy có ba
điều kiện quyết định kết quả của các phiên họp động não:
Sự tận tâm trong nhóm: những nhóm nào quan tâm đến kết quả của các
phiên họp động não sẽ thu được hiệu quả cao hơn các nhóm đầu tư khác.
Cơ cấu nhóm: các nhóm khác nhau về nền tảng, kĩ năng và cấp độ tổ chức sẽ
hiệu quả hơn các nhóm đồng nhất.
Áp lực về sự đồng nhất: tất cả các nhóm đều tạo áp lực đối với thành viên
của mình để hướng tới tính đồng nhất. Để có một phiên họp động não hiệu quả
thì cần phải giảm những áp lực này đến mức tối thiểu. Và cách giảm những áp

lực này là dành thời gian để ý tưởng cá nhân nảy sinh, chia nhóm thành các tiểu
Lê Thị Bích Thuận – CNPM-K52 Page 14
nhóm, thường xuyên sắp xếp lại các nhóm và s> d@ng khiếu hài hước để khắc
ph@c những trở ngại về giao tiếp và tổ chức.
Các kĩ thuật thực hiện động não:
Khám phá con đường chưa được khai phá: Khi bạn trải nghiệm những điều
mới lạ, quan sát những cái mà bạn chưa từng quan sát bao giờ sẽ cho bạn có
được cách nhìn khác về sự vật, sự việc đó. Cũng như việc, hàng ngày bạn đi đi
về trên một con đường cố định, hình ảnh xung quanh con đường đó đã trở nên
quá quen thuộc với bạn, đến lúc nào đó bạn đi trên con đường khác, quang cảnh
mới lạ hoàn toàn, bạn sẽ dễ dàng kiếm được những điều thú vị mà lâu nay bạn
không để ý tới. Đường lạ thì bạn dễ bị lạc, khi bạn đang trong trạng thái không
biết đường nào để về nhà, bạn phải tự tìm kiếm đường để về, khi đó vô tình bạn
lại biết được một đường đi khác nữa. Trong sáng tạo cũng vậy, cứ mãi đi theo
một lối mòn khiến cho ta không thể nào tìm được ý tưởng mới. Bởi vậy, hãy cứ
đặt mình vào một trường hợp mới mẻ hoàn toàn, suy nghĩ khác đi, dẫn dắt mình
đi xa hơn với những gì mình đã từng nghĩ, bạn sẽ tìm được một “con đường”
mới lạ có thể dẫn bạn tới m@c tiêu một cách tốt hơn.
Nhìn vào sự hiển nhiên: trái ngược với kĩ thuật trên, với kĩ thuật này, bạn
cần phải quan sát kĩ những thứ bạn nhìn thấy hằng ngày. Ngoài ra bạn cũng nên
quan sát từ cách nhìn của người khác. Bạn th> đặt mình vào trường hợp của
người khác xem nếu là người ta thì họ sẽ nhìn nhận vấn đề này như thế nào.
Hoặc bạn có thể nhìn sự vật, sự việc theo một hướng khác.
Lê Thị Bích Thuận – CNPM-K52 Page 15
Với hình ảnh trên bạn nhận thấy điều gì?Cảnh trên chính là hình ảnh của một
quán cafe ở Mĩ. Đây chính là hình ảnh một thư viện được nhìn theo một chiều
hướng khác. Khi ta bước vào quán café đó, ta sẽ có cảm giác như mình đang đi
vào một cái thư viện bị lật ngược vậy.
Đặt ra giới hạn và điều kiện, luật lệ: khi tìm hiểu ý tưởng cho một sự vật, sự
việc nào đó mà liệt kê một cách tràn lan thì đó không phải là cách hữu hiệu, nó

sẽ dẫn dắt bạn đi quá xa. Do đó, bạ nên đặt ra giới hạn và điều kiện khi thực hiện
phiên họp động não. Ví d@ khi thực hiện một phiên họp động não về máy vi tính,
ta nên chia nhỏ nó ra, giới hạn chỉ tìm hiểu về kiểu dáng hay về chức năng, về
cấu hình, cũng có thể đặt ra điều kiện là máy vi tính được s> d@ng dành cho độ
tuổi nào, s> d@ng trong trường hợp nào. Triển khai từng ý nhỏ đó sẽ cho bạn thật
Lê Thị Bích Thuận – CNPM-K52 Page 16
nhiều ý tưởng c@ thể, để qua đó tổng hợp lại thành những ý chính cho sản phẩm
của mình.
Kết hợp các ý tưởng để tạo ra ý tưởng mới: đây là một kĩ thuật rất quan
trọng khi tìm kiếm ý tưởng. Hãy lấy một ví d@ đơn giản: có hai hình ảnh, chiếc
bút và con mèo. Hai hình ảnh tưởng chừng không liên quan đến nhau. Vậy khi
hãy th> kết hợp chúng lại? Chiếc bút có dán hình con mèo? Hình ảnh con mèo
cầm chiếc bút? Chiếc bút đặt trên lưng con mèo? Màu sắc của chiếc bút là màu
lông con mèo…Có rất nhiều ý tưởng xung quanh con mèo và chiếc bút. Do đó,
khi kết hợp hai hay nhiều thứ khác nhau theo chức năng, cấu tạo, màu sắc, kiểu
dáng, ta sẽ có được nhiều, rất nhiều ý tưởng, nghe qua có vẻ ngớ ngẩn, nhưng lại
có thể giúp bạn cho ra những sản phẩm độc đáo.
Siêu đối lập: khai thác những ý tưởng mang tính đối nghịch với vấn đề ta
muốn tìm hiểu, cũng là một cách để tìm kiếm ý tưởng theo nhiều hướng khác
nhau. Ví d@ tại sao không đặt chiếc thuyền chạy được trên cạn mà lại đặt cho nó
chạy dưới nước?
Siêu phóng đại: bên cạnh những ý tưởng mang tính đối nghịch như thế, ta lại
triển khai theo hướng phóng đại nó lên, nâng giá trị của nó lên gấp nhiều lần,
giống như một quả bóng phóng đại lên thì nó là một chiếc khinh khí cầu vậy.
Liên kết và quan hệ: với kĩ thuật này, bạn tạo những liên kết tới chủ đề của
mình theo một mối quan hệ nào đó. Hãy liệt kê những suy nghĩ đầu tiên khi
nghe nói đến chủ đề đó.
4. Storyboarding
- M@c đích của storyboarding là phát hiện sớm các tác động “Vâng, nhưng…”
- Storyboards có thể bị động, chủ động hoặc là ảnh hưởng lẫn nhau.

- Storyboards có thể nhận biết tham gia, giải thích chuyện gì xảy với họ, và mô
tả cách thức mà nó xảy ra.
- Tạo một phác thảo storyboard, dễ dàng để s>a đổi
Lê Thị Bích Thuận – CNPM-K52 Page 17
- Tiến hành storyboard dễ dàng và thường xuyên trên mọi dự án với sự phát
triển nội dung mới.
Các dạng của storyboards:
- Passive storyboards: kể về một câu chuyện của người s> d@ng. Có thể bao
gồm bức phác thảo, bức tranh, ảnh ch@p, hay trang thuyết trình dùng
PowerPoint, hoặc là các đầu ra mẫu.
- Active storyboard: cố gẳng để làm cho người dùng thấy “một cuộn phim
không thể được tạo ra”. Active storyboard là những hoạt động sống động
hoặc được tự động hóa, có lẽ bởi một chuỗi các slide thuyết trình tự động
hoặc một công c@ hoạt hình hay thậm chí là một bộ phim.
- Interactive storyboards: để cho kinh nghiệm người s> d@ng hệ thống một
cách thực thế, kiểu cư x> thực tế. Đòi hỏi sự tham dự của người s> d@ng
trong một trật tự thực hiện. Sự ảnh hưởng lẫn nhau của storyboards có thể bắt
chước hoặc có thể nâng cao đến điểm thông báo code.
5. Applying Use Cases
- S> d@ng use case, giống như storyboards, để nhận ra ai, cái gì và làm thể nào
để hệ thống hoạt động.
- Use case mô tả sự tương tác giữa một người s> d@ng và một hệ thống, chú ý
vào cái mà hệ thống làm cho người s> d@ng.
- Các mẫu use case mô tả tổng quan hoạt động chức năng của hệ thống.
- Mô tả cách thức hệ thống “phản ứng” với các sự kiện kích hoạt.
- Sự kiện kích hoạt là nguyên nhân thực thi.
- Mọi hoạt động của hệ thống là để “phản ứng” lại các sự kiện
- Hữu ích trong trường hợp mô tả các yêu cầu nghiệp v@ phức tạp.
6. Prototyping(tạo mẫu)
Lê Thị Bích Thuận – CNPM-K52 Page 18

- Tạo mẫu là một kĩ thuật đặc biệt hữu hiệu trong việc đánh địa chỉ “Đúng,
nhưng” và hội chứng “chưa tìm thấy sự dổ nát”
- Một tạo mẫu yêu cầu phần mềm là một phần thực thi của một phần mềm hệ
thống, xây dựng để giúp cho người phát triển, người s> d@ng, và khách hàng
tốt hơn việc hiểu yêu cầu hệ thống.
- Tạo bản mẫu những yêu cầu không rõ ràng: những điều đó, mặc dù được biết
hoặc hiểu ngầm, là những định nghĩa chưa được xác định và chưa được hiểu
rõ.
VII. Sử dụng EA trong phát hiện yêu cu phn mềm:
Một trong những kỹ thuật tiêu biểu để xác định và phát hiện các yêu cầu s>
d@ng là “Trường hợp s> d@ng” (use-case ).
Use case là một mô hình UML mô tả cách thức tương tác giữa các tác nhân
(actor) và hệ thống:
Các thành phần của toolbox và các kí hiệu liên kết s> d@ng trong biểu đồ use
case
Lê Thị Bích Thuận – CNPM-K52 Page 19
1. Các thành phần của use case:
1.1. Actor:
- Actor không phải là một phần của hệ thống. Nó thể hiện một người hay
một hệ thống khác tương tác với hệ thống. Một actor có thể:
• Chỉ cung cấp thông tin cho hệ thống
• Chỉ lấy thông tin từ hệ thống
• Nhận thông tin từ hệ thống và cung cấp thông tin cho hệ thống.
- Thông thường các actor được tìm thấy trong phát biều bài toán bởi sự trao
đổi giữa phân tích viên với khách hàng và các chuyên gia trong lĩnh vực.
- Có 3 loại actor chính là:
• Người dùng: ví d@: sinh viên, nhân viên, khách hàng…
• Hệ thống khác
• Sự kiện thời gian. Ví d@: kết thúc tháng, đến hạn…
Lê Thị Bích Thuận – CNPM-K52 Page 20

- Điều gì tạo nên một tập hợp Actor tốt? cần phải cân nhắc kĩ lưỡng khi xác
định actor của hệ thống. Công việc này thường được thực hiện lặp đi lặp
lại. Danh sách đầu tiên về các actor hiếm khi là danh sách cuối cùng.
Ví d@ như trong bài toán đăng kí các môn học của một trường Đại học, có
một câu hỏi là liệu các sinh viên mới vào trường là một actor và sinh viên
cũ là một actor khác? Giả s> câu trả lời là acos thì bước tiếp theo là xác
định xem cách thức mà hai actor này tương tác với hệ thống. Nếu chúng
s> d@ng hệ thống theo những cách khác nhau thì chúng là hai actor, ngược
lại sẽ chỉ là một actor mà thôi.
Việc mô tả một cách ngắn gọn về mỗi actor cần thêm vào mô hình. Mô tả
này cần chỉ rõ vai trò của actor khi tương tác với hệ thống.
Ví d@: sinh viên là những người đăng kí các lớp ở trường đại học.
1.2. Use case
- Một use case xác định một tập các thể hiện use case
- Trong đó mỗi thể hiện là một chuỗi các hành động được hệ thống thực
hiện và đem lại một kết quả thấy được có ý nghĩa đối với một actor c@ thể
nào đó.
Lê Thị Bích Thuận – CNPM-K52 Page 21
Đặc tả use case:
- Tóm tắt
- Dòng sự kiện ph@: các sự kiện và những hoạt động bất thường của use
case ngoài những hoạt động chính.
- Các yêu cầu đặc biệt
- Pre-condition(tiền điều kiện): mô tả trạng thái của hệ thống phải đạt được
để use case có thể bắt đầu
- Post-conditions (hậu điều kiện): liệt kê các trạng thái có thể của hệ thống
tại cuối use case. Hệ thống phải thuộc một trong những trạng thái đó khi
use case kết thúc.
- Điểm mở rộng
Khi s> d@ng usecase ta thể hiện được mối quan hệ giữa:

- Actor- actor
- Actor- use case
- Use case- use case
Lê Thị Bích Thuận – CNPM-K52 Page 22
1.3. Collaboration
Collaboration (hợp tác) xác định một tập các vai trò (role) và sự liên kết giữa
chúng.
Một Collaboration chỉ nên xác định vai trò và thuộc tính cần thiết để hoàn
thành một nhiệm v@ hoặc chức năng c@ thể
Lê Thị Bích Thuận – CNPM-K52 Page 23
1.4. Boundary:
Boundary dùng để phân biệt ranh giới , chẳng hạn các thành phần hay các hệ
thống ph@ , nhưng vẫn bao quát trong đó một use case
1.5. Package:
- Package Diagrams được s> d@ng để phản ánh tổ chức của packages và các
elements của chúng. Khi được s> d@ng để trình bày các elements class
Lê Thị Bích Thuận – CNPM-K52 Page 24
trong các package diagram thường cung cấp cái nhìn về các namespaces.
Điểm chung nhất s> d@ng package diagrams là để s> d@ng chúng nhằm
m@c đích tổ chức use – case Diagrams và Class diagrams, mặc dù s> d@ng
package diagrams không bị giới hạn trong các elements UML này
2. Use case diagram connectors:
2.1. Use:
2.2. Associate
2.3. Generalize
Lê Thị Bích Thuận – CNPM-K52 Page 25