2018年，该书“软件需求的开发”被转载。 同事给我发送了出版物的链接。 作者添加了用于敏捷项目的技术，确定了分析人员的角色并提出了自动化建议。 网络
上的评论极为
矛盾 。 我订购了一本书，想出了问题。
优点
一切都画完了
初学者将全面了解分析师的工作。 专业人士会记住自己面对的事情。 分析了创建规范的所有阶段。 附录B包含根据问题解决原理编写的手册。 目录本身就是一个提示。 几乎每章都包含详细的清单。 例如，规范模板包括8个子句，24个子句和两个附录。 综合指南。
容易找到信息
信息结构清晰，可以轻松搜索书籍。 目录被覆盖9页。 它会迅速找到正确的阶段和解释。 在每一章中都有其他章节的引用，如果在此有更详细的描述，则有其他问题。 本手册的末尾是术语表，因此您不必担心诸如“ UML”，“瀑布项目生命周期”或“ CRUD矩阵”之类的短语。 几分钟后，便有了以前版本的PDF版本，如果需要特定数据，可以使用文档搜索。
对于每个IT人士
分析师会与项目中涉及的每个人进行联系：客户，设计师，开发人员，测试人员，销售人员，产品支持和用户。 每个小组都应该知道如何将职权范围与他们的工作充分相关。 缺乏经验的员工可能会问：“当您单击此项目时，什么都不会发生？这是什么写给我们的呢？” 如果他读了这本书，他将回答这个问题并在文档上留下合理的评论。
条款解释
出于习惯，很难阅读该手册，但是在第700页之后，它变得更容易了：)在介绍过程中，每个概念都用括号括起来，并用英文原文给出。 这很方便，因为翻译器并不总是准确的，并且您可以用英语打开Wikipedia。 本书的最后是术语表和解释。 没错，手册中没有所有概念。 为了补充列表，我不得不手动添加50个新短语和页码。
缺点
细度
作者滥用冗长的句子和不必要的信息。 因此，含义更难理解。
“需求管理工具可帮助您跟踪需求，从而可以识别不同类型的需求之间，不同子系统中的需求之间以及各个需求与相关系统组件（例如设计，代码模块，测试和用户文档）之间的关系。”
列夫·托尔斯泰，是吗？
“ ...沟通方法可以在团队内部的时间和空间上提供有效的同步。”
在the叶上写着这是一本手册，而不是哲学论文。
“食品订单状态的状态图。”
作者不重复两次，不重复。
“ Stephen Withall（2007）描述了许多用于精确记录数据（也称为信息）的方案。”
数据=信息。 而且有一些东西！
而且这种语义干扰贯穿全书。 有人怀疑作者为这些台词付费。
语法错误
在阅读过程中，我对它们的计数超过160。学校课程中的所有错误。 例如：跳过单词，使用“ -tsya”代替“ -tat”，在一个段落中重复句子，遇到普通的错字，跳过逗号，以类似方式编写的概念被混淆。
打开书后，就会出现第一个错误。 克里斯没有狂妄自大，他们只是将她与卡尔（Karl）混淆了，后者专门为她写了一本书。 他们是配偶。
你觉得那句话怎么样？
“重新设计系统以更好地处理作为复杂项目支持的易变业务规则。”
产品放置
在演示过程中，作者反复提到Microsoft产品。 它们是如此著名，以至于没有必要写关于它们的文章。 当需要命名需求管理系统（SUT）时，作者对此保持沉默。 我只为他们阅读本章。 该书刚刚由Microsoft Press发行，而“软书”没有完整的SUT。 公司忠诚度超过专业债务。
轻描淡写
例如，在附录B中，作者提供了需求文档的示例。 他们写道，客户应该能够更改订阅。 但是关于创建订阅并没有说。 如何更改尚未创建的内容？ 跳过初始阶段。
或者表明系统应允许客户指定付款方式。 但这不是关于付款确认的文字。 如果无法确认付款，表明要付款的目的是什么？ 错过了最后阶段。
其余步骤在应用程序中有详细说明。 在这种背景下，期权链中缺失的环节让人感到被低估了。 显然，应用程序只是作为示例给出的。
与俄罗斯有关？
在阅读之前，我想过这样的话：“美国人能为我们提供什么建议？ 他们拥有一切，而且没有问题。” 事实证明，问题大致相同。
没有尊重要求的文化
正如一位熟悉的开发人员所说：“我不会读TK，但要立即编写代码。” 这不是一种平衡的方法。 该实现未与有关方面进行协调，未在研究其他选项，并且忽略了与其他元素的通信。 错误的风险及其价格上涨。 如果用户在发布后发现错误，则其价格将上涨21倍。 在传统知识阶段，消除它要便宜得多。 但是，尽管公司对规范并不认真，但它会“希望是最好的，但结果却一如既往”。
没有业务要求
业务需求描述了组织为什么需要一个系统，即公司打算通过该系统实现的目标。 但是，如果您看一下俄罗斯的中型公司，就会有一种奇怪的印象。 有些人不理解他们为什么生产，而另一些人不理解他们为什么购买。 但是雄心勃勃，而且押注在Instagram的印章上。 碰巧您与Skolkovo的另一个天才进行了交流，他热情地将虚构的需求强加给他的客户。 结果，该公司看起来像个蔬菜，预算看起来像个空洞的桶。
“附加”设计
这是不可能的，因为在重新设计之后，您必须编辑TK。 这是不必要的时间浪费。 该规范不必依赖于设计。 让设计人员可以选择如何实现此要求。 例如，“删除”控制元素可以表示为按钮，图标，链接，滑动或上下文菜单项。 最好通过功能和电路而不是接口来描述。 不是“系统显示下拉列表”，而是“系统提供选择”。
不了解分析师的细节
例如，在一家公司中，分析师扩大了职责范围。 他们被告知要告知当局何时或何时实施该要求以及由谁实施。 如果有延迟，他们会找出原因。 任务已分阶段转移，并任命了其他部门的负责人。 结果，内容部分遭受了损失。 所描述的一切都是项目经理的责任。 经理负责有关项目的信息交换，分析员负责有关产品的信息交换。 这是两个不同的业务领域。
不使用工具
一位老板希望与传统知识有关的人知道他们接近案文。 这是不现实的。 该公司拥有数十种传统知识，并且数量还在不断增加。 如果您一个月前完成了传统知识的起草，您仍然会忘记它，因为那样您就将自己沉浸在2-3个新的传统知识中。 解决问题的方法不是内存，而是需求管理系统（SUT）的实现。 它们支持对需求的识别，管理，跟踪和撤消。 但是，您必须为此付出代价，而且雇主更喜欢按照老式的方式工作，就像一句话：
建筑营的两名士兵替换了挖掘机。
一支空降部队加倍取代了他们。
投稿后我用俄语写了本书的发行人关于错误的建议，并建议将它们纠正在一起。 该请求已阅读，但工作人员未回复。 因此，他们认为文盲是普遍现象。 这很可悲，因为原始照片很好。
结论
这本书由于其不统一而给人留下了有争议的印象。 含量很高，但形式不是。 这真是令人生畏。 但是，如果专家想担任分析师，他将必须了解作者想说的话。 这并不容易，但是花时间是值得的，您将更加尊重自己。