Hệ thống máy tính - Chương 3: Xác định yêu cầu hệ thống (Requirement Engineering)

Nội dung text: Hệ thống máy tính - Chương 3: Xác định yêu cầu hệ thống (Requirement Engineering)

1. Chương 3 Xác định yêu cầu hệ thống (Requirement Engineering) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 1
2. Nội dung • Xác định yêu cầu hệ thống là gì? • Bốn bước thực hiện • Các loại yêu cầu hệ thống • Bước 1: thu thập yêu cầu • Bước 2: phân tích yêu cầu • Bước 3: Đặc tả yêu cầu • Bước 4: Đánh giá yêu cầu BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 2
3. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 3
4. Chu kỳ phát triển phần mềm (Software Development Life Cycle - SDLC) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 4
5. Software Requirements (SR)? • Requirements là đặc tả của cái gì cần được thực thi, mô tả hệ thống sẽ hoạt động như thế nào hay hệ thống có thuộc tính gì. • Yêu cầu cũng có thể là các ràng buộc trong quá trình phát triển hệ thống. • Requirements described the “what” of a system, not the “how” BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009
6. Tầm quan trọng của giai đoạn xác định yêu cầu • Là giai đoạn quan trọng nhất trong chu kỳ phát triển phần mềm, nó quyết định chính xác cần phải phát triển cái gì • Without well-written requirements specifications: – Developers do not know what to build – Customers do not know what to expect – There is no way to validate that the built system satisfies the requirements BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 6
7. Phân loại yêu cầu BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009
8. Requirement engineering • Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system • Requirements engineering produce one large document, written in a natural language, contains a description of what the system will do without describing how it will do BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 8
9. Các khó khăn của giai đoạn xác định yêu cầu 1. Requirements are difficult to uncover 2. Requirements change 3. Over-reliance on CASE tools 4. Tight project schedule 5. Communication barries 6. Market-driven software development 7. Lack of resources BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 9
10. Giá phải trả cho việc tìm và sửa lỗi BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 10
11. Input/ Output của xác định yêu cầu • Input: – Các yêu cầu từ khách hàng (Problem statement prepared by the customers) • Output: – Tài liệu đặc tả yêu cầu ( Software requirements specification – SRS) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 11
12. Ví dụ • Tham khảo Problem statement cho hệ thống – Hệ thống quản lý điểm của sinh viên (page 39 –India) – Hệ thống quản lý thư viện của trường đại học (page 40 – India) – Hệ thống đặt vé tàu (page50 ) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 12
13. Các bước cơ bản • Thu thập yêu cầu (Requirement Elicitation) • Phân tích yêu cầu (Requirement Analysis) • Tạo tài liệu đặc tả yêu cầu (Requirement Documentation) • Đánh giá yêu cầu (Requirement Review) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 13
14. Yêu cầu hệ thống • Các yêu cầu của hệ thống phần mềm thường được chia thành ba loại: – yêu cầu chức năng – yêu cầu phi chức năng – yêu cầu miền ứng dụng. • Thực tế khó phân biệt ba loại yêu cầu này một cách rõ ràng. • Case study: Hệ thống đặt vé tàu trước BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 14
15. Yêu cầu chức năng (Functional requirement) • Còn được gọi là product feature • Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức năng hoặc các dịch vụ của hệ thống một cách chi tiết. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 15 6/11/2021 15
16. Ví dụ về Yêu cầu chức năng • Xác định các yêu cầu chức năng của Hệ thống đặt vé tàu trước • Problem statement for Railway reservation ? BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 16 16
17. Yêu cầu phi chức năng (Non- functional requirement) • Yêu cầu phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. Yêu cầu phi chức năng thường định nghĩa các thuộc tính như: độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ và các ràng buộc của hệ thống như: khả năng của thiết bị vào/ra, giao diện • Một số yêu cầu phi chức năng còn có liên quan đến quy trình xây dựng hệ thống. Ví dụ: các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình • Các yêu cầu phi chức năng có thểb ị hạn chế hơn những yêu cầu chức năng. Nhưng nếu nó không được thoả mãn thì hệ thống sẽ không sử dụng được. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 17 6/11/2021 17
18. Yêu cầu phi chức năng (tt1) • Các yêu cầu phi chức năng xuất hiện là do yêu cầu của người sử dụng, ràng buộc về ngân sách, các chính sách của tổ chức sử dụng hệ thống, yêu cầu tương thích giữa phần cứng và phần mềm và các tác nhân ngoài khác. Do đó, chúng ta có thể phân loại các yêu cầu phi chức năng như sau: • Các yêu cầu về sản phẩm xác định ứng xử của sản phẩm như: hiệu năng, khả năng sử dụng, độ tin cậy của sản phẩm • Các yêu cầu về tổ chức: các yêu cầu này được lấy từ những chính sách và quy tắc của khách hàng hoặc tổ chức sử dụng hệ thống. • Các yêu cầu ngoài: được xác định từ các tác nhân ngoài của hệ thống. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 18 6/11/2021 18
19. Yêu cầu phi chức năng (tt1) • Yêu cầu phi chức năng (tt2) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 19
20. Ví dụ vê yêu cầu phi chức năng • Xác định các yêu cầu phi chức năng của Hệ thống đặt vé tàu trước – Yêu cầu về sản phẩm: phải xây dựng website – Yêu cầu về mặt tổ chức: mạng máy tính nối tất cả các trạm xe lửa với nhau. – Yêu cầu ngoài: Hệ thống phải bảo mật BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 20 20
21. Ví dụ vê yêu cầu phi chức năng • Các mục tiêu và yêu cầu phi chức năng có thể thẩm định được của Hệ thống đặt vé tàu trước – Mục tiêu của hệ thống là dễ sử dụng đối với nhân viên cũng như hành khách và được tổ chức để sao cho tối thiểu hoá được lỗi. – Các yêu cầu phi chức năng có thể thẩm định được: Những người nhân viên sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi người sử dụng là không quá hai lỗi một ngày. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 21 6/11/2021 21
22. Yêu cầu miền ứng dụng (Domain requirement) • Yêu cầu miền ứng dụng được xác định từ miền ứng dụng của hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng dụng. Nó có thể là yêu cầu chức năng hoặc phi chức năng. – Nếu yêu cầu miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được. • Ví dụ: trong hệ thống thư viện có yêu cầu miền nghiệp vụ như sau: Because of copyright restrictions, some received on-line documents must be deleted immediately after printing BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 22 6/11/2021 22
23. Yêu cầu miền ứng dụng (Domain requirement) • Một số vấn đề liên quan đến yêu cầu miền ứng dụng: – Được diễn tả bằng ngôn ngữ riêng của miền ứng dụng mà có thể kỹ sư phần mềm không hiểu đuợc. – Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 23 6/11/2021 23
24. Bước 1: Thu thập yêu cầu Bước thu thập yêu cầu thường gặp nhiều khó khăn 1. Khó khăn về phạm vi (Problems of scope): đường biên hệ thống thường mập mờ, hay khách hàng chỉ nhắm đến các yếu tố kỹ thuật hơn là mục tiêu tổng thể của hệ thống 2. Khó khăn về hiểu biết khách hàng: khách hàng không biết họ cần gì, có ý kiến trái ngược nhau về hệ thống cần xây dựng, ít hiểu biết về kỹ thuật, thời gian giao tiếp với kỹ sư hệ thống thường rất hạn chế. 3. Khó khăn về tính ổn định: yêu cầu thường thay đổi theo thời gian BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 24
25. Bước 1: Thu thập yêu cầu • Nhận biết stakeholder “anyone who benefits in a direct or indirect way from the system which is being developed” – Operation manager, product manager – Makerting people – Internal/external customer – End-users – Consultant – Product engineer, Software engineer – sponsor • Mỗi stakeholder có mộttầm nhìn (viewpoint) khác nhau về hệ thống BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 25
26. Bước 1: Thu thập yêu cầu • “Put three stakeholders in a room and ask them what kind of system they want. You’re likely to get four or more different opinions” • Các quan điểm khác nhau thường sẽ dẫn đến xung đột ➔Kỹ sư (requirement engineer) cần phân loại tất cả thông tin sao cho người ra quyết định dễ chọn ra được tập các yêu cầu ổn định. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 26
27. Bước 1: Thu thập yêu cầu • Đánh giá tính khả thi về nghiệp vụ và kỹ thuật của hệ thống • Nhận biết xem ai sẽ giúp xác định yêu cầu và hiểu biết thực chất của tổ chức • Xác định môi trường kỹ thuật • Nhận biết các ràng buộc nghiệp vụ (domain constraint) • Xác định các phương pháp thu thập yêu cầu ( phỏng vấn, nhóm thực hiện). • Tạo các kịch bản (scenario) để giúp khách hàng/người dùng xác định tốt hơn các yêu cầu chính của hệ thống BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 27
28. Bước 1: Eliciting techniques • Traditional Techniques • Questionnaires and Surveys • Interviews • Analysis of existing documentation • Group Elicitation: kỹ thuật thảo luận nhóm giúp tìm ra nhanh chóng những ý tưởng mới • Group brainstorming sessions • RAD (Rapid Application Development) • JAD (Joint Application Design) • Prototyping BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009
29. Kết quả của thu thập yêu cầu • Nhu cầu và tính khả thi của hệ thống • Phạm vi của hệ thống • Danh sách customers, users, and other stakeholders tham gia vào quá trình thu thập yêu cầu • Mô tả môi trường kỹ thuật của hệ thống. • Danh mục các yêu cầu và các ràng buộc cho mỗi yêu cầu. • Tập hợp các kịch bản se xảy ra khi sử dụng hệ thống dưới các điều kiện thao tác khác nhau • Bất kỳ prototype để giúp hiểu tốt hơn các yêu cầu còn mơ hồ. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 29
30. Bước 2: Phân tích yêu cầu • Phân tích yêu cầu nhằm phân loại và tổ chức các yêu cầu thành các tập con có liên quan nhau; xếp loại các yêu cầu theo nhu cầu của người dùng. • BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 30
31. Các câu hỏi để phân tích yêu cầu 1. Is each requirement consistent with the overall objective for the system/product? 2. Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? 3. Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? 4. Is each requirement bounded and unambiguous? BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 31
32. Các câu hỏi để phân tích yêu cầu 5. Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? 6. Do any requirements conflict with other requirements? 7. Is each requirement achievable in the technical environment that will house the system or product? 8. Is each requirement testable, once implemented? BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 32
33. Bước 2: Phân tích yêu cầu • Các bước phân tích yêu cầu theo hướng dòng dữ liệu (Flow oriented) Draw the context diagram Develop Prototypes (optional) Model the requirements Finalise the requirements BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 33
34. Flow-oriented modeling • Flow-oriented modeling vẫn là 1 trong những cách thông dụng nhất hiện nay để phân tích hệ thống • Tuy lược đồ dòng dữ liệu ( Data Flow Diagram– DFD) và các lược đồ có liên quan không thuộc định dạng của UML nhưng chúng vẫn được dùng để bổ sung cho các lược đồ UML và giúp xác định rõ hơn các yêu cầu của hệ thống BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 34
35. Flow-oriented modeling • Lược đồ Data Flow Diagram (DFD) dùng để mô hình hóa các yêu cầu hệ thống. • DFD biểu diễn các bước mà luồng dữ liệu phải trải qua trong hệ thống từ điểm đầu tới điểm cuối. • DFD mô hình hoá hệ thống từ góc độ một chức năng. Việc tìm vết và tư liệu hoá quan hệ giữa dữ liệu với một quy trình rất có ích đối với việc tìm hiểu toàn bộ hệ thống. • DFD chứa các ký pháp dễ hiểu đối với khách hàng. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 35
36. Các ký hiệu trong DFD Data Flow Process Source of system inputs or sink of system outputs Data store BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 36
37. Lược đồ dòng dữ liệu (Data Flow Diagram - DFD) • DFD có thể biểu diễn ở nhiều mức khác nhau. – DFD mức 0 hay còn gọi lược đồ ngữ cảnh (context diagram) : biểu diễn cả hệ thống như 1 process, với các mũi tên để chỉ ngõ vào và ra của hệ thống – DFD mức 1: hệ thống được chia nhỏ theo chức năng, mỗi process sẽ biểu diễn một chức năng con. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 37
38. Lược đồ ngữ cảnh (Context diagram) • Là mô hình đơn giản để xác định phạm vi (boundary) và giao diện (interface) của hệ thống với thế giới bên ngoài. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 38
39. DFD mức 1 BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 39
40. Prototype • Trong giai đoạn phân tích yêu cầu, có lúc cần phải mô hình hóa hệ thống cần xây dựng → mô hình này được gọi là prototype. • Prototype được dùng như 1 phương tiện: – Giúp suy diễn các yêu cầu của hệ thống, – Để khách hàng và nhà phát triển đánh giá yêu cầu BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 40
41. Phát triển prototype (Development of protoype) • Xây dựng prototype tương tự như hệ thống cần xây dựng, khách hàng sẽ xem xét cho cho ý kiến phản hồi, prototype sẽ liên tục được điều chỉnh để thỏa mãn yêu cầu khách hàng. • Prototype là cách giúp tìm hiểu hiệu quả mong muốn thực sự của khách hàng. • Prototype thường được xây dựng nhanh, chi phí thấp, nên sẽ có nhiều hạn chế và thiếu xót so với hệ thống ➔cuối Prototype chỉ là 1 tùy chọn (optional) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 41
42. Chọn phương pháp prototype • Có 2 dạng prototype – Close-ended: còn được gọi là throwaway prototype, prototype được dùng một lần và chỉ để mô tả yêu cầu – Open-ended: còn được gọi là evolutionary prototype, prototype được dùng như phần đầu tiên của quá trình phân tích và tiếp tục được dùng trong các giai đoạn tiếp theo cho đến khi thành hệ thống cuối cùng • Để chọn dạng nào tùy thuộc vào: – Miền ứng dụng (Application area) – Độ phức tạp của ứng dụng (Application complexity) – Đặc tính của khách hàng và dự án (Customer & project characteristics) BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 42
43. Chọn phương pháp prototype BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 43
44. Throwaway prototyping • Sau khi thu thập sơ bộ yêu cầu, một mô hình đơn giản được xây dựng để người dùng có thể thấy 1 cách hình ảnh yêu cầu của họ có thể được thực thi như thế nào. • Có thể tạo mỗi mô hình cho từng thành phần khác nhau của hệ thống. Sau khi khách hàng khảo sát và làm rõ hơn yêu cầu của họ thì prototype có thể được 'thrown away‘→ hệ thống sẽ được chính thức xây dựng dựa vào các yêu cầu đã xác định được. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 44
45. Throwaway prototyping methods • Prototypes có thể được phân loại dựa vào mức độ trung thực (fidelity) so với sản phẩm thực khi xét về diện mạo (appearance), cách tương tác (interaction) • Các phương pháp tạo throwaway Prototype dựa theo độ trung thực: – Paper Prototyping: dùng giấy và bút. – GUI Builder : tạo giao diện giống hệ thống thực với các click dummy không có chức năng đi kèm – storyboards BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 45
46. Các bước tạo throwaway Prototype 1. Write preliminary requirements 2. Design the prototype 3. User experiences/uses the prototype, specifies new requirements 4. Repeat if necessary 5. Write the final requirements 6. Develop the real products BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 46
47. Evolutionary Prototyping • Khi cần xây dựng 1 hệ thống mới hay khi cần cải tiến và phát hiện thêm các yêu cầu mới. • " evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood.” • Khi phát triển hệ thống bằng evolutionary Prototyping, hệ thống sẽ liên tục được tinh chỉnh và xây dựng lại. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 47
48. Evolutionary Prototyping • Các nhà phát triển có thể tập trung vào việc phát triển từng phần của hệ thống thay vì phải phát triển cả hệ thống khi mà họ chưa hiểu đầy đủ hết hệ thống. • Prototype có thể không có đầy đủ tính năng nhưng chúng có thể được dùng tạm thời (interim) cho đến khi hệ thống được hoàn chỉnh. – Caution: khi người dùng sử dụng prototype trong lúc đợi sản phẩm hoàn chỉnh, có thể họ cho rằng hệ thống bị lỗi 'flawed‘ BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 48
49. Evolutionary Prototyping • Để giảm rủi ro, nhà phát triển không nên triển khai các tính năng chưa đuợc hiểu đầy đủ. • Khi người dùng sử dụng prototype, họ có cơ hội phát hiện các tính năng mới và đưa ra các yêu cầu mới cho nhà phát triển.→ nhà phát triển sẽ thay đổi lại đặc tả yêu cầu của phần mềm, cập nhật thiết kế, viết lại mã và test lại prototype. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 49
50. Bước 3: Đặc tả yêu cầu • Yêu cầu cần được đặc tả sao cho có thể dẫn đến việc thực thi thành công phần mềm. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 50
51. Bước 3: Đặc tả yêu cầu • Tạo tư liệu về yêu cầu (requirement documentation) là một hoạt động rất quan trọng sau khi thu thập và phân tích yêu cầu hệ thống. Đây là cách để biểu diễn yêu cầu theo một định dạng thống nhất. • Các tài liệu về yêu cầu được gọi làđặc tả yêu cầu phần mềm (Software requirement Specification – SRS) • Các đặc tả có thể là tài liệu, mô hình đồ họa, mô hình toán học, tập hợp các ngữ cảnh hay dùng. • Có một số mẫu tiêu chuẩn“ standard template”, tuy nhiên tùy theo hệ thống các đặc tả này có thể thay đổi linh động theo. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 51
52. Các nguyên tắc đặc tả yêu cầu 1. Tách phần chức năng khỏi phần thực thi. 2. Xây dựng một mô hình mô tả hệ thống với các tác nhân bên ngoài hệ thống 3. Xác lập ngữ cảnh mà phần mềm được vận hành (các hệ thống khác có tương tác với phần mềm đang khảo sát) 4. Xác định môi trường mà phần mềm sẽ vận hành 5. Tạo mô hình ý niệm hơn là mô hình thiết kế hay thực thi 6. Chấp nhận “the specifications must be tolerant of incompleteness and augmentable.” BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 52
53. Nội dung của SRS 1. Functionality: phần mềm được dùng để làm gì? 2. External interfaces: phần mềm giao diện với người dùng như thế nào? Với phần cứng và các phần mềm khác ra sao? 3. Performance: tốc độ, thời gian đáp ứng, thờigian hồi phục, của mỗi chức năng phần mềm thế nào? 4. Attributes: khả năng bảo trì, độ chính xác, độ tin cậy, khả năng bảo mật, 5. Design constraints: Phần mềm bị ràng buộc bởi các tiêu chuẩn nào? Ngôn ngữ thực thi, chính sách bảo toàn cSDL, hạn chế về tài nguyên, hệ điều hành sử dụng, BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 53
54. Yêu cầu của SRS 1. Nên xác định đúng tất cả yêu cầu phần mềm. 2. Không nên mô tả bất kỳ chi tiết nào liên quan đến thiết kế hay thực thi 3. Không nên đưa các ràng buộc dư thừa vào SRS. Một số ràng buộc về chất lượng nên đưa vào kế hoạch bảo đảm chất lượng phần mềm Mẫu SRS BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 54
55. Đặc tính của SRS • Correct • Unambiguous • Complete • Consistent • Stability • Verifiable • Modifiable • Traceable BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 55
56. Bước 4 : Đánh giá yêu cầu Requirement validation • Đánh giá SRS được thực hiện bởi: – Software developer – Customer. • Ngay khi việc đánh giá được hoàn tất thì SRS được ký xác nhận bởi cả 2 phía khách hàng và nhà phát triển. → SRS trở thành hợp đồng (contract) để tiếp tục phát triển phần mềm. • Nếu có nhu cầu cần thay đổi yêu cầu trong SRS đã ký thì khách hàng sẽ phải chú thích vào sau mỗi thay đổi phát sinh này BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 56
57. Project • Tuần 3: nộp problem statement của mỗi nhóm • Tuần 4: nộp lược đồ use case (vẽ bằng Rational Rose) và DFD mức 0 và 1 • Tuần 5: nộp SRS • Quy định: – Nộp trễ thì bị 1 điểm trừ – Nộp đúng hạn được thưởng 1 điểm – Bài làm hay được chọn làm bài mẫu và thưởng 1 điểm – Bài làm không đạt thì bị trả làm lại cho đến khi đạt BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 57
58. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 58
59. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 59
60. BM HTTT – Khoa CNTT – ĐHCN tpHCM - 2009 60