TR
ƯỜ
NG Đ I H C BÁCH KHOA HÀ N I Ộ
Ạ Ọ
VI N CÔNG NGH THÔNG TIN VÀ TRUY N THÔNG Ệ Ệ Ề
----------
Báo cáo bài t p tuân 3
ậ
̀
Môn h c: Phân tich yêu câu phân mêm
ọ
́ ̀ ̀ ̀
Gi ng viên: PGS.TS. Huynh Quyêt Thăng ả ̀ ́ ́
Danh sách sinh viên: (nhóm 3 )
Lê Trung Hiêu 20111568 CNTT-TT 2.3 K56 ́
Đam Văn Hoai 20111600 CNTT-TT 2.3 K56 ̀ ̀
Nguyên Đ c C ng 20111203 CNTT-TT 2.3 K56 ứ ươ ̃
Đoan Văn Đat 20111370 CNTT-TT 2.3 K56 ̀ ̣
Hà N i – 4/2014
ộ
M c l c ụ ụ
Page 2 Phân tích yêu c u ph n m m. ầ ề ầ
I. M i đăc tinh chât l ng cua môt ban đăc ta yêu câu phân mêm tôt. ườ ́ ượ ̣ ́ ̉ ̣ ̉ ̣ ̉ ̀ ̀ ̀ ́
1.1. Tính đúng đ n (correct)
ắ
- M t đ c t yêu c u ph n m m t ố ầ ầ ượ
ỗ ả ầ ề ọ ầ ầ ứ ộ ặ ả ầ
ả ự ả ắ
ộ ặ ả ặ
ế yêu c u h ầ ộ ộ ớ ề ầ ầ
ự ầ ơ ươ ắ
ộ ứ ể ỉ ự ầ ắ ị
ủ ầ ự ườ ặ ủ ầ
t là m i yêu c u đ ề c xác đ nh đ u ề ị ứ chính xác ch c c ph n m m đáp ng. M i yêu c u c n mô t ph i đ ả ượ c xây d ng. S đ m b o cho tính đúng đ n đó là tham chi u đ n ế năng đ ượ ệ ngu n c a yêu c u, đó có th là khách hàng ho c m t đ c t ể ồ ủ th ng m c cao h n. M t yêu c u ph n m m mà xung đ t v i m t yêu ố ứ ủ c u h th ng t ng ng thì là không đúng đ n. Ch s trình bày c a ệ ố ầ ng i dùng, i dùng m i có th xác đ nh tính đúng đ n c a yêu c u ng ớ ườ đi u đó cho bi i sao khi rà soát yêu c u ta c n s có m t c a chính t t ế ạ ề i dùng ho c ng ng ặ ườ i đ i di n c a h . ệ ủ ọ ườ ạ
ẫ ể ự
ứ ớ ầ ̣ ́ ̀ ̉ ̉ ̉
ề ể ầ
i dùng hay không. - Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ ầ Specification (SRS) v i đăc tinh nay đê đam bao ph n m m đáp ng đ y đ các đ c t ầ yêu c u ph n m m. Đây cũng là tiêu chí đ đánh giá ph n ủ m m có đáp ng đ ề ề c các yêu c u c a ng ầ ủ ặ ả ứ ầ ượ ườ
ầ
1.2. Tính hoàn ch nh (complete) ỉ - M i yêu c u c n mô t ỗ ầ ứ ấ ả ả
ả ầ ầ
ầ ế
ả đ y đ ch c năng đ ứ ủ t đ nhà phát tri n thi t c các thông tin c n thi ế ể ầ ư ề ề ế ầ ấ
ọ ẽ ẩ ệ
ư ậ ệ ầ ộ ị
ể ế ụ ệ
c k t qu c a các d li u đ u vào, đ c bi ượ ệ ầ ị ả
c k t qu c a nh ng d li u đ u vào h p l c chuy n giao. Nó ể ượ ự t k và th c ph i ch a t ế ế ể N u yêu c u ph n m m nào đó còn ch a rõ ràng, và ai thi ch c năng này. ứ ầ đó có c m giác còn thi u khi nói v yêu c u đó, h s đánh d u yêu c u đó là "TBD - To Be Determined" - đây là ký hi u chu n trong IEEE 830. Nh v y khi rà soát toàn b tài li u SRS, chúng ta tìm các yêu c u b đánh d u TBD đ ti p t c hoàn thi n SRS. ấ ả ủ ữ t là ặ ữ ệ và d li u ữ ệ ầ ế ả ủ ợ ệ ữ ệ
- Ph i xác đ nh đ ph i xác đ nh đ ượ ế ị ả đ u vào không h p l . ợ ệ ầ ủ ệ ấ ả
ả ể - Ph i có đ y đ nhãn và tài li u tham kh o cho t ủ ấ ả ị ố ệ t c các s li u, t c các đi u kho n và ả ề
ầ ơ ồ ng. ả b ng bi u, s đ trong SRS và đ nh nghĩa c a t ả đ n v đo l ị ơ ườ
ự ể ẫ
- Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ c mô Specification (SRS) v i đăc tinh nay đê đam bao m i yêu c u đã đ ượ ớ ầ ỗ ̣ ́ ̀ ̉ ̉ ̉
Page 3 Phân tích yêu c u ph n m m. ầ ề ầ
t đ y đ . ả ầ ủ
1.3. Tính nh t quán (consistent)
ấ
ầ ầ ầ ộ ớ
ơ ặ ệ ố
ặ c phân gi ả ượ ề ấ ầ
ạ ể ẫ ễ ấ ộ
ề -Các yêu c u ph n m m không xung đ t v i các yêu c u ph n m m ấ ả i tr c khi quá trình ả ướ t m t yêu c u đ n nh t (single ơ ầ ộ ố ế ạ ế ế ậ ầ ể ắ
ứ ề ầ
ầ khác ho c các yêu c u c p cao h n (h th ng ho c kinh doanh). T t c ầ các mâu thu n trong yêu c u c n ph i đ phát tri n di n ra. B n có th không bi requirement) nào đó là đúng đ n cho đ n t n khi b n ti n hành m t s nghiên c u nào đó v yêu c u này. ẫ ự ể
ủ ầ ̣ ́ ̀ ̉ ̉ ̉
ượ ủ ả ả ấ
- Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ ầ Specification (SRS) v i đăc tinh nay đê đam bao các yêu c u c a ph n ớ m m không xung đ t l n nhau, đ m b o đ c tính nh t quán c a các yêu ộ ẫ ề c u ph n m m. ầ ầ ề
1.4. Tính kh thi (Feasible) ả
̉ ự ầ ́
ế ủ ớ ạ ỗ t c a h th ng và môi tr ườ ệ ố
̣ ̀ ́ ́ ̉ ́ ́ ̣
ạ ộ ̉ ự ự ̉ ự ư ̣ ̀ ̀ ̀ ̀ ́ ̀
- Kh thi có nghĩa là co thê th c thi m i yêu c u trong các kh năng và ả ả ng ho t đ ng c a h th ng. i h n đã bi gi ệ ố ủ c hoăc co Môt yêu câu không co tinh kha thi nêu no không thê th c hiên đ ́ ̣ ượ thê th c hiên nh ng yêu câu chi phi l n (vê nhân l c, vê tai chinh, vê tai ̀ ́ ớ nguyên phân c ng, phân mêm, hoăc vê đô ph c tap tinh toan). ̣ ứ ̀ ứ ̀ ̀ ̣ ̀ ̣ ́ ́
ầ ầ ể ủ ộ
ữ ệ ớ ặ ́ ̀
ẽ
ườ ặ ả ầ ậ ̉
- Đ tránh các yêu c u không kh thi, c n m t thành viên c a nhóm d ự ả ầ án làm vi c v i nh ng nhân viên ban hang ho c các nhà phân tích yêu c u i này s đánh giá trong quá trình x lý yêu c u (elicitation process). Ng ầ ầ v tính kh thi c a các yêu c u v m t k thu t ho c chi ra các yêu c u ề có th th c thi nh ng v i m t chi phí l n. ề ặ ỹ ớ ử ủ ư ể ự ớ ộ
ẫ ể ự
ượ ư ̣ ́ ̀ ̉ ̉ ̉ ́ ̀
ự ́ ́ ́ ̣ ̀ ̉ ̀ ̀
̣ ượ ng t ưở ̣ ự ớ ̀ ́ ̃ ̉ ̀ ́ ̀ ́ ́ ̉ ̀ ̃ ́
ng l n công s c, tai nguyên ma đem lai l ̣ ợ ứ ớ ̀ ̀ ́ ́ ̉ ́
ng rât l n t ự ́ ớ ớ ưở ̀ ́ ̣ ̉ ̀ ̀ ̀ ̉
Specification (SRS) v i đăc tinh nay đê đam bao cac yêu câu đ co thê th c hiên đ ̉ ự thi no se anh h l ượ Thêm vao đo, viêc không thê hoan thanh yêu câu anh h tin cua ng - Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ c đ a ra ớ c trong th c tê. Nêu môt yêu câu không thê hoan thanh ̣ i toan bô d an. Yêu câu đo co thê lam lang phi môt i ich qua nho cho d an. i uy ̣ i phat triên phân mêm. Vi vây, môt SRS tôt cân đam bao moi ườ ́ ̉ ́ ̉ ̀ ̀ ̀ ̣ ̣ ́ ̀ ̉ ̉
Page 4 Phân tích yêu c u ph n m m. ầ ề ầ
yêu câu đê co tinh kha thi. ̀ ̀ ́ ́ ̉
1.5. Tính có th thay đ i (Modifiable)
ổ
ể
̣ ́ ̉ ̉ ̀ ̉ ̉ ̃ ̀ ̉ ̉
ượ ự ̣ ̉ ̣ ̀ ̀ ́ ̀ ̣ ̀ ̀ ̣ ̣ ́
ớ ́ ́ ́ ̀ ̃ ̉ ̉ ́ ́ ́ ́ ̀ ̀
- Môt SRS co thê thay đôi cân đam bao môi khi cân bô sung, s a đôi hay ử loai bo môt yêu câu nao đo thi công viêc nay cân đ c th c hiên môt cach nhanh chong, chinh xac va vân đam bao tinh nhât quan v i cac yêu câu con lai.̣
- Đ tăng tính thay đ i đ c c a yêu c u ph n m m, vi ầ ầ ế ề ể ổ ượ ủ
ậ ạ
ườ ấ ấ ̣ ́ ̀ ̀
ừ ầ ả
ầ ụ ể ộ ữ ộ
ữ ế ầ ả ́ ́
ầ t các yêu c u ỗ th t rõ ràng, m ch l c (fine grain fashion), gán nhãn khác nhau cho m i ạ yêu c u. Ng i đoc không thích nhìn th y các d u châm đâu hang trong tài ầ li u, vì khi dò tìm các yêu c u, ph i dò qua t ng yêu c u c th m t - t n ố ể th i gian và không rõ ràng (vì không có nhãn). M t trong nh ng cách đ ư lo i b các dâu châm, đó là s p x p các yêu c u theo b ng ch cái - nh ắ th dùng ch cái đ gán nhãn. ệ ờ ạ ỏ ế ữ ể
- SRS co thê đ c nghiên c u lai khi c n thi ầ ế ̉ ượ ́ ̣ ̀ ̉
ầ ề ế ỗ
ổ ủ ấ ầ
ỗ ả ế ầ ầ ỗ
ấ ấ
ứ ỗ ượ ượ ầ ủ ể ầ ạ
ệ ể ệ ộ ự ữ ộ ộ
t và cân phai duy trì thông ầ tin di n bi n thay đ i c a m i yêu c u. Đi u này đòi h i m i yêu c u ễ ỏ c di n gi i riêng r v i các yêu c u khác c dán nhãn duy nh t và đ đ ẽ ớ ễ ượ ỉ sao cho m i yêu c u đ u đ c tham chi u chính xác. M i yêu c u ch ề đ c xu t hi n duy nh t 1 l n trong SRS đ tránh s không nh t quán ượ ấ i nh ng n i khác nhau. gi a các th hi n (instance) c a cùng 1 yêu c u t ơ ữ M t b ng n i dung (table of contents), m t index, m t danh sách tham ộ ả chi u chéo (cross – reference listing) s làm SRS d s a ch a h n. ế ữ ơ ễ ử ẽ
- IEEE 830-1998 hô tr xây d ng SRS v i đăc tinh chât l ớ ự ̃ ợ ́ ượ ̣ ́ ̀ ̉
ờ ̉ ́ ̣ ́ ́ ̀ ̀ ́ ̀ ̉ ́ ̀
̣ ử ̀ ̀ ̣ ́ ̣ ́ ́ ̉ ̃ ́ ̉
̀ ở ữ ̀ ̣ ́ ̉ ̀ ̀ ́ ̀ ̣
c đo. ́ ng nay đê co thê tiêt kiêm th i gian, chi phi cho qua trinh đam phan va quan ly yêu câu ̉ phân mêm. Môt SRS co đăc tinh “co thê s a đôi” se giup viêc s a đôi chi ̉ ử môt sô it n i cua SRS, đông th i không cân lo lăng vê viêc nh ng cân lam ờ ́ ơ thay đôi nay mâu thuân v i cac yêu câu tr ướ ớ ̉ ̀ ̃ ́ ̀ ́
1.6. Tính c n thi
t (Necessary)
ầ
ế
ậ - M i yêu c u c n ph i tài li u hoá m t cái gì đó mà khách hàng th t ệ ầ ầ ả ỗ ộ
Page 5 Phân tích yêu c u ph n m m. ầ ề ầ
ặ ộ ệ ố ể
ộ m t bên mà b n bi t” là yêu c u đó đ ượ ề ầ ạ
s c n ho c m t h th ng khác bên ngoài c n. M t cách khác đ xác ự ầ nh n “tính c n thi ế t ầ ậ r t rõ r ng ng ằ ấ c đ xu t t ế i đo có th m quy n đ ra yêu c u. ề ầ ấ ừ ộ ầ ườ ề ầ ́
́ ứ ́ ̣ ̀ ̀ ̀ ̣ ̣ ̉ ́
́ ̀ ̣ ́ ̀ ̀ ́ ̀ ̀ ̀ ́ ̀ ̉
̣ ợ ự ự ̉ ̣ ̣ ̀ ̀ ́ ̀ ́ ̀
- Nêu môt yêu câu phân mêm không đap ng nguyên vong cua bât ki ̀ ̣ khach hang hay hê thông nao thi no la yêu câu không cân thiêt, cân phai loai bo. Viêc th c hiên yêu câu nay không mang lai l i ich nao cho d an phân mêm, chi lam lang phi công s c, tai nguyên. ứ ̀ ̉ ̀ ̃ ́ ̀
- IEEE 839-1998 hô tr xây d ng SRS v i đăc tinh chât l ́ ượ ự ớ ̣ ́ ̀
̉ ̉ ̣ ̀ ̀ ̀ ́ ́ ̀
̉ ng nay đê c đ a ra trong SRS đêu cân thiêt cho d an phân ự th i gian, công s c ứ ̀ ư ờ ớ ̀ ̉ ́ ̀ ̀ ́ ̀
̃ ợ đam bao moi yêu câu đ ượ ư mêm. Chi cac yêu câu thât s cân thiêt m i cân đâu t ̣ ự đê hoan thanh. ̉ ̀ ̀
1.7. Có đ u tiên (Prioritized)
ộ ư
ỗ ầ ứ ự ư - Gán m i th t ỗ ặ
ể ể ả ầ
ị ầ ượ ượ ầ ị
ượ ủ ự ẽ ể
u tiên cho m i yêu c u, tính năng (feature), ho c use ề case đ có th hình dung l ch trình phát tri n các phiên b n ph n m m. ể ị ự N u t c coi là quan trong nh nhau thì qu n tr d án t c các yêu c u đ ả ư ế ấ ả c cách th c thi công khi m t yêu c u m i phát sinh s không xác đ nh đ ớ ộ ứ ẽ trong quá trình thi công c a d án, anh ta s không ki m soát đ c ngân sách, l ch bi u và nhân l c c a s án. ụ ủ ự ể ị
ẫ ể ự
ả ̣ ́ ̀ ̉ ̉ ̉
ườ ầ ự ỗ
c t ệ ầ
- Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ i qu n tr d án đánh ị ự c chính xác m c đ quan trong c a m i yêu c u. Tù đó có s đánh ủ t c các yêu c u hi n có và các yêu c u phát sinh ầ ứ đúng m c v i t ng yêu c u t ng ng ầ ươ ớ ừ ớ ứ ộ ượ ấ ả i qu n tr s đ u t ả ứ
Specification (SRS) v i đăc tinh nay đê đam bao ng giá đ ượ giá, ki m soát đ ể thêm. Ng v i m c đ u tiên c a nó. ớ ị ẽ ầ ư ủ ườ ứ ộ ư
1.8. Có th truy v t (Traceable)
ể
ế
êu c u t i ngu n phát sinh c a nó, t ả ên k t các y ế ầ ớ ủ
ạ ầ thi t est cases th c thi v ã ngu n, các t ồ ể
- B n c n ph i li ph n t ế k , mế ầ ử đ n trong vi c thi công ệ ắ các yêu c u. Các y ầ êu c u có th theo v t đ ể ồ ự ầ i các ớ à ki m tra s đúng ự ế ư c gán ợ
Page 6 Phân tích yêu c u ph n m m. ầ ề ầ
t theo t v ợ ế m t cách có c u trúc, chi ti ấ ộ ế à đư cợ
nhãn duy nh t vấ à đư c vi thuy t minh đ y đ . ầ ủ ế
ẫ ể ự
ườ i làm d án tìm đ ự ̣ ́ ̀ ̉
c đ nguyên nhân phát sinh đ n lúc thi ỗ ủ ừ ề
ế ầ ầ ầ ượ ứ ầ ỗ
ị
c giúp ng ầ ế ế ủ ữ ự ế
- Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ ng Specification (SRS) v i đăc tinh nay đê ng ượ ườ ớ ế ế t k đi c a m i yêu c u ph n m m t ầ c yêu c u đó trong ph n m m. M i yêu c u c n xác đ nh đ đáp ng đ ề ể ị m t cách rõ ràng ngu n phát sinh, v trí c a nó trong khâu thi t k . Truy ộ ủ ồ i sai hay nh ng thi u sót c a yêu i làm d án tìm ra l t đ vi ườ ế ượ c u m t cách nhanh chóng nh t do đã bi c v t đi c a yêu c u đó. t đ ộ ầ ỗ ế ượ ế ủ ấ ầ
1.9. Không nh p nh ng (Unambiguous).
ậ
ằ
- T t c nh ng ai khi đ c b n báo cáo y ả êu c u đầ ộ
i nh t quán v n i dung c a các y ả ọ ấ ủ
t m t y ên vi ề ộ ên là có tính nh p nh ng cao n ậ ế ằ
ệ
o yêu c u b ng các các báo cá à mô t ả ể ạ ỏ ngôn ng hữ ình th c nh ứ ả ằ
ều có cùng m t cách ữ ấ ả êu c u. Do ngôn di n gi hi u, m t cách ầ ễ ộ ể ộ êu c u rầ õ ràng, cụ ng t nhi ữ ự ậ th , để ơn nghĩa không ph i lả à d . ễ Cách hi u qu đ lo i b tính nh p nh ng l ư ầ ằ use-case ch ng h n, qua các k ch b n s d ng c th . ụ ể ả ử ụ ạ ẳ ị
ẫ ể ự
ớ ̣ ́ ̀ ̉
ặ ầ
ấ ườ ớ ấ ả ề ấ ế
ấ ễ ẫ ớ ự ự ứ ể ề ặ ộ
i. - Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ Specification (SRS) v i đăc tinh nay đê giúp cho SRS trình bày rõ ràng ng minh nh t. T t c các yêu c u không có s trùng l p hay trùng nh t,t ế ý nghĩ v i nhau vì n u đi u này có trong SRS thì d án r t d d n đ n th t b i. M t ph n m m không th trùng l p các ch c năng v i nhau đó ầ là m t ph n m m t ầ ấ ạ ộ ề ồ
c (Verifiable)
1.10. Ki m tra đ ể
ượ
ỗ ạ ể ể
ỏ ệ ộ ể ậ ế
ế ả ẩ
ầ ầ ượ ệ ặ ị
ộ ố - Hãy ki m tra m i yêu c u đ xem li u b n có th nghĩ ra m t s ầ ng nh các phép tests ho c s d ng m t cách ti p c n ki m tra khác l ể ặ ử ụ ượ t li u nh thanh tra (inspection) ho c ch ng minh (demonstration) đ bi ể ế ệ ặ ứ ư ộ trong s n ph m hay không. N u m t c cài đ t h p l yêu c u đó đã đ ượ ặ ợ ệ c cài đ t đúng đ n yêu c u không th ki m tra thì xác đ nh li u nó có đ ắ ể ể ấ thành v n đ gây tranh cãi. Các yêu c u không nh t hay không s tr ẽ ở ề ấ ầ
Page 7 Phân tích yêu c u ph n m m. ầ ề ầ
c. quán, không kh thi ho c nh p nh ng thì cũng không th ki m tra đ ằ ể ể ặ ả ậ ượ
ẫ ể ự
̣ ́ ̀ ̉
ự ấ ể ặ ợ
ư c s nhanh phát hi n l i c a m i yêu c u trong quá trình tri n khai d ể ỗ
- Các bi u m u IEEE 830-1998 hô tr xây d ng Software Requirement ̃ ợ ặ i làm d án ki m tra cài đ t Specification (SRS) v i đăc tinh nay đê ng ể ớ i u nh t. M t SRS ki m tra yêu đó đã h p lí hay ch a, sai ho c ch a t ộ ự đ ượ ẽ án giúp gi m chi phí v ti n b c và nhân l c đ s a ch a. ườ ư ố ư ầ ự ể ử ệ ỗ ủ ạ ề ề ữ ả
II. Các Tips đ vi t đ c t yêu c u ph n m m ể ế ặ ả ề ầ ầ
1. Đ a ra các đánh giá d a trên góc nhìn c a nhà phát tri n. ủ ự ư ể
ể ư ấ ể
ể ể ầ ả
ố ủ ư ề
ố ể
ng, h không ph i là ng ể ầ ườ ế ẽ ả ế ệ
ữ ệ ề ầ ả
ườ ặ ủ ề ể ả ầ ậ ầ
ứ B t k phía đ i tác đ a ra yêu c u nào, quan đi m nào, nên đ ng ầ trên quan đi m c a nhà phát tri n đ đánh giá yêu c u đó. B n thân ể phía đ i tác khi đ a ra yêu c u ph n m m nào, đã mang góc nhìn và ầ i trong ngành quan đi m c a h . Thông th ọ ủ ọ công ngh thông tin, và vì th s không hi u h t rõ đ c thù c a công ủ vi c phát tri n ph n m m cũng nh nh ng kh năng c a máy tính. Do ư đó, luôn ph i đánh giá, nh n xét các yêu c u ph n m m trên góc nhìn c a nhà phát tri n. ủ ể
ấ ằ ổ ậ
ấ ự ầ ấ ấ ở ả
ề ố
ỏ ấ ữ ầ
ầ ầ ứ ầ ớ ấ
ấ ữ ầ ấ ặ
ự ề ơ
ứ
ằ
ườ ố ấ ứ ạ ỏ ề ể
ể ế ấ
ấ ầ ụ ữ ầ ậ
1. Làm n i b t các yêu c u b ng c u trúc phân c p. Và cũng nên suy nghĩ, đánh giá d a theo c u trúc phân c p này. B i b n thân c u trúc ệ phân c p đã mang trong nó ít nhi u nh ng thông tin v m i quan h ề logic gi a yêu c u: Yêu c u l n, yêu c u nh , yêu c u cha – con, các yêu c u cùng m c phân c p… Chính c u trúc này giúp vi c đánh giá ệ t đánh giá d a trên hình tr nên chính xác, h p lý, và sát h n. Đ c bi ở ự ệ ơ ợ cũng d dàng h n là ch suy nghĩ v n đ trong nh tr c quan bao gi ễ ả ấ ỉ ờ ầ cũng ch ng minh, h u đ u mà không có hình nh h tr . Và th c t ỗ ợ ự ế ả ầ i đ i m t v i các v n đ ph c t p b ng c u trúc phân h t m i ng ề ặ ớ ấ ấ ọ ế c p (nó phân rã v n đ l n thành các v n đ nh - hi u và có th gi ể ả i ấ ề ớ ấ ể c). N u không bi u di n theo c u trúc phân c p, khó có th quy t đ ễ ế ượ nh n ra m i quan h logic gi a các yêu c u/m c yêu c u, khó nh n ra ệ ố ậ đâu là yêu c u l n, đâu là yêu c u nh , … ầ ớ ầ ỏ
2. C g ng vi ố ắ ế t các câu và đo n ng n - đ n gi n (write concisely): ơ ạ ắ ả
Page 8 Phân tích yêu c u ph n m m. ầ ề ầ
ạ ộ
ạ c yêu c u mà nó nói t i không ch t đ ớ Tránh các đo n văn nói dài. B i đôi khi m t đo n văn dài, v i ở ớ i ố ượ ạ ầ ố ề
Dùng ng pháp, chính t ữ ả ể ợ ườ i
o nhi u ý, cu i cùng l chính xác là cái gì! o thông th o ngôn ng đ o
, và ng t câu phù h p (nên đ ng t SRS) c s d ng đ vi ắ ể ế
ạ Dùng t v ng trong lĩnh v c kinh doanh ừ ự ữ ượ ử ụ ự
ệ ừ ộ cũng làm thay đ i toàn b ý ổ
(đôi khi vi c không s d ng chính xác t ạ nghĩa mà yêu c u mu n di n đ t) ử ụ ố ễ ầ
ộ ạ ể ề ầ
ề ề ộ ọ ạ ỉ
ầ ứ
ự t trong m t đo n quá dài, đ a các mô t c vi ư ế ạ ộ
ứ ạ
Trong m t đo n nói v m t yêu c u ph n m m nào đó, có th có ầ i không ch rõ ra yêu c u này r t nhi u thông tin quan tr ng, nh ng l ư ấ c n xây d ng cái gì! Thay vì đó, đ ng đ yêu c u v m t ch c năng ầ ề ộ ể ừ ầ n n t ng (additional đ ả ề ả ượ descriptive background), context c a ch c năng ra ngoài, tách b ch v i ớ ủ mô t ch c năng. ả ứ
i khác rà soát l ầ ạ i m t tài li u ch a đ ệ ư ượ ộ ể c ki m
Đ ng yêu c u ng tra ng pháp - chính t ừ ữ ườ . ả
S t ỏ
i ngôn ng rà soát l ữ ạ c 1 tài li u t ừ i SRS, tìm ra các ễ t v m t di n ệ ố ề ặ ượ
ế ẽ ố ơ v n đ v dùng t ề ề ấ đ t yêu c u ph n m m. ầ ạ t h n n u có 1 ai đó gi và câu, đ cho ra đ ể ề ầ
cho c các hành vi đ ẫ ả ả ả
ợ ệ ố ượ ạ ộ
ượ ế
ữ ố ạ
ẽ
ỉ
ưở i/ngo i l i, ngo i l ng h n t ạ ệ ườ ươ ạ ệ ầ
c mong mu n l n các 1. Ph i có văn b n mô t ố ả ữ - Chúng ta mong đ i h th ng ho t đ ng theo đúng nh ng ngo i l ạ ệ c vi t cùng hành vi mà ta mong mu n, tuy nhiên, 1 ch ng trình đ ươ . Và n u chúng ta i, ngo i l v i r t nhi u nh ng đo n mã đ x lý l ề ế ể ử ạ ệ ỗ ớ ấ cũng nh cách x lý chúng trong quá không xác đ nh các l i, ngo i l ỗ ử ư ạ ệ ị ẽ trình xây d ng yêu c u ph n m m, s có 2 vân đ ! 1 là developers s ề ề ầ ự ầ đó theo 1 cách mà t k x lý ngo i l đó và c g ng thi ch ra ngo i l ạ ệ ế ế ử ố ắ ạ ệ quan đi m c a ng kém lý t i dùng. 2 là s không ai nghĩ ẽ ủ ể ơ ừ v l đó, ng trình g p l đó. Và l n đ u tiên ch ặ ỗ ầ ề ỗ nó crash!
ượ ệ ở
ự có th x y ra v i ch Công vi c ch ra các ngo i l ỉ ề ọ b i h s nghĩ v m i đi u t ở ọ ẽ ạ ệ ị i t ề ồ ệ b thi u nên đ ế ể ả c th c hi n b i tester, ệ ng trình. ớ ươ
2. Tránh các ràng bu c thi t k (design constraints) không c n thi t. ộ ế ế ầ ế
Tránh vi c đ a vào SRS quá nhi u ý t ệ ưở ư ế
ề ề
ng gi i quy t (solution ả t k vào tài li u ideas). Có nghĩa là đ ng đ a quá nhi u ràng bu c thi ệ ộ ừ ế ế ư ệ i pháp trong tài li u ng gi SRS b ng cách k t h p quá nhi u ý t ả ế ợ ưở ề ằ
Page 9 Phân tích yêu c u ph n m m. ầ ề ầ
h ng d n, tr khi có 1 lý do đ c bi t th a đáng. ướ ừ ẫ ặ ệ ỏ
3. Vi t các yêu c u m c chi ti t h p lý ế ầ ở ứ ế ợ
Khó đ xác đ nh xem tài li u SRS c n đ ể ượ ế ầ ị
t chi ti ầ ướ ữ ộ
nào, m t trong nh ng h thành các b ph n mà có th đ c l p ki m tra. ộ ứ t đ n m c c vi ệ ế ế ng d n, đó là chia các yêu c u ph n m m ra ề ầ ẫ ể ộ ậ ể ậ
"and" và "or" xác đ nh các yêu c u ph n m m có đ ừ ề ầ
Các t ớ ượ ầ ầ ừ ặ
ế ủ ừ ị ụ ả ẽ ặ
ầ
c k t ế ầ "and" trong yêu c u ph n h p v i nhau hay không. Ví d khi g p 1 t ợ "and" là c a cùng 1 m m, ta s đ t ra câu h i, ph i chăng 2 v c a t ủ ỏ ề yêu c u? Hay chúng v m t logic là 2 yêu c u khác nhau và c n chia ra ầ ề ặ ầ (split)?
ụ ể ơ ồ ầ ộ
t các yêu c u m t cách chính xác, c th , không m h và gây 4. Vi ế ẫ nh m l n. ầ
ề ầ
ắ ầ ể ộ ố ậ ẫ ầ ể ự ọ
ọ ự ầ ườ ậ
ạ
ầ ộ ể ố
ng t ơ ồ M t s l p trình viên đôi khi thích các yêu c u ph n m m m h , gây nh m l n, đ khi b t tay vào xây d ng, h có th xây d ng cái gì ơ ồ i dùng cũng thích các yêu c u m h , mà h mu n ? Và th m chí ng ố i yêu c u đó theo ý mà gây nh m l n, b i nó cho phép h đ nh nghĩa l ọ ị ầ ẫ ở h mu n t i th i đi m c th ! Đi u này không t t m t chút nào cho ề ờ ọ ố ạ vi c xây d ng m t ph n m m ch t l ấ ượ ộ ự ệ ụ ể ề ố t! ầ
nên đ Có m t s t ộ ố ừ ầ
c s d ng đ vi ượ ử ụ ừ ẽ t yêu c u, và m t s t ẽ ể ế ả
ể
ữ ậ ọ
ừ ầ ế ề ấ ố
nên ộ ố ừ tránh. Nên s d ng các t "s ", "ph i" thay vì nói "nên", "có l ", "có ử ụ th ",… (should, may, might, could, can, if possible, if you feel like, if ử ụ you have time, if you get around). Nên ch n 1 s thu t ng và s d ng ố nó m t cách nh t quán t đ u đ n cu i SRS khi nói v các ch c năng ứ ộ h th ng. ệ ố
i b n c a tác gi ả ợ M t ng ộ ườ ạ ủ
g i ý là thay th t ỏ
should b ng c m t ằ ườ ng, ng
ừ ế ừ ụ s không)", và h i ý ki n ng i dùng có đ ng ý ế ẽ ẽ ồ i dùng nói ườ ề probably won't cũng đã m h , không rõ ườ ơ ồ ầ ả ừ
"probably won't (có l v i yêu c u (ph n m m) đó không, và thông th ầ ớ không (t c là b n thân c m t ụ ứ ràng).
i vi ầ ế ề ử ụ
ượ ứ
M t s ng ộ ố ứ ượ ố ọ
ừ ố
ế ẽ ề
ế t yêu c u ph n m m s d ng should - nói đ n ầ c mong ch c năng đ ệ ố ầ ự mu n có trong h th ng, và may - ch c năng tùy ch n; đi u này th c ệ ố này trong giao ti p hàng s không t ở ự ế ngày đã ít nhi u đ c s d ng thay th nhau. Chính đi u đó s khi n cho vi c s d ng chúng làm văn b n tr nên thi u tính nh t quán, các ả ườ c yêu c u trong h th ng, might - ch c năng đ ứ ề ữ ế ở t, b i chính b n thân nh ng t ả ượ ử ụ ề ệ ử ụ ế ấ
Page 10 Phân tích yêu c u ph n m m. ầ ề ầ
gây ầ ử ụ ư ậ ế ầ ơ ừ
yêu c u thi u tính đ n nghĩa! Nh v y c n tránh s d ng các t nh m l n và mang tính ch quan. ủ ầ ẫ
Page 11 Phân tích yêu c u ph n m m. ầ ề ầ
