昨天进行了一次内部的研制任务书评审，请了内部的一位经常在外做评估的专家Z老师。
通过昨天的评审，解决了几个疑问。
一、项目是个有软硬件采购集成的项目，只有一份软硬件混杂在一起的合同和技术协议，在软件研制任务书的软硬件设备章节，硬件设备清单是否要列出所有所有硬件？
讨论结果是不需要，只列出与软件紧密相关的即可。例如需要采购的防火墙、网关、机柜等，不用列出。
二、在研制任务书环节用户提出了不包含在合同中的功能需求，研制任务书中写出来，追溯如何处理？
讨论结果，其实用户提出来的功能需求，是能够追溯到合同中的某些具有含糊边界的要求中，如在安全需求中有“可以识别的其他安全需求”的话。——实际上，应该尽量避免合同中有这种“敞口”需求。
这个讨论结果解决了当前这个项目的问题，但似乎没有解决本质上的问题。
严格来说，如果真有不在合同范围内的需求，是否应该有补充协议，增补经费，或者做功能置换，或者明确由乙方赠送？总归，应该明确说明。当然，从现实执行更容易的情况就是拿了放大镜、显微镜在合同文本中寻找能够匹配上这种事先没有想到的功能的需求条款——一般是隐藏在某个条款中的一个短语、词汇。
三、工作模式
研制任务书中有个工作模式，一直比较含糊，写得不好。
这次说了下，一个软件也可以只有一种工作模式。
工作模式举例：大院门口的阻车器系统，有两种工作模式。工作日执勤工作模式，阻车器默认是平放状态，当有某种情况时通过工作人员发送指令让阻车器竖起。非工作日工作模式，阻车器默认竖立，有特殊场景有车需要进入时，由工作人员发送指令放下阻车器。
这里其实有个困惑，会上忘记提出来讨论了。在体系要求里说的是要有工作模式，但没有地方说是整个软件的工作模式，个人理解也可以是每个用户需求都可以描写其工作模式。但现在的模板是用了一个独立的章节，描写统一工作模式。这个还是个疑惑。
四、关于功能需求中的验收标准
功能需求中的验收标准如何描述？
一种是就功能本身进行描述。往往对于一个简单的功能，比较不好描述。
如增加功能，描述成了“支持新增XX信息”。
如果换种视角，站在验收测试的视角，可以写成“输入XX，成功保存”。这么写将会引起更多的思考，对输入信息可能存在一些不同场景的考虑，一些限制条件的考虑。这样的结果是要求更高了。
五、关于产品遵循的标准
在多个文件中，前面有个章节是“引用文件”，后面还有个章节是“产品遵循的标准”。
各项目在产品遵循的标准这节基本上写的都是前面引用文件中的几个通用标准，如2786A、438C等。我之前提过，认为这个不恰当，这里应该是产品所针对的行业领域的特定标准。以前自己这么认为，但不确定。这次算是确定了。
