pulpul 日本の試験

システムアーキテクト 概念書 · システム開発・アーキテクチャ

問合せ管理と通知機能の設計

問合せ管理と通知機能の設計とは、顧客からの問合せや業務上の出来事を登録・追跡し、関係者へ確実に知らせるための機能を定義する作業である。通知は利用者の安心や業務の正確さに直結するため、通知の契機、送信失敗時の扱い、状態の管理、既存機能の変更による影響を設計段階で明確にする必要がある。以下では、この順に整理する。

通知の契機と送信内容

通知機能は、業務上のイベントを契機として自動的に発生させる。学習塾の通知システムでは、生徒が塾に到着したときと塾を退出したときに、保護者へ電子メールで登校・下校を知らせる。 イベントの発生条件が曖昧なまま設計すると、同じ出来事で二重に通知したり、本来送るべき通知が漏れたりする。したがって、どの状態の変化をイベントとみなすかを一つずつ定義することが基本になる。

送信失敗時の扱いと例外への対応

メールの送信に失敗した場合に備えて、メール送信エラー通知機能を設けることがある。 この機能で関係者へ知らせるためには、どの拠点の、どの生徒に関する通知が失敗したかを特定できなければならない。通知すべき拠点を特定できない場合は、失敗した送信の記録と拠点の対応付けが不足していないかを点検する必要がある。

既存機能で対応できる範囲には限界がある。登下校代理登録機能では実現できない要望を整理することは、既存機能の限界を明らかにする作業である。 その要望が業務上不可欠であれば、既存機能の拡張か新たな機能の追加を検討することになる。

既存機能の変更と影響範囲

既存の機能を変更する場合は、変更する機能名と変更内容を明確にし、他の機能へ与える影響を確認しなければならない。 例えば、通知の対象を一部だけ変えると、同じ通知の仕組みを利用している別の機能の動作が変わる恐れがある。変更の懸念を評価する際は、変更箇所だけでなく、その機能を呼び出す側と参照する側を見て、悪影響を具体的に洗い出すことが求められる。

オンラインの申込では、確定操作の時点で残席数を正しく判定しないと、定員を超過する申込を受け付けてしまうことがある。 判定のタイミングと申込の登録の順序を設計で明確にすることが、この種の不整合を防ぐ要点である。

この節の続き

ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。

アプリでこの節を読む