Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 10 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(4)
我对 Word 很满意。我认为工具并不重要,重要的是流程或工具的使用方式。
I'm happy with Word. I don't think it's the tool that matters as much as the process, or how the tool is used.
一些模型工具也可以非常接近为开发人员生成“规范”。例如 MockupScreens(我是开发人员):
http://MockupScreens.com
编辑:哦,在一个大型/正式项目中,您可能真的需要一个可追溯性矩阵(您可以使用 Excel 或一些专用工具(如 RequisitePro)。您知道我正在谈论的情况:有数百个“利益相关者请求”需要以某种方式映射到“功能需求”,以 1)证明每个请求都已得到解决,2)在某处发生变化时进行回归检查
Some mockup tools can get pretty close to producing the "spec" for developers, too. MockupScreens for example (I am developer):
http://MockupScreens.com
EDIT: Oh, and on a big/formal project you might really need a traceability matrix (you can use Excel for that, or some specialized tool like RequisitePro). You know the situation I'm talking about: there are hundreds of "stakeholder request" that need to somehow be mapped onto "functional requirements" to 1) prove that each request is addressed and 2) to do regression checks when something somewhere changes
我们使用 Word + Balsamiq 模型 (www.balsamiq.com)。
如果您交付 Web 或桌面应用程序,并且用户需要帮助来指定他们的需求或所需的视觉布局,则模型是基础。
此外,Balsamiq 使用轻量级线框样式,这将帮助您的客户专注于信息,而不是图形细节(字体等)。
我们在版本控制的 Excel 文件中跟踪每个需求的状态。
We use Word + Balsamiq mockups (www.balsamiq.com).
If you deliver Web or desktop applications, and the users need help specifying their needs or the desired visual layout, a mockup is fundamental.
Also, Balsamiq uses a lightweight wireframes style that will help your customer to focus on the information, and not in the graphic details (fonts. etc.)
We track the state of each requirement in a version controlled Excel file.
由于这篇文章被标记为“敏捷”,并且您将问题描述为应该如何编写和传达产品需求,所以我想说最常用的工具是用户故事和对话。
您提到了 Jira 和 wiki,因此您正在寻找的东西似乎是需求存储库。拥有这些固然很棒,但不要忘记,在大多数敏捷框架中,这些需求工件仅仅是对话的占位符。这种对话是大多数敏捷团队的主要需求沟通机制,没有任何工具或应用程序可以完全取代它。
Since this post is tagged 'agile' and you framed your question as how you should write and communicate product requirements, I'd say the most common tools used are user stories and conversations.
You mention Jira and wikis, so it seems like one thing you're looking for is a requirements repository. Those are great to have, but don't forget that within most agile frameworks those requirements artifacts are merely placeholders for a conversation. That conversation is the primary requirements communication mechanism for most agile teams and no tool or application can completely replace it.