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

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

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

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 5

I Giới thiệu 5

1 Mục đích 5

2 Phạm vi 5

3 Tài liệu tham khảo 5

II Các kỹ thuật phát hiện và tổng hợp phần mềm 5

1 Kỹ thuật Phỏng vấn 5

1.1 Những điểm chính 5

1.2 Các câu hỏi phạm vi tự do 5

1.3 Value-added Context 6

1.4 The moment of Truth 6

1.5 Biên soạn lại các dữ liệu cần thiết 6

1.6 Chú ý vào những sự đáng ngờ 6

2 Kỹ thuật Hội thảo 6

2.1 Tổng quát 6

2.2 Đẩy nhanh quá trình giải quyết 6

2.3 Sửa chữa cho hội thảo 7

2.4 Vai trò của sự thuận tiện 7

2.5 Thiết lập nhật kí công tác 7

2.6 Bắt đầu hội thảo 8

3 Kỹ thuật BrainStorming 8

3.1 Giới thiệu 8

3.2 Áp dụng 9

3.2.1 Định nghĩa vấn đề 9

3.2.2 Tập trung vào vấn đề 9

3.2.3 Khuyến khích tình thần tích cực 9

3.3 Tiến hành 9

4 Kỹ thuật StoryBoarding 12

4.1 Những điểm chính 12

4.3 StoryBoards làm những gì? 13

4.4 Công cụ và kỹ thuật cho StoryBoarding 13

5 Kỹ thuật Use Case 13

5.1 Xây dựng Use Case 14

5.2 Áp dụng Use Case vào phân tích yêu cầu phần mềm 15

5.3 Role Playing 16

5.3.1 How to Role Play 16

5.3.2 Các kĩ thuật khác tương tự 17

6 Kỹ thuật Prototyping 18

6.1 Các điểm chính 18

6.2 Các kiểu mẫu thử 18

III Sử dụng EA trong phát hiện và Tổng hợp yêu cầu 22

1 Sử dụng EA với kĩ thuật BrainStorming 22

2 Sử dụng EA với kĩ thuật Prototyping (Mẫu : GUI) 24

3 Sử dụng EA với kĩ thuật Use Case 25

Phần 2 : Các kỹ thuật phân tích các yêu cầu phần mềm 25

I Giới thiệu chung 25

1 Mục đích 25

2 Phạm vi 26

3 Tài liệu tham khảo 26

II Các kỹ thuật phân tích yêu cầu phần mềm 26

1 Requirement Classification 26

1.1 Giới thiệu 26

1.2 Function Requirements 26

1.3 Non-Function Requirements 26

1.4 Design Contraints 26

2 Conceptual Modeling 27

3 Architectural Design and Requirements Allocation 27

4 Requirements Negotiation 28

III Kĩ thuật trong EA giúp phân tích yêu cầu phần mềm 28

1 Xem xét cấu trúc phân cáp và cài đặt của yêu cầu phần mềm 28

2 Phân tích sự phụ thộc của yêu cầu 30

3 Quản lý thay đổi 32

4 Lập báo cáo 33

Phần 3 : Xây dựng tài liệu đặc tả yêu cầu phần mềm 36

I Giới thiệu chung 36

1 Mục đích 36

2 Tài liệu tham khảo 36

II Đặc tả các yêu cầu phần mềm 36

1 Giới thiệu 36

2 Các điểm lưu ý khi đặc tả yêu cầu phần mềm 37

3 Ghi lại các nguyên tắc của công việc 37

4 Đặc tả yêu cầu phần mềm theo mẫu 38

4.1 Gán nhãn các yêu cầu phần mềm 38

4.2 Đánh dấu những điểm chưa rõ ràng trong đặc tả 38

4.3 Mỗi liên quan giữa đặc tả và giao diện người sử dụng 38

5 Các mẫu đặc tả yêu cầu phần mềm 39

5.1 Template SRS IEEE 830 -1998 39

6 Phương thức kỹ thuật cho đặc tả yêu cầu 41

III Chức năng EA hỗ trợ đặc tả yêu cầu phần mềm 41

1 Tạo các yêu cầu ngoài (External Requirements) 41

2 Tạo các yêu cầu bên trong từ một thành phần khác (Internal Requirement) 52

3 Chuyển các Internal Requirement thành External Requirement 53

4 Quản lý các thuộc tính cơ bản của yêu cầu 54

5 Ghi chú các thông tin bổ sung 55

6 Xóa , Sắp xếp các yêu cầu 58

7 Tạo cấu trúc phân cấp cho yêu cầu 58

8 Đánh số cho các Requirement 59

9 Kết xuất thành văn bản 62

Phần 4: Các thuật ngữ và các chữ viết tắt 64

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

 Ở đâu khác có thể tìm một giải pháp cho vấn đề này?

1.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âuhỏi.Hãy tạo cảm giác thoải mái, cởi mở khi nói chuyện

1.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ốnsá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ỏngvấ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

1.5 Biên soạn lại các dữ liệu cần thiết

 Thảo luận, góp ý là phần quan trọng nhất của hội thảo

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

2.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í

2.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ườibên ngoài, những người đã có kinh nghiệm trong quá trình quản lý các yêucầ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ị

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

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

3.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ảiphá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àylầ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ómngườ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ộtnguyê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

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ácthành kiến hay phê bình sẽ dễ bị gạt bỏ và như thế sẽ làm mất sự tổngquan

3.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ùytheo trình độ, khía cạnh nhìn thấy riêng và không giới hạn cách nhìn củamỗ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.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ở, đánhgiá, 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ộtchữ 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 khaihó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 khichấ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 haynguyê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ủacá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ôngcần phải suy nghĩ nó là một ý tưởng tốt hay chỉ là một suy nghĩ thoảng quatrong đầu Người ta cũng chẳng cần bận tâm đến việc thẩm mỹ của việctrình bày đó Nếu cần diễn tả một hình ảnh, nó sẽ được phác họa thật nhanhchó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ữngthứ 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ỏ quamộ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ìnhthường bạn nghĩ.Ngoài việc đưa ra thật nhiều ý tưởng, brainstorming còngiúp ta phân tích kỹ vấn đề, tự xem xét tất cả vấn đề có thể xảy ra khi trongkhi 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étPhương pháp này có thể tiến hành bởi một hay nhiều người Số lượngngười tham gia nhiều sẽ giúp cho phương pháp tìm ra lời giải được nhanhhơ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ằngcá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ànhbrainstroming 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

4.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ếttrì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ộtslide trình chiếu được sắp xếp tự dộng sẵn hoặc một công cụ tạo hoạtcả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ớithực tế Cách này đỏi hỏi phải có sự tham gia của người sử dụng để thựchiện được Storyboards tương tác có thể giả lập hoặc tạo dựng mô hìnhhay có thể nâng cao tới mức mã dùng một lần (throwaway code)

4.3 StoryBoards làm những gì?

Trong phần mềm, Storyboards được sử dụng thường xuyên để làm việcthông qua các chi tiết của giao diện tương người máy Trong Lĩnh vựcnày, mỗi người có thể có ý kiến khác nhau về cách thức giao diện làmviệ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.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 Để ghinhậ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ápuse-case rất mạnh mẽ trong suốt quá trình phát triển phần mềm, ví dụ như usecases đó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ươngtá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ốitiế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ểudiễn bằng một hình oval chứa tên của use case

5.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-casecũ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ủachú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à ranhgiớ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 choviệc hỗ trợ nhu cầu người dùng Những luồng này là các use cases, hoặc nhữngtrì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

5.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ấutrú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ốngmới Và mỗi user độc lập sẽ tự nhiên tập trung vào những khả năng hệ thốngcầ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àihướ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ủastakeholders, và chúng ta có thể cần phải áp dụng các kĩ thuật khác để thu thậpyê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áckhí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ảiquyế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ủamỗi use-case Đặc tả use-case này bao gồm miêu tả bằng văn bản và đồ họacủ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 lienquan, do đó có thể được dùng để bao hàm các yêu cầu khác sẽ được phát triểnhơ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”

5.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 đề đượcgiả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ữngthủ 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à ápdụng cách giải quyết hoặc con đường duy nhất của việc thực thi côngviệ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âuhỏ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âuhỏ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 “roleplaying” có thể có hiệu quả mạnh mẽ

5.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ântí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 haicá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ântích các đơn đặt hàng có lỗi Định lượng lỗi theo loại và giải quyếtnhững lỗi có số lượng cao nhất trong thiết kế của hệ thống mới Việcnà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

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ườidù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 địnhnghĩ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ườidù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

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áttriển một mẫu thử yêu cầu (requirements prototype), sử dụng bất cứ côngnghệ 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 1 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ự thihành cục bộ (riêng lẻ) của hệ thống phần mềm, được xây dựng để giúp cácnhà 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ọncách xây dựng các mẫu thử như “throwaway, horizonal(rộng), userinterface” prototype (mẫu thử dùng một lần, mẫu thử rộng, mẫu thử ngườidùng)

Horizonal prototypes (các mẫu thử rộng) ám chỉ rằng chúng ta sẽ thử xâydựng một dải khá rộng chức năng của hệ thống, ngược lại, verticalprototype xây dựng chỉ một vài yêu cầu nhưng theo một số phương phápkhá chất lượng User interface prototype ngụ ý rằng chúng ta sẽ xây dựnghầ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ảithuật và các logic xung quanh phần mềm hoặc làm cả mẫu thử giao diệncho 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ẫuthử 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ủakhá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áckhuyế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êutố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ệnngười dùng được làm mẫu sẽ khám phá ra rất nhiều các yêu cầukhá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ứcnă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ữngcông cụ này không làm ảnh hưởng tới việc xây dựng mẫu thử chocá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ủangườ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 1 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 rochư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ữngmẫ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ớihoặ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ùnghiể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ầnBrainStorming

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êucầ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

Function Requiremnts

Non-Function Requirements

Design Contraints

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ắcchắ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ặcthiế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ệmvụ

 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ởiquy 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ànhphần của chúng sẽ chịu trách nhiệm nhận biết các yêu cầu an toàn Đây làyêu cầu cấp phát- sự phân công các thành phần có trách nhiệm đáp ứng cácyêu cầu

 Phân bỏ rất quan trọng cho việc phân tích chi tiết các yêu cầu Sau đây cho

ví dụ một bộ các yêu cầu được chỉ định các thành phần, các yêu cầu cá

nhân có thể được tiếp tục phân tích để khám phá thêm các yêu cầu trên cácthành phần cần tương tác với các thành phần khác như thế nào để đáp ứngđược sự phân bố các yêu cầu trong một dự án lớn, sự phân bố khuyếnkhích một vòng lớn của phân tích các hệ thống con.

 Lặp lại yêu cầu và thiết kế

 Sử dụng các yêu cầu Parent-Child để tăng tính đặc trưng

 Thiết kế kiến trúc được xác định chặt chẽ với khái niệm mô hình hóa Việcánh xạ từ đên miền thực thể trọng thế giới thực đến thành phần phần mềmkhông phải luôn luôn rõ ràng, vì vậy thiết kế kiến trúc được xác định là mộtchủ đề riêng biệt các yêu cầu kí hiệu và các phương thức được rộng rãinhư cả hai khái niệm mô hình và thiết kế kiến trúc

4 Requirements Negotiation

Một thuật ngữ khác được sử dụng cho chủ đề này là “ conflict resolution” Điều quan tâm này giải quyết vẫn đề với các yêu cầu mà sự xung đột xảy ragiữa hai yêu cầu của các bên liên quan cùng các tính năng không tương thích ,giữa các yêu cầu và nguồn lực hoặc giữa yêu cầu chức năng và yêu cầu phichức năng

Trong tất cả các trường hợp , nó không thận trọng cho các kĩ sư phần mềm làmcác quyết định đơn phương và do đó nó cần thiết tham khảo từ các bên liênquan để đạt được một sự đồng thuận trên sự thỏa hiệp thích hợp

Sử dụng Use Cases

 Để hỗ trợ các hoạt động thiết kế và mã hóa, các Use Case phát triểntrong các hoạt động suy luận hơn là xây dựng đầy đủ

 Các Use Cases thích hợp nhất khi hệ thống giàu chức năng và phải

hỗ trợ các loại người dùng khác nhau

 Các Use Case không có hiệu quả khi áp dụng đến hệ thống với mộtvài hoặc không có giao diện người dùng tối thiểu, chủ yếu là nhữngyêu cầu phi chức năng và những hạn chế khi thiết kế

III Kĩ thuật trong EA giúp phân tích yêu cầu phần mềm

1 Xem xét cấu trúc phân cáp và cài đặt của yêu cầu phần mềm

Sử dụng cửa sổ Hierachy Khi lựa chọn 1 Requirement, ta sẽ xem được các thông tin về:

 Quan hệ phân cấp của Requirement: cho biết nó là con của các Requirement nào, cha của các Reqiurement nào, quan hệ thuộc loại nào (sở hữu hay kết tập) …

 Quan hệ về cài đặt của Requirement: nó được cài đạt bởi các Element nào Nếu Requirement có các Requirement con, EA có thể chi tiết việc cài đặt của từng Requirement con đó.

2 Phân tích sự phụ thộc của yêu cầu

Sử dụng ma trận quan hệ (Relationship Matrix): thông qua cửa sổ Relationship Matrix Cho biết quan hệ giữa các đối tượng trong 2 package

3 Quản lý thay đổi

Sử dụng cửa sổ Audit View: ghi chép lại các thay đổi đã thực hiện.Kích hoạt Audit View:

 Mở cửa sổ Audit View

 Chọn Audit Settings

 Enable Auditing