可以。软件需求不完整并不妨碍启动前期诊断，但不宜直接进入开发，应先把管理目标、角色、流程、数据和验收边界梳理成可验证的系统方案。
企业说不清完整的软件需求，仍然可以启动项目，但应先启动需求诊断和原型验证，而不是直接启动编码开发。客户更需要准确描述现实工作、主要问题和期望变化，专业团队负责把这些内容转化为角色、流程、数据、页面与集成方案。
客户应该先准备哪些信息？
不需要准备专业需求文档，可以从四类材料开始：目前怎样工作、哪些岗位参与、最常发生什么问题、希望上线后哪些结果能够被确认。现有表格、流程图、系统截图和代表性业务样本都可以作为讨论依据。
需求怎样逐步变得清楚？
- 通过访谈和场景复盘确定管理目标与优先级；
- 梳理正常流程、异常路径和责任边界；
- 定义核心数据、权限范围和外部系统条件；
- 用流程图和交互原型验证共同理解；
- 形成首阶段范围、验收方式和后续候选清单。
这套过程对应官网介绍的系统蓝图与原型方法。原型的作用不是提前美化界面，而是让业务人员在投入开发前发现理解偏差。
哪些内容不能一直留到开发后再决定？
关键角色、数据责任、审批条件、敏感权限、主要接口和验收标准必须在相应阶段被确认。局部交互可以迭代，但影响整体架构和业务边界的事项长期悬而未决，会显著增加返工风险。
常见追问
需求梳理通常由谁参加？
至少需要业务负责人、关键岗位代表、项目负责人和信息化人员参加。涉及跨部门流程时，还需要能对边界作出决定的人参与确认。
需求会不会在项目过程中继续变化？
会。合理做法不是假设需求永远不变，而是通过版本范围、变更评估和阶段确认管理变化。可参考跨部门流程交接的设计方法。
如果目前只有一个想法或管理问题，也可以从需求诊断开始。