시나리오와 화면 정의서

개발 방법론을 학습하다 보면, 모든 것의 기본은 시나리오라는 생각을 갖게 된다.
잘 쓰인 시나리오는 단어를 뽑아 냄으로써, 용어 사전이 되고,
이를 규칙에 맞게 정리하면 테이블 정의서가 된다.
또, 항목별로 정리하면 요구정의서가 되고, 화면으로 정리하면 화면 정의서가 된다.
이렇게 나온 각종 정의서들은 설계 단계와 코딩 단계에 참조가 되고, 마지막 테스트 단계에선 평가의 기준이 된다.

근데 시나리오보다, 글 보다 이미지가 더 전달력이 강력하다는 생각때문에 화면 정의서가 시나리오를 대신하게 된다.
시나리오에 화면 정의서가 부가 되는 것이 아니라, 시나리오는 없고, 화면 정의서만 남는다.
그나마 화면 정의서의 여기저기에 설명들이 달려 있으면 다행이지만, 정말 화면들만 있는 화면 정의서는 대응하기 힘들다.

일의 시작인 전체적인 업무의 흐름을 화면들만 보고 이해해야 한다는 점에서 오해의 소지가 크다.
그보다 더 중요하게는 운이 좋아 업무 흐름은 제대로 이해해도 왜 그렇게 해야 하는지 알기가 쉽지 않다.
따라서 설계 단계에서 새로운 아이디어를 반영할, 의도에 더 충실한 설계를 할 기회는 영영 없어지고 마는 것이다.

정말 화면 정의서에 따라, 의도는 제쳐두고 작동하게 만드는 것이 지상과제가 되고,
의도가 조금만 바뀌어도, 의도에 따른 기획이 조금만 바뀌어도 많은 것을 수정해야 하는 상황이 된다.

화면 정의서는 분명 시나리오에서 나오는 것이고, 시나리오에 부가적으로 덧붙이는 것이지 시나리오를 대체하는 것이 아니다.
이미지의 힘에 현혹되어 글의 힘을 하찮게 보는 실수를 범해서는 안될 것이다.