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 đề,

• 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 ở

• 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.

- 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

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 ý

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

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.

- 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

- 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