2023.06.30 107일차 Team Project 요구사항명세서, 화면목록

107일차

요구사항 명세서 작성

참고한 블로그
https://mklab-co.medium.com/%EC%9E%91%EC%84%B1%EB%B2%95-%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD-%EB%AA%85%EC%84%B8%EC%84%9C-requirements-specification-ad3533d6d5b8

서비스를 구현하기 위해 다양한 요구사항이 거론되는데, 이를 명확하게 정리해야 할 필요가 있다.
요구사항 명세서는 요구사항을 분석하여 명확하고 완전하게 기록하는 것을 말한다.
소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자가 합의한 스펙에 대한 사항을 기록한다.

요구사항 명세서(SRS, Software Requirements Specification)은 요구사항 정의서, 요구사항 기술서도 같은 의미로 봐도 무방하다고 한다.

1. 왜 작성하는가?

작성된 요구사항 명세서를 토대로 회의가 진행된다.
실제 필요한 기능인지, 개발 이슈는 없는지, 이번 단계(버전)에서 개발하는 것이 좋은 것인지에 대해 검토한다.
피드백된 내용 또한 업데이트하여 관리해야한다.

프로젝트 전체 규모를 파악
구현 가능 여부에 대한 논의
커뮤니케이션 비용 절약
프로젝트 일정 계획 수립 등의 역할을 한다.

2. 어떤것을 작성해야하는가?

요구사항 명세서는 공식적으로 사용하는 양식은 없지만 필수로 기재 해야 하는 항목은 대게 유사하다.

2.1 ID

식별자를 부여한다. 하나의 요구사항에 하나의 요구사항에 하나의 식별자를 준다.

2.2 화면명

어느 화면에서 구현할 기능인지를 정한다. 화면에 속하지 않는 요구사항도 있을 수 있다.

2.3 요구사항명

요구사항의 설명을 요약하여 기재한다.

2.4 내용

요구사항의 상세한 내용을 기재한다.

기타

중요도, 부서및 작성자, 날짜 등을 작성할 수 있다.

3. 요구사항 명세서에서 필요한것

요구사항 명세서를 읽는 작업자가 이해하기 쉬워야 한다.
무엇을 어떻게 구현되어야 하는지 명확하게 작성한다.
하나의 요구사항에 여러가지(복수) 요구사항을 작성하지 않는다.
다른 요구사항 모순 또는 중복되지 않게 한다.
애매한 단어를 사용하지 않고 명확하게 기재한다.
꼭 필요하고 중요한 요구사항은 표시하는 것이 좋다. 다만 모든 요구사항에 남발 해서는 안된다.
동일한 용어를 사용한다. 댓글, 코멘트, 덧글과 같이 모두 같은 의미를 다르게 표현하면 안된다.
난이도가 있는 기능이거나 프로젝트 기간이 짧아 모든 요구사항을 구현하기 어려울 상황일 경우, 대체 가능한 다른 방법도 함께 기술하여 전달하는 것이 좋다.

화면 설계서

화면설계서란 제품을 개발하기 위해서 제품 설계도면을 만들듯이 사용자를 기준으로 화면단위로 작성하게 된다.
실제 작업자가 아닌 관계자도 화면설계서로 이해할 수 있다.

즉 화면설계서란 건축에서의 청사진과 다르게 없다.
웹페이지 및 앱의 윤곽을 2차원으로 보여주는 것이다. 이는 페이지의 구조 레이아웃 정보구조 유저플로우 기능 의도된 동작에 대한 명확한 개요를 제공한다.
일반적으로 화면설계서는 제품의 초기 컨셉을 표현하는 것이기 때문에 스타일 컬러 그래픽 등이 최소한으로 유지된다.

화면설계서를 만드는 목적

1.사용자 초점에 맞춘 컨셉 유지
화면설계서는 사용자가 인터페이스와 어떻게 상호작용할지를 측정할 수 있는 것이다.

2.웹사이트의 특징 분명하게 정의하기
화면설계서를 활용하면 각각의 기능들에게 필요한 공간이 어느정도인지 사이트의 정보구조를 시각적인 디자인에 어떻게 연결해야하는지 페이지의 기능을 어떻게 하면 선명하게 보여 줄 수 있는지에 대해서 생각해볼 수 있다. 이처럼 모든 기능이 어떻게 동작하는지를 명확하게 시각적으로 확인할 수 있게 되면 방향성과 맞지 않는 불필요한 요소인지 아닌지의 여부를 판다하기 쉬워진다.

다음은 우리팀에서 작성한 화면설계서의 예시이다.

화면목록

모든 화면을 리스트로 정리한 문서이다. 각각의 화면들은 기획-디자인-퍼블리싱-개발작업의 기준이 된다.
따라서 중복되지 않는 고유의 화면명과 ID값을 갖고 작업자들에게 공유된다.

실제로 내가 작성한 화면목록이다.

Depth로 구성하여 화면목록 메뉴에 따라서 구분한다.
화면Id는 수많은 화면을 구분하기 위해 부여한다.
중복되지 않도록 작성해야한다.

2023.06.30

기타 등등 많은 회의와 시간을 거쳐 맏늘어나가고 있다.
회의를 하면서 하나씩 만들어지고 있다.
이런 점에서 느낀점은 지난번 프로젝트를 매우 주먹구구식으로 진행했다는 것이다.

현재 이 새 프로젝트는 기한이 길지 않기때문에 급하게 진행되고 있지만
실무에서도 이런 과정을 거친다고 하신다.
요구사항을 정의하고 화면을 설계하고 목록을짜고 erd를 설계한다.
충분한 구성이 진행되어야 개발시에 문제가 덜 발생하게 된다.

실무에서의 방법을 멘토링을 통해서 배우니 확실히 배울점이 있다.