【计算机软件毕业设计】基于web的个人阅读管理系统的设计与实现文献翻译.doc

【计算机软件毕业设计】基于web的个人阅读管理系统的设计与实现文献翻译（完整版）
(文档可以直接使用，也可根据实际需要修改使用,可编辑 欢迎下载）
重 庆 理 工 大 学
文 献 翻 译
第五章 查找和构建的内容
现在你已经了解数据流图，程序说明，以及其他工具和概念的各具特色的故事，现在来看看如何找到你的故事的内容和可能的最佳方式去构建它。
你会发现你的故事的内容在项目团队成员的头脑中。项目团队是一群管理装配规划、管理，并有可能执行系统的开发的人。你可能会或可能不会有过团队任何实际权力，但作为指定的编写需求文档的人，你必须成为它的声音。你的任务是让团队专注于一系列的问题，这需要识别系统，它的主要内容、主要操作和基本要求及目的。你必须建立一个基本的默契团队，并以鼓励自由交流和相互尊重的倾听方式捕获信息。你不必给背后的团队解释所有的理论和方法，但你需要从特定的信息开始。一旦你有大量的信息，你就可以写一个适合团队和项目的大纲。
你是一个非常重要的团队成员
没有你，项目组里不会很善于弥补其头脑上的差异并清晰或精确地表达本身的想法。团队没有编档的成员往往会认为问题已经解决到了他们的满意程度，而实际上不同的团队成员可能会与书面结论上有很大出入，甚至有自私自利的观念。作为编档，指出这些是你的工作。通常情况下，简单地写下所有矛盾的结论是必要的。作为一个没有威胁的中立的一方，你能澄清不同的需求，轻轻地鼓励团队成员重新接合，达成共识。
项目组里产生的需求文档的内容。在编写需求文档时，你希望捕捉并表达团队的意志。你是不是需求文档的编者，你是抄写员，经理，司机，分析师，或是项目团队的看门人。你是不是表达你的想法，还是你表达了团队。
如果你认为某个组没有表现好，你可能没有选择团队成员，但你都不可能对添加成员有一些影响。一个好的项目团队应该是工作的利益相关者的每一个主要群体的代表。利益相关者是那些以获得或失去对系统的部署的人。通常，这些包括，但不限于，用户（具有不同的功能组，如运营，客户服务，顾问等），经理，工程师，依赖于系统工程师，你的系统将取决于主题专家，产品经理，市场营销人员和支持人员。
建立融洽的项目团队
由于项目团队的几乎所有内容都是需求文档中的信息的来源，你必须找到有效的方法来获取团队成员的信息。有很多书，提供有关如何从项目团队，采访相关专家，得到很好的指导和其他具体的要求。一些包括像专门的座位图表详细说明，会议议程，饼干食谱，信任建设活动，等等。
我建议从苏珊娜和詹姆斯·罗伯逊掌握需求过程（尽管它不包括饼干食谱）。
我将主要专注于你需要从团队去获得项目开工，让它给你良好的判断力以找到获取信息的最佳途径的基本信息。我会只有几个基本的建议：
l 鼓励充沛，不拘内容。在最初的采集过程中，你应该鼓励团队成员自由地描述他们做什么，系统做什么，和重要的部分是什么样的。前几个会议或面谈不应该刻意详述。你应该专注于数量超过产出的​​质量。你以后会努力改进你得到的材料，并且要鼓励团队成员自由地表达自己。
l 协作，重复，并确认你做好笔记。在你工作时，写下别人说的，以一个非正式的风格在白板，屏幕，挂图上，或什么最适合你的地方。团队必须能够看到你写下来的东西，你应该问团队成员，以确认你使用类似的短语已经写下了，“所以这样说是正确的，当前系统有效地识别了无效的账户？”
l 满足只在必要时，并不会太久。不要有太多的会议，并没有定期的安排见面。一个项目小组会议应服务于一个特定的目的，否则它不应该发生，因为你应该满足每一个。不要为超过两小时满足：团队或许可以去更长的时间，但你可能无法参与他们在说着的。即使你的会议录音了，并采取良好的笔记，你必须能够完全掌握。做了这些东西后，我发现，约90分钟后，理解复杂的问题的解释能力迅速下降。如果你有一整天的系列会议，一定要规划好休息。
l 满足个人或小团体。很多人都不太喜欢参与大组会议。如果你发现有人不参加大组，跟进刚才那个人。对于参与主题专家会议，你将要进入相当详细的讲解，这将是很乏味的组的一部分。
捕捉关键信息
还有就是你必须捕获开始该项目的具体信息。提出以下的问题，将是你的团队开始获得重要的信息的过程。
什么是系统的公事？
在一个项目中最重要和明显的原因往往不会写下来，因为他们不是直接相关的功能。什么是明显和重要的，项目团队可能是在世界的另一边完全陌生的程序员。鼓励团队成员清楚地说明整个系统应该怎样来完成。这些语句将推动众多的功能要求和业务规则。最重要的是，他们将填补这一空白，当其他要求不包括每一个可能的细节时例外。你可以做些什么来更深刻的认识构建的系统，更多的读者会如何做一些团队可能都忽略了的，而这个项目以后却是正确的猜测。
这些一般性发言也将是许多需要做摘要的内容，尤其是内容提要非常重要的。
以下是商业上的原因的一些例子：
l 确保对他们来说，我们处理交易的客户有没有记录或是有声誉可疑的活动。
l 请相信，我们了解和信任，我们在执行每一笔交易的买家和卖家。
l 确保我们可以深入研究的买家和卖家，我们不知道尽可能快，所以我们可以做正确的事情，仍然可以得到业务。
l 确保我们交付的问题响应速度不够快，当有来自传送问题导致隔夜交易延迟，这是没有我们的错。
系统的主要内容是什么？
鼓励团队成员自由地列出系统的所有部分，以创建系统的全面清单。这可以包括任何在这个过程中扮演一个角色的成员：数据，硬件，人员，团队，或任何重要的系统。系统库存可能包括这样的项目：
l 客户
l 经营业务员工
l 运营管理
l 客户交易文件
l 文件传输
l 对于交付共享文件夹
l OFAC数据库
l 交易管理系统（TMS）
l 新的决算报告
l 账户团队
系统做什么？
问问团队系统的基本动作。在这个阶段不要担心捕获指标，或使用准确的语言。没有很多的细节，我们想知道系统的基本功能。在后面详细文档里这些将成为高层次的流程。如果团队有熟悉的术语“用例”，就要求他们用用例。无论你使用的术语是什么，从所有类型的用户和外部系统的角度出发，一定要问清楚团队来描述系统做什么。
像这样的列表可能包括以下内容：
l 比较在交易账户中客户数据库
l 检查未知的账户对OFAC数据库
l 处理传递问题
l 屏幕占据可疑活动
l 进入交易TMS
l 通信交货问题管理
l 建立新账户
l 报告可疑交易
l 保留账户资料
现在什么是好系统？
你不希望新的系统，以撤消当前系统的优势。确保捕捉到当前系统的长处。此信息将成为当前状态分析的起点。
l 我们知道它（无需培训）。
l 事务处理由下午五时美国东部时间90％的时间内完成。
l 两名操作人员可以处理目前的交易量。
l 从坏的账户交易失败率小于1％。
l 容易改变的过程，新的筛查数据成为可用的和法律的变化。
l 可靠地满足业务目标：无交易已亲自处理过的可疑账户。
什么是系统表现不佳？
问团队来命名，其中的系统不符合当前的需要，它需要太多的精力，太慢，太不灵活，缺少的重要功能，也辜负任何其他方式的地方。
你最终可能会有像这样的列表：
l 完全取决于高层人员的知识
l 不能有足够的知识雇用和培训员工
l 不能满足预期增长50％
l 虽然事务处理上的时间通常是10％的延迟将不会在更高的量是可以接受的
l 筛选过程是完全手册
什么必须在系统继续做？
目前的系统已经是满足各种需求，你必须确保新的系统继续满足他们。收集需求的最简单的方法就是问团队它们是什么。你会得到一个长长的名单，大概包括大部分的关键需求，至少在系统输出方面。你在这个过程中收集的许多要求可能是密切联系在一起的现行制度执行情况和在现实中有没有基础的真正的商业理由。例如，你可能会听到要求。例如，“LT报告必须在上午10点提交作业”在不同的时间可能没有需要的报告，因为所有的数据是可用于实时性查询的。不过，在这个阶段的信息收集只是记下一切，然后继续。
下面是一个需求列表你可以创建在这个阶段项目的摘录。请注意，在不同类型的需求之间没有区别。在此阶段，解释类别是个复杂的过程。
l 所有的交易必须是已经在我们的客户数据库或已筛选不当活动的任何记录账户之间。
l 新的账户必须由两名工作人员按照账户管理政策和程序手动确认。
l 提供日常处理的所有交易文件到交易文件放置文件夹。
l 文件传输必须响应在30分钟内到文件递送的查询与恢复时间的估计。
l 当文件传输不作回应或不可达30分钟，交易团队管理必须应对文件传输问题。
l 如果文件传输不可达30分钟，操作人员发出警报事务团队的管理。
l 账户筛选数据库保持与公司认可的服务监控可疑账户一致。
l 有可疑活动记录的未知账户持有并用于研究建立新账户。
l OFAC查询未知账户必须寻找匹配者的名字和姓氏（包括两个字符的区别） ，公司匹配，匹配的主权，交易匹配和产品的匹配。
哪些外部数据是系统需要的？
当你正在改变东西，你必须保持你不能改变轨道。在系统中处理数据时，你常常无法控制你开始处理的数据。让团队去思考每一个这样的实例，并保持类似下面的列表：
l 文件传输档降
l 客户交易文件的格式
l OFAC数据结构
l 客户数据库
必须在系统提供与其它系统的哪些数据？
每一个系统向用户和其他系统中必须提供的数据，常常在不能改变具体的方法。在我们的例子中，以下是外部系统提供的数据：
l OFAC查询
l 在TMS事务条目
l 新的账户数据
l 交货警示
我们希望新的系统会做的更好的是什么
鼓励团队从大处着眼，并提出一些显著的改善，即使他们似乎行不通。让他们忽略系统如何运作，并采取新的办法，以实现他们已经描述的业务目的。
聆听并记下所有的答复。不必指出为什么他们将无法正常工作。
列表中的一个片段可能是这样的：
l 自动完成整个过程，从而无需手动工作，除非一个新的账户已经被创建。
l 到文件传输自动报告的交付问题。
l 摆脱文件传输。
l 寻找可疑交易的长期模式。
l 过程中，屏幕上只要它们是从客户传递进入的。
l 防止需要验证客户无效的账户信息。
其他列表
我所提及的名单可能是必要的每一个项目，但也有很多其他的事情要考虑在这个阶段。这些措施可能包括安全性，法规，更多的性能，等等。
编写大纲
经过与项目团队，并与主要利益相关方的几个会议，你应该有一个系统的库存，足以完成你写一个提纲。纲要定义文档的结构。根据项目和项目团队你的文档可能有一个非常不同的结构，以及时间和资源。
包括什么，什么离开了
我必须假设，如果你正在读这本书，你就打算真正建立某种形式的需求文档。你可能会面临来自团队在这个阶段的一些反对，找到你需要的需求文档的主意。许多开发方法需要文档才开始工作，很少或没有需求文档。
我还没有看到，也不会从有少量文档中受益的项目。每次一群人走到一起，并决定该怎么做，这是好主意，写下这一决定，检查每个人都同意大家做任何事情。在长期的职业生涯中，我一直在反复思考由不同的人在同一会议上的矛盾和自私自利的结论震惊。一个精确的书面记录没有什么决定，你永远不能持有错误却口头指定任何人负责。开发人员可以选择跳过功能规范文档，直接进入编写代码，但我从来没有听说过不从项目团队捕获至少粗略的高层次需求的辩护论点。
到目前为止，我已经为需求文档描述了稳健的做法，但我希望你适应我的建议的东西，实际上是为了你的项目。如果你的团队涉及到与“刚好够用”的文档开发工作的软件，以较小的增量快速或敏捷开发方法，没有任何理由为什么一个小的增量文件不能与一个小增量工作的软件来完成。这可能是因为你的团队是高度可视化的，喜欢图和屏幕实物模型，以散文的冗长方式运行。更具视觉导向的文件没有什么不妥。请参阅第4章的视觉文件的一个例子的图。我已经解释了该工具可以适应使用很少的散文。
小增量文件极大地提高了机会，该小量创建工作的软件将是一些项目组的打算，并且当许多这些小文件都完成了时，它们可被组装，以一个非常有用的大文件，准确地解释什么开发。
在项目的大纲阶段，你可以决定什么样的团队是文档的最简洁的可能结构。对于一个小的，快速移动的项目，你可以选择只记录单独进程及其要求。一个更大的项目，需要你从其他团队和管理在大型组织中获得实质性的支持，你可能需要创建一个细节丰富的文档。在大纲阶段，你帮助团队以决定该文件的确切内容。
一种通用的外形
尽管无穷的变化，也有共同的几乎所有的需求文档元素。几个文件包括所有这些部分，但我会简单介绍一下它们。我解释所有这些部分在本书的其他部分更多的细节。
l 内容提要：解释业务问题和项目的范围，并给出主要建议，指的是文件中其他地方的细节整个文档的一个非常简洁有力的总结。
l 当前状态：一个高层次的汇总之后进行了一系列数据流图和工艺描述，解释如何在系统功能，同时把握关键要求。对于较大的系统可能存在的重要过程许多子过程和摘要。
l 未来状态：相同结构的当前状态，但解释新的或变更的制度将如何运作。
l 差距分析：一个分析部分，通常包括表，突出当前和未来状态的进程和要求之间的差异。
l 要求总结：系列表中，这对于项目的各种方式分组不同类型的需求。
l 附录：参考材料，对文档至关重要，但不是主要的文档的叙述推力的一部分。典型的附录包括数据的描述，报告描述，用户界面的需求，安全需求，等等。
敏捷纲要
如果团队想要使用一个快速移动的敏捷方法，你可能不能及时勾勒出整个作品在开发者创建工作的软件之前。相反，打算在同一时间创建作为团队的作品，通常是一个过程的小部分。
总结
l 企业宗旨
l 成功标准
非功能性需求
l 业务规则
未来国家（跳过当前状态）
数据要求
在我们的例子中，一个敏捷的轮廓可能看起来像这样：

一种稳健的外形
执行摘要
l 问题：账户交付筛选过程过于人工，劳动强度大，且不一致。它不能扩展以满足预计的需求。
l 建议：建立一个自动化的系统，同时保持或超过目前的性能和质量标准。
l 主要规定和成功标准：交易交付时立即处理，自动发货，问题警报，自动OFAC筛查，筛查交易自动交易项目。
尽管对整体需求文档流行的叛乱，将有可能永远是一个需要准确描述的。较大的组织受益于，常常需要一个更完整的需求文档在开发之前，然后就可以开始。当写出一个较长的轮廓，它有助于简要描述你打算做的各部分的内容。一个完整的需求文档的轮廓可能看起来像这样：

l 适用范围：不改变交易管理系统（TMS），没有改变账户设置，无需更改OFAC数据库。
现状
l 总结
l 交易文件传递
l 账户匹配
l 未知账户OFAC筛查
l 筛选可疑活动
l 事务条目
l 举报可疑交易

l 新账户设置
l 账户维护
未来状态
l 摘要
l 交易文件传递
l 账户匹配和筛选
l 事务条目
差距分析
l 筛选标准（手动）与未来（自动）
l 交易输入验证当前（手动）与未来（自动化）
要求摘要
l 全面总结
l 非功能性需求
l 业务规则
l 筛选要求
l 交货要求
附录
l 数据说明：交易数据，账户数据，OFAC数据
l 报告说明：送货警示，可疑活动警报，处理状态警报
l 用户界面要求：界面设计委员会的过程中，可用性测试

总结
本章解释如何与项目团队合作，勾勒出需求文档的内容。本章提出以下建议：
l 建立融洽的项目团队。管理时间与团队要用心，小团体和满足个人。
l 收集关键信息来构建系统库存：基本的元素，目前的优势，以及目前的弱点。
l 编写适合你的项目和团队的大纲文档。
在接下来的两章，我将更详细的讲述如何编写每个列出的部分。

注：译自A Short Path to Writing Better Software Requirements by Ben Rinzler

译文原文（或复印件）

译 文 评 阅
导师评语（应根据学校“译文要求”，对学生外文翻译的准确性、翻译数量以及译文的文字表述情况等作具体的评价）

指导教师：
年 月 日