有个web应用系统，特定业务领域的项目管理，服务器版的，由于用户人员有大量工作是去客户现场开展工作，客户现场是不能访问这套系统的，因此需要开发一套单机版，在客户现场使用，回公司后将项目数据导入服务版。
同一个项目，既有成员在公司的服务版操作数据，也会有成员在客户现场操作。两者的操作的数据范围还不能做严格的边界划分，因此可能有对同一数据进行操作的可能性。
因此软件需要处理两个系统的数据冲突问题。
需求分析人员不太懂技术。在需求分析初始阶段，与开发人员进行了一次讨论，当时有一个关键问题是两套系统没有办法给每条数据一个唯一标识:系统中原来设计的流水号，两个系统都会有新增删除操作，无法保证流水号唯一。也没有能够做唯一索引的业务字段。基于这样的假设，让需求分析人员在做功能原型设计时大伤脑筋。
某天，需求在和团队外的一名技术人员讨论到这个问题时，经过一番讨论，找到了给数据一个唯一标识的途径。基于此前提再去做功能原型，就变得容易很多了。
在这个案例中，这个技术前提很重要。当需求知道这个技术不是问题后，就可以要求团队想办法解决这个问题。如果需求拿不准，就不会有底气坚持自己的方案。
因此很多时候需求和开发是在共创一个解决方案，需求因为技术的现状去设计自己的产品。
这里的需求已经是覆盖了用户需求和软件需要了。
这里的软件需求其实已经覆盖了功能设计。
以前有人问我，需求和设计的边界在哪？按我们这种需求的做法，po要把需求分解到比较小颗粒度的用户故事，那开发人员的设计就没多少可做的了。
我这次算是对这个问题有了进一步的认识。如果需求分析人员侧重于做用户需求分析，确实可以不做那么细，将具体的功能交给开发人员设计。但如果是一个po的角色，做到具体功能设计似乎也不算过分。
如果需求分析人员不做功能设计，那么就更应该将用户的各种应用场景明明白白的描述出来，这样开发人员做设计时才有依据。
如果自己是po，那么即使不明白的描述出来，至少自己在进行功能设计时会再思考应用场景的问题。
当然，重要的还是需求与开发在一起探讨共创，形成双方理解一致、在约束条件下的最优方案。
