問題タブ [requirements]

昨年のプロジェクトを今から見始めているので、仕様要件のドキュメントを作成しています。さて、このプロジェクトには高度な「使いやすさ」が必要です。これが英語で正しい単語かどうかはわかりませんが、ユーザーのPoVからは本当に使いやすいはずです。さて、これまで取り組んできたすべてのプロジェクトで、使いやすさはそれほど大きな要因ではなかったので、それを回避するためにちょっとしたことを書くことができました。私はいつも先生にユーザビリティの要件をどのように指定するか尋ねましたが、私が十分だと感じた答えはまだ誰も私に与えていません。

私たちの教師は、プロジェクトに与えられた要件はすべて「テスト可能」である必要があると常に説教してきましたが、ユーザーインターフェイスにどれだけ簡単にアクセスできるかをどのようにテストしますか？

リアルタイムアプリケーションを実行していたとしましょう。ここでは、「最初の呼び出しから100ミリ秒以内にエントリを削除する必要がある」と言うのは難しいことではありません。しかし、「ユーザーインターフェイスは86％直感的でなければならない」と言うのははるかに困難です。

これは難しいことだと思いますが、問題を抱えていることは言うまでもなく、私がこれについて考えた世界で最初の人になることはできません。

UI駆動開発のアイデアはまったく理にかなっていますか? ほとんどのクライアントは、要件を画面の形で伝えることを好みます。たとえば、これとあれを行う画面が必要です。場合によっては、画面のレイアウトを自分で決定することさえあります (これは、今日のクライアントがほとんどのタスクで既にソフトウェア アプリケーションを使用しているためかもしれません)。

また、この要件収集の方法は、データと関連する動作の両方を自動的に伝達するようです。

皆さんはどう思いますか？

私たちのクライアントは、ソフトウェア要件を収集するための Web ベースのリッチ インターネット アプリケーションを構築することを望んでいます。基本的には、利害関係者から要件を取得するための特定のプロセスに従う Web ベースのケース ツールです。私はプロジェクト マネージャーで、まだプロジェクトの初期段階にあります。

クライアントと開発者の両方にとってツールの要件を明確にするために、形式的な方法を使用することを考えていました。正式な方法とは、何らかの形のモデリング、おそらく数学に基づくものを意味します。Z ( http://en.wikipedia.org/wiki/Z_notation )、ステート マシン、UML 2.0 (おそらくOCLなどの拡張機能を使用)、ペトリ ネット、およびいくつかのコーディングについて読んだことがあり、検討していることもあります。契約や前後の条件などのレベルのもの。他に考慮すべきことはありますか？

開発者は経験豊富ですが、使用する形式によっては、数学を学ぶ必要がある場合があります。

このプロジェクトで形式的な方法を使用する価値があるかどうか、もしそうならどの程度の価値があるかを判断しようとしています。私は「場合による」ことを知っているので、私にとって最も役立つ答えは、はい/いいえとそれを裏付ける議論です。

あなたがこのプロジェクトに参加した場合、正式な方法を使用しますか?

投票システムが組み込まれた要件収集ツールはありますか? 土地の法則は、最後にレビューした人が最終決定権を持っているため、分類の使用はうまく機能していません。これは、プロジェクトの要求段階で意見の相違を解決するために提案された解決策です。 委員会による設計はよく知られたアンチパターンです。あると便利なものとして分類し、特定の要件が持つ価値の欠如を他の人が認識する機会を提供する標準的な「トリック」があります。残念ながら、民主的な決定プロセスを許可するという要求は、拒否するにはあまりにも合理的であるように思われます。

医療アプリケーションのコーディング要件について調査していますが、有用で構造化されたものが見つかりません。基本的に、セキュリティ要件のリストを含む構造化された（可能であればXMLファイルの）ドキュメントを探しています。たとえば、使用する暗号化の種類、アプリのどの機能をデフォルトで無効にするか、どのログ情報を保存するか、どのように保存するかなどです。

もちろん、要件はアプリや会社によって異なる可能性があります。必要なのは一般的な情報だけで、可能であれば米国の場合です。

ASP.NET MVCにはIISが必要ですか？IISがインストールされていないクライアントマシンで新しいASP.NETMVCフレームワークを使用するアプリケーションを開発できますか？

現在よりも正式な要件とテスト手順を確立しようとしていますが、関連するドキュメントの適切な参照例が見つかりません。

現時点では、機能フリーズテスターが展開前に「アプリケーションをクリックして」実行した後、テストする必要のある正式な仕様はありません。

まず、テストする必要のあるすべての機能を指定するドキュメントについて考えています。これは次のようなものです（これを構成します）。

1. ユーザー登録フォーム
   1. 国のドロップダウン（国はサーバーから正しくフェッチされていますか？）
   2. パスワードの検証（すべてのパスワードルールが守られていますか？パスワードが弱すぎる場合はユーザーに通知されますか？）
2. 登録ありがとうございます

...等々。これは、プログラマーがコーディングを開始する前に、クライアントが要件の一部として署名できるものとしても機能する可能性があります。機能リストが完成したら、このリストをスプレッドシートの最初の列にして、機能が最後にテストされたのはいつか、機能したか、機能しなかった場合はどのように壊れたかを示すことを考えています。これにより、テスターが各テストサイクルの後に記入できるドキュメントが得られるので、プログラマーは、何が機能せず、いつ壊れたかについての情報を含む、やることリストを作成する必要があります。

次に、次のような詳細な手順で、テスターのテストケースを考えています。

1. ユーザー登録フォームをロードします。
2. （機能1.1）国のドロップダウンメニューを確認します。
   1. 国のドロップダウンには国が表示されていますか？
   2. 国の名前はローカライズされていますか？
   3. 言語ごとにソート順は正しいですか？
3. （機能1.2）次のパスワードを入力します： "a"、 "bob"、 "password"、 "password123"、 "password123＃"。最後のパスワードのみを受け入れる必要があります。
4. 「OK」を押します。
5. （特徴2）お礼状を確認してください。
   1. テキストはサポートされているすべての言語にローカライズされていますか？

これにより、テスターに​​特定のケースとチェックリストを提供し、最初のドキュメントの機能へのポインターを示します。これにより、テストプロセスの自動化を開始することもできます（現在、単体テスト以外のテスト自動化はあまりありません）。

あまり事務処理をせずに、他の人がこれをどのように行ったかの例を探しています。通常、テスターは1〜2時間ですべてのテストを実行できる必要があります。次のバージョンでどの機能を実装するかについてクライアントに同意させ、テスターがすべての新機能が実装され、既存のすべての機能が機能していることを確認し、プログラマーに報告する簡単な方法を探しています。

これは主に内部テスト資料であり、Word/Excelドキュメントのカップルである必要があります。1回のテスト/バグ修正サイクルを2日以内に維持しようとしています。プログラミング時間、新機能の実装、他の方法での顧客チケット（JIRA）を追跡しています。これは、基本的にドキュメントのテストになります。これは私が念頭に置いていたライフサイクルです。

1. PMは機能のリストを作成します。顧客はそれに署名します。（ドキュメント1が作成されます。）
2. テストケースが作成されます。（ドキュメント2）
3. プログラマーは機能を実装します。
4. テスターは、テストケースに従って機能をテストします。（そして、ドキュメント1を通じてバグを報告してください。）
5. プログラマーはバグを修正します。
6. すべてのバグが修正されるまでGOTO4。
7. 内部テストの終了。製品は顧客に示されます。

テストケースを含むいくつかのサンプルドキュメントを見つけることができる場所へのポインタを誰かが持っていますか？また、上記で概説したプロセスに関するすべてのヒントを歓迎します。:)

機能仕様を開発するための共同ツールを探していました。私は次の能力を探しています：

• 複数のユーザーに仕様に貢献してもらいます。
• 何らかの形式のトレーサビリティを提供します。これは、必要に応じて手動で行うことができます。
• ユーザーがコメントやメモを追加できるようにします。
• Visio ドキュメントをアップロードして表示する
• Balsamiq Mockup を使用してモックアップ画面をアップロードして表示します。

私の最初の印象は、wiki を使用すると、このタスクに適したツールになる可能性があるということです。wiki を使用して機能仕様を作成した経験のある人はいますか? 要件管理ツールとは対照的に、このようなツールを使用することの長所と短所は何ですか?

ご意見をお待ちしております。

ソフトウェア システムの実装を終えたばかりで、要件を満たしているかどうかを文書化する必要があります。どのような情報を含め、どのようにレイアウトすればよいですか?

私の最初の機能要件と非機能要件は、2 列の表にあり、次のようなものでした。

• FN-01 システムは、ユーザーが互いにプライベート メッセージを送信できるようにする必要があります。
• NFN-03 セットアップ/構成フォームには、ほとんどのフィールドで適切なデフォルト値が含まれている必要があります。

多くの組み込みアプリケーションでは、コードを非常に効率的にするか、特定のシステム構成からコードを分離して要件の変化の影響を受けないようにするかのトレードオフがあります。

両方の長所 (効率を損なうことなく柔軟性と再構成可能性) を実現するために、通常どのような種類の C コンストラクトを採用していますか?

時間があれば、私が話していることを正確に理解するために読んでください。

私がエアバッグ コントローラー用の組み込み SW を開発していたとき、特定の要件に関して顧客が気が変わるたびに、コードの一部を変更しなければならないという問題がありました。たとえば、エアバッグの展開をトリガーする条件とイベントの組み合わせは、開発中に数週間ごとに変更されました。そのコードを頻繁に変更するのは嫌でした。

当時、私は組み込みシステム カンファレンスに出席し、Stephen Mellor 氏による「変化する要件への対応」という素晴らしいプレゼンテーションを聞きました。ここで論文を読むことができます(サインアップする必要がありますが、無料です)。

これの主なアイデアは、コアの動作をコードに実装し、特定の詳細をデータの形式で構成することでした。データは簡単に変更できるものであり、EEPROM またはフラッシュの別のセクションでプログラムすることもできます。

このアイデアは、私たちの問題を解決するのに最適です。私はこれを同僚と共有し、すぐに SW モジュールの一部を作り直しました。

このアイデアをコーディングで使用しようとすると、実際の実装でいくつかの問題が発生しました。私たちのコード構成は、制約のある組み込みシステムにとって非常に重く複雑になりました。

これを説明するために、前述の例について詳しく説明します。入力の組み合わせがエアバッグの展開を必要とする状態にあるかどうかを判断するための多数の if ステートメントを使用する代わりに、テーブルの大きなテーブルに変更しました。いくつかの条件は自明ではなかったため、多くの関数ポインタを使用して、いくつかの条件を何らかの方法で解決する多くの小さなヘルパー関数を呼び出せるようにしました。いくつかのレベルの間接化があり、すべてが理解しにくくなりました。簡単に言うと、大量のメモリ、ランタイム、コードの複雑さを使用することになりました。物事のデバッグも簡単ではありませんでした。モジュールが重くなりすぎたので、上司は私たちにいくつかの変更を加えました (そして彼はおそらく正しかったでしょう!)。

PS: SO にも同様の質問がありますが、焦点が異なるようです。変化するビジネス要件を満たすために適応していますか?