没有合适的资源?快使用搜索试试~ 我知道了~
资源详情
资源评论
资源推荐
阶段性需求阐述:2018/11/17
需求阐述
给定自然语言文档,设计一套标签,手工嵌入到需求文档中,使其成为流程式的需求。
并使用机器学习方法来自动插入标签。然后从根据标签来提取信息,形成结构化的需求。
.1 需求描述
现明确,给定的自然语言文档按照 GWT 形式进行描述,产生的结构化需求描述遵循
RUCM 格式并组成完整文档。由于这两种文档并不存在严格的一一对应关系,所以需要一组
中间标签,从而实现 GWT 到中间标签,中间标签到 RUCM 的平稳转化。在此转化过程中,
我们会使用自然语言处理以及机器学习相关技术。
.2 需求规约
在这里,我们将对本次需求的输入和输出进行一些约束,明确输入和输出要求,从而保
证系统第一版本能在规定时间内完成。
.2.1 输入规约
本系统通过分析,具有两种输入文件,分别为 GWT 输入文档与领域背景输入文档。GWT
输入文档是本系统的核心文档,用于转化成为 RUCM。而领域背景则是作为转化过程中需求
的补充文档,用于自然语言处理过程模型的建立与修改。
GWT 规约
1. 同一个用例,Featrue 为用例名称
2. 每个用例包含一个正常情况下的 GWT,
a) 正常 GWT,每个步骤正常完成,得到理想的输出,满足用例的要求
i. Scenario:对具体场景的简要描述,简单句描述
ii. Given:每个 GWT 都是一个用例的具体场景,描述正常情况场景的 GWT 描述
了用例最主要的场景,其 Given 与用例的前提条件保持一致。每个条件的表述
都应该为简单句。
iii. When
1. 关于条件的表述:对可能发生异常情况的操作都要做判断为正常情况下的
表述,如对验证账户合法的操作,表述为“系统验证账户合法”。
2. 除了表示判断、循环和并发的语句应为复合句之外,每句话均为主谓宾结
构的简单句,句子的主语应为系统本身或用例的参与者,即用例的 actor。
3. 句子中若有具体场景的数据,应用于修饰宾语,作为宾语的定语。
4. 表示判断的句子应符合“如果……那么……[否则……]”句式,表示循环的句子
应符合“……直到……”,表示并发的句子应符合“……同时……”句式。
5. 每个判断和循环的条件、结果、终止条件均必须是简单句,且循环必须有
终止条件。比如,“如果告白不成功,那么一直告白,直到成功”。但是,“如
果告白不成功,那么一直告白,直到成功或者完全失去信心”不允许
iv. Then:具体场景的最终结果,用简单句描述。
3. 每个用例可以包含多个用来描述异常场景的 GWT:
a) 异常 GWT:
i. Scenario:对具体场景的简要描述,应以主谓宾结构的简单句描述
ii. Given: 描述异常场景的 GWT 既要满足用例的前提条件,又要满足具体场景的
前提条件。
1. 每个表示条件的语句均为主谓宾结构的简单句。
2. 对由正常情况下的某一个或几个操作引起的异常,描述具体场景前提条件
的句子应表述为判断异常情况发生的句式,如对验证账户合法的操作,表
述为“系统验证账户不合法”。
iii. When 要求相同
iv. Then 要求相同
领域背景输入文档规约
领域背景输入文档即为分词外部词典,分词外部词典本身是一个文本文件(plain
text),每行指定一个词,编码同样须为 UTF-8,
1.2.2 输出规约
即 RUCM 规约,因为最后的输出文档是由 RUCM 所组成。简单可以描述为 RUCM 的 26
种语法限制。详细描述如下:
1. 基本信息
a) 用例名称:
i. 描述:以动词开头的用例名称
ii. 格式:动词短语,动词+名词
b) 简要描述:
i. 描述:简要概括用例
ii. 格式:一句话或多句话。
c) 前置条件:
i. 描述:本用例执行所需要的条件(what should be true)
ii. 格式:一句话或多句话。
d) 主要活动者:
i. 描述:本用例的发起者
ii. 格式:名词
e) 次要活动者:
i. 描述:完成用例提供的服务系统所依赖的其他活动者
ii. 格式:名词或“None”
2. 关系描述:
a) 依赖关系:
i. 描述:包含和扩展其他用例
ii. 格式:
1. “None”或
2. 关键词”INCLUDE USE CASE”/”EXTENDED BY USE CASE” + 其他用例名
b) 泛化关系
i. 描述:对其他用例的泛化
ii. 格式:“None”或???(暂时没有实例和关键词)
3. 基本事件流:
a) 步骤号:
i. 描述:顺序排列的数字
ii. 格式:“STEP”+数字
b) 事件流:
i. 描述:主要的“成功”路径的说明
ii. 格式:
1. <step>:一行
2. <action>:简单句,主语+谓语(+宾语),不能出现代词、否定词
3. <step>:(the system) VALIDATES THAT <condition>为一句话
4. <step>:<action> MEANWHILE <action> | MEANWHILE <action>
5. <step>:DO <steps> UNTIL <condition>
a) steps 占一行,condition 为一句话
6. IF <condition> THEN <steps> ENDIF
7. IF <condition> THEN <steps> ELSE <steps> ENDIF
8. IF <condition> THEN <steps> ELSEIF <condition> THEN<steps> ENDIF
c) 后置条件:
i. 描述:基本事件流执行后产生的变化
ii. 格式:一句话或多句话
4. 分支事件流:
a) 格式:
i. 事件流内部要求相同。
ii. 后置条件要求相同
iii. 所有分支事件流必须以“ABORT”或“RESUME”+”RFS”+数字结尾,占据一行
b) 分类:
i. 特定分支流:“RFS”+单个数字
ii. 有界分支流:“RFS”+数字+“-”+数字
iii. 全局分支流:
1. “IF”+一句话
2. +步骤
3. “END IF”
.3 需求目标
在这里我们将对于系统所要达成的目标进行描述。
.3.1 功能性需求
系统需要提供 GWT 转为 RUCM 的功能
系统需要对用户提供的输入文档进行保存
系统需要向用户提供可以操作的窗口
系统需要可以向用户提供展示生成的 RUCM 的窗口
系统需要将生成的 RUCM 保存成文件,以供用户查阅
.3.2 非功能性需求
系统需要便于安装,减少学习成本。
系统对硬件系统要求不应超过当前主流电脑要求,若放置云端应以最小的成本进行运行。
系统应减少在运行过程中崩溃的可能性
系统应采取一定空间换时间的方式提高运行效率。
系统应给予用户一定的自定义特性,或作为开源项目以方便自定义
系统应在高等软件工程结课之前开发完 version 1
系统代码应包含必要的注释,以方便修改。
系统应依赖自包含,或者通过依赖管理工具以提高可维护性和分布式开发效率。
.3.3 系统质量判断标准
由于本系统是课程系统,所以我们对于第一版的系统质量判断标准为:
能够将规定格式的 GWT 转化为标准的 RUCM 文档。若生成的 RUCM 与原先的 RUCM
表述意思相同,则为合格的转化过程。可通过转化率(合格 RUCM/总 RUCM)判断
系统质量。
剩余17页未读,继续阅读
基鑫阁
- 粉丝: 58
- 资源: 358
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0