• 软件功能说明书书写
    • 应用架构
      • 业务划分
        • HSF图例
          • 每个业务的功能点要从业务分析说明书中获取;
          • 先确定业务点,然后在每一个业务点中再确定功能点;
          • 功能点的命名动宾/主谓关系要保持一致;名字的字数要尽可能保持一致,如:都是4个字,或都是6个字;不要使用能让用户误解的字词;名字命名时避免大、空,要贴切功能点;
        • 功能列表
          • 用途说明
            • 用途说明:使用用户的口吻描述该功能的用途;描述通过使用该功能能够完成什么样的工作;如果需要,还需指明操作的数据内容、操作方式等,但不限于这两个;最好,写出功能点在业务分析说明书中的出处;表达描述中,不能让业务人员无法理解;
      • 权限控制
        • RRF图例
        • 角色列表
          • 用户类型
            • 项目有哪些人使用
          • 职能说明
            • 能够做哪些操作
            • 列出功能点
          • 先进行权限控制的书写,最好的方法是从项目使用者的角色入手;角色确定以后, 业务划分中的HSF图就可以根据这些角色来分出大的业务块;
    • 功能描述
      • 业务点
        • 功能点
          • 应用场景
            • 使用用户的口吻描述该功能的场景;在什么情况下会使用该功能点;场景可能不止一个;如果多角色使用该功能点,则要分开进行描述,因为不同角色使用的重点内容不同;“应用场景”是对功能点最重要的描述;
          • 参考界面
            • 参考界面能够帮助文档阅读者更好理解功能点;
            • 并不是每一个功能点都需要有界面;
            • 当然,一个功能点的参考界面也可能不止一个;
          • 特性说明
            • 特性说明:书写该功能点能够支持哪些特性、不支持哪些特性;最好能够分为三部分:支持、暂不支持、无需支持;把当前不支持的以后会支持的项写入到暂不支持中;同时,书写者应该能够讲的出为什么支持某些项、为什么不支持某些项;
            • 查询时,书写“按时间进行查询”的意思就是:查询结果按照时间进行分组;如果不是要表达分组这个意思,就应该换成其他的,如:将时间作为查询条件来查找数据
          • 相关信息
            • 描述的是信息实体;列出信息实体的具体内容;
          • 注意事项
            • 注意事项则是对特性说明的注释;不能列到特性说明的,并且需要指出的,就应该写到注意事项中;特性中的一些规则性的东西也要写到注意事项中;
          • 用途说明和应用场景的区别
            • 都要从业务用户的角度描述
            • 用途说明重点在于:用户使用某个功能点时系统能够帮用户完成“什么”样的工作;描述中应多使用“来”、“以”、“以便”、“能够”……这样的词;“什么”样的工作是指“用户”的工作,如:管理员可以查询已经记录下的日志,来分析用户操作情况,分析系统对外提供的服务情况;
            • 应用场景重点在于:用户在什么样的场景下使用某功能点;如:当有新的仓库加盟到平台时,使用“仓库管理”添加仓库信息、仓库系统访问地址,使仓库系统和平台能够进行数据通讯,完成仓库信息的初始化;
              同时,在场景中也要写出系统是如何完成这个过程的;
    • 对外接口
      • 系统交互
        • DSI图例
        • 接口列表
          • 接口名称
          • 用途名称
      • 接口名称
        • API图例
        • 协议列表
          • 协议名称
          • 用途说明
        • 还没有书写这一部分,还不清楚有哪些注意事项;


blog comments powered by Disqus

Published

04 January 2013

Tags