7．画面設計（ﾃﾞｰﾀ項目、機能など）

◆作業の概要、目的、タイミング

各画面について、レイアウト等とあわせて機能（動的な部分、内部的な動き方：プログラミングが必要な部分）の  
詳細を検討し、定義する。
  • メニュー体系で意識したこと（画面の動き、エラー・システムメッセージの扱いなど）を再度確認する。
  • 各画面の各機能（「各ボタン」と言ってもいい）で具体的にどんな動きをするのかを説明する。
複数画面間にまたがる機能やバッチ的な処理など、（特定の画面に属さないものでも）システムで必要な機能を洗い出して  
その詳細を検討し、具体的にどんな動きをするのかを定義する。  

ここでの定義内容は、（ユーザが見るというよりは）この後の製造担当者が見て、プログラム製造に必要な情報を得るところとなる。
  • ユーザから見た表面的な動き（外部設計レベル）だけでなく、画面制御やＤＢアクセス、プログラム的な計算処理の方法などの内部的な動き（詳細設計レベル）についても検討する。
  • 定義内容が甘いと、プログラマーが何をどう作っていいか分からなかったり、勝手な解釈で作ってしまって本来の仕様とズレていったり、各画面がバラバラの動きになって全体が統一されなかったりする。

◆事前に必要なもの、情報

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

この前の作業 事前情報、他
・メニュー体系図
・共通デザイン定義
・各画面設計書（レイアウト他）		 ・ヒアリングで得た情報
・一般的な／最新の業界・技術情報
・対象システムの業務知識
・技術知識（マシン、ソフト、プログラム言語）
・製造時に使う開発ツール・プログラム言語の知識

◆具体的な作業項目、手順

画面上に配置されるデータ項目について定義する。　　
画面作成時、画面制御のプログラム製造時（入力チェック、自動表示など）、あるいはデータベース設計時などの情報となる。
  1. 主に、ユーザが入力・選択をする部分、システムで自動的に表示する部分を抽出する。
  2. それぞれ、主に以下のようなことを定義する。
    • ユーザの入力・選択部分に対して
      インターフェースの種類（テキストボックス、チェックボックスなど）、入力必須かどうか、入力値の最大数、入力値の制限、初期値など
    • システムで自動表示する部分に対して
      どのデータをもとに、それをどう加工して、どう表示するか
    • 前の画面の情報を、次の画面に引き継ぐ
      何画面のどの項目を、（次に表示される）何画面のどこの部分に、（どう加工して）表示するか
入出力項目での、主な定義項目
  • 項目名、内容
    開発環境や使用する技術要素によっては、オブジェクト名なども必要となる。
  • 種類
    テキストボックス、チェックボックス、コンボボックスなど。開発環境や使用する技術要素によって、使える種類や名称が異なる。
  • データ種類
    文字（半角英数、全角など）、数値、日付、．．．
  • 桁数
    表示／入力する最大桁数。
    固定項目の表示の場合は、特に定義する必要はない。
  • デフォルト値
    入力項目などで、あらかじめ選択／表示させておく初期値。
  • 必須属性
    入力項目などで、必ず入力／選択されなければならない項目かどうか。
  • 選択肢
    選択項目などの選択肢。データベースや別ファイルから値を取得する場合、そのデータ元。
  • データ元、計算方式
    データベースや別ファイル、別画面から取得した値や、別のデータからの計算値を表示する場合、そのデータ元、計算方式。
  • 表示形式
    日付の場合："yyyy/mm/dd"（年は西暦4桁、月は2桁、日は2桁で、 "/" で区切る）、など
    数値の場合："000"（3桁表示で、1桁・2桁の数値の場合、空いた部分は"0"表記）、など
    開発環境や使用する技術要素によって、書き方などが異なる。
  • フォント、フォントサイズ、色などが、統一されている共通デザインと異なる場合は必ず個別に定義する。
何かしらの機能を実行するボタンや画面遷移時など、プログラム的な動きを定義する。
プログラム製造時、あるいはテスト項目作成時などの情報となる。
  1. プログラミングが必要な部分を特定する。
    • ユーザ入力部分、ボタン、自動的に変化する部分、画面遷移時（で、特に何かする場合）、．．．
  2. それぞれの箇所について、具体的な動きを細かく説明する。（文章、またはフローで）データの変化、画面上の変化に着目する。
    • どんなデータに対して（入力）、どう計算・加工し（処理）、どう表示するか（出力）。
    • データベースやファイルとの読み書きがある場合、どのデータベース（ファイル、テーブル）のどのデータ項目をどう使うか、についても定義する。
  3. 基本の動きだけでなく、エラー時の処理も定義する。
    • 入力チェック：どのデータをどうチェックし、どう判断し、どんな対応（メッセージ等）をするか（データ項目の定義、またはＤＢ定義を参考にする）
      • 必須項目が入力されているかどうか
      • 入力されるものが決まっている場合（数値、日付など）、その通りのものが入力されているか
      • 入力データ範囲が決まっている場合（数値や日付の上限・下限、最大文字数など）、適切な範囲か
      • エラーメッセージをするかどうか、する場合はそのメッセージ内容
      • メッセージ表示後の処理
      • （データ項目の定義、またはＤＢ定義を参考にする）
    • 処理中などの確認メッセージ、処理終了時などの通知メッセージ、エラー時などのエラーメッセージなども定義する。
      • メッセージ表示のタイミング
      • メッセージ内容
      • メッセージ表示後の処理（OK／Cancelで違う場合など、それぞれ定義）

定義内容を、各画面設計書に書き加える。または、「機能設計」として独立させる。

◆成果物、最終イメージ、作業例

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

成果物、完成イメージ、他 この後の作業
・画面設計書 ・設計書の全体調整

◆作業上のポイント、注意点

プログラマーが、見ればプログラムできる状態まで定義する。
  • 「どうプログラムするか」をイメージし、そのために必要な情報を書き出す。
目に見える部分については、ユーザの確認が必要となる。
  • どこに何を入力すると、どこがどうなるか
  • メッセージなどの文言
技術的に難しそうな部分は、必ず事前に検証する。
  • 書籍やネットで調べるだけでなく、できればミニプログラムを作って、試す。
  • できないことを「やる」と言って、ほんとにできないと、後で自分が困る。

Copyright © Xincor miXell Co., Ltd. All rights reserved

results matching ""

    No results matching ""