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

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

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

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

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

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

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

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