設計 - daisuke suzuki's project

設計

人間のやりたいことを動くソフトウェアとして実装する方法を考えること

ヒト/モノ/コトに分けて分析する

ヒト: 個人、企業など

意思をがある

判断する

行動する

モノ: ヒトが業務を遂行するときの関心の対象

物理的なモノ

権利や義務のような概念

コト: 業務活動で生じる事象

対象: 何について発生した事象か

種別: どういう種類の事象か

時点: いつ起きた事象か

要求

ユーザからヒアリングして要求を集める

クライアント・ユーザが求めるもの・こと

解決したい課題

https://www.ipa.go.jp/files/000045530.pdf

https://backlog.com/ja/blog/what-is-project-requirements-definition/

https://www.geekly.co.jp/column/cat-technology/1903_059/

要件定義

必要な条件を明確にすること

要件定義フェーズでの成果物がクライアントに提出するものになるので、専門知識がなくても読めなくてはならない

クライアントのイメージとすり合わせる

作りたい(作って欲しい)システム・機能を定義する

成果物をイメージできる

エラーまで想定して書く

全体像から細部まで書く

業務要件

現状の業務を分析し問題を抽出する

新たに何を実現すべきかを考える

業務上の要望

システム要件

システム開発の方向性

システムかを通じてできること

機能要件

クライアントが求めている機能

システムを実装することで何ができるようになるのか

非機能要件

機能面以外で求めること

性能や効率性、セキュリティなど

要件定義とシステム仕様が厳密に定義されていて、設計段階で抽象化がされている事で、実装時に再度定義し直さなくて済む

考え方プログラムするものを抽象的に考える

システム仕様は、ユーザ起点ではないができないといけないシステム都合の話バッチとか認証とか

調べて理解したこと

仕様作成の流れ

要件定義→仕様作成→設計の流れ

要件定義の目的

クライアントやユーザからの要求を、どのようにして叶えるかを文章にまとめる

成果物をイメージできるよう要求を文章に落とし込む

要件定義フェーズで何をおこなうのか