これはプログラミングに関するものではなく、プログラマー向けのパフォーマンス（技術仕様）の作成方法に関するものです。
ただし、プログラマーであり、その情報が有用であると思う場合は、もちろん、アナリストにいくつかの興味深いアイデアを伝えることができます。 :-)
だから、ソフトウェアの技術的なタスクを書く必要があると想像してください。
どうしますか？ きっと彼らは、システムの内部構造と機能を説明し始めますよね？
はい、全体的に。 しかし、悪魔はあなたが知っているように、詳細に隠れています...
通常、TKは機能の列挙です。システムはこれを実行する必要があります...、システムはこれを実行する必要があります...そのような特性を提供する必要があります...
しかし、その本質を理解しましょう。 実際の参照条件とは何ですか？..
少しアナリストになった後、画面上のボタンを押して空のウィンドウを開くという非常に簡単なことをプログラミングする必要があるプログラマーを想像してください。
質問してみましょう：プログラマはここで正確に何をプログラムしますか？
答えは明らかです。ウィンドウを開くようにアクションをプログラムします。 ユーザーのクリックに対するシステムの応答。
これが基本原則です。 プログラマーがプログラムしたものが何であれ、彼のすべてのタスクは、ユーザーのアクションに対するシステムの反応をプログラミングすることに減らすことができます。
ボタンをクリックするだけでなく、テキストフィールドへのデータ入力、マウスクリック、リスト選択なども可能です。
さらに、ロボットで何かを起動したり、他のシステムと情報を交換したりするなど、何らかの内部モジュールをプログラミングする場合でも、プログラマのタスクをこのような形式に減らすことができます。
つまり プログラマーにタスクを与える必要がある場合、技術的なタスクでは次のリストが最適であることがわかります。
- 作成されたインターフェースで可能なすべてのユーザーアクション
- システムの応答はユーザーの操作ではありません。
そのようなもの。
実際にプログラマはシステムインターフェイスをプログラムすることがわかります。 そして本質的に技術的なタスクは、主にインターフェースの説明でなければなりません。
インターフェイスの説明に基づいてTKをコンパイルする方法は、他の記事で説明する主な使用例です。
このようなアプローチは、ユースケース理論の古典- クレイグ・ラーマンとアリスター・コバーンによって一度に提案されました。彼らの作品は彼らと知り合う価値があります。
TKのインターフェイスを説明し、プログラマーに感謝するドキュメントを作成してください。