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

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

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

Hà Nội 11-2010

M c l c ục lục ụ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 4

I Phân tích bài toán 4

II Xác định quá trình phát triển các yêu cầu phần mềm 7

III Xây dựng khả năng (vision) và phạm vi (scope) của phần mềm 7

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 9

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 10

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) 11

1 Interview 12

2 Requirements Workshops 14

3 Brainstorming and Idea Reduction 14

4 Storyboarding 19

5 Applying Use Cases 20

6 Prototyping(tạo mẫu) 20

VII Sử dụng EA trong phát hiện yêu cầu phần mềm: 21

1 Các thành phần của use case: 22

1.1 Actor: 22

1.2 Use case 23

1.3 Collaboration 25

1.4 Boundary: 26

1.5 Package: 26

2 Use case diagram connectors: 27

2.1 Use: 27

2.2 Associate 27

2.3 Generalize 28

2.4 Include: 28

2.5 Extend 28

2.6 Realize: 28

2.7 Invokes 29

2.8 precedes 29

3 Ví dụ về kĩ thuật use case: 29

Phần 2 Các kỹ thuật phân tích các yêu cầu phần mềm Sử dụng EA trong phân tích các yêu cầu phần mềm 30

I Requirements Classification: 31

1 Yêu cầu chức năng: 31

2 Yêu cầu phi chức năng 32

II Conceptual Modeling 33

III Architectural Design and Requirements Allocation 33

IV Requirements Negotiation 34

V Using the Use Cases 35

VI Sử dụng EA trong phân tích yêu cầu phần mềm: 36

Phần 3: Xây dựng tài liệu đặc tả yêu cầu phần mềm Sử dụng EA trong hỗ trợ xây dựng các tài liệu đặc tả yêu cầu phần mềm 38

I Đặc tả yêu cầu phần mềm: 38

1 Các lưu ý khi đặc tả yêu cầu phần mềm (SRS): 38

1.1 Ghi lại các nguyên tắc của công việc: 39

1.2 Đặc tả các yêu cầu phần mềm theo mẫu: 40

1.2.1 Gán nhãn các yêu cầu phần mềm (labeling): 40

1.2.2 Đánh dấu những điểm chưa rõ trong đặc tả: 40

1.2.3 Mối liên quan giữa đặc tả và giao diện người sử dụng: 41

1.3 Các mẫu đặc tả yêu cầu phần mềm (SRS template): 41

1.4 Đánh giá chất lượng của các gói đặc tả yêu cầu phần mềm hiện đại: 43

1.5 Các phương pháp đặc tả yêu cầu: 43

2 Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm: 44

II Sử dụng EA trong đặc tả yêu cầu phần mềm 47

1 Tạo các yêu cầu phần mềm bên ngoài: 47

2 Tạo các yêu cầu phần mềm bên trong các yêu cầu khác (Internal Requirement): 47

3 Truy vết và liên kết các yêu cầu ngoài 51

Tài liệu tham khảo: 58

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êubiể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ủacá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ầukhác (yêu cầu phi chức năng)

I Phân tích bài toán

- 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ềucầ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íchvấ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 ý?

- Bước 2: hiểu gốc của nguyên nhân – vấn đề sau vấn đề

 Độ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ệcnhậ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áccủ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

- 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áncủa phần mềm và các kĩ thuật sẽ được sử dụng để phát hiện các yêucầ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ủaphầ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-8trang 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 nhaucho 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ềmmới: tại sao, cơ sở nào Có thể giải thích tổng thế lịch sử hoặctì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 đangtồn tại vấn đề mà phần mềm sẽ giải quyết Có thể mô tả ngắngọ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

 Yêu cầu khách hàng hay yêu cầu thị trường: mô tả các đối tượngkhá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ăngcủa phần mềm sẽ cung cấp cho khách hàng: khả năng giải quyếtcông việc, khả năng tiết kiệm, khả năng tự động hóa các côngviệ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ầnmề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ăngcủ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ạncủ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ácchấ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ạikhá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ầnmềm (objectives); các ràng buộc và hạn chế (constraint); mức độ

tự do của phần mềm (khả năng cân đối giữa mục tiêu và cácrà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ườisử 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ườisử 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ữngkhách hàng này

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ầnmề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ặ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ớingườ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áchhàng) Đó là:

- Interview (Phỏng vấn)

- Requirements Workshops (Hội thảo)

- Brainstorming and Idea Reduction

- 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ằngcá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êucầ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ữngcâ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 chonhững câu trả lời với người phỏng vấn

- 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 đảmrằ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 tinthu 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 nhanhchó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ẽ đượcnghiê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ìnhthiế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 haynhữ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ướngdẫ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 thamkhảo đường như thế nào, và điều gì họ mong muốn ở một hệ thống hướngdẫ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

- 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ốnghướ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ợpnhiề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 đầutrô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

- 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ưởngmớ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ánhphạ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ủatoà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ộtcâ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 đốivớ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

- 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ươnglai

Các qui tắc của kĩ thuật động não:

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 áplự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ểunhó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ắcphụ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ênquá quen thuộc với bạn, đến lúc nào đó bạn đi trên con đường khác, quang cảnhmớ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ạnkhông để ý tới Đường lạ thì bạn dễ bị lạc, khi bạn đang trong trạng thái khôngbiết đường nào để về nhà, bạn phải tự tìm kiếm đường để về, khi đó vô tình bạnlạ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 theomộ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ênquan 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ủangườ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

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ộtquán cafe ở Mĩ Đây chính là hình ảnh một thư viện được nhìn theo một chiềuhướng khác Khi ta bước vào quán café đó, ta sẽ có cảm giác như mình đang đivà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ệnphiê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ậtnhiều ý tưởng cụ thể, để qua đó tổng hợp lại thành những ý chính cho sản phẩmcủ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ếcbút và con mèo Hai hình ảnh tưởng chừng không liên quan đến nhau Vậy khihã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èocầ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àulô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ểudá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ácnhau 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 khinghe 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

- Tiến hành storyboard dễ dàng và thường xuyên trên mọi dự án với sự pháttriể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ùngPowerPoint, 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 độnghoặc được tự động hóa, có lẽ bởi một chuỗi các slide thuyết trình tự độnghoặ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ụngtrong một trật tự thực hiện Sự ảnh hưởng lẫn nhau của storyboards có thể bắtchướ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

- 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ếthoặc hiểu ngầm, là những định nghĩa chưa được xác định và chưa được hiểurõ

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

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 haymộ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…

- Đ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ặplạ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úngsử dụng hệ thống theo những cách khác nhau thì chúng là hai actor, ngượclạ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ựchiệ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 đó

Đặ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 usecase 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ốngtại cuối use case Hệ thống phải thuộc một trong những trạng thái đó khiuse 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

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ácelements của chúng Khi được sử dụng để trình bày các elements classtrong 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ằmmục đích tổ chức use – case Diagrams và Class diagrams, mặc dù sử dụngpackage 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

2.4 Include:

2.5 Extend

2.6 Realize:

Biểu diễn cho việc thiết kế use case Cần tách riêng use case và case hiện thực nhờ đó có thể quản lí chúng một cách riêng biệt  có thểthay đổi use case thiết kế mà không ảnh hưởng đến use case gốc.

use-2.7 Invokes

2.8 precedes

3 Ví dụ về kĩ thuật use case: