收集业务规则文档的好解决方案是什么?

发布于 2024-08-04 09:57:04 字数 1539 浏览 7 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

花想c 2024-08-11 09:57:04

+10⁶ 对于 Wiki,这是我迄今为止找到的文档(尤其是技术文档)的最佳解决方案。 IMO,“好的”Wiki 引擎相对于 VCS 中的 Office 文档的优势是(但您已经意识到这一点,因为此功能列表非常接近您的要求):

  • 它们比 VCS 中的 Office 文档更快、更容易使用。 VCS(无需打开 VCS 客户端、签出最新版本、可选择锁定它、打开 Word、保存、签入、释放锁定)
  • 它们是基于文本的,因此您可以进行差异(与 Word 不同),这只是必须的 他们是否
  • 提供通知机制(例如邮件、RSS),因此信息会推送给您(与 VCS 不同,您需要在文档过期时提取文档)
  • 不存在“文档被另一个用户问题锁定”的情况,因为有人忘记了释放它(如果您使用排他锁,这通常是您无法合并的文档的情况)
  • 页面可以轻松地重构,重新组织,组装在更大的文档中,
  • 它们确实是协作的,
  • 它们为代码提供了更好的支持(例如,您可以直接指向 VCS 中的源代码,格式比 Word 好得多)
  • 它们可以索引页面内容和附加文档(pdf、office 文档等)并使其可搜索 这是

我在使用文档的 Wiki 的缺点是,很难在与代码同时对文档进行版本控制(即,您交付版本 xyz 并希望“锁定”该版本的文档)。我已经使用导出来解决这个问题,但它并不完美。

我已经与 TWiki FoswikiConfluenceXWiki。它们都是“好的”Wiki 引擎(如上面所定义)并且都满足您的要求。因此,最终的选择可能仅取决于您的限制(许可证、定价、技术)和个人喜好。

截至今天,如果可以选择商业工具,我会选择 Confluence,如果没有,我会选择 XWiki。

+10⁶ for a Wiki, it's the best solution I've found so far for documentation, especially technical documentation. IMO, the advantages of "good" Wiki engines over Office documents in a VCS are (but you're already aware of that as this features list is very close to your requirements):

  • they are just faster and easier to use than Office documents in a VCS (no need to open the VCS client, checkout the latest version, optionally lock it, open word, save, check-in, release the lock)
  • they are text based so you make diffs (unlike word) and this just a must have
  • they offer notification mechanisms (e.g. mail, RSS) and so the information is pushed to you (unlike a VCS where you need to pull document when they are out of date)
  • there is no "document locked by another user problem" because someone forgot to release it (if you are using exclusive lock which is often the case on documents that you can't merge)
  • pages can be easily refactored, reorganized, assembled in bigger documents
  • they are really collaborative
  • they provide much better support for code (e.g. you can point directly on the source code in a VCS with much better formatting than in word)
  • they can index the content of pages and attached documents (pdf, office docs, etc) and make it searchable

The only issue I've faced when using a Wiki for documentation is that it's harder to version your documentation in the same time as your code (i.e. you deliver version x.y.z and want to "lock" the documentation of this version). I've used exports to solve this but it's not perfect.

I've already worked with TWiki Foswiki, Confluence and XWiki. They are all "good" Wiki engines (as defined above) and all meet your requirements. So the final choice may just depend on your constraints (license, pricing, technology) and personal preferences.

As of today, I'd choose Confluence if a commercial tool is an option, XWiki if not.

风吹雪碎 2024-08-11 09:57:04

一个更另类的想法是查看 FitNesse。它是一个 wiki,主要旨在将业务规则(或验收要求)描述为测试。

A more off-the-wall idea is to look into FitNesse. It is a wiki, primarily aimed at describing business rules (or acceptance requirements) as tests.

锦上情书 2024-08-11 09:57:04

我正在开发一个。

大约一年前,我在网上寻找需求管理软件,发现了至少 30 个软件,大约分为 3 个类别:

  • 无价(例如在航空航天公司销售)

  • 昂贵(例如每个席位 1000 美元),我的雇主从未选择使用它

  • 便宜或免费,但缺少对我来说重要的功能

还有通用工具(例如 Wiki、电子邮件和 Word 文档和/或电子表格),这些工具也缺少在我看来很重要的功能。


我认为你应该详细说明:“缺少在我看来很重要的功能”。

您可以使用通用 Wiki 做一些事情:

  • 创建功能列表
  • 描述每个功能(可能每个功能都有一个单独的页面/部分)
  • 协作执行此操作(版本控制、更新通知、

但是,我认为有些事情是通用 Wiki 无法做到的,甚至是非常基本的事情:

  • 定义自定义属性(例如“开始日期”、“预计成本”等) ;将这些属性值与您的特征相关联;列出功能(在表格或网格中)及其属性(以便可以对它们进行排序,例如按“重要性”或“难度”排序)

  • 帮助跟踪(当只有两个阶段时,跟踪不太困难,例如“需求”和“实现”;但是当有多个阶段时,例如“用例”、“功能规范”、“架构”、“实现细节”、“测试用例”、“测试结果”和“错误报告”)

  • 支持结构化信息,即小节而不仅仅是顶级部分。

即使只是简单的编辑也没有达到应有的效果。商务人士可能更喜欢使用 MS Word UI 进行编辑:但 MS Word 生成文档,即“信息孤岛”;但如果您不使用 MS Word,那么您正在使用什么?所见即所得的浏览器内编辑器?或者markdown语法?

I am developing one.

About a year ago I looked for requirement management software on the 'net and found at least 30 of them, in approximately 3 categories:

  • Priceless (and marketed e.g. at aerospace companies)

  • Expensive (e.g. $1000s per seat), which my employers have never chosen to use

  • Cheap or free, but missing features which seem to me important

There are also general-purpose tools (e.g. Wiki, or emails and Word documents and/or Spreadsheets), which too are missing features which seem to me important.


I think you should elaborate re: "are missing features which seem to me important".

There are things which you can do with a general-purpose Wiki:

  • Create a list of features
  • Describe each feature (perhaps a separate page/section for each feature)
  • Do this collaboratively (version control, update notifications, discussion pages)

But, there are some things which I think you can't do with a general-purpose Wiki, even pretty basic things:

  • Define custom attributes (e.g. "Date started", "Estimated cost", etc.); associate these attribute values with your features; list features (in a table or grid) with their attributes (so that they can be sorted, e.g. sorted by "Importance" or by "Difficulty")

  • Help with traceability (traceability not too difficult when there are only two stages, e.g. "requirements" and "implementation"; but it's harder when there are several stages, e.g. "use cases", "functional spec", "architecture", "implementation details", "test cases", "test results", and "bug reports")

  • Support structured information, i.e. subsections and not just top-level sections.

Even simply editing isn't a nice as it ought to be. Business people might prefer use an MS Word UI for editing: but MS Word produces documents, i.e. "information silos"; but if you don't use MS Word, then you're using what? A WYSIWYG in-browser editor? Or markdown syntax?

北笙凉宸 2024-08-11 09:57:04

我喜欢使用 FogBugz 中内置的 Wiki 功能来实现此目的,假设您已经使用它来进行功能/错误跟踪。在同一个工具中包含这些信息很方便。

I like using the Wiki feature built into FogBugz for this, assuming you already use it for feature/bug tracking. It's handy to have that info in the same tool.

木落 2024-08-11 09:57:04

Drupal 满足您列出的要求,它具有高度可扩展性,具有大量模块(请参阅下面的一些内容),并且可以在 GPL 下使用。

Drupal meets your listed requirements, it is highly extensible with loads of modules (see some below) and it's available under GPL.

人疚 2024-08-11 09:57:04

我们在之前的项目中使用 JIRA 来存储大约 750 个不同的业务规则。 JIRA 主要/有点是一个错误跟踪工具,但它非常强大且可定制,您可以将它用于各种工作流程/流程/知识库情况。 (顺便说一句 - 我不为生产它的公司工作)。

  • 易于更新:是的
  • 差异视图:提供完整的更改历史
  • 记录 可订阅:是的,有“监视列表”的
  • 想法基于:是的,功能丰富的安全模型
  • 附件:是的,每个规则都可以有自己的附件
  • 搜索:是的,可用全文搜索
  • 附件限制:嗯 - 不确定这个以及您到底想要做什么。

如果您决定走这条路,请提供一些提示...

  • 在其他地方使用 JIRA 的可自定义 ID 来引用规则,例如 MYPRJ-334
  • 对于您计划使用的任何状态的含义、建议、批准、实施有明确的指导方针,已验证,已删除。
  • 规则的唯一定义在描述中 - 所有注释都只是注释
  • 您可以将规则链接到用例、组件等,

这是一个很好的方法,我真的推荐它。

We have used JIRA on a previous project to store around 750 different business rules. JIRA is mostly/kinda-of a bug tracking tool, but it's so powerful and customisable that you can use it for all sorts of workflow/process/knowledge base situations. (BTW - I don't work for the company that produces it).

  • Easily updateable: yes
  • Diff view: a full change history is available
  • Subscribable: yes, has the idea of "watch-lists"
  • Role based: yes, feature rich security model
  • Attachments: yes, each rule can have it's own attachments
  • Search: yes, full-text search available
  • Attachment Restriction: hmm - not sure about this one and exactly what you are trying to do.

Some tips if you do decide to go down this path...

  • Make use of JIRA's customizable ID's elsewhere to refer to the rule e.g. MYPRJ-334
  • Have clear guidelines on what the whatever states you plan to use mean, Proposed, Approved, Implemented, Verified, Dropped.
  • The only definition of a rule is in the description - all comments are just comments
  • You can link Rule to use cases, components whatever

It's a great approach and I'd really recommend it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文