• 主题
高级搜索  >
历史搜索 清空历史
首页> 外文会议>Innovate integrate amp; invigorate >Can Requirement Specifications be Replaced by Databases?
【24h】

Can Requirement Specifications be Replaced by Databases?

机译：需求规格书可以用数据库代替吗？

获取原文
获取原文并翻译 | 示例
页面导航
  • 摘要
  • 著录项
  • 相似文献
  • 相关主题

摘要

With the increasing maturity of Requirements Management Tools, and the impact of "Faster,rnCheaper, Better" sometimes interpreted as "Get through the Requirements Phase as quickly as you can", it is tempting to do away with formal Requirements Specifications altogether, and manage your requirements set directly via a shared, Configuration-managed database. Is this adequate? What do we lose in the evaluation and review process? Is the database or the paper specification more likely to be read and used?rnAre there differences in practice (& efficiency) between internally-generated requirements sets (eg for Commercial product development) and different 'layers' of explicit customer-supplier procurement (e.g. contracting for a User capability; prime System requirement; detailed subsystem subcontract)? What effect does this have on depth of detail and flexibility throughout the development lifecycle - e.g. number of levels of decomposition, rigor of traceability?rnThe panelist's will present their own views, from experience gained in all types of industry and customer / supplier relationship. A moderated debate will ensure the audience can participate and voice their own concerns. The purpose of the panel is to learn from the panelist's, and each other, that reliance on a requirements database tool, with fully traceable multi-level decomposition and verification matrices, is no more the answer to our prayers than 1000-page requirements specifications. There are 'best-practice' lessons to be learned from using a little of both worlds!rnIn particular, the panel will discuss, and invite challenges from the floor, on the following topics:rn1. Paper versus database as the master version of the requirementsrn2. Use in the review and evaluation processrn3. Comparative readability and usabilityrn4. Treatment of internal and externally-generated requirementsrn5. Decomposition and traceability (whole system vs e.g. software component), and how to treat them in DB and paper environments.
机译：随着需求管理工具的日趋成熟，以及“更快，更便宜，更好”的影响有时被解释为“尽快完成需求阶段”，因此，人们很想完全放弃正式的需求规范，并进行管理您的需求可以通过共享的，由配置管理的数据库直接设置。这样够吗？我们在评估和审查过程中会失去什么？是否更容易阅读和使用数据库或纸张规范？rn内部生成的需求集（例如，用于商业产品开发）与明确的客户-供应商采购的不同“层次”之间的实践（和效率）是否存在差异？签订用户能力合同；主要系统要求；详细的子系统分包合同）？这对整个开发生命周期中的细节深度和灵活性有什么影响-例如分解级别的数量，可追溯性的严格性？小组成员将根据在各种行业和客户/供应商关系中获得的经验提出自己的观点。进行适度的辩论将确保听众可以参与并表达自己的担忧。小组的目的是向小组成员互相学习，即对需求数据库工具的依赖以及具有完全可追溯的多级分解和验证矩阵，对于我们的祈祷而言，答案不超过1000页的需求规范。从两个方面的共同使用中可以学习“最佳实践”课程！特别是，小组将就以下主题讨论并邀请与会者提出挑战：rn1。纸本与数据库作为要求的主要版本。在审核和评估过程中使用3。比较可读性和可用性rn4。处理内部和外部产生的需求rn5。分解和可追溯性（整个系统与例如软件组件），以及如何在数据库和纸张环境中处理它们。

著录项

相似文献

  • 外文文献
  • 中文文献
  • 专利
获取原文

客服邮箱：kefu@zhangqiaokeyan.com

京公网安备：11010802029741号 ICP备案号：京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有

  • 客服微信

  • 服务号