2023. 2. 3. 22:06ㆍ카테고리 없음
1) 시나리오
기술 명세는 사용자 관점에서 시스템을 바라본 것이므로, 이를 가장 잘 기술하는 방법은 실제 사용자를 가정하고 시스템을 어떻게 쓸 것인지 시나리오를 작성해 보는 것이다. 예를 들어, 온라인 영어 학습 사이트에 대한 기술 명세를 쓴다고 하면, 성적은 중위권이며 방과 후에 PC방에서 게임하는 것이 취미인 15살 박 모 군과 같이 구체적인 인물을 설정하고, 이런 인물이 영어 학습 시스템을 사용할 때 어떤 패턴을 보일 것인지를 기술하는 것이 효과적이다.
이때 시나리오는 유스 케이스(Use Case)가 될 수도 있고, 조금 더 단순화된 형태인 유저 시나리오(User Scenario)가 될 수도 있다. 소프트웨어 방법론이나 프로젝트의 성격에 따라 어떤 방식을 선택해도 무방하다. 하지만 원칙은 시스템의 모든 기능을 한 번 이상을 이용할 수 있도록 충분히 많은 시나리오를 작성해서, 개발자가 시스템을 설계할 때 전혀 고려된 적이 없는 상황을 마주치는 일이 생기지 않도록 해야한다.
기능 명세의 시나리오는 무엇을 테스트해야할지 단서를 제공한다는 측면에서 소프트웨어 테스트나 품질보증(Quality Assurance, QA) 팀에게도 소중한 문서이다. 특히 시스템의 기능 테스트(Functional Test)는 유저 시나리오에 바탕을 뒀을 때 가장 효과적이다. 유저 시나리오는 최종 제품이 원래 요구사항에 기술된 요소를 모두 충족시켰는지를 판단하는 중요한 근거가 되기 때문이다.
2)세부사항
기능 명세를 작성함에 있어서는 세부사항이 무척 중요하다. 특히, 무엇인가 잘못될 수 있는 경우 모든 가능성에 대해서 꼼꼼히 명세를 작성해야 한다. 예를 들어, 전자상거래 웹페이지의 로긴 페이지를 만든다고 한다면 다음과 같은 이슈를 모두 고민해야 한다.
1)등록되지 않는 ID로 로긴한 경우
2) 등록된 ID지만 패스워드가 틀린 경우
3) 같은 ID에 3번 이상 다른 패스워드를 입력했을 경우 추가적인 로그인 시도를 금지할 것인가?
4) 아이디와 패스워드를 잃어버린 사람이 이를 되찾는 방법은?
5) 패스워드 관련 힌트를 제공할 것인가?
6) 한 번 로긴한 후에는 얼마나 오래 세션이 지속되는가?
세부사항을 작성할 때, UI를 중심으로 기능을 기술하는 것이 가장 효과적이다. 특히, 웹개발의 경우 각각의 페이지를 기준으로 소프트웨어가 어떻게 동작하는지 설명하는 방법이 일반적이다. 모든 페이지에 고유의 이름을 붙이고, 각 페이지에서 나오는 메뉴와 UI 위젯이 어떤 역할을 하는지 구체적으로 기술한다.
3) 열린 이슈
명세를 작성하는 목적은 프로젝트 시작 전에 최대한 많은 요구사항을 끌어내고 최종 산출물의 모습을 파악하는데 있지만, 필연적으로 일부 문제들은 미해결 상태로 남아있게 된다. 이런 부분은 기능 명세에 분명히 기술하여 프로젝트가 진행되면서 나가야 한다.
4) 변경 추적
기능 명세뿐만 아니라 모든 개발 관련 문서의 생명은 얼마나 변경 추적이 잘 되느냐에 달려 있다. 명세와 관련된 가장 큰 불만은 명세를 작성한 이후 프로젝트의 요구사항이 변화하고 설계 및 코드에 수정이 일어남에도 불구하고 명세가 갱신되지 않는다는데 있다. 따라서 개발자들을 비롯해 이해 관계자들은 명세를 신뢰하지 않고, 쓸모없다고 생각하게 된다.
특히 요구사항 분석, 설계, 구현, 테스트, 유지 보수를 한 번씩만 거치는 폭포수 모델(Waterfall Model)을 따르는 조직일수록 이런 경향이 강하게 나타난다. 요구사항 분석은 프로젝트 초기에 단 한번만 이루어지며, 이후 설계나 구현은 요구사항 변경 요청 시에 수정되지만 정작 요구사항 문서는 그대로 남는 경우이다. 이런 조직에서는 시간이 지날수록 기능 명세를 비롯한 요구사항 문서의 질은 극도로 낮아지며 유지 보수 단계에서는 누구도 기능 명세를 보지 않는 상황이 벌어진다.