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

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

^ 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.Quản lý CS1: nhiều tên: danh sách biên tập viên (liên kết)