daigai

Well-Known Member
Link tải luận văn miễn phí cho ae Kết nối

Phần 3 Xây dựng tài liệu đặc tả 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 nói rõ cách đặc tả yêu cầu phần mềm
2. Tài liệu tham khảo
• Requirements Management in Enterprise Architect
• Slide môn Xây Dựng và Thiết Kế Phần Mềm Của thầy Huỳnh Quyết Thắng
• Managing Software Requirement
II. Đặc tả các yêu cầu phần mềm
1. Giới thiệu
Không phụ thuộc các yêu cầu phần mềm được tìm ra , được xây dựng như thế nào, cuối cùng bao giờ chúng ta cũng phải đặc tả các yêu cầu này.
Các tiêu thức để đánh giá một đặc tả:
• Tính nhất quán
• Tính thân thiện
• Dễ sử dụng
Trong đặc tả phải nêu được cả Business Requirement, phạm vi ứng dụng, giới hạn của ứng dụng.
Trong đặc tả phải nêu được đầy đủ các User Requirement, sử dụng các mẫu (template) của các trường hợp sử dụng của từng yêu cầu.
2. Các điểm lưu ý khi đặc tả yêu cầu phần mềm
Làm theo và sử dụng các mẫu đặc tả : nên quy định một mẫu đặc tả chung trong tổ chức của chúng ta, sử dụng một số mẫu (template) nào đó: IEEE 830 – 1998. Lưu ý rằng hoàn toàn có quyền sửa đổi , quy định lại các biểu mẫu nếu như điều đó là cần thiết.
Xác đinh rõ nguồngốccủayêucầuphầnmềm trongđặc tả: để có thể tấtcả biết đượctạisaolại phát sinhcác yêu cầuphầnmềm này, chúng ta nên chỉ rõ tạisaonólạicó-từ NSD, yêu cầuchứcnăng hệ thống, do quy chế, hay do các nguồn khác.
Đặt nhãn (label) cho từng yêu cầuphầnmềm: chúng ta nên thống nhất quy ướccách đặt nhãn (tên) chocác yêu cầu - nên đặt nhãn làm sao nhãn củacácyêu cầu mang càng nhiều các thông tin về các yêucầu đó càng tốt.
Ghi lại các nguyên tắccủa công việc (business rule): các nguyên lý hoạt động củahệ thống, của các thaotác, công việccần đượcmiêutả.
Nên tạorama trận theo dõi các yêu cầuphầnmềm (requirements traceability matrix): điều này rấtcóíchtrong quá trình phân tích các yêu cầu, quá trình thiếtkế, lập trình và kiểmthử các chứcnăng củahệthống. Ma trậnnàycũng rất có ích giúp cho chúng taliên kếtcácchứcnăng vớicácyêucầuphầnmềmliên quan. Nên sử dụng thường xuyên ma trận trongsuốt thời gian phát triển phần mềm
3. Ghi lại các nguyên tắc của công việc
Khi NSD miêu tả cho chúng ta mộthoạt động nào đó chỉđượcthựchiện trong những diềukiệnnhất định, donhững tác nhân nhất định, v.v. tức là chúng ta đãcómột nguyên tắc công việc.
Nguyên tắc côngviệclàtậphợp các các nguyên tắc hoạt động của quá trình thựchiện công việc.
Chúng ta có nghĩ vụ phải xây dựng các yêu cầuhệthống về mặtchứcnăng để đáp ứng các nguyên tắccông việc này - tuy nhiên không nền đồng nhấtyêucầuchứcnăng với nguyên tắc công việc.
Trong SRS nên tậphợpvà đặctả tấtcả các nguyên tắc của công việcvàomộtmục riêng.

4. Đặc tả yêu cầu phần mềm theo mẫu
Có thể nó đặctả yêu cầuphầnmềm (SRS) được coi như: đặctả chứcnăng hệ thống, sự thoả thuậnvề chứcnăng, đặctả hệ thống.
SRS là cơ sở cho mọihoạt động củadự án: phân tích, thiếtkế, lậpkế hoạch, viếtmã, kiểmthử, v.v.
Khi đặctả yêu cầuphầnmềmcóthể sử dụng các công cụ:
• Vănbản (textual document)
• Mô hình đồ hoạ (graphical models)
• Các ngôn ngữđặctả hình thức
Các điểmlưuý:
• Tấtcả các yêu cầuphầnmềmphải được đua vào đặctả.
• SRS đượcxâydựng trước khi phân tích và xây dựng phầnmềm
4.1. Gán nhãn các yêu cầu phần mềm
Để có đượcmột đặctả tốt, có thể theo dõi mối liên quan giữacácyêucầu, quá trình phát sinh rachúng, v.v. chúng ta cầncómột quy định gánnhãn các yêu cầu một cách khoa học. Có một số phương pháp thông dụng:
• Gánnhãnliêntiếp (sequence number): UR - xxxx
• Gán nhãn theo thứ bậc (Hierarchical numbering): UR 3.2.1 (phương pháp này đượcsủdụng rộngrãi nhất)


Link Download bản DOC
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:

 
Các chủ đề có liên quan khác

Các chủ đề có liên quan khác

Top