仕様のあいまいさをどのように解決しますか？

StackOverflow https://stackoverflow.com/questions/626737

  •  06-07-2019
  •  | 
  •  

質問

アプリケーション仕様のあいまいさを解決する方法について、いくつかのアドバイスが必要です。 簡単な例として、

  

ユーザーが何度も認証に失敗した場合、ITに通知を送信します。

上記の例では、「何度」「何回」です。 明確ではなく、1000回などのランダムな制限を単純に設定することはできません。

どのような仕様の不明確な部分を解決するにはどうしますか？ （私が言及したものだけでなく）

また、このような状況のGoogleや書籍を検索するには、どのようなトピックを検索する必要がありますか？ ソフトウェア工学？アジャイル開発？どこから始めればよいかわかりません。

有用なノウハウやヒントは大歓迎です。

役に立ちましたか？

解決

正式な方法で要件を追跡している場合は、仮定を立てて、派生要件として文書化できます。

例：

ユーザー要件：

要件1：ユーザーが何度も認証に失敗した場合、ITに通知を送信します。

派生要件：

Req 1.1ユーザーが3回試行しても認証に失敗すると、システムはアカウントを一時停止し、ITサポートデスクにメールを送信します。

Req 1.1.1アカウント停止のメールには次の内容が記載されています：

  • ユーザーのアカウント名。
  • 認証試行が行われたコンピューターのIPアドレス。

顧客、または顧客が利用できない場合は利害関係者に依頼し、派生した要件を確認して承認します。

詳細については、Googleの「要件管理」をご覧ください。または「要件エンジニアリング」。防衛産業部門には、例とテンプレートがロードされている、おそらく多すぎる;）

ブックマークしたもの：

他のヒント

あなたが持っているかもしれない正確な質問でクライアントに応答します。可能な場合、これが最良のオプションです。そうでない場合は、エンドユーザー（クライアント）が構成できるようにします。

（できればその順序で）通信する：

  • ビジネスアナリスト
  • クライアント（最終製品の代金を支払う人）
  • エンドユーザー

ビルドまたはプロトタイプを作成してから、仕様を書いた人に見せてください。

曖昧さは、物事がどのように機能するかを説明する紙片ではなく、実際のものについて話すことにより、はるかに簡単に解決できます。

これを考え過ぎています。

  1. 「回数」の値はweb.configに簡単に入れることができます
  2. 想定される適切な値に設定します。 （間違っていることを心配しないでください）
  3. あなたの仮定と、あなたの仮定が間違っている場合に彼らがそれをどのように変更できるかについて、あなたのマネージャーにメールを送ります。

他のすべてのアプリ通知が電子メール（非現実的ではない）である場合、仕様の通知部分を想定できます。それ以外の場合は、何かを行う前に確認してください。

もちろん、明確化を求めることに反対ではありません。しかし、ほとんどまたはまったく欠点がないで仮定を立てることができる場合は、そうするのが最善であることがわかりました。結局のところ、彼らは問題を解決するためにあなたを雇い、それ以上持ち込まないようにしています。 ;-)

そして奇妙なことに、とにかく、あなたの仮定のほとんどは正しいと思うでしょう。

その例から、クライアントに戻り、「回数」が必要かどうか尋ねます。設定可能になります。また、次のような質問につながる可能性があります。

1）構成された回数を誰が管理するか。 2）これらの設定を表示して変更するにはUIが必要ですか？

よりアジャイルな開発プロセスを採用することも役立ちます。たとえば、3回ログインすることを許可する例を示すと、機能が実証され、おそらく番号の入力を求めるプロンプトが表示されます。

要件を明確にすることの重要性は、質問への回答がプロジェクトの時間、複雑さ、およびコストに影響する場合に変わります。

利用可能な人に応じて、あいまいさを解決するいくつかの異なるルートがあります：

1）プロジェクトマネージャー/ビジネスアナリスト-＆gt;これらはおそらく、プロジェクトの最も近くにあり、仕様に関する問題を迅速に解決できる可能性があります。これには、他の人に尋ねて後で連絡することが含まれますが、それは許容できるはずです。

2）スペシャリストアナリスト/役員-＆gt;たとえば、セキュリティへの影響がある場所に言及した場合、それを実施するポリシーを持っている可能性があり、議論するべきセキュリティ担当者がいる場合。別の例としては、ネットワークアナリストにハードウェアの観点からアーキテクチャを見てもらうことがあります。これは場合によっては役立ちます。

3）プロダクトオーナー-＆gt;アプリケーションを定義する責任者。これは技術者ではないことに注意してください。したがって、「知っている、私はそれを考えていませんでした...」応答。

4）グループマネージャー/チームリード-＆gt;他のすべてが失敗した場合は、上司に行き、説明を求めます。

＆quot;要件の収集＆quot;または「要件分析」 「ソフトウェア開発ライフサイクル」のこの部分の一般的な用語です。または「システム開発ライフサイクル」さらにいくつかの用語を除外するには、検索して多くの記事を見つけます。

最良の方法は、さまざまなオプションがユーザーに与える影響を説明する簡単な代替ユーザーストーリー（ユースケース）を作成し、サポートする必要があるオプションを選択するよう顧客に依頼することです。

多くの場合、仕様のあいまいさは顧客の心の中のあいまいさを反映しています-彼らはまだ自分自身でそれを理解していないので、このアプローチはあなたの両方に役立ちます。 （それらの用語で物事を説明するために、書かれたメモを使用します-技術的なことはありません。）

仕様が正確でない場合、それは問題ではないのでしょうか？他の何かが機能するために重要ではありませんか？呼び出します。 を1000にします。ハードコーディングされていないことを確認します。構成ファイルに配置することをお勧めします（ただし、通常、ユーザーは自分よりもアイデアが少ないため、エンドユーザーインターフェイスには公開しません）。

それが相互運用性の問題である場合、他の人は何をしますか？ Windowsでは it 200ですか？ 200にするよりも、今ではWindowsとspecの両方に一致します&& 8212;＆nbsp;悪くない：-）

通話に問題があり、 it が1500だった場合、少なくともユーザーにソフトウェアを再インストールせずに修正する方法を伝えることができます。

企業では、これは一般的な企業ポリシーに従うことを意味します。

実際に自分で仕様を書くときは、これらの一般的な仕様に煩わされることはありません。単にポリシーを参照して、特定のビジネス要件の中核に直行するだけです。

そのために、フォーカスグループを作成するか、クライアント/適切な関係者と通信することができます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top