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

私のチームと私は、顧客との対話に使用するソフトウェアを開発しています。さらに、私たちは自分たちのドッグフードを食べ、ソフトウェアを使用して顧客と対話します。 したがって、私たちの従業員はオペ​​レーターになることができ、お客様はオペレーターになることができ、お客様のお客様は訪問者になることができるため、ユースケースやシナリオを説明するのは難しい場合があります。 ただし、お客様はオペレーターの従業員とやり取りする訪問者である場合もあり、お客様のお客様は私たちの顧客または従業員とやり取りする訪問者である場合もあります。 ここにモデルがあります： A is an employee B is a customer C is our customers' customer X interacts with Y Operator --> Visitor A --> B A --> C B --> C 時にはお客様がさまざまな役割を演じることがあるため、従業員と顧客ではなく、オペレーターまたは訪問者という特定の役割を参照する必要がある場合があります。 いつも「お客様のお客様」と言っても一口です。 他の開発ショップがこれらのセマンティックの詳細をどのように処理するのか、それらのユースケースとシナリオを書くときに疑問に思いました。 第3レベルの俳優を含む製品に適用できる一語の一般的な用語はありますか？ 特定の役割であるオペレーターと訪問者を使用する以外に、顧客の顧客を識別するためにどのような言葉を使用できますか？ 単語は、組織内で採用されるように十分に短くする必要があります。2音節より長い場合でも、短縮形は他の俳優と区別する必要があります。

9 communication  naming  specifications 

すぐに小さなサイドプロジェクトを開始しますが、今回はプログラミングの前によく行う小さなUMLドメインモデルとケース図だけではなく、完全な機能仕様を作成することを考えました。私がそれに追加する必要があるものを私に勧めることができる機能仕様を書いた経験がある人はいますか？どのように準備を始めるのが最善でしょうか？ここで、より関連性があると思うトピックを書き留めます。 目的 機能の概要 コンテキスト図 重要なプロジェクト成功要因 スコープ（イン＆アウト） 仮定 アクター（データソース、システムアクター） ユースケース図 プロセスフロー図 アクティビティ図 セキュリティ要件 性能要件 特別な要件 ビジネスルール ドメインモデル（データモデル） フローシナリオ（成功、代替…） タイムスケジュール（タスク管理） ゴール システム要求 予想経費 それらのトピックについてどう思いますか？他に何か追加しましょうか？または何かを削除しますか？ ひとつひとつの回答に乗りましたが、有益な情報をありがとうございます。 私はこのサイドプロジェクトを会社のために行っています。彼らは私から一定のコミュニケーションの流れを見ており、私が彼らに提供するリソースを管理する必要があるので、私がすべてのことを行う理由を説明する必要があります。これは私の最初の機能仕様になります。私が言ったように、私はそれが大きくて役に立たないだけでなく、役に立つことを望んでいます。これはやらなければならないことだと思いますが、私や私のチームにとってもっと役立つ方法でやりたいです。マネージャーがいないのは悪いことなので、管理タスクにも注意が必要です... アジャイルプログラミングに関しては、これはアジャイルアプローチと100％互換性があると思います。私は自分自身をアジャイルプログラマです。正直に言って、誰かがすでに私のために考えているときは、自信がつきました。私はまだジュニアですが、以前は他のプロジェクトでタペストリーのWeb開発者として働いていました。 私は滝のアプローチをしていることに同意しません。開発が始まるときにプロジェクトをより簡単にするいくつかの境界を定義しようとしているだけだと思います。

9 java  project-management  specifications  projects-and-solutions 

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

8 project-management  requirements  specifications 

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

8 requirements  specifications