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

如何写好需求分析 ：需求规格说明书(Volere版) At lant ic Syst em Guild （www.at lsysguild.co m ）公司所提供的Vo lere需求过程与软件需求规 格说明书模板则 分利用了现代软件工程思想与技术 ，是一个十分实用、完善的SRS模板。 其所提供的Vo lere需求记录卡也十分实用 ，强烈推荐。 1.产品的目标 1.1 该项目工作的用户问题或背景 对引发开发任务的工作和情况的描述。同时也应描述用户希望用将要交付的软件来完成的工作。 该节内容为该项目提供了合法的理由 ，你应该考虑用户的问题是否严重 ，是否应该解决和为什么应 该解决。 1.2 产品的目标 用一句话或很少的几句话来说明“我们希望该产品做什么 ？”换言之 ，即开发该产品的真正原因。 项目如果没有一个表述清晰、易于理解的目标 ，就会迷失在产品开发的沙漠中。产品必须带来某种 优势。典型的优势是产品会增加组织在市场上的价值 ，减少运作成本 ，或提供更好的客户服务。这 个优势应该是可度量的 ，这样才能够让您确定交付的产品是否达到目标。 2.客户、顾客和其它风险承担者 2.1 客户是为开发付费的人 ，并将成为所交付产品的拥 者 这一项必须给出客户的姓名 ，三个以内是合理的。 客户最终将接受该产品 ，因此必须对交付的产品满意。如果你无法找到一个客户的姓名 ，那么也许 你就不应该构建该产品。 2.2 顾客是将花钱购买该产品的人 也给出姓名和相关的信息 2.3 其它风险承担者 其他的一些人或组织的名称 ，他们或者受到产品的影响 ，或影响产品。 1. 经理或项目负责人 ； 2. 业务领域专家 ； 3. 技术人员 ； 4 . 系统开发者 ； . 市场人员 ； 6. 产品经理 ； 7. 测试和质量保证人员 ； 8. 审查员 ，诸如安全审查员或审计人员 ； 9. 律师 ； 10. 易用性专家 ； 11. 你所处行业的专业人员。 3.产品的用户 3.1 产品的用户 产品的潜在用户或操作员的列表。针对每种类型的用户 ，提供以下信息 ： 1. 用户分类 2. 用户工作的任务 ； 3. 主要相关的经验 ； 4 . 技术经验 ； . 其他用户特征 ：包括身体、智力、工作态度、对技术的态度、教育程度、语言技能、年龄、性 别等。 用户是为了完成工作而与产品交互的人 ，你了解用户 ，就越可能提交适合用户工作方式的产品。 3.2 对用户设的优先级 在每类用户后面附上一个优先级 ，这区别了用户的重要性和优先地位 ： 1. 关键用户 ：对产品的后续成功至关重要 ； 2. 次要用户 ：他们使用产品 ，但对产品的长期成功并无影响 ； 3. 不重要的用户 ：不常用、未授权和没有技能的用户。 如果认为某些用户对产品或组织更重要 ，那么应该写明 ，因为它会影响你设计产品的方式。 4 .需求限制条件 4 .1 解决方案限制条件 此处明确了限制条件 ，它们规定了解决问题必须采取的方式。您可以认为它们是指令式的解决方案 。仔细描述该解决方案 ，以及测试是否符合的度量标准。如果可能 ，您应该解释使用该解决方案的 原因。 换一句话说 ，就是要求软件解决方案满足哪些限制条件 ！ 4 .2 实现环境 此处描述产品将被实施的技术环境和物理环境。 该环境也将成为设计解决方案时的限制条件之一。 4 .3 伙伴应用 此处描述那些不属于产品的一部分 ，但产品却又必须与其协作的应用程序。 4 .4 COT S 此处描述实现产品需求所必须使用的COT S(商业组件)。 4 . 预期的工作场地环境 此处描述用户工作和使用该产品的工作场地。此处应该描述任何可能对产品设计产生影响的工作场 地特征。 4 .6 开发者构建该产品需要多少时间 任何已知的最后期限 ，或商业机会的时限 ，应在此处说明。 4 .7 该产品的财务预算是多少 该产品的预算 ，以金钱的形式或可得资源的形式说明。 .命名标准和定义 定义项目中使用到的所有术语 ，包括同义词。这里的内容就是一个字典 ，包括在需求规格说明书中 使用的所有名称的含义。这个字典应该使用你的组织或行业使用的标准名称。这些名称也应该反映 出在工作领域中当前使用的术语。该字典包括项目中用到的所有名称。请仔细地选择名称 ，以避免 传达不同的、不期望的含义。为每个名字写下简明扼要的定义 ，这些定义必须经过相应的风险承担 者同意。 6.相关事实 可能对产品产生影响的外部因素 ，但不是命令式的需求限制条件。 7.假定 列出开发者所做的假设。 将所有的假设列在此的目的是让每一个项目成员都