Phân tích yêu cầu

Một phần của loạt bài về
Phát triển phần mềm
Hoạt động cốt lõi Mô hình hóa dữ liệu Quy trình Yêu cầu Thiết kế Xây dựng Công nghệ Thử nghiệm Gỡ lỗi Triển khai Bảo trì
Mô hình và hình mẫu Linh hoạt Phòng sạch Tăng dần Nguyên mẫu Xoắn ốc Mô hình V Thác nước
Phương pháp và framework ASD DevOps DAD DSDM FDD IID Kanban Lean SD LeSS MDD MSF PSP RAD RUP SAFe Scrum SEMAT TDD TSP OpenUP UP XP
Các ngành hỗ trợ Quản lý cấu hình Tài liệu Đảm bảo chất lượng phần mềm Quản lý dự án Trải nghiệm người dùng
Thực hành ATDD BDD CCO CI CD DDD PP SBE Đứng TDD
Công cụ Trình biên dịch Trình gỡ lỗi Hồ sơ Trình thết kế GUI Mô hình hóa UML IDE Tự động hóa xây dựng Tự động hóa phát hành Cơ sở hạ tầng dưới dạng mã
Tiêu chuẩn và khối kiến thức CMMI Tiêu chuẩn IEEE ISO 9001 Tiêu chuẩn ISO/IEC PMBOK SWEBOK ITIL IREB OMG
Bảng thuật ngữ Trí tuệ nhân tạo Khoa học máy tính Kỹ thuật điện và điện tử
Sơ lược Sơ lược về phát triển phần mềm
x t s

Trong các ngành kỹ thuật hệ thống và kỹ nghệ phần mềm, phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng, đưa ra. Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án.^[1]

Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (requirements engineering). Đôi khi nó còn được gọi một cách không thật chính xác bằng những cái tên như thu thập yêu cầu (requirements gathering, requirements capture), hoặc đặc tả yêu cầu (requirements specification). Thuật ngữ "phân tích yêu cầu" còn được áp dụng cụ thể cho công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm rõ yêu cầu hay viết tài liệu yêu cầu).

Các yêu cầu phải có tính đo được, kiểm thử được, có liên quan đến các nhu cầu hoặc cơ hội doanh nghiệp đã được xác định, và các yêu cầu phải được định nghĩa ở một mức độ chi tiết đủ cho việc thiết kế hệ thống.

Các kỹ thuật chính

Về khái niệm, việc phân tích yêu cầu bao gồm ba loại hoạt động sau:

• Làm rõ yêu cầu (Eliciting requirements): giao tiếp với khách hàng và người sử dụng để xác định các yêu cầu của họ.
• Xem xét yêu cầu (Analyzing requirements): xác định xem các yêu cầu được đặt ra có ở tình trạng không rõ ràng, không hoàn chỉnh, đa nghĩa, hoặc mâu thuẫn hay không, và giải quyết các vấn đề đó.
• Làm tài liệu yêu cầu (Recording requirements): các yêu cầu có thể được ghi lại theo nhiều hình thức, chẳng hạn các tài liệu ngôn ngữ tự nhiên, các tình huống sử dụng (use case), câu chuyện sử dụng (user story), hoặc các đặc tả tiến trình.

Phân tích yêu cầu có thể là một quá trình dài và khó khăn, cần đến nhiều kĩ năng tâm lý khéo léo. Các hệ thống mới làm thay đổi môi trường và các mối quan hệ giữa con người, do đó điều quan trọng là phải xác định được tất cả những người có vai trò quan trọng, xem xét tất cả các nhu cầu của họ và đảm bảo rằng họ hiểu được các hàm ý của hệ thống mới. Các nhà phân tích có thể sử dụng một số kĩ thuật để làm rõ các yêu cầu của khách hàng. Trong lịch sử, các kỹ thuật này bao gồm các cuộc phỏng vấn, thành lập các nhóm trọng tâm (focus group) với các cuộc họp bàn về yêu cầu (requirements workshops), và tạo ra các danh sách yêu cầu. Các kỹ thuật hiện đại hơn gồm có tạo nguyên mẫu (prototyping), và tình huống sử dụng. Khi cần thiết, nhà phân tích sẽ kết hợp các phương pháp này để thiết lập các yêu cầu chính xác của những người có vai trò quan trọng, nhằm mục đích xây dựng một hệ thống thỏa mãn các yêu cầu doanh nghiệp.

Các vấn đề

Vấn đề về người dùng và khách hàng

Trong cuốn Rapid Development, Steve McConnell đã liệt kê một loạt các khả năng người dùng có thể cản trở quá trình thu thập yêu cầu:

• Người dùng không hiểu họ muốn gì
• Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa
• Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển đã được hoạch định xong.
• Mức độ giao tiếp với người dùng là thấp
• người dùng thường không tham gia các đợt thẩm định hoặc không thể tham gia.
• Người dùng không hiểu kỹ thuật
• Người dùng không hiểu quy trình phát triển.

Những điều này có thể dẫn tới tình huống khi yêu cầu người dùng liên tục thay đổi ngay cả khi việc phát triển hệ thống hay sản phẩm đã được bắt đầu.

Vấn đề về kỹ sư/nhà phát triển

Trong quá trình phân tích yêu cầu, các vấn đề sau có thể nảy sinh từ phía các kỹ sư và nhà phát triển:

• Nhân viên kỹ thuật và người dùng cuối có thể có ngôn từ khác nhau. Kết quả là họ có thể tin rằng họ hoàn toàn đồng thuận cho đến khi sản phẩm hoàn thiện được đưa ra.
• Các kỹ sư và nhà phát triển có thể cố lái cho các yêu cầu khớp với một hệ thống hay mô hình sẵn có, thay vì phát triển một hệ thống theo sát nhu cầu của khách hàng
• Việc phân tích có thể do các kỹ sư hoặc lập trình viên thực hiện, thay vì các nhân viên có kỹ năng và kiến thức miền ứng dụng để có thể hiểu các nhu cầu của khách hàng một cách đúng đắn

Giải pháp đã được thực hiện

Một giải pháp đối với các vấn đề về giao tiếp là thuê các chuyên gia về doanh nghiệp hoặc chuyên gia phân tích hệ thống.

Các kỹ thuật được đưa ra trong thập kỷ 1990 như tạo nguyên mẫu, UML, tình huống sử dụng. và phát triển phần mềm linh hoạt (Agile software development) cũng đã được dùng làm giải pháp cho các vấn đề trên.

Chú thích

1. Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis biên tập (2005). “Chapter 2: Software Requirements”. Guide to the software engineering body of knowledge (ấn bản thứ 2004). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Truy cập ngày 8 tháng 2 năm 2007. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.

Nguồn

• McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (ấn bản thứ 1). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
• Wiegers, Karl E. (2003). Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle (ấn bản thứ 2). Redmond: Microsoft Press. ISBN 0-7356-1879-8.
• Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.

Xem thêm

• Phân tích hệ thống (Systems analysis)
• Tình huống sử dụng
• Process architecture
• Process modeling
• Mô hình hóa dữ liệu (Data modeling)
• Yêu cầu chức năng (Functional requirements)
• Yêu cầu phi chức năng (Non-functional requirements)
• Model-driven engineering
• Model Transformation Language