跟踪需求和假设的工具
我现在正在领导一个相当庞大的项目，该项目正处于构思阶段（刚刚起步），今天的问题多于答案。由于存在所有的不确定性，我们用于跟踪需求和收集估算的标准方法并不能解决问题。然而，我仍然需要建立一个模型并获取管理层用于企业会计和预算目的所需的数据。
我被要求简单地记录我们作为项目团队所做的假设，并且开发人员和应用程序所有者将能够根据业务需要为预算目的提供非常高水平的工作估计......
我需要一个工具，该工具还允许将假设以一对多的关系与高级需求联系起来，以便对假设的任何更改都将使我们能够确定哪里需要更多的估计工作。
示例...
假设：
我们将使用负责 x、y 和 z 的单一设施进行操作。
要求/范围：
- 该系统需要添加额外的设施。
- 该其他系统需要能够处理 x、y 和 z。
因此，归根结底，如果我的假设发生变化，我想快速看到我至少对我的 2 个需求/范围线产生了影响......
I am leading a fairly massive project right now that is in it's idea phase (just getting off the ground) that has more questions than answers today. With all of the uncertainty, our standard methodology for tracking requirements and gathering estimates won't cut it. However, I still have to build a model and get the data that management needs for corporate accounting and budgeting purposes.
I've been asked to simply document the assumptions we're making as a project team and that the developers and application owners would be able to provide a very high level estimate for the work as needed by the business for budgeting purposes...
I need a tool that will also allow assumptions to be tied to high level requirements in a 1 to many relationship so that any changes to an assumption will allow us to identify where more estimation work is required.
Example...
Assumption:
We will operate with a single facility responsible for x, y, and z.
Requirement/Scope:
- This system will need to have an additional facility added.
- This other system will need to be capable of processing x, y, and z.
So at the end of the day, if my assumption changes I want to quickly see that I have at least an impact to 2 of my requirements/scope lines...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为这称为“可追溯性”（例如 需求可追溯性），因此，请将该词包含在您的搜索词。
I think this is called "traceability" (for example Requirements traceability) so, include that word in your search terms.
当事情结构不合理时，您不需要太多工具。
http://www.w3.org/2001/tag/doc/leastPower.html
您需要很大的耐心和清晰度才能从您所拥有的内容转变为更正式的要求。
普通的文字处理通常是最好的。
由于您想要进行估算，因此电子表格包含了问题当前可以承受的所有结构。
一个大的旧矩阵，一个轴上有要求，另一轴上有假设，这将允许您柚木、调整和评估影响。
如果您花时间将所有问题和答案加载到某个工具中，那么您就会花费大量时间来使用该工具，而不是问题。此外，随着想法的出现和消失，您讨厌从工具中删除真正 EPIC FAIL 的想法。
通常，您应该随意“从头开始”重新开始，放弃不好的想法。
写、写、重写，直到问题、答案和要求达到可管理的水平。
然后将简单的东西迁移到更严格和正式的工具。将复杂、不明确且没有重点的内容留在文字处理程序中。
When things are ill-structured, you don't need much of a tool.
http://www.w3.org/2001/tag/doc/leastPower.html
You need a lot of patience and clarity to get from what you have to more formal requirements.
Plain-old word-processing is often best.
Since you want to do estimating, a spreadsheet is about all the structure that the problem can stand right now.
A big-old-matrix with requirements on one axis and assumptions on the other will allow you to teak, adjust and assess impact.
If you spend time loading all your questions and answers into some tool, you spend a lot of time playing with the tool -- not the issues. Also, as ideas come and go, you hate to delete the really EPIC FAIL ideas from the tool.
Often, you should feel free to start again "from scratch", discarding the bad ideas.
Write, write and rewrite until the questions, answers and requirements get to a level of manageability.
Then migrate the easy stuff until a more rigid and formal tool. Leave the complex, ill-defined and unfocused stuff in a word processor.
尝试终极跟踪。它是免费的，并且提供任何可追踪对象之间的双向 n 对 m 关联。
Try out Ultimate Trace. It is free and it provides two-way n-to-m association between any traceables.
我认为您需要一个便宜且快速的解决方案。有很多工具可以做到这一点，但可能要花费很多美元。我喜欢的一个是 Compuware 的测试和需求管理套件。 TrackRecord 我想这个名字是。
一个更便宜的解决方案可能是用思维导图来满足需求。您可以将需求与解决方案的许多部分等联系起来。
您可以研究的另一件事是 UML 工具。
I take it you need a cheap and quick solution. There are lots of tools to do this that can cost lots of $$$$. One that I like was Compuware's test and requirements management suite. TrackRecord I think the name was.
A cheaper solution could be MindMapping the requirements. You could tie in the requirements to the many parts of the solution etc.
Another thing you could look into are UML tools.
澄清一下：当您开始收集需求时，您已经陈述了有关各种事物的需求和假设，包括某些需求应该是什么。那时，是的，为了方便起见，我在同一个工件中跟踪它们。
现在，正如我所说，有些假设是关于请求的，但有些或许多则不是。这些其他假设可能与设计有关，也可能与依赖关系有关，举两个例子。我希望所有有关请求的假设都能在请求获得批准时得到解决。其他的我将转入下一个工件，在那里它们在设计中得到解决。
解决假设的例外情况是假设的“范围”超出了项目。我见过一两个非常基本和/或难以证明该假设是该项目的基础的假设。
To clarify: When you start gathering requirements you have stated req'ts and assumptions about various things including what some requirements should be. At that point, yes I track them in the same artifact for convenience.
Now, as I said, some of the assumptions are about req'ts, but some, or many, are not. These other assumptions may be about design or they may be about dependencies, to give two examples. I expect all assumptions that are about req'ts to resolve by the time the req'ts are approved. The others I will roll forward into the next artifact where they get resolved in design.
The exception to resolving assumptions is if the "scope" of the assumption goes beyond the project. I've seen one or two assumptions that were so basic and/or difficult to prove that the assumption was an underpinning of the project.
假设并不与具体要求同时存在。一旦假设得到证实并成为要求，该假设就会消失。
我总是将假设与需求放在同一个工件中。因此，任何跟踪需求的工具都可以用来跟踪相关假设。我将它们放入 BRD（业务需求文档）、用例、IBM 的 RequisitePro 中...
Assumptions don't exist in tandem with specific requirements. Once an assumption has been confirmed and becomes a requirement, the assumption goes away.
I always put assumptions in the same artifact with the requirements. So any tool that tracks requirements can be used to track related assumptions. I've put them in BRDs (Business Requirements Documents), use cases, IBM's RequisitePro...