如何写好需求分析:需求规格说明书(Volere版)

如何写好需求分析:需求规格说明书(Volere版)

ID:37875139

大小:194.13 KB

页数:9页

时间:2019-06-01

如何写好需求分析:需求规格说明书(Volere版)_第1页
如何写好需求分析:需求规格说明书(Volere版)_第2页
如何写好需求分析:需求规格说明书(Volere版)_第3页
如何写好需求分析:需求规格说明书(Volere版)_第4页
如何写好需求分析:需求规格说明书(Volere版)_第5页
资源描述:

《如何写好需求分析:需求规格说明书(Volere版)》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、如何写好需求分析:需求规格说明书(Volere版)AtlanticSystemGuild(www.atlsysguild.com)公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术,是一个十分实用、完善的SRS模板。其所提供的Volere需求记录卡也十分实用,强烈推荐。1.产品的目标1.1该项目工作的用户问题或背景对引发开发任务的工作和情况的描述。同时也应描述用户希望用将要交付的软件来完成的工作。该节内容为该项目提供了合法的理由,你应该考虑用户的问题是否严重,是否应该解决和为

2、什么应该解决。1.2产品的目标用一句话或很少的几句话来说明“我们希望该产品做什么?”换言之,即开发该产品的真正原因。项目如果没有一个表述清晰、易于理解的目标,就会迷失在产品开发的沙漠中。产品必须带来某种优势。典型的优势是产品会增加组织在市场上的价值,减少运作成本,或提供更好的客户服务。这个优势应该是可度量的,这样才能够让您确定交付的产品是否达到目标。2.客户、顾客和其它风险承担者2.1客户是为开发付费的人,并将成为所交付产品的拥有者这一项必须给出客户的姓名,三个以内是合理的。客户最终将接受该产品,因此必须对交付的产

3、品满意。如果你无法找到一个客户的姓名,那么也许你就不应该构建该产品。2.2顾客是将花钱购买该产品的人也给出姓名和相关的信息2.3其它风险承担者其他的一些人或组织的名称,他们或者受到产品的影响,或影响产品。1.经理或项目负责人;2.业务领域专家;3.技术人员;4.系统开发者;5.市场人员;6.产品经理;7.测试和质量保证人员;8.审查员,诸如安全审查员或审计人员;9.律师;10.易用性专家;11.你所处行业的专业人员。3.产品的用户3.1产品的用户产品的潜在用户或操作员的列表。针对每种类型的用户,提供以下信息:1.用

4、户分类2.用户工作的任务;3.主要相关的经验;4.技术经验;5.其他用户特征:包括身体、智力、工作态度、对技术的态度、教育程度、语言技能、年龄、性别等。用户是为了完成工作而与产品交互的人,你了解用户,就越可能提交适合用户工作方式的产品。3.2对用户设的优先级在每类用户后面附上一个优先级,这区别了用户的重要性和优先地位:1.关键用户:对产品的后续成功至关重要;2.次要用户:他们使用产品,但对产品的长期成功并无影响;3.不重要的用户:不常用、未授权和没有技能的用户。如果认为某些用户对产品或组织更重要,那么应该写明,因为

5、它会影响你设计产品的方式。4.需求限制条件4.1解决方案限制条件此处明确了限制条件,它们规定了解决问题必须采取的方式。您可以认为它们是指令式的解决方案。仔细描述该解决方案,以及测试是否符合的度量标准。如果可能,您应该解释使用该解决方案的原因。换一句话说,就是要求软件解决方案满足哪些限制条件!4.2实现环境此处描述产品将被实施的技术环境和物理环境。该环境也将成为设计解决方案时的限制条件之一。4.3伙伴应用此处描述那些不属于产品的一部分,但产品却又必须与其协作的应用程序。4.4COTS此处描述实现产品需求所必须使用的C

6、OTS(商业组件)。4.5预期的工作场地环境此处描述用户工作和使用该产品的工作场地。此处应该描述任何可能对产品设计产生影响的工作场地特征。4.6开发者构建该产品需要多少时间任何已知的最后期限,或商业机会的时限,应在此处说明。4.7该产品的财务预算是多少该产品的预算,以金钱的形式或可得资源的形式说明。5.命名标准和定义定义项目中使用到的所有术语,包括同义词。这里的内容就是一个字典,包括在需求规格说明书中使用的所有名称的含义。这个字典应该使用你的组织或行业使用的标准名称。这些名称也应该反映出在工作领域中当前使用的术语。

7、该字典包括项目中用到的所有名称。请仔细地选择名称,以避免传达不同的、不期望的含义。为每个名字写下简明扼要的定义,这些定义必须经过相应的风险承担者同意。6.相关事实可能对产品产生影响的外部因素,但不是命令式的需求限制条件。7.假定列出开发者所做的假设。将所有的假设列在此的目的是让每一个项目成员都意识到这个假设。8.产品的范围8.1工作的上下文范围上下文范围图用来表示将要开发的系统、产品与其它系统之间的关系,以确定系统边界。8.2工作切分一个事件清单,确定系统要响应的所有业务事件。清单包括:1.事件名称2.输入和输出8

8、.3产品边界你可以使用用例图(use-case)来确定了用户与产品之间的边界。9.功能性需求与数据需求9.1功能性需求对产品必须执行的动作的描述。每个功能性需求必须有一个验收标准。9.2数据需求与产品/系统有密切关系的主题域相关的业务对象、实体、类的说明书。进行问题域建模,生成相应的类图。10.观感需求一些与产品的用户界面相关的需求描述。11.易用性需求11

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。