要件のトレーサビリティと実現仕様への落とし込み

on


とあるレビューでにこやかに要件をシステム方式として紐付しているか、要件の紐付忘れがないか、システム方式を選択する根拠の確からしさを設計書に落とし込んで欲しい、とコメントが付いて、「あーコメントはごもっとも。」と昔に同じことを思ったことを思い出したのです。


業務要件があって、それから業務要件とシステム要件に整理されてシステム要件がITの機能として実装されることになるわけです。そのITの機能として実現される予定のシステム要件がシステム方式から漏れてしまったら、要件の道筋は途絶えることになるので、そのレビューアはそこを心配しているのでしょう。


ITのシステム方式の選択も、要件に対してどのような機能でそれを実現するかもそのもととなるシステム要件の漏れを防止するうえで欠かすことのできない観点です。折角、システム要件からそれを実現するシステム方式につなげても、そのシステム要件で期待されている要件をシステム方式で機能をシステムを開発する都合で分解していると分解したときに重複や抜け漏れがないことを押さえていないとシステム要件がその分解して再構成されて実装するITのしくみでは実現されない、ということになるからです。


業務をIT化するというとき、今どきは、何等かしかのパッケージソフトウェアが入るもので、アプリだといってもフレームワークは使うでしょうからエンタープライズのシステムならフルスクラッチは稀有ではないかと思います。そうであれば、システム要件からシステム方式に機能分解してその機能をパッケージなどで機能を実現する場合、そのパッケージがもともと持つフル機能をすべて使うことはないでしょうから、そこでもシステム要件に対する適用予定のパッケージの機能を並べて、度の機能がシステム要件と結びついて、他の機能はシステム要件と紐づかないから使用しない、としておかないと誤って余計な機能やサービスを動かしてしまう可能性があります。


それもやっぱり、システム要件と紐づけてあれば、動かす機能と動かさない機能を判別することが所謂上流設計の工程でできるのでそういった観点での整理は必要なのではないか、と思うのです。別の観点で言うとするなら、上流で動かす動かさない機能を判別してしまうので、使うか使わないのかわからない状態で後続工程を進めるリスクとムダを省くことができるのです。