Bài giảng Thu nhận yêu cầu - Chương 1: Tổng quan về kỹ thuật yêu cầu - Trần Thị Kim Chi

1 TỔNG QUAN VỀ KỸ THUẬT YÊU CẦU REQUIREMENT ENGINEERING Giảng viên: Trần Thị Kim Chi 2 Nội dung  Khái quát về phần mềm  Tầm quan trọng của việc xác định cầu  Kỹ thuật yêu cầu  Yêu cầu theo quan điểm khách hàng  Nhà phân tích yêu cầu 3 Khái Quát Về Phần Mềm  Software = Program  Software product = Program + Document + Support  Loại sản phẩm phần mềm Generic Product: là sản phẩm đóng gói và bán rộng rãi trên thị trường. Bespoke Product: là sản phẩm được phát triển theo yêu cầu đặc thù của từng khách hàng. 4 Khái Quát Về Phần Mềm Các đặc tính quan trọng của sản phẩm phần mềm  Maintainability: phần mềm có thể thay đổi thuận tiện theo yêu cầu của người dùng  Dependability: tính ổn định, bảo mật và an toàn của phần mềm. Không gây tổn hại về vật chất hay kinh tế cho hệ thống.  Efficiency: Sử dụng hiệu quả tài nguyên của hệ thống cho công việc  Usability: giao diện và phương thức phải phù hợp với người dùng đồng thời đáp ứng đúng yêu cầu của người dùng 5 Phần Mềm – Đủ hay Thiếu  Phần mềm được viết ngay từ khi có những máy tính programable đầu tiên. Được quan tâm và phát triền từ rất sớm  Có rất nhiều phần mềm đã được viết Không thiếu phần mềm  Thực tế việc sản xuất phần mềm không đáp ứng kịp yêu cầu của người sử dụng:  Không đủ về số lượng  Thiếu về chất lượng  Không kịp về thời gian  Phần mềm không đáp ứng đủ cho người dùng 6 Nguyên nhân khách quan  Số lượng phần mềm phải được hiểu là số đầu/loại phần mềm được sử dụng cho từng mục tiêu ứng dụng.  Nhu cầu sử dụng phần mềm là rất lớn  Nhiều ngành nghề cần dùng phần mềm máy tính  Mỗi ngành nghề cần nhiều loại phần mềm khác nhau  Mội loại phần mềm cần nhiều cấp độ khác nhau theo trình độ người dùng 7 Nguyên nhân khách quan  Chất lượng phần mềm cũng chưa đáp ứng tốt hoàn toàn người sử dụng:  Tính customize rất cao của sản phẩm phần mềm.  Trình độ sử dụng khác nhau và điều kiện hạ tầng ứng dụng khác nhau  Nhu cầu phần mềm thường rất cấp bách  Tầm nhìn và chiến lược chưa đầy đủ của người sử dụng  Không có kế hoạch lâu dài  Phải thay đổi theo từng đối tượng người dùng 8 Nguyên nhân chủ quan  Tính chuyên nghiệp trong sản xuất phần mềm chưa cao.  Các dữ liệu quan sát được  Cứ 6 đề án triển khai thì có 2 bị huỷ bỏ  Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt 200-300%)  Các đề án lớn dễ thất bại  3/4 các hệ thống lớn có lỗi khi thực thi  Quá trình phân tích yêu cầu (5 % công sức): để lại 55 % lỗi, có 18 % phát hiện được  Quá trình thiết kế (25 % công sức): để lại 30 % lỗi, có 10 % phát hiện được  Quá trình mã hoá, kiểm tra và bảo trì: để lại 15 % lỗi, có 72 % phát hiện được 9 Nguyên nhân chủ quan  Nhiều vấn đề về phần mềm xuất hiện do thiếu sót trong lúc thu thập, thỏa thuận và chỉnh sửa yêu cầu.  Lỗi xảy ra trong giai đoạn thu thập yêu cầu chiếm từ 40- 60% tổng lỗi trong một dự án phần mềm.  Có sự khác biệt giữa cái mà người phát triển phần mềm (developer) nghĩ và xây dựng với cái mà khách hàng thật sự cần.  "Hello, Phil?” This is Maria in Human Resources. “We're having a problem with the employee system you programmed for us. An employee just changed her name to Sparkle Starlight, and we can't get the system to accept the name change. Can you help?"  "She married some guy named Starlight?"  "No, she didn't get married, just changed her name," Maria replied. "That's the problem. It looks like we can change a name only if someone's marital status changes." Tại sao xác định yêu cầu là quan trọng A story 10  "Well, yeah, I never thought someone might just change her name. I don't remember you telling me about this possibility when we talked about the system. That's why you can get to the Change Name dialog box only from the Change Marital Status dialog box," Phil said. A story 11  "I assumed you knew that people could legally change their name anytime they like," responded Maria. "We have to straighten this out by Friday or Sparkle won't be able to cash her paycheck. Can you fix the bug by then?"  "It's not a bug!" Phil retorted. "I never knew you needed this capability. I'm busy on the new performance evaluation system. I think I have some other change requests for the employee system here, too." [sound of rustling paper] A story 12  "Yeah, here's another one. I can probably fix it by the end of the month, but not within a week. Sorry about that. Next time, tell me these things earlier and please write them down.“  "What am I supposed to tell Sparkle?" demanded Maria. "She's really going to be ticked if she can't cash her check." A story 13  "Hey, Maria, it's not my fault," Phil protested (phản kháng). "If you'd told me in the first place that you had to be able to change someone's name at any time, this wouldn't have happened. You can't blame me for not reading your mind."  Angry and resigned, Maria snapped, "Yeah, well, this is the kind of thing that makes me hate computer systems. Call me as soon as you get it fixed, will you?" A story 14 15 Tầm quan trọng trong XĐ 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ọng  Cầ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 Vậy tầm quan trọng của thu nhận yêu cầu là gì? 16 Tầm quan trọng trong XĐ yêu cầu? Lý do 1:  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. 17 Tầm quan trọng trong XĐ yêu cầu? 18 Tầm quan trọng trong XĐ yêu cầu? 19 Tầm quan trọng trong XĐ yêu cầu? Lý do 2:  Thay đổi không ngừng của công nghệ và chuyển giao đã ảnh hưởng nhiều đến mức độ thành thạo của chuyên gia. Vài năm trước, các kỹ sư có thể sống cả đời với nghề nghiệp của mình trong một công ty nào đó, nhưng ngày nay việc thay đổi công việc rất thường xuyên. 20 Tầm quan trọng trong XĐ yêu cầu? Lý do 3:  Gia công phần mềm đã làm thay đổi nhanh chóng chu kỳ phát triển phần mềm  Đặc tả sản phẩm để thực thi hay sản xuất bởi nhiều bộ phận khác nhau nên bị nhiều hạn chế và không có chuyên môn nghiệp vụ.  Tương tự như phải tạo đặc tả cho máy giặt mà người thiết kế có thể chưa từng nhìn thấy máy giặt lần nào. Để thành công, đặc tả cần phải chính xác. 21 Tầm quan trọng trong XĐ yêu cầu? Lý do 4:  Việc phát triển phần mềm thường liên kết chặt chẽ với nghiệp vụ. Ví dụ: phần mềm cellphone và phần mềm về hàng không thường được thiết kế xây dựng chặt chẽ phù hợp với nghiệp vụ.  Công nghiệp bắt đầu dùng phần mềm để tạo các phiên bản mới cho sản phẩm. Các sáng kiến có thể thực hiện hiện dễ dàng bằng phần mềm hơn là phần cứng vì ít đầu tư kỹ thuật hơn và chi phí sửa đổi rẻ hơn 22 Tầm quan trọng trong XĐ yêu cầu? Nguyên nhân thất bại của dự án (RE-62%)  Những yêu cầu không đầy đủ - Incomplete requirements (13.1%)  Lack of user involvement – không cuốn hút người dùng(12.4%)  Lack of resources – thiếu nguồn tài nguyên(10.6%)  Unrealistic expectations – thiếu thực tế(9.9%)  Lack of executive support (9.3%)  Changing requirements and specifications (8.7%)  Lack of planning (8.1%)  System no longer needed (7.5%) 23 Tầm quan trọng trong XĐ yêu cầu? 24 25  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  Yêu cũng có 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”  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) Yêu cầu (requirement) 26  “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?” Yêu cầu (requirement) Theo IEEE 1990, yêu u n m : 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. Software Requirements (SR)? 27  Yêu cầu quan trọng vì nó cung cấp các cơ sở cho tất cả công việc phát triển hệ thống sau đó.  Ngay khi yêu cầu được xác định, nhà phát triển khởi đầu các công việc kỹ thuật khác như: thiết kế hệ thống, phát triển, kiểm thử, thực thi và vận hành. Vai trò của yêu cầu 28  Yêu cầu được phát biểu (stated requirement)  Yêu cầu thực (real requirement) Phân loại yêu cầu 29  Là các yêu cầu được cung cấp bởi khách hàng khi bắt đầu phát triển hệ thống.  Các dạng yêu cầu:  Yêu cầu về thông tin  Dự toán  Bảng báo giá  Phát biểu công việc (statement of work – SOW) Stated Requirements 30  Là các yêu cầu phản ánh nhu cầu xác thực của người dùng.  Thường khác nhau rất lớn giữa yêu cầu phát biểu và yêu cầu thực.  Việc phân tích các yêu cầu khách hàng (stated requirements) được dùng để xác định và tinh chỉnh các nhu cầu thực sự của khách hàng. Real Requirements 31  Là hệ thống các phương thức có liên quan với nhau chỉ định cái mà khách hàng muốn hệ thống làm gì.  There are two majors tasks in the requirements engineering:  Analysis  Modeling Requirements Engineering 32  Analysis is the process of determining what the customer wishes the system to do and formally creating a list of requirements that the customer can understand and agree to do.  Modeling is a process of interpreting the customer requirements into something that software engineers can understand. Requirements Engineering 33 Phân i yêu u 34 Gồm hai loại chính: • Yêu cầu chức năng (Function requirements) • Yêu cầu phi chức năng (Non Functional Requirements) Yêu cầu chức năng (Functional requirements) 35  Yêu cầu chức năng (Functional requirements): chức năng dịch vụ hệ thống cung cấp.  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à behavioral requirements.  Ví dụ: “The system shall e-mail a reservation confrimation the user” Yêu cầu chức năng (Functional requirements) 36  Yêu cầu chức năng (Functional requirements): 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án • Chức năng lưu trữ • Chức năng tìm kiếm • Chức năng kết xuất • Chức năng backup, restore • Chức năng đa người dùng • Chức năng đa phương tiện Yêu cầu chức năng (Functional requirements) 37 Thí dụ: Trong hệ thống quản lý thư viện • Người dùng có thể tìm kiếm, download, in những bài báo • Ngườ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 Yêu cầu phi chức năng (Non-functional requirements 38  Yêu cầu phi chức năng (Non-functional requirements): Không tập trung vào các chức năng của hệ thống mà chỉ tập trung vào các ràng buộc của hệ thố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ượng.  Sáu loại chính của yêu cầu phi chức năng: security, privacy, usability, reliability, availability, and performance.  Rà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. Yêu cầu phi chức năng (Non-functional requirements 39 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ện • Ràng buộc về ngân sách • Phù hợp với 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 • Các yêu cầu từ các tác nhân ngoài khác Yêu cầu phi chức năng (Non-functional requirements 40 Yêu cầu phi chức năng (Non-functional requirements 41 Ví dụ Trong hệ thống quản lý thư viện • Yêu cầu sản phẩm: giao diện người dùng không chứa frame và applet java • Yê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) Phân i yêu u 42  Khả thi - Feasible  Có giá trị - Valid  Không nhập nhằng - Unambiguous  Dễ kiểm chứng - Verifiable  Dễ biến đổi - Modifiable  Toàn vẹn - Consistent  Đầy đủ - Complete  Lần vết được - Traceable Đặc trưng của yêu cầu 43 Software Requirement bao m 3 c phân t:  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 yêu u 44  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)cung cấp  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ụ (Business requirements) 45  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, scenario  Bả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 (User requirements) 46  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 (Functional requirements) 47  Mô yêu u c cao i n m, a c ng con (subsystem) o.  t ng thể n n m hay bao m c ng con a n m ng như n ng.  Con i ng n ng, y c c năng ng ng nh vai a con i. System requirements 48 i liên hê a c c yêu u srse 49 i liên hê a c c yêu u srse 50 Phân i i u yêu u 51  Môi trường vật lý  Giao tiếp  Người dùng và nhân tố con người  Chức năng  Lập tài liệu  Dữ liệu  Tài nguyên  An ninh  Bảo đảm chất lượng Các loại yêu cầu 52  i c giao m t n m n ng ng m, ng sung thêm ng nh c c a t o y c n y tinh (beaker)  Yêu cầu của phần mềm là gì? Case study 53  Nhấn mạnh tới tính cộng tác và lặp lại  Tạo tài liệu cho những kết quả quan sát  Kiểm tra  Nó còn nhấn mạnh tới vai trò của kinh nghiệm và tính xã hội t thu p yêu u Requirements Engineering 54  t thu p yêu u liên quan n t c t ng chu :  c nh yêu u a i ng,  Phân ch yêu u suy n thêm c yêu u c  c yêu u  m tra xem yêu u a c p i nhu u i ng không t thu p yêu u Requirements Engineering 55 Các bước trong Qui trình phát triển yêu cầu 56 Các bước trong Qui trình phát triển yêu cầu 57 Các bước trong Qui trình phát triển yêu cầu 58 Các bước trong Qui trình phát triển yêu cầu 59 Xác định yêu cầu: • Là hoạt động chuyển thông tin phát sinh trong suốt tiến trình phân tích thành tài liệu định nghĩa tập hợp các yêu cầu • Phản ánh chính xác điều mà người dùng muốn • Tài liệu phải được viết để hệ thống sẽ được hiểu bởi • Người dùng cuối • Những khách hàng của hệ thống. Các bước trong Qui trình phát triển yêu cầu 60 Đặc tả yêu cầu: • Bản mô tả các yêu cầu hệ thống được thiết lập như cơ sở của hợp đồng giữa khách hàng và nhà phát triển phần mềm • Mô tả thật chi tiết về yêu cầu người dùng và yêu cầu hệ thống • hữu ích cho thiết kế • Mô tả chính xác để nắm bắt đúng vấn đề • Việc lập tài liệu này được thực hiện song song cùng với một số các thiết kế cấp cao khác. • Lỗi trong định nghĩa yêu cầu cần được xem xét kỹ lưỡng. • Nó phải được sửa chữa theo đúng vấn đề này. Các bước trong Qui trình phát triển yêu cầu 61 Quản lý yêu cầu: • Quản lý yêu cầu là tiến trình quản lý sự thay đổi của yêu cầu trong suốt quy trình công nghệ yêu cầu và phát triển hệ thống • Yêu cầu thì chắc hẳn là sẽ không hoàn thiện và không nhất quán • Các yêu cầu mới thì liên tục phát sinh trong suốt tiến trình khi nhu cầu công việc thay đổi và có sự hiểu rõ hơn về hệ thống đang phát triển • Các quan điểm khác nhau có các yêu cầu khác nhau và điều này thường làm phát sinh mâu thuẫn c nh n a requirement engineering 62 Ranh i a t n n yêu u 63 Kỹ thuật yêu u 64 65 Lợi ích khi thu thập yêu cầu hiệu quả  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ại  Thu 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 66 Lợi ích khi thu thập yêu cầu hiệu quả  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 ngũ 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ùng  Sự 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. 67 Những lợi ích không định lượng 1. Lỗi liên quan đến yêu cầu ít hơn 2. Giảm được việc phải làm lại trong bước phát triển 3. Ít hơn trong việc tạo tính năng không cần thiết 4. Giảm chi phí mở rộng 5. Quá trình phát triển hệ thống sẽ nhanh hơn 6. Giảm bớt các giao tiếp sai lầm với khách hàng 7. Hạn chế phạm vi hệ thống bị phình rộng 8. Hạn chế được những hỗn độn dự án 9. Các ước lượng về hệ thống chính xác hơn 10.Mức độ thỏa mãn khách hàng và thành viên của đội sẽ cao hơn  u do c nh yêu u không ng i rework ( m i ) —doing over something that you thought was already done.  Rework t – % ng chi t n n i do yêu u m i – % chi m i. u khi c nh yêu u sai 68 So nh chi a sai i a yêu u i i i m c nhau n t??? 69 SDLC 70  Imagine how different your life would be if you could cut the rework effort in half! You could build products faster, build more and better products in the same amount of time, and perhaps even go home occasionally. Khi không i rework 71  Insufficient User Involvement – thiếu sự tham gia người dùng  Creeping User Requirements – Yêu cầu người dùng phình ra  Ambiguous Requirements – yêu cầu mơ hồ, không rõ ràng  Gold Plating - Yê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ả  Minimal Specification – Yêu cầu tối thiểu  Overlooked User Classes – Bỏ qua lớp người dùng  Inaccurate Planning – Hoạch định không chính xác  assignment a m: m m 10 (srse) Nguyên nhân n n c nh yêu u không nh công 72