些系统需要时间，开发与它们的接口也需要时间，而且用友、金蝶等这些系统存在多个不同的版本。因此与外部系统接口的可行性定义为:不可行。
人的方面主要考虑目标用户是否具有相应的素质和能力。在实际项目中，笔者曾对快速消费品行业经销商批次管理的可行性进行了分析。首先，批次管理将涉及到所有产品的出入库操作，并存在一个产品有多个批次的情况，因此批次管理对操作人员的能力和素质要求比较高。
其次，快速消费品行业的特点决定了产品的出入库操作极为频繁，因此，操作人员的工作强度比较大。再次，大部分经销商的仓库所在地都距离城镇比较远，因此工作人员的文化水平普遍不高。在综合考虑后，将批次管理的可行性定义为低。
对于复杂的项目，还应从经济方面和环境方面进行考虑。经济方面主要从投入、收益、短期、长远利益等方面进行分析。环境方面主要考虑市场环境和政策因素。
八、正确理解需求分析文档确认
需求分析是一项繁琐枯燥的工作，需要和用户不断的商讨、确认和反复。但大部分用户并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心在笔者曾负责的经销商管理系统中，经销商认为，库存过高将占用企业运转资金，增加企业负担;项目管理者联盟
库存过低则无法满足客户订单，从而导致交货周期延长，降低企业市场竞争力。由于经销商对当前可用库存十分关注，因此可用库存的优先级被定义为:高优先级。仔细考虑或回答你的问题。这很容易使你错误地认为用户已经真正地了解并认可了你的分析文档。
在需求分析文档上签字确认，通常被认为是用户同意需求分析内容的标志行为。而实际操作中，签字确认工作并未得到用户的充分重视。“他们要求我在需求文档上签名，于是我就签了，否则开发人员不开始编码。”用户的这种态度将可能给项目带来潜在的风险，如不断地进行需求变更等。对于需要用户确认的需求分析文档，最好在用户确认前，就文档内容对用户进行一定的讲解，以确保用户完全理解并认可文档中的内容。若用户对文档中的内容存在修改意见，则修改后再与用户进行确认，直至用户完全认可文档中的内容为止。
需求确认将给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的用户与需求分析人员的关系，为项目的成功奠定坚实的基础。通常为对项目有一个整体、准确的理解，需求分析所包含的内容通常大于项目范围所包含的内容。因此，应让用户理解对于某些功能的讨论并不意味着即将在系统中实现它。应使用户明白对需求分析文档的签字确认是建立一个需求的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。