要件にWikiを使用する

要件管理を改善する方法を検討しています。現在、Word文書をWebサイトで公開しています。残念ながら、（私の知る限り）あるリビジョンから次のリビジョンへの変更を確認することはできません。私は、wikiやVCSのように（または両方がbitbucket上のwikiのように！）できるようにしたいのですが。

また、各ドキュメントは、開発者が所定の期限までに満たすことが期待される変更について説明しています。蓄積されたアプリ機能のコレクションはどこにも文書化されていないため、レガシーアプリをすばやく修正しようとすると、バグと（設計が不十分な）機能を区別するのが難しい場合があります。

だから私はフィードバックを得たいと思っていました。何について：

1. 誰がいつ何を変更したかを追跡できるようにwikiを使用します（ほとんどの場合、前回の表示以降に編集が行われたかどうかを確認するためにも）。
2. たとえば、期限ごとではなく製品ごとに1つのwikiページを用意し、実装すべき変更ではなく製品のすべての機能に対応します。このようにして、ページの特定のリビジョンを確認して、特定の時点でアプリが何をすべきかを確認できます。また、次の期限までに要件を実装するための最後のリリース以降のページの変更を確認できます 。

ワダヤシンク？

はい、それは良いページだと思います。ページをシンプルな構造で整理し、簡単に閲覧できるようにするのです。

シンプルな構文のWikiを選択してください。（Dokuwikiはシンプルなものであり、DBは必要ありません）

編集：バージョン管理システム、つまりSVNまたはBZRを使用している場合は、マイルストーンを定義し、バグと機能のリクエストを維持し、バグを管理するための独自のワークフローを定義できるTracを試してください！Wikiが含まれています！

ウィキは良い方法です。ドキュメントがまだバージョン管理されているのが最善だと思います。最新の機能を維持するフローティングドキュメントを使用できます。それでも、スナップショットを撮れば、誰かが3バージョン前にそのソフトウェアのドキュメントを簡単に探すことができます。ドキュメントの履歴を確認する必要はありません。これは、迅速な復帰のために作成されており、数年または数か月前にさかのぼるにはあまり適していません。

私はMedia Wikiを使い始めましたが、現在はXwikiを使用しています。かなり良いGUIエディターがあり、誰もトレーニングなしで使用できます。「スペース」と呼ばれるアイデアもあり、各スペースは新しい名前空間を作成するので、product_x_featuresや愚かなものではなく、すべての製品に「features」というページを含めることができます。これにより、複数のWikiインストールを管理する必要が大幅に減少します。また、WordとXWikiを統合するツールがあり、Word文書を直接Wikiに保存できます。すべてがはるかに機能が豊富だと言った。

プロジェクトごとのwikiアプローチが気に入っています。あなたはbitbucketについて言及しましたが、リポジトリホストとして使用していると思います。そうでない場合は、GitHubのWikiも確認します。

あなたが少しお金を費やすことをいとわないなら、灯台をチェックアウトしてください。現在のところ、機能のリクエストとバグを追跡するための私のお気に入りの方法です。また、Pivo​​tal Trackerの使用も非常に気に入っています。pivotalは無料でしたが、現在は有料モデルに移行しています。