问题标签 [requirements]

假设我在 MS Word 中有一个需求文档，其他人对其进行审核并提供使用“跟踪更改”功能发现的问题列表。

有没有办法提取“审查过程中发现了多少个主要/次要问题”？使用自动化脚本 - 用于度量目的？

我看到CodeCollaborator有一些 MS Word 集成，但它似乎不知道如何查看 Word 内部以提取跟踪的更改数据。它只是启动文档。

用例只是多个用户故事吗？

使用用户故事而不是用例有什么好处……反之亦然……何时使用一个而不是其他……所有敏捷方法都使用用户故事吗？

您使用什么方法来确定服务器需要什么样的硬件？

我经常发现很难预测带有数据库的基于 Web 的应用程序需要什么样的硬件。

对于如何最好地选择要使用的硬件，您有什么好的方法或建议吗？

您如何确定 Windows 应用程序的最低系统要求是什么？（操作系统、RAM、HD、CPU）。我通常凭直觉行事，但我希望能够用一些东西来支持它。

似乎安全要求似乎不喜欢使用 AI 来满足安全相关要求的系统（尤其是在涉及巨大潜在破坏/死亡风险的情况下）。谁能建议为什么？我一直认为，只要您正确地编写逻辑，您在算法中投入的智能越多，该算法就越有可能预防危险情况。实际情况有什么不同吗？

有很多网站可以教人们如何构建更好的软件，但为什么很少有网站能够真正详细描述我们（作为程序员）应该创建的领域呢？在不同类型的系统开始出现共同需求模式之前，人们只能构建如此多的库存、会计和 ERP 系统。从逻辑上讲，如果程序员花费大量时间试图在他们的架构中创建可重用的组件，这是否意味着他们应该有一些可重用的“蓝图”来描述他们应该创建的系统？换句话说，似乎软件开发的重点过于关注“如何”

所以我的问题是：是否有任何工作将所有不同类型的系统规范分类到一个地方，都在一个站点上？如果在项目开始时缺乏适当的需求是软件开发的祸根之一，那么能够“重用”以前已经编写的相同类型系统的需求规范不是更有意义吗？

尽管项目经理可能每个人都有自己的个性和管理风格，但似乎他们中的许多人都对在可能的情况下（无论是否有人在看）潜入“范围蔓延”充满了有害的爱。虽然他们通常是善意的（祝福他们的心），但您发现对项目经理说“不”的最佳方式是什么？

尽管Steve Yegge 很有智慧，但大多数开发人员都面临着从非技术客户那里收集到的需求。有时有项目经理与客户打交道并翻译他们的要求，有时则没有。无论如何，需求将发生变化的事实是不可避免的。

构成“良好编程实践”的大部分内容都与开发适应性强的系统有关，以便它们能够承受不断变化的需求。YAGNI、DRY、松散耦合等原则促成了这一点。诸如敏捷之类的迭代开发过程也试图解决试图击中移动目标的问题，当然，拥有一个正在测试的系统使得进行更改变得更加可行。

尽管如此，对于我们中的许多人来说，不断变化的需求似乎不仅会损害我们的软件质量，而且还会消耗我们的动力，让我们想要刺伤某人。

这个问题是关于如何管理客户，使他们能够以他们需要的方式改变他们的需求，同时阻止随意或轻率的改变。你怎么做呢？

• 您是否有项目经理将开发人员与客户隔离开来？
• 您有正式的变更管理流程吗？更换经理？
• 客户在真正需要时获得更改有多难？
• 相反，当“轻率”时，客户获得更改有多容易？
• 在解释变更成本时，您向客户提供了多少细节？
• 在收到更改请求后，您能多快向客户提供此信息？
• 哪些因素会破坏流程（例如无法对客户说不的 PM？）
• 什么对你有用？

我喜欢打印出软件需求，这样我就可以轻松地标记它们、绘制 UI 等。

您是提前打印出需求和设计材料还是仅以数字方式查看它们？

什么功能造就了理想的“程序员”打印机？

• 激光还是喷墨？
• 黑白还是彩色？
• USB 或以太网连接器？
• 双工？
• 通用墨盒或碳粉的可用性？

我正在编写系统需求文档，需要包含与系统可用性相关的非功能性需求，但我不确定表达这一点的最佳方式。

“系统应易于使用”对我来说似乎有点模糊，不可测试。是否有任何与程序可用性相关的“官方”标准/指南可以遵守？