Questions tagged «requirements»

人们如何定义软件的最低硬件要求？例如：软件开发公司如何告知客户他们将需要8 GB的RAM才能正确运行程序？

21 requirements  hardware 

在项目投标阶段的很多时候，我从各种来源（电子邮件，Word文档，excel）以非常非结构化的格式从潜在客户那里收到软件系统的要求。通常是一群来自客户方面的“产品开发”人员针对他们所遇到的业务问题提出这些“建议的解决方案”。尽管他们是业务领域的专家，但很多时候他们没有正确的解决方案。 这导致 相同需求的多个版本 将两个需求混为一谈 稍后有几个版本的需求，再将合并在一起的需求分离出来，每个需求都包含一些新增加的内容 您如何处理这些需求，并在开始开发之前将它们分类为正确的用例？从第一次构思到将其具体化为合适的用例，我们可以使用哪些工具来跟踪特定需求的历史？根据这样收到的需求来估算工作是一场噩梦，最终导致在正确理解需求并正确估算针对需求的工作时犯了错​​误。 一旦我们赢得了该项目，客户就可以对他们的要求进行更多的考虑，并能够正确地阐明它。在这种情况下，发生的事情是某些功能被丢弃，某些功能得到增强，某些功能又有了新的转变。从根本上讲，这可以使赢得项目之前所做的某些工作项估计无效。我很想知道是否有任何系统可以构建具有特定需求的树，以及每个分支如何导致不同的估算。 有任何技巧，工具和技巧可以使此活动更易于管理吗？我只是想从比我在需求管理和工作量估算方面更有经验的人那里获得一些见解。

21 requirements  development-methodologies  use-case  requirements-management  engineering 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我的工作环境背景 我的经理对计算机或软件没有任何背景或了解。他很可能一生中都没有看过任何形式的代码（甚至从10英尺或更短的物理距离来看）。 有没有人谁懂什么，我要求执行的复杂性。到这一点，如果我半硬编码，没人会知道。 在Joel的测试中，我们得到了令人难以置信的0分。 问题所在 经理和其他“高级”经理有时会不断更改需求规范。如果进行了良好的工程设计而不是修补性的“修复”，则需要进行基础设计的更改。 有绝对没有人谁看代码（也许是因为没有人知道如何，或者即使它应该做的），这意味着没有人会能够： 欣赏问题的复杂性或解决方案的精妙之处。 建议改进方法。 赞赏代码的质量。 指出可以改进代码的地方。 使用了很多行话，这在语法上是有意义的，但是在任何其他方式上都没有任何意义。 不像软件公司那样感觉，表现或工作。 问题 应该做什么？特别是关于没有人指出我的代码有所改进。 更新资料 要回答HLGEM（以及可能的其他问题）有关我为修复该问题所做的工作。我提议成立Redmine并向所有人介绍源代码控制。我说过我会推荐分布式（git或mercurial），但也会讨论集中式的，让团队决定。回应是事情正在做，将在几周内完成。还没有看到，我也不知道公司的其他部门是否在使用它。

21 requirements  management  communication 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我是一名软件工程师，在过去的几年中，我之所以成为事实上的软件项目经理，仅仅是因为没有人。因此，为了保持我们在研发/工程部门的理智，客户已经习惯了向我提出他们的要求。我没有这个领域的经验，所以这是我第一次担任软件项目的项目经理。我已经管理了其他东西，但没有管理软件。 那么，您如何管理软件项目并标记优先级？请求以不频繁的间隔出现，因此我们很可能会为其他人做某事，然后另一个人来了需要处理的“紧急”工作。只是说“先来先服务”还是更容易赚钱？

21 project-management  requirements  feature-requests 

我们正在开发一个应用程序；它包括由另一个编码器开发的库，该库通过多个网络连接与服务器通信，并且涉及多个线程一起工作。服务器端代码非常复杂，我们无法访问源代码。 最近，我发现了一个Mandelbug有时会使应用程序崩溃。我可以重现一次并获得堆栈跟踪，因此打开了一个错误报告。该错误本身易于修复（后台线程之一中未捕获的Web异常，这使CLR终止程序）。 问题是开发人员拒绝修复该错误，因为“他不相信它的存在”。不幸的是，老板对我表示支持，并说除非我创建一个“可靠的测试用例”以证明该错误的存在并进行单元测试以确认该错误已消失，否则无法修复该错误。由于bug的性质，基本上是不可能的。 有什么建议吗？

20 project-management  teamwork  requirements  collaboration 

有人告诉我“用户故事不是需求，它只是在提醒客户需要什么，您不能在故事中放入需求”。但让我们举一个例子，客户希望对不同的信用卡进行不同的处理。必须执行并知道严格的要求，以便可以编写测试用例。如果不在用户故事中，需求应该去哪里？ 如果没有更低的要求，开发人员如何从故事中发展？测试人员如何根据用户故事编写测试用例（详细的用例）？用户故事之外还存在DB约束，字段验证等需求吗？

18 agile  scrum  requirements 

作为自由程序员： 从客户收集需求的过程是什么？ 需求收集过程需要花费多少时间？我知道这不是固定的，并且有一些变量，例如客户端响应的提示速度等等。通常，考虑到响应的延迟等等，达到最终要求需要多长时间？ 您使用哪个通信渠道（电子邮件，电话，即时通讯工具等）来收集这些要求？ 您是否花时间收集需求？ 您的需求收集过程中是否有任何可交付成果？如果是这样，那是什么？

18 productivity  development-process  business  freelancing  requirements 

已关闭。这个问题需要细节或说明。它当前不接受答案。 想改善这个问题吗？添加详细信息并通过编辑此帖子来澄清问题。 去年关闭。 在“ 需求质量”段落中阅读“代码完成2”，我发现： 是否在竞争属性之间（例如，稳健性和正确性之间）规定了可接受的折衷？ （以上是检查复选框质量的一个大复选框） 因此，我在网络，学术书籍等中找到了很多关于稳健性和正确性的定义。 例如： 在“面向对象的软件构造，第二版，Bertrand Meyer，Prentice-Hall，1997”一书中： 正确性：系统在其规格，设计和实施中没有[缺陷]的程度。 鲁棒性：在无效输入或压力环境条件下，系统继续运行的程度。 尽管如此，尚不清楚这两个原因为何以及在哪些情况下可能发生冲突。 我的问题是：为什么这两个属性在竞争中？

17 development-process  requirements  quality-attributes 

我一直在研究如何更正式地记录软件项目，并且了解了IEEE 830-1998：《软件需求规范的推荐做法》。但是，从该链接可以看到，它已被取代。 我知道830-1998，甚至830-1993都可以使用。但是，如果没有别的，我想知道是什么标准取代了它。在这种情况下，可能没有关系，但是如果为了其他技术问题而取代了其他标准，我认为最好在某个地方链接取代的另一个标准（如果不是同一行中的另一个标准的话（830，在本指南中）案件））。 值得一提的是： 在IEEE标准协会网站上搜索“软件要求规范”或“软件要求”时，最新标准为830-1993， SWEBOK的2004年（当前）版本引用了830-1993（第2.5段）， 该文档的Wikipedia文章并未提及该标准已被取代。 TLDR：您如何找到取代另一标准的标准，以及取代830-1998的标准？

17 documentation  requirements  standards 

我们都看到了无数带有“最低系统要求”的软件示例，如下所示： Windows XP / Vista / 7 1GB内存 200 MB储存空间 一般如何确定这些？显然，有时会有特定的限制（如果程序在磁盘上占用200 MB，则这是一个硬要求）。除了那些情况之外，对于RAM或处理器之类的东西很多次都发现，没有硬性约束的情况下，更多/更快更好。如何确定这些？开发人员只是编造看起来合理的数字吗？质量检查人员是否经过严格的流程测试，以测试各种要求，直到找到性能可接受的最低设置？我的直觉说应该是后者，但实际上通常是前者。

17 documentation  requirements  qa 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引文回答。 4年前关闭。 我经常听到项目经理（项目经理）谈论特性和功能。而且我很困惑要区分它们。有时我认为功能等同于用户故事。诸如“作为用户，鲍勃应该能够看到他的付款清单”之类的东西，他们称其为功能。有时它变得像子系统一样大，例如“通过Web应用程序发送SMS的能力”。另一方面，功能有时会像“为数字输入实现数字分组”这样的任务一样小，而在某些情况下，它会像整个CRUD操作一样大。 我的问题是，如何区分功能和功能？

16 design  terminology  requirements  functions  features 

我确信每个人都经历过这样的事情。您与有项目的客户开会。他们没有/很少有需求，对他们想要/需要的东西最模糊的理解。在这一点上，似乎有两个选择： 1）告诉用户，“好吧，如果您什至无法描述它，我也无法为您提供帮助。为什么您知道自己想要的东西后几个星期不回来呢”。 2）与用户会面几次，并通过良好的ole Socratic方法指导他们进行操作，帮助他们弄清他们想要的东西。“您需要跟踪X吗？”，“ Y怎么样？”，“是否需要功能Z？” 使用第一个选项，您不会被困于他人的工作或获得心理能力，但是，用户可能永远不会向您展示连贯的规范，或者随着期限的临近，他们可能会花很长时间。使用第二种方法时，您会浪费大量时间成为业务分析师，并且不得不将很多业务知识塞进脑海中，您可能永远不会再使用它，但是您更有可能提出一种规范，有道理。 对我来说，这是发展中最具挑战性的方面之一，我感到我并不孤单。根据您的经验，这些选项中的哪一个更有效？

16 requirements  planning  specifications 

我所体验到的敏捷开发的最大缺点是，不参与开发的人们专注于这样的口头禅：用户故事（3-10个理想人日）不应包含超过1-3个句子，例如： 作为客户，我可以使用自由文本搜索，以便找到所需的产品。 给出这句话，项目经理希望我作为开发人员致力于估算并开发故事。他们认为敏捷开发意味着他们必须提供给开发人员的此类语句。 我不会责怪他们，因为关于敏捷开发的著名文献给人以这样的印象，即它实际上是可行的。在“ Planning XP”中，每个故事我都用自然语言阅读了大约2页，但这就是事实。因为“工作软件”比“综合文档”更受青睐，所以似乎通常避免使用此主题。 当然，现实是，如果开发人员有机会这样做，则与客户的访谈会提出一长串客户对故事的要求清单： 我们需要布尔运算符，例如AND和OR。 我们需要所有的模糊搜索。 我们需要按单词和短语进行搜索。 我们不想找到符合标准X，Y和Z的产品。 我们要对结果进行排序。哦，顺便说一句，用户可以在带有选项a，b和c的组合框中选择排序标准。 所以您看到我不是在谈论技术细节，软件设计甚至实施细节。这是纯粹的要求。我们交谈的时间越长，客户就越能意识到他们想要的东西很多。 但是，我经常发现自己处于这种情况，即没有提供此类信息或以次充好方式。我既不可能进行面试，也没有可能进行面试的人为我提供面试的结果。 有时，经理甚至会提出“我们希望进行Lucene搜索”之类的技术细节，但他们不想考虑是否只想查找产品名称或产品描述。有时我认为他们只是懒惰;） 对我来说，这是我工作的项目中的头号问题（电子商务Web应用程序，每个项目500-2000人日）。我已经足够频繁地解决了这个问题，并且经理们意识到大多数开发人员对此情况都有疑问。但是他们认为开发人员实在是太“完美主义者”了。他们似乎对开发人员“总是希望指定所有内容”感到恼火。 由于缺乏公认的数字，因此很难争论。每个人都知道迭代应该持续多长时间。但是没有人能说出估计和发展一个故事需要多少需求。 你有参考吗？

15 agile  requirements 

关于编写规范，我有几个问题，它们是： 在编写软件规范时，在“用户需求定义”主题下，我们仅需指定“功能”和“约束”？ “用户界面”属于“功能”还是“约束”？ 软件可以细分的主要关键领域（要求）有哪些（例如UI）？

15 documentation  requirements 

在短期内，敏捷项目的需求管理对我来说似乎是一个已解决的问题。 从Scrum角度，新需求或对现有需求的更改是通过用户故事交付的。并且，按Epic或Feature分组的User Stories有助于交付更大，更复杂的需求。 当然，从技术上讲，用户故事不是要求文档。这是一个可管理的工作分组，映射到通常称为功能的垂直切片的内容。这些故事的范围可以通过使用接受标准（AC）来明确定义。 因此，尽管用户故事不是正式的要求，但浏览它们可以使您对他们的基本要求有一个清晰的认识。在短期内。 我之所以说是短期的，是因为随着项目的进展，用户故事的数量会增加。因此，随着时间的流逝，浏览不断增加的故事列表以找到需求的效率越来越低。 当您考虑扩展，取代甚至否定先前故事的用户故事时，此问题会更加复杂。 现在，假设一个项目的开发迭代（生产稳定）之间存在2年的差距。最初的团队消失了，他们所有的知识也消失了。 如果原始团队知道这将要发生（例如，这是企业的性质），那么他们可以采取哪些措施来帮助后续团队？ 当然，待办事项将提供一些信息，但是它几乎不容易浏览。 那么，可以做些什么来帮助后续团队了解项目的状态，包括为什么以及如何到达那里？ 以我的经验，以下几项无效： 积压整理以删除或更新以前的用户故事，以便可以将积压阅读为需求文档。 文档冲刺团队成员的任务是记录系统的当前状态。 通过行为测试的文件。这种方法是我所见过的唯一接近可行的方法。不幸的是，编码行为测试是命名问题的受害者。尽管这些测试可能正确记录了该系统，但要使变动的开发人员团队按照相同的Domain术语，措辞和样式编写测试几乎是不可能的。 因此，重申一下： 长期如何管理敏捷项目需求？

14 agile  requirements  requirements-management