需求之系统用例规约课件.pptVIP

* 书写路径步骤的注意事项 主语只能是主执行者或者是系统。 写需求，就是把系统看作一个黑箱，描述它对外提供的功能和约束。 例子： 执行者请求前端系统做某事，前端系统请求后端系统做某事（错误） 执行者请求客户端做某事，客户端请求服务器做某事（错误） * 书写路径步骤的注意事项 使用核心域概念。 路径步骤是功能需求，应该使用核心域的概念来描述。 例子： 系统建立连接，打开连接，执行SQL，从“零件”表查询（错误，因为涉及技术） 系统根据查询条件搜索零件（正确） * 书写路径步骤的注意事项 不要涉及交互设计的细节。 错误例子： 会员从下拉框中选择类别 会员在文本框中输入查询条件 会员单击“确定”按钮 这些界面细节很可能不是需求，只是开发人员选择的解决方案—设计，应该把它们删掉，然后问“为什么”，背后隐藏的才是涉众在意的、真正的需求，也许是非功能需求中的可用性需求“操作次数不超过5次”，也许是非功能需求中的可用性需求“反馈速度应该在3秒以内”。 * 书写路径步骤的注意事项 不要涉及交互设计的细节。 需求是问“不这样行吗”，而不是问“这样行吗”。 * 书写路径步骤的注意事项 不要写系统不能负责的事情。 错误例子： 顾客付款 收银员找零 以上两个是系统无法感知和承诺的。 * 扩展路径 执行者的选择。 执行者需做出选择，选择结果不同，带来的交互也不同。 例子： 1.会员请求查看订单 2.系统反馈