View source for Phân tích yêu cầu

{{Quy trình phát triển phần mềm}}

Trong các ngành [[kỹ thuật hệ thống]] và [[công nghệ phần mềm|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 (kỹ thuật)|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.<ref>{{chú thích sách
 | editor = Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis
| title = Guide to the software engineering body of knowledge|url = http://www.swebok.org|
accessdate = ngày 8 tháng 2 năm 2007|edition=2004 Version| year = 2005 | month = 3
 | publisher = IEEE Computer Society Press | location = Los Alamitos, CA | isbn = 0-7695-2330-7
 | chapter = Chapter 2: Software Requirements | chapterurl = http://www.swebok.org/ch2.html
 | quote = It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
}}</ref>

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.

Pha 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 niên 1990|thập kỷ 1990]] như [[tạo nguyên mẫu]], [[Ngôn ngữ mô hình hóa thống nhất|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==
{{tham khảo}}

==Nguồn==

*{{chú thích sách
 | first = Steve
 | last = McConnell
 | authorlink = 
 | year = 1996
 | title = Rapid Development: Taming Wild Software Schedules
 | edition = 1st ed.
 | publisher = Microsoft Press
 | location = Redmond, WA
 | id = ISBN 1-55615-900-5
 | url = http://www.stevemcconnell.com/
}}
*{{chú thích sách
 | first = Karl E.
 | last = Wiegers
 | authorlink = 
 | year = 2003
 | title = Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle
 | edition = 2nd ed.
 | publisher = Microsoft Press
 | location = Redmond
 | id = ISBN 0-7356-1879-8
 | url = http://www.processimpact.com
}}
*{{chú thích sách
 | author = Andrew Stellman and Jennifer Greene
 | authorlink =
 | year = 2005
 | title = Applied Software Project Management
 | edition =
 | publisher = O'Reilly Media
 | location = Cambridge, MA
 | id = ISBN 0-596-00948-8
 | url = http://www.stellman-greene.com
}}

==Xem thêm==
<!--*[[Business process reengineering]]-->
*[[Phân tích hệ thống]] (''Systems analysis'')
<!--*[[Business 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]]
{{thể loại Commons|Requirements analysis}}

{{Công nghệ phần mềm}}
{{Khoa học Máy tính}}
{{Chuyên ngành Tin học}}

[[Thể loại:Kỹ nghệ phần mềm]]
[[Thể loại:Kỹ nghệ hệ thống]]

[[da:Kravspecifikation]]
[[de:Anforderungsanalyse]]
[[en:Requirements analysis]]
[[ja:要求分析]]
[[pt:Análise de requisitos]]
[[ru:Техническое задание]]
[[th:การวิเคราะห์ความต้องการ]]
[[zh:需求分析]]