CHƯƠNG I YÊU CẦU PHẦN MỀM · PDF fileThu nhận yêu cầu 1. Tầm quan...
Transcript of CHƯƠNG I YÊU CẦU PHẦN MỀM · PDF fileThu nhận yêu cầu 1. Tầm quan...
TNYCThu nhận yêu cầu
1
CHƯƠNG IYÊU CẦU PHẦN MỀM
Thu nhận yêu cầu
1. Tầm quan trọng của xác định yêu cầu 2. Yêu cầu phần mềm (software requirement) là gì?3. Phân loại yêu cầu4. Kỹ thuật yêu cầu (Requirements Engineering - RE) là gì?5. Lợi ích từ quy trình xác định yêu cầu chất lượng cao6. Vai trò của người phân tích yêu cầu
Nội dung
2
Thu nhận yêu cầu
Công nghệ và xã hội không ngừng thay đổi một cách nhanh chóng, và ảnh hưởng to lớn của hệ thống thông tin trong một môi trường vô cùng phức tạp
Kỹ thuật yêu cầu (requirements engineering - RE) đóng một vai trò vô cùng quan trọngCần có sự tham gia của các chuyên gia trong việc thu nhận và quản lý yêu cầu
Hệ thống nghiệp vụ - Hệ thống thông tin – Phần mềm
1. Tầm quan trọng trong XĐ yêu cầu?
3
Thu nhận yêu cầu
Sản phẩm phát triển với tốc độ chóng mặt. Ngày nay khách hàng thường đòi hỏi phiên bản mới của sản phẩm trong khoảng thời gian dưới 1 năm
Ví dụ: theo Siemens thì 20 năm trước, 55% hàng bán là từ sản phẩm tuổi <5. Ngày nay, 75% hàng bán được là từ sản phẩmcó tuổi <5.
Một số đặc trưng
4
5
Thu nhận yêu cầu
Thay đổi không ngừng của công nghệ Các kỹ sư không thể sống cả đời với nghề nghiệp của mình trong 1 công ty nào đó
Một số đặc trưng
6
Thu nhận yêu cầu
Gia công phần mềm đóng một vai trò vô cùng quan trọng có tính toàn cầu
Vai trò quan trọng của đặc tả. VD: Đặc tả cho máy giặt cho đội ngũ xây dựng nó chưa từng nhìn thấy máy giặt lần nào
Một số đặc trưng
7
Thu nhận yêu cầu
Việc phát triển phần mềm thường liên kết chặt chẽ với nghiệp vụ mà nghiệp vụ thì biến đổi không ngừng nên các phiên bản mới của sản phẩm thường được tạo bằng cách thay đổi phần mềm nhằm hạ thấp chi phí biến đổi
Một số đặc trưng
8
Thu nhận yêu cầu
Tại sao yêu cầu là quan trọng?
Nguyên nhân thất bại của dự án (RE-62%)1. Những yêu cầu không đầy đủ - Incomplete requirements (13.1%)2. Lack of user involvement (12.4%)3. Lack of resources (10.6%)4. Unrealistic expectations (9.9%)5. Lack of executive support (9.3%)6. Changing requirements and specifications (8.7%)7. Lack of planning (8.1%)8. System no longer needed (7.5%)
Thu nhận yêu cầu
Ai thành công ???
For the first half of the 20th century, the Indian and Harley Davidson motorcycle manufactures were fierce competitors.In WWII the U. S. Army asked for a 500 cc motorcycle.Indian made one for them.Harley Davidson built a 750 cc motorcycle.Have any of you heard of a Indian motorcycle?
10
Thu nhận yêu cầu
Một yêu cầu là một đặc trưng của hệ thống, hay là sự mô tả những việc, mà hệ thống có khả năng thực hiện để hoàn thành mục tiêu của hệ thống
2. Yêu cầu (requirement)
11
Thu nhận yêu cầu
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2.
Theo IEEE 1990
12
Thu nhận yêu cầu
13
Yêu cầu?
“Tôi không có thời gian để viết yêu cầu!
Bạn không thấy tôi đang bận gỡ lỗi?”
Thu nhận yêu cầu
Yêu cầu
Yêu cầu có thể được ràng buộc bởi hợp đồng hay văn bản Có những yêu cầu ngầm định (implicit)Một yêu cầu có thể được nhận biết (known,spoken)/ không nhận biết (forgotten, unspoken…)
Thu nhận yêu cầu
Khả thi - FeasibleCó giá trị - ValidKhông nhập nhằng - UnambiguousDễ kiểm chứng - VerifiableDễ biến đổi - ModifiableToàn vẹn - ConsistentĐầy đủ - CompleteLần vết được - Traceable
Đặc trưng của yêu cầu
15
16
Thu nhận yêu cầu
3. Phân loại yêu cầu
17
…….
Thu nhận yêu cầu
18
Yêu cầu hệ thống
Yêu cầu chức năng: chức năng dịch vụ hệ thống cung cấpYêu cầu phi chức năng: những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển…, chủ yếu là những yêu cầu về chất lượngRàng buộc: phản ảnh những đặc trưng của miền ứng dụng. Chúng có thể là những yêu cầu chức năng hay yêu cầu phi chức năng.
Thu nhận yêu cầu
Yêu cầu chức năng
Yêu cầu chức năng chỉ ra những gì hệ thống làm, chúng thường quan hệ các use-case hay những qui tắc nghiệp vụ (business rule)Một số yêu cầu chức năng
Chức năng tính toánChức năng lưu trữChức năng tìm kiếmChức năng kết xuấtChức năng backup, restoreChức năng đa người dùngChức năng đa phương tiện…
Thu nhận yêu cầu
20
Ví dụ
Trong hệ thống quản lý thư việnNgười dùng có thể tìm kiếm, download, in những bài báoNgười dùng được cấp một vùng lưu trữ riêng để có thể copy để lưu trữ tài liệu lâu dài…
Thu nhận yêu cầu
Yêu cầu phi chức năng
Một số yêu cầu phi chức năngĐộ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ… Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình…Yêu cầu của người sử dụng: dễ sử dụng, thân thiệnRàng buộc về ngân sáchPhù hợp với các chính sách của tổ chức sử dụng hệ thốngYêu cầu tương thích giữa phần cứng và phần mềmCác yêu cầu từ các tác nhân ngoài khác…
Thu nhận yêu cầu
22 CNPM/NN
Yêu cầu phi chức năng
Thu nhận yêu cầu
23
Ví dụ
Trong hệ thống quản lý thư việnYêu cầu sản phẩm: giao diện người dùng không chứa frame và applet javaYêu cầu tổ chức: qui trình phát triển hệ thống và tài liệu phân phối phải phù hợp theo tiêu chuẩn “STAN-07” (sử dụng ngôn ngữ, phương pháp thiết kế…)Yêu cầu ngoài: hệ thống không được lộ thông tin của khách hàng (tên, số tham chiếu…)
Thu nhận yêu cầu
Yêu cầu nghiệp vụ (Business requirements)Yêu cầu người dùng (User requirements) Yêu cầu chức năng (Functional requirements)
Các mức yêu cầu
24
Thu nhận yêu cầu
Biễu diễn các mục tiêu của tổ chức hay khách hàng yêu cầu hệ thống phải có Yêu cầu nghiệp vụ thường do người tài trợ cho dự án, khách mua phần mềm, người quản lý các người dùng, bộ phận tiếp thị (maketing)…Thường được ghi nhận trong phần đặc tả (vision) và phạm vi (scope) của tài liệu, đôi khi còn được gọi là tuyên bố dự án (project charter) hay tài liệu yêu cầu thị trường (market requirements document)
Yêu cầu nghiệp vụ
25
Thu nhận yêu cầu
Mô tả mục tiêu (goal) hay tác vụ (task) của người dùng đối với hệ thống. Các cách để biểu diễn yêu cầu người dùng:
use cases, scenarioBảng event-response.
Yêu cầu người dùng mô tả cái (what) mà người dùng có thể làm đối với hệ thống.
Ví dụ: use case "Make a Reservation" dùng trong các website của hàng không, thuê xe, hay khách sạn.
Yêu cầu người dùng
26
Thu nhận yêu cầu
Xác định chức năng của phần mềm mà các nhà phát triển phải xây dựng để giúp người dùng hoàn thành nhiệm vụ của họ, thỏa mãn được yêu cầu nghiệp vụ. Đôi khi còn được gọi là yêu cầu về hành vi (behavioral requirements)Ví dụ: Hệ thống sẽ gởi một xác nhận giữ chỗ cho khách hàng…
Yêu cầu chức năng
27
Thu nhận yêu cầu
Mối liên hê ̣ giữa các mức yêu cầu
Thu nhận yêu cầu
Các mức yêu cầu
29
Thu nhận yêu cầu
Các loại yêu cầu
Môi trường vật lýGiao tiếpNgười dùng và nhân tố con ngườiChức năngLập tài liệuDữ liệuTài nguyênAn ninhBảo đảm chất lượng
Thu nhận yêu cầu
4. Kỹ thuật yêu cầu (RE)
Nhấn mạnh tới tính cộng tác và lặp lạiTạo tài liệu cho những kết quả quan sátKiểm tra
Nó còn nhấn mạnh tới vai trò của kinh nghiệm và tính xã hội
31
Thu nhận yêu cầu
Quy trình phát triển yêu cầu
32
Thu nhận yêu cầu
Sơ đồ kỹ thuật yêu cầu
33
Thu nhận yêu cầu
Ranh giới yêu cầu
34
Thu nhận yêu cầu
Kỹ thuật yêu cầu
35
Thu nhận yêu cầu
Lợi ích của việc tạo yêu cầu có chất lượng thường không dễ thấy nên nhiều người thường nhầm lẫn là tiêu tốn thời gian khi bàn luận về yêu cầu sẽ dẫn đến làm chậm trễ việc hoàn thành sản phẩm
Giảm việc phải làm lạiThu thập yêu cầu cho phép đội phát triển hiểu rõ về người dùng và thị trường, một nhân tố quan trọng cho sự thành công của bất kỳ dự án nào
5. Lợi ích khi thu thập yêu cầu hiệu quả
36
Thu nhận yêu cầu
Khi người dùng cùng tham gia trong giai đoạn thu thập yêu cầu sẽ xây dựng được niềm tin và lòng trung thành của khách hàngĐội phát triển có thể tránh viết những đoạn mã thừa khi nắm vững nhiệm vụ của người dùngSự quan tâm của khách hàng giảm được khoảng cách giữa cái người dùng cần và cái người phát triển tạo ra.
Lợi ích
37
Thu nhận yêu cầu
1. Lỗi liên quan đến yêu cầu ít hơn2. Giảm được việc phải làm lại trong bước phát triển3. Ít hơn trong việc tạo tính năng không cần thiết4. Giảm chi phí mở rộng5. Quá trình phát triển hệ thống sẽ nhanh hơn6. Giảm bớt các giao tiếp sai lầm với khách hàng7. Hạn chế phạm vi hệ thống bị phình rộng8. Hạn chế được những hỗn độn dự án9. Các ước lượng về hệ thống chính xác hơn10. Mức độ thỏa mãn khách hàng và thành viên của
đội sẽ cao hơn
Những lợi ích không định lượng
38
Thu nhận yêu cầu
Nhà phân tích yêu cầu (Requirements analyst)Nhà phân tích hệ thống (Systems analyst)Kỹ sư yêu cầu (Requirements engineer)Nhà quản lý yêu cầu (Requirements manager)Nhà phân tích (Analyst)
6. Nhà phân tích yêu cầu
39
Thu nhận yêu cầu
Nhà phân tích là người chuyển các ý tưởng thành những đặc tả yêu cầu.Nhà phân tích là người có quan hệ truyền thông với các stakeholder, giúp các stakeholder tìm thấy sự khác nhau giữa cái họ muốn và cái họ thực sự cầnLà người có nhiệm vụ cơ bản là thu thập, phân tích, ghi chép và kiểm tra nhu cầu của các stakeholder
Vai trò của nhà phân tích
40
Thu nhận yêu cầu
Họ như là một cầu nối giữa cộng đồng khách hàng và đội phát triển phần mềm. Nhà phân tích đóng vai trò trung tâm trong việc thu thập và phổ biến thông tin, còn người quản lý dự án (project manager) giữ vai trò lãnh đạo trong việc truyền đạt thông tin dự án
Vai trò của nhà phân tích
41
Thu nhận yêu cầu
Các mối quan hệ
42
Thu nhận yêu cầu
Nhà phân tích trước tiên phải hiểu mục tiêu của người dùng, sau đó xác định các yêu cầu chức năng; cho phép người quản lý dự án xây dựng các ước lượng; người phát triển (developer) thiết kế, xây dựng và kiểm định sản phẩm.
Nhiệm vụ tổng quát
43
Thu nhận yêu cầu
Xác định yêu cầu nghiệp vụ.Xác định các stakeholder và các lớp người dùngRút ra những yêu cầu (Elicit)Viết đặc tả yêu cầuMô hình hóa yêu cầuĐiều hành việc đánh giá yêu cầuPhân loại ưu tiên các yêu cầuQuản lý yêu cầu
Nhiệm vụ
44
Thu nhận yêu cầu
Kỹ năng lắng ngheKỹ năng phỏng vấnKỹ năng phân tíchKỹ năng điều khiển (họp)Kỹ năng quan sátKỹ năng viếtKỹ năng tổ chứcKỹ năng mô hình hóaKỹ năng giao tiếpTính sáng tạo
Kỹ năng của nhà phân tích
Thu nhận yêu cầu
46
Create a means to transport a singleindividual from home to place of work.
ManagementInterpretation
I TInterpretation
UserInterpretation
Nhập nhằng
Requirement:
Thu nhận yêu cầu
Không gồm người dùng không đầy đủYêu cầu người dùng phình ra (Creeping UR) RequirementsYêu cầu nhập nhằngYêu cầu mạ vàng (Gold Plating): khi người phát triển cộng thêm chức năng không có trong đặc tả Yêu cầu tối tiểuBỏ qua lớp người dùngHoạch định không chính xác
Những rủi ro
48
Dư thừa thông tin,rối rắm cho người sử dụng.
Phù hợp yêu cầu người dùng
Thu nhận yêu cầu
51 CNPM/NN
Thu nhận yêu cầu
Thực hành
Dưới vai trò của người phân tích hệ thống hãy đưa một dự án CNTT và đưa ra các yêu cầu của hệ thống, cách thức xác định các yêu cầu đó
52