화면설계서
- 일반적으로 일본에서 업무하는 개발자라면 화면설계서라는 단어를 많이 들어볼거라고 생각합니다. 화면설계서란 기본적인 레이아웃과 그 기능, 그리고 API정보들을 작성한 일종의 기획서와 비슷하다고 보실수있습니다.
- 이전 프로젝트에서 설계서의 퀄리티가 매우 떨어지는 문제로 개발에 큰 어려움을 겪으면서 회사에서 설계서에 꼭 필요한 항목이 무엇인지에 대해 논의했고 그 내용을 정리한 포스트를 작성해보려고합니다.
- 해당내용은 단순히 이러한 방식으로 관리하는것이 편할것같다고 저희 회사에서 논의한 것으로 다른 좋은 방법이 있을수도있고 잘못된 방법일수도있습니다. 여러가지로 시행착오를 겪어가며 일하기 좋은 설계서를 작성하는 방법중 하나로 생각해주시면 좋을것같습니다.
- history
- 수정내역 기록
- 기본적으로 언제 누가 무엇을 수정했는지 남겨서 어떤 내용으로 변했는지 확인 가능하도록 수정
- 사이트맵
- 카테고리별 분리
- 화면의경우, 메뉴별로 어떤 화면이 어떤 화면과 이어져있는지 어떤 이벤트를 통해 화면이 이동되는지 확인할 수 있도록 작성할 것 ットで表示
- 아래 예의 경우, 점선은 화면전의, 선은 카테고리
- 일반적으로 화면전이도를 작성해서 알기쉽게 표현할 것
flowchart TB
classDef grey fill:grey, stroke:black, stroke-width:2px, color:white
r1(Project):::grey
r1--->h1(home)
r1--->r3(User)--->u1(login)-->p1(reset Password)
r3--->u2(join)
u1.->h1
p1.->u1
m1--->m4(紹介)
r1--->m1(明細)--->m2(生成)
m1--->m3(削除).->m4
m2.->m4

- 화면리스트
- 화면리스트를 한 페이지에 관리할 수 있도록함.
- 화면리스트에서 각 화면의 설계서로 이동하도록 작성하면 개발자가 확인하기 용이함
- 기능
- 플로우챠트
- user flow
- Logic Flow
- 조건별로 어떻게 이동되는지 이해하기 쉽도록 작성
- 화면에 따라 간단하다면 플로우차트를 작성하지 않아도 좋지만 복잡하다면 확인하기 쉽도록 작성할 것

- 정책
- 화면에서의 정책을 화면에 기록
- 복잡한 내용의 경우 따로 페이지를 작성하고 이동 링크 첨부
- 예
- 우편번호-hypen없음、공란은 에러
- 에러메세지표시⇨에러메세지만 관리하는 파일을 별도로 작성.(에러코드를 한번에 정리하기 쉽도록-> 이는 새로운 에러가 추가되거나 에러메시지가 변경될때 수정이 용이하다)
- 타임존규약
- 권한표시
- 레이아웃
- 화면UI、항목별로 번호를 붙여서 매칭하기 쉽도록 작성
- 기능명세
- 항목별로 맞춰서 구체적으로 작성
- 예
- 입력
- 버튼
- 버튼 활성, 비활성의 조건
- 버튼을 눌렀을때 어떤 이벤트가 발생하는지 작성
- 에러
- 각 에러에 대해서 어떻게 핸들링할것인지 작성
- エラーケース記入
- 制限条件
- 入力制限
- アップデートのファイル形式、サイズ、名前などの制限
- バリデーションチェック
-
シナリオ別に表示する。
-
例
- 必須
1 | ID | IDは必須項目です。 | IDのフィルードにCursor、赤い文字でメッセージ表示 |
---|
2 | Password | PWは必須項目です。 | PWのフィルードにCursor、赤い文字でメッセージ表示 |
- APIからのレスポンスと送るリスポンスに対して記入