我刚刚完成了我的软件系统的实现,现在我必须记录它是否满足了它的要求。我应该包括哪些信息以及如何列出?
我的初始功能和非功能需求在两列表中,看起来像这样:
答案 0 :(得分:1)
我会使用已经存在的需求编号方案,而不是创建一个新方案。我会为每个要求记录以下项目:
要记住的其他几点:
最后,除非你为某人做狗和小马表演,否则你不需要截图作为需求文档的一部分。您也不需要提供完成的“证据”。测试部门会为你做这件事。
答案 1 :(得分:1)
有一些技术可以将您的需求转换为测试用例。 但这取决于您的需求如何记录。 如果您已经进行了基于场景的需求分析,那么这将非常简单:只需为场景的每个路径创建一个序列图,编写/执行测试 - >完成。 除了以这种方式创建的文档也应该给你的讲师留下深刻的印象。
如果您没有方案,则应该在用例中创建一些。
这里的缺点是它非常耗费工作量,只能用于证明其使用的情况(例如论文;))
答案 2 :(得分:0)
逐个列出需求行的需求数字,然后是文本和/或截图,证明了这一点。
左侧的需求号以粗体显示,然后将需求文本标签化为斜体。将校样文本/屏幕截图与需求文本对齐,左栏清晰显示需求编号。 EG:
REQ-1 italicized requirement text
text discussing how the software has
fulfilled the requirements, possibly
with a picture:
-----------------------
| |
| |
| |
| |
| |
-----------------------
REQ-2 italicized requirement text
etc...
您应该根据逻辑程序区域分组到章节或章节,并开始介绍整个程序区域如何满足要求的章节或章节(一般
答案 3 :(得分:0)
我会保持简单并添加以下列:
使用需求ID,我假设他们回到包含更详细信息的文档,包括布局,屏幕截图等。
答案 4 :(得分:0)
我们通常会制定一个测试计划,如果满意,可以勾选每个项目。该计划将基于原始要求(功能性或非功能性),例如:
要求:三次尝试使用错误密码登录后,应锁定用户帐户。
测试:使用错误的密码尝试登录三次以上。用户帐户现已锁定吗?
我们会针对每个要求执行此操作,并重新运行每个候选发布版的计划。有些测试是自动化的,但我们确实有一个测试团队的工作人员来执行手动测试!
根据运行这些测试计划和用户验收测试的结果,我们将签署RC正确并适合发布。
请注意,即使测试计划中的某些项目未通过,有时我们也会签署发布,这一切都取决于项目的性质!
答案 5 :(得分:0)
验证要求的正式方法是测试 - 通常是验收测试。
这个想法是:对于每个要求,应该有一个或多个验证要求的测试。在正式的开发情况下,客户在签署要求的同时签署验收测试。
然后,当产品完成后,您会在接受最终产品之前展示验收测试的结果,并且客户会对其进行审核。
如果您的要求无法测试,那么它们可能写得不好。
e.g。不要说“加载文件应该快”,说“大小为X的文件应该在不超过Y毫秒的Z硬件上加载”或类似的东西。