タグ付けされた質問 「requirements」

ソフトウェアを書くとき、正式で詳細なデッドツリー仕様を書く意味は何ですか？明確にするために、コードを読みたくない人のためのやや非公式な高レベルの仕様は私には理にかなっています。十分にコメントされた読みやすいソースコードのリファレンス実装は、コンピュータが実行できる必要があるため、取得するあらゆるものの最も明確な仕様についてのものです。形式的な仕様は、コードと同じくらい読みにくく、ほとんど書くのが難しいです。 正式な仕様は、リファレンス実装に比べてどのような利点がありますか。リファレンス実装での動作に関係なく、未定義/実装定義の動作についての小さなドキュメントが提供されます。 編集：または、テストが正式な仕様であることの何が問題になっていますか？

8 project-management  requirements  specifications 

OSを考慮せず、開発ソフトウェアを実行するための要件。必要な保管スペース。 仕事の観点から厳密に言えば（フリーランサーではなく会社のセットアップ）。ビデオ、オーディオ処理（巨大な未加工ファイル）3D /グラフィックス開発の領域でない限り、個々の開発者（ビルドシステムは考慮しない）。必要なストレージ容量。 ソフトウェアの試用版をダウンロードして資料を読んだとしても、20GBで十分であり、それ以上のものは無駄であり、または不適切に利用されると想定することは適切か安全か？ オフィスのセットアップで開発者ごとに割り当てられる典型的なハードディスクの容量はどれですか。これは、役割や特定の要件、および会社がどのような仕事をしているのかによって異なる場合があります。しかし、開発者/プログラマにとって平均して、通常どのくらいのスペースが割り当てられますか。 編集： 意図を明確にする これらは私がビジネス/管理の人々が直面していた質問です。私がこの問題にさらに出会ったときに、答え（またはより良い答え）を与えるために、この点についてもっと理解したいと思います。この点に関して、私は仮定を立てたり、攻撃したりするつもりはありません。この点に関してオンラインのデータへのリンクが提供されていると助かります。 編集2： 私が理解している問題は、ストレージスペースを作業ファイルの保存のみに制限して、余分な使用を防ぐことでした... ハードウェアのスクリッピング/コスト削減についてではありません。

8 requirements  hardware 

私が勤務する会社では、ソフトウェア開発ライフサイクルへの準拠を計画し始めています。私たちはすでに、wiki、vcsシステム、バグ追跡システム、継続的インテグレーションシステムを持っています。 次のステップとして、ソフトウェア要件の構造化された方法での管理を開始します。多くの入力（開発者、マネージャー、商用、セキュリティアナリストなど）があり、ネットワーク共有の周りの.docの急増に対処したくないため、wikiや共有ドキュメントを使用したくありません。私たちは検索を試みており、FOSSソフトウェアを見つけて使用して、これらすべてを管理できることを願っています。 私たちは約30人で、商用ソフトウェアの予算がありません。要件管理のための無料のソリューションが必要です。 私たちが求めているのは、以下を管理できるソフトウェアです。 必要な機能： 構造化された構成可能な方法で分割されたソフトウェア要件 要件のバージョン管理（履歴、diffなど、ソースコードと同様） 要件の相互依存性（の子、親、関連） データ処理のためのルールベースのアクセス制御 マルチユーザー、マルチプロジェクト ファイルのアップロード（グラフ、関連ドキュメントなど） レポートおよび抽出機能 オプション機能： ウェブベース テストケース 時間ベースの管理（タイムライン、例外データ、結果データ） 人割等 ビジネス関連のもの ハードウェア割り当て処理 私はすでにtestlinkで遊んでいて、今はRTHで遊んでいます。次に試すのはredmineです。

8 project-management  tools  requirements 

私の質問は次のとおりです。ソフトウェア作成プロセスの早い段階でユーザーの要件をどのように確認できますか？ ユーザーの仕様、プロトタイプ、デモなどを紹介しますが、それでもユーザーはプロセスやビジネスルールやデータに関する「重要でない詳細」を共有するのを忘れています。これは、最終的なテストの後に、いくつかの「非常に小さくてまれな例外」としてポップアップします。これは、変更要求に変換され、多くの作業が蓄積されます。 では、プロジェクトの早い段階でユーザー要件をどのようにプロトタイプ化（または検証）するのでしょうか。

8 requirements  specifications 

質問 要件ドキュメントの機能要件では、動詞に基づく表現を使用する必要がありますか？ 環境 学校の割り当て、チームでの作業、SDLCによる作業。要件ドキュメントが作成され、設計に取り掛かりました。 問題 要件のドキュメントには、アプリの機能と呼ばれるもの、つまり機能要件の一覧が列挙されています。その中には、「何を」ではなく「どう」だと思いますが、今、デザインに取り組もうとすると、デザインの一部が時期尚早に規定されているような気がします。 私はこれを前にやったことがありません！私にとっては、「何を」ということを厳密に扱うべきです。 現在の例 仕事がオムレツを作ることであるふりをします。リスト：卵を割る、ボウルに割り込む、スクランブルなど; どのように領土に線を越えます。そのトラックに沿って、次のような表現も作成します。作成、生成、リスト、計算、決定、検証など-基本的に動詞。現在、部分的に動詞に根ざしている要件のリストがあります。 オムレツの要件ドキュメントについての私の考えは、2つの卵、xオンスのハム、xオンスのベーコン、xオンスのモンテリージャックチーズ、xオンスのコリアンダーなどなどです。何も（名詞） 。 経験があれば、要件ドキュメントを完成させる前に、発言した可能性があります。

8 requirements