软件项目的需求分析工作往往面临着一些潜在的风险，这些风险主要表现在：
一 用户不能正确表达自身的需求
在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。
这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。
二 业务人员配合力度不够
有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。
三 用户需求的不断变更
由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，需求在项目的整个生命周期都可能发生变化。
因此，我们要认识到，软件开发的过程实际上是同变化做斗争的过程，需求变化是每个开发人员、项目管理人员都会遇到的问题，也是最头痛的问题。
一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化就像是万恶之源，为项目的正常的进展带来不尽的麻烦。
四 需求的完整程度
需求如何做到没有遗漏？这是一个大问题，大的系统要想穷举需求几乎是不可能的，即使小的系统，新的需求也总会不时地冒出来。
一个系统很难确定明确的范围并把所有需求一次性提出来，这会导致开发人员在项目进展中去不断完善需求，先建立系统结构再完成需求说明，造成返工的可能性很大，会给开发人员带来挫折感，降低他们完成项目的信心。
五 需求的细化程度
需求到底描述到多细，才算可以结束了？虽然国家标准有需求说明的编写规范，但具体到某一个需求上，很难给出一个具体的指标，可谓仁者见仁，智者见智，并没有定论。
需求越细，周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求也越高，相反，需求越粗，开发人员在技术设计时不清楚的地方就越多，影响技术设计。
六 需求描述的多义性
需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解；另一方面是指同一读者能用不同的方式来解释某个需求说明。
多义性会使用户和开发人员等项目参与者产生不同的期望，也会使开发、测试人员为不同的理解而浪费时间，带来不可避免的后果便是返工重做。
七 忽略了用户的特点分析
分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。如果忽略这些的话，将会导致有的用户对产品感到失望。
八 需求开发的时间保障
为了确保需求的正确性和完整性，项目负责人往往坚持要在需求阶段花费较多的时间，但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑。
他们往往会强迫项目尽快往前推进，需求开发人员也会被需求的复杂和善变折腾的筋疲力尽，他们也希望尽快结束需求阶段。