招标与需求与解决方案设计
按照惯例，当涉及到系统验收时，上述哪一种文件被认为是最重要的？
我最近进行了一次这样的谈话：
有人认为，应利用最初的要求/投标文件来确定系统的接受程度。有人说，解决方案设计只是用来描述系统解决问题的方式，而不是它要解决的问题。此外，有人认为，如果在解决方案设计过程中遗漏了需求，则应在系统验收过程中引用这些需求，如果有任何需求被忽略，则应引用原始招标。
相反，我建议--尽管要求可能基于最初的投标--但一旦与利益相关者达成协议，他们就会取代它。此外，在解决方案设计期间，将执行分析来处理和细化这些初始需求，将它们转换为能够满足实际需求的系统。一旦得到相关用户的批准，这个解决方案设计应该绝对代表需求(因为它是设计在他们身上的)，但实际上取代了它们作为系统接受的基础。
上述参数中的一个比另一个更有效吗？
编辑:为含糊不清的术语道歉。在这种情况下，招标是客户在为供应商购物时拿到市场的文件--包括他们正在寻找的所有高级功能的详细信息。解决方案设计不是技术文档，而是功能规范。
回答 2
Software Engineering用户
发布于 2013-11-07 17:25:42
通过验收测试表明系统满足了用户的要求。因此，需求文档通常被认为是接受标准的真相来源。
在设计过程中，几乎总是会有对需求的进一步阐述。如果这些确实是范围的扩大，则应更新需求文件以反映这一点。取决于你的过程有多正式，这可能涉及变更请求，诸如此类。
Software Engineering用户
发布于 2013-11-07 17:41:58
系统验收应与客户的要求相违背。您正确地认为，分析和派生是针对客户的初始需求集执行的。通常，客户需求不足以针对客户进行设计和实现，因此有必要详细说明客户的需求，细化他们的需求，并产生适合于工程师工作的技术系统需求。在某些情况下，由于法规的原因，甚至有必要增加要求，或满足业务目标。所有这些改进和派生应该与客户一起验证，以确保每个人都了解必须做什么，以及最终产品将是什么或做什么。
派生的需求应该可以追溯到更高层次的需求，要么是客户需求，要么是法规，或者是业务目标。这将确保您的设计和实现满足已知的需求。确保在系统/技术需求级别确定每个客户需求也有助于避免在设计和实现活动中缺少需求。
https://softwareengineering.stackexchange.com/questions/216810
复制相似问题
腾讯云开发者
