BLOG main image
24,456 Visitors up to today!
Today 0 hit, Yesterday 0 hit

2007.01.10 09:38, 생각하기..

소프트웨어 요구사항 명세는 누구나 해야 한다는 사실은 알지만 아무도 잘하지 못하는 일 중 하나다. 전통 소프트웨어 공학이나 XP나 애자일이나 요구사항 명세는 빠짐없이 등장한다. 하지만, 요구사항을 명세하는 세부 실천 방법은 저마다 차이가 있다. 오늘은 요구사항 명세에 대한 얘기를 해보자.

나는 휴대폰에 들어갈 카메라, 캠코더, 미디어 플레이어와 같은 멀티미디어 어플리케이션 개발을 위한 멀티미디어 프레임워크를 만드는 일을 진행 중이다. 요구사항 분석을 위해 나는 각 개발실로부터 기존에 작성된 요구사항 명세서를 요청했다. 그를 통해 내가 받은 요구명세서는 90% 이상은 파워포인트로 작성된 화면 설계서였다. 그나마도 실제 제품 기능이 다 들어있는 문서는 단 한 건도 없었다. 심지어는 설계 문서나 API를 보내온 곳도 있었다. 물론 문서화가 안되어 있다고 해서 각 개발실의 개발 능력을 의심하는 것은 아니다. 그들은 지금까지 훌륭한 제품들을 많이 만들어왔고 앞으로도 그럴 것이다. 다만, 소프트웨어 전문 조직으로 각 개발실이 사용할 부품을 만들고 있는 입장에서 각 개발실은 나의 고객이라 할 수 있다. 고객에게 제품을 인도할 때 그들이 늘어놓는 푸념 중의 하나는 제품이 '우리의 요구사항을 다 반영하지 못하고 있어요!'라는 것이다. 그 상황에서 나는 '우리가 받은 요구사항 명세에는 그런 내용들이 기록되지 않았습니다!'라고 반박하고 싶으나 반박할 수 없다. 그들은 돈을 쥐고 있고 때문에 나의 명줄을 틀어쥐고 있는것이나 다름없기 때문이다. 따라서, 나는 전체 개발실로부터 요구사항을 새로 수집하기로 결심했다. 다행히 우리 팀장은 이런 내 입장을 적극 지지해주었다.

우선은 완벽하지 않다해도 각 개발실이 보내온 문서로부터 출발했다. 최초에 한 일은 화면 설계(즉, 사용자 인터페이스)와 실제 기능을 분리하여 문장으로 표현하는 것이었다. 상식적으로 생각해보라. 카메라나 캠코더는 현재 거의 모든 휴대폰에 탑재되고 있고 디지털카메라도 널리 보급되어 있다. 이들의 사용법이 개발실마다 틀리다는 것은 이해가 되지 않았다. 나는 각 개발실마다 요구사항이 다르다고 느끼는 것은 기능보다는 사용자 인터페이스나 시나리오의 구성이 틀리기 때문에 발생한 것이라 가정했다. 실제로 사용자 인터페이스와 시나리오와 기능을 분리하고 각 개발실들의 요구사항을 비교해보니 서로 상당히 비슷했다. 차이가 나는 부분은 지원되는 어플리케이션의 종류와 고급 기능들뿐이었다.

나는 이런 상황을 개발실에 보고하고 문장화된 요구사항을 시작으로 요구사항을 검토해주길 부탁했다. 예상했던대로 거의 모든 요구사항들은 채택이 되었고 간간이 몇 가지 요구사항들이 추가되었을 뿐이었다.

우리는 문서산출물로서 IEEE Std 830 스타일의 소프트웨어 요구사항 명세서를 작성해야 한다. 소위 SRS(Software Requirement Specification)라고 하는 문서이다. IEEE Std 830 SRS는 대개 아래와 비슷한 구조를 지닌다.

IEEE Std 830 SRS(Software Requirement Specification)

- SRS 기본 목차

1. 소개(Introduction)
 a. 목적(Purpose)
 b. 범위(Scope)
 c. 정의, 두문자어, 약어
 d. 참조
 e. 개요

2. 전반적(종합적) 기술(Overall Description)
 a. 제품 관점(Product Perspective)
 b. 제품 기능들(Product functions)
 c. 사용자 특성(User Characteristics)
 d. 제약사항(Constraints)
 e. 가정 및 의존성(Assumptions and Dependencies)
 f. 요구사항 할당(Apportioning of Requirements)

3. 세부적인 요구사항(Specific Requirements)

제약사항(Constraints)
a. 규제정책(Regulatory Policies)
b. HW 제약사항(Hardware limitations (eg. signal timing requirements))
c. 타어플리케이션에 대한 인터페이스 (Interfaces to other applications)
d. 병렬수행(Parallel operation)
e. 감사기능(Audit function)
f. 제어기능(Control functions)
g. 시그널 핸드쉐이킹 프로토콜(Signal handshake protocols(eg. XON-XOFF, ACK-NACK))
h. 신뢰성 요구사항(Reliability requirements)
i. 어플리케이션 치명도(Criticality of Application)
j. 안전 및 보안에 대한 고려사항

- IEEE Std 830의 좋은 요구사항 명세서가 지녀야할 속성

1. 정확성(Correct)
2. 모호하지 않음. 명백함(Unambiguous)
3. 완전성(Complete)
4. 일관성(Consistent)
5. 중요도/안정 우선순위
6. 검토가능(Verifiable)
7. 수정가능(Modifiable)
8. 추적가능(Traceable)

- Alexander & Stevens

1. 완벽하게 하지말고 품질이 좋게하라
2. 개략적으로 기술하고 다시 개선시켜라
3. 좋은 요구사항을 해부해보라
4. 가이드라인
   a. 간단하고 직접적인 문장
   b. 제한된 단어 사용
   c. 각 요구사항에 대해서 사용자 부류 식별
   d. 결과를 언급하는데 초점을 맞추라
   e. 입증할 수 있는 기준을 정하라

5. 피해야할것
   a. 모호성을 피하라
   b. 다중 요구사항을 만들지 말라
   c. 회피용 문구를 만들지 말라
   d. 문장을 너무 길게 쓰지말라
   e. 시스템을 설계하지 말라
   f. 요구사항을 뒤섞고 설계하지 말라
   g. 요구사항과 계획을 뒤섞지말라
   h. 추측하는 문장을 포함하지 않도록하라
   i. 분명치 않은 요구사항에 매달리지 말라
   j. 막연한, 정의되지 않은 용어를 사용하지 말라
   k. 가능성을 표현하지 말라
   l. 희망사항을 작성하지 말라

이 요구사항 명세 양식은 크게 기능적 요구사항과 비기능적 요구사항을 명시적으로 기술하고 각 요구사항의 세부사항을 자세히 기록하는 특징을 가진다. 보통은 '시스템은 ~ 해야 한다.' 형식으로 기술한다.

나는 이런 형식의 SRS 문서를 작성하는데 애로가 있었다.

  • 첫째, 우선 요구사항이 확정되지 않았다. 휴대폰은 하드웨어나 소프트웨어 플랫폼, 모델의 폼 팩터(form factor)와 같은 많은 변동이 있다. 따라서, 모델마다 다른 요구사항이 수집되어야 한다. 그런데, 현재 모델이 결정되지 않은 상태에서 상세한 요구사항을 명세화하기 어려웠다.
  • 둘째, 요구사항을 모호하지 않게 기술하기 어려웠다. 문장을 모호하지 않게 기술하려면 한정된 단어 집합을 사용해야 한다. 그러나, 전체 개발실마다 같은 단어도 다른 의미로 사용하고 있었기 때문에 용어 정의조차 막막했다.
  • 셋째, SRS는 의사소통 수단으로 개발하기 보다는 고객과의 계약 수단으로 사용되기 때문에 변경이 매우 까다롭다. 보통, SRS문서는 변경 통제를 받는 문서이다. 고객의 변심은 곧 돈이다. 따라서, 대체로 프로젝트 중간에 요구사항이 변경되는 상황을 '위험'으로 간주하고 처리하게 된다. 따라서, 적극적인 변경 통제 계획을 세운다. 그리고 이 문서를 변경하려면 변경 요청서를 작성해야 한다. (물론, 이래야 한다고 하지만 이렇게 해 본 적은 없다 ^^)

나는 IEEE Std 830 형식보다 유연한 형식이 필요했다. 우리 팀장이 엘스테어 코번의 'Writing Effective Use Cases'를 찾아보라는 말이 단초가 되어 나는 요구사항 명세 방법을 체계적으로 조사하는 일을 수행하였다. 이 때까지 나는 유스케이스가 UML에서만 사용하는 용어인줄 알았다. 왜 UML에서 쓰는 졸라맨 스타일의 액터와 타원형의 쓰임새를 엮어놓은 우스꽝스런(?) 그런 그림들말이다. 그런데, 유스케이스는 UML의 유스케이스 다이어그램보다 훨씬 포괄적이고 융통성이 있는 요구사항 명세 방법이다. 다음 예를 보자.

주 행위자: 채용 담당자
수준: 행위자의 목적
전제조건: 채용 정보가 입력되었지만 아직 볼 수는 없는 상태다.
최소한의 보장: 없음
성공 보장: 채용 공고가 등록되었음. 채용 담당자의 신용카드로 결제 되었음.
주 성공시나리오:
  1. 채용 담당자는 신용카드 번호, 날짜, 인증 정보 등을 입력한다.
  2. 시스템은 신용카드를 검증한다.
  3. 시스템은 신용카드 결제를 수행한다.
  4. 등록한 채용 공고를 구직자들이 조회할 수 있다.
  5. 채용 담당자는 고유한 등록 확인 번호를 부여 받는다.
확장:
  2a: 시스템이 처리할 수 없는 카드종류다.
     2a1: 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.
  2b: 카드의 ID번호가 잘못되었다.
     2b1: 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.
  2c: 카드의 유효기간이 지났다.
    2c1: 시스템은 사용자에게 다른 카드를 사용하라고 통지한다.
  3a: 카드의 신용한도가 부족하다.
    3a1: 시스템은 결제할 수 있는 만큼 결제한다.
    3a2: 사용자는 이에 대해 통지받고, 잔액 결제를 위해 두 번째 카드 정보를 입력하다는 요청을 받는다. 단계 2에서 계속된다.

('사용자 스토리'에서 발췌함)

유스케이스는 성공적인 실행경로외에도 다른 부차적인 경로들을 같이 기록한다. 이 점이 나에게 상당한 매력이었다. 이 때까지 개발된 요구사항 명세서는 주 성공 시나리오에 대해서만 다루고 예외상황이나 특별한 상황에서의 시나리오는 명세화되지 않았다. 그리고, 이런 요구사항들은 QA팀의 테스트 케이스에 빼곡히 차 있었다. SQA에 참가했을 때 불과 몇 개되지 않던 요구사항이 3~4배로 늘어나는 상황을 겪은 적이 있었다. 우리팀은 추가된 요구사항으로 인해 거의 월화수목금금금 형태로 일하지 않으면 일정을 맞출 수 없었다. 만약, 이런 요구사항들을 미리 발견하여 포함했다면 어땠을까? 적어도 불완전한 소프트웨어를 QA팀에 인도하지 않았을 것이고, 개발단계에서 품질에 대해 더 신경썼을 것이다.

유스케이스가 IEEE std 830형식보다는 기술하기는 편했지만, 여전히 하나의 유스케이스를 채우는 일은 고통이었다. 직접 해보지 않으면 이것이 왜 괴로운 작업인지를 모를 것이다. 대체 하루종일 왜 하나의 유스케이스도 제대로 못채우느냐고 닥달 당할 수도 있을 것이다. 이런 상황은 쉽게 나아지지 않았다. 코딩을 했어도 벌써 만들었겠다고 느낀 적이 한 두번이 아니다. 유스케이스는 IEEE std 830처럼 어느정도 상세화된 명세를 요구한다. 더군다나, 제대로 기록하려면 시나리오 또는 흐름(flow) 형태로 기술해야 하는데 각 개발실마다 흐름을 달리 정의하고 있어서 이를 기록하기가 매우 어려웠다. 즉, 주 성공시나리오를 기술하는 일이 어려웠고 때문에 확장 역시 기록이 어려워졌다.

그래서 나는 보다 효과적인 요구사항 명세 방법을 찾기로 결정했다. 그래서 찾아낸 것은 바로 '사용자 스토리'였다. XP에서는 소프트웨어의 요구사항을 의사소통의 문제로 바라본다. 따라서, 요구사항은 고객에 의해 작성되어야 한다고 주장한다. 고객은 자신에게 가치가 있는 요구사항을 기술할 것이고 이러한 고객을 프로젝트에 직접 참여시키라고 말한다. 좋은 말이다. 그러나, 우리의 고객은 요구사항 명세나(?) 할 정도로 한가하지 못하다는 문제가 있었다. 실천 방법은 따르지 못하더라도 그들이 주장하는 요구사항 명세법은 충분히 참고할 만하다. 고객이 작성하는 요구사항을 그들은 '스토리(Story)'라고 불렀다.

스토리는 서술 형태로 기록되고 대화를 통해 세부사항을 구체화하며, 테스트를 통해 세부사항을 문서화하고 완료 여부를 판단한다. 또한, 스토리는 사용자에게 가치를 평가받을 수 있도록 기능을 표현해야 한다.
 

나는 고객의 피드백이 절실히 필요했기때문에 요구사항의 승인을 위해서는 고객의 평가를 거쳐야 했다. 그렇다면, 요구사항을 평가받을 수 있는 형태로 작성하는 것이 중요했다. 더군다나, 스토리는 세부사항을 테스트로 기술하기 때문에 요구사항을 작성하면서 테스트 케이스를 만들 수 있는 장점도 가지고 있다. 결정적으로, 스토리는 작성이 쉽다.

사용자는 자신의 이력서를 웹사이트에 게시할 수 있다.

예와 같이 스토리는 단순한 기능의 표현이라기보다는 고객의 의도와 목적이 담겨져 있다. 또한, 스토리는 절차의 일부가 아닌 시작과 끝이 명료한 닫힌 속성을 가진다. 필요하다면 대화를 위한 주석을 적을 수 있고, 개발자 피드백을 제약사항으로 기술할 수 있다. 스토리의 특징을 간단히 나열하면 다음과 같다.

  • 독립적이다(Indipendent)
  • 협상가능하다(Negotiable)
  • 사용자 및 고객에게 가치가 있다(Valuable)
  • 추정 가능하다(Estimatable)
  • 작다(Small)
  • 테스트 가능하다(Testable)

일단 이런 원칙을 따르기로 했다면 요구사항을 명세하는 작업에 일관성을 갖출 수 있게 된다. 너무 크거나 작지 않은 스토리, 또는 의존성이 있는 스토리들을 걸러내는 작업을 하는 동안 요구사항들이 자연스레 정리된다. 원칙만 바꾸었을 뿐인데 작업은 굉장이 쉬워졌다. 아마도 세부사항을 기록해야 한다는 부담을 떨칠 수 있었던 것이 가장 큰 이유였던 것 같다.

그러나 우리 프로젝트는 다루어야할 요구사항이 너무나 방대했기 때문에 스토리 또한 너무나 많아졌다. 이렇게 많은 스토리로를 하나하나 검토하면서 의사소통을 하기는 어려울 것 같았다. 구조화 되지 않은 너무 많은 스토리들이 나를 혼동 속에 빠뜨렸다.

구조? 그래, 유스케이스는 어느정도 이런 구조적인 면이 있었지. 퍼뜩 나는 이런 생각이 들었다. 만약, 유스케이스를 시나리오로 기술하지 않고 스토리로 기술한다면 어떨가? 유스케이스는 스토리를 묶는 기준 역할을 해주고 특수한 상황이나 예외 상황을 요구사항에 포함시킬 수 있는 구조를 제공한다. 스토리는 상세화를 뒤로 미룰 수 있고, 세부사항을 테스트로 기록함으로써 테스트 케이스를 포함시킬 수 있는 장점이 있었다. 나는 "유스케이스는 스토리를 담을 수 있는 훌륭한 그릇이 될 수 있다"는 가정을 세웠고 이를 즉시 실행했다. 그 결과 나는 다음과 같은 새로운 유스케이스 템플릿을 만들었다.

<유스케이스와 스토리를 결합한 요구사항 명세 템플릿>
 
1. 유스케이스 대표이름
 
1.1 Purpose
     유스케이스의 목적 기술
 
1.2 Local View
     유스케이스에 포함된 흐름들을 Usecase Diagram으로 표시
 
1.3 Basic Flows
     유스케이스의 목적에 부합하는 흐름들에 대한 요구명세
 
1.4 Alternative Flows
    유스케이스에 목적에 부합하지 않지만 필요한 흐름들에 대한 요구명세
    (예: 전화가 올때, 메시지가 올 때 등)
 
1.5 Exceptional Flows
    예외 상황이 발생했을 때의 흐름들에 대한 요구명세
    (예: 메모리 부족, 배터리 부족 등)
 
 1.6 Special Requirements
     비기능적인 요구사항들이나 시스템 제약사항, 의존성 기술
 
 1.7 Appendix
    화면 설계서와의 상호 참조 또는 별도 문서에 대한 상호 참조 포함
    기타 기록이 필요한 내용
 
<요구사항 작성 요령>
1. 요구사항이 사용자의 의도 및 목적을 반영할 수 있도록 기술한다.
2. 요구사항은 절차의 일부가 아닌 시작과 끝이 있는 닫힌 항목으로 기술한다.
3. 요구사항에 사용자 인터페이스 항목을 포함시키지 않는다.
4. 요구사항에 대한 세부사항은 테스트로 기술한다. '테스트) ~'로 별도로 기록한다.
5. 의사소통이 필요한 부분은 '주) ~ ' 로 별도 기술하고 feedback을 받아 채운다.
6. 알아야할 제약사항들은 '제약사항) ~'로 별도 기술한다. 제약사항은 중요한 요구사항으로 간주한다.
7. 필요한 시스템 반응은 '시스템 반응)~'로 기술했다. 사용자 인터페이스를 기술하지 않는 것이 원칙이나 꼭 필요한 부분은 명세에 포함한다.

사실 유스케이스를 템플릿으로 기록해야할 의무는 없다. 코번은 유스케이스를 자유형식으로도 기술할 수 있다고 했다. 나는 액터, 전제, 보장과 같은 요소들을 없애고 위와 같이 요약된 유스케이스 템플릿을 만들었다. (액터의 역할 모델은 중요하지만 당장은 고려하지 않기로 했다.)

UML의 유스케이스 다이어그램을 그려보는 일도  매우 유용했다. 의미없다고 생각했던 유스케이스 다이어그램이 사실은 스토리를 담을 그릇들이 무엇인가를 결정하는데 많은 도움을 주었다. StarUML이라는 프리웨어를 사용하여 다이어그램을 손쉽게 그릴 수 있다. Basic Flow와 Alternative Flow의 내용은 시나리오가 아닌 스토리로 기술했다. 스토리는 여러 시나리오로 구현될 수 있지만 시나리오는 그렇지 못했다. 각 개발실마다 통일된 시나리오를 사용할 처지가 못 되었기 때문에 시나리오로 기술하는 것은 옳지 못했다. 그러나, 스토리는 시나리오보다는 고객이 원하는 기능 자체에 초점을 두기 때문에 이를 기술하는 것은 쉬웠다.

여기에 구체적인 예를 싣지 못함이 안타깝다. 그러나, 위의 방식을 이용했을 때, 스스로도 만족할 만한 요구사항 명세를 하고 있다는 느낌이 들었다. 이 템플릿은 의사소통 수단으로도 쓸 수 있고 또한 문서 산출물로도 쓸 수 있을 것 같다. 아마도 프로젝트 말기에 이 문서는 필요한 모든 세부사항들이 포함하게 될 것이다. 그리고 나는 이를 IEEE std 830 스타일의 요구사항 명세서를 작성해야 할 것이다. 요구사항 명세를 프로젝트가 끝날 때하는 것은 넌센스다. 그렇지만, 다음 프로젝트를 준비한다는 의미에서 이러한 넌센스도 가치있는 일이 될 것이라 생각한다.  

문서화에 가치를 두지 않는 집단과 가치를 두는 집단 사이에서 일하고 있기 때문에, 나는 두 집단을 모두 만족시키는 방법을 찾아야만 했다. 개인적으로 피곤한 일이지만 너무 문서화에 치중한다는 느낌을 주기도 싫었고, 그렇다고 어떻게든 되겠지하며 형편없는 요구사항 명세를 하기도 싫었다.

나의 목표는 내가 참여한 프로젝트를 베스트 프랙티스로 만드는 것이다. 그 초석이 되는 것이 바로 '제대로된 요구사항 명세'이다.
top
happying | 2007.01.25 08:41 신고 | PERMALINK | EDIT/DEL | REPLY

아직 코번의 책 'Writing Effective Use Cases'를 구하지 못했다. 강컴에서 검색했더니 절판이란다. 대신, 'UML과 패턴의 적용(Applying UML and Patterns)' 란 책에서 유스케이스에 대해 비교적 상세하게 다룬다. 유스케이스를 스토리로 기술한 후 느꼈던 점은 스토리는 '시스템의 피처(Feature)를 표현하는 것과 유사하다'라는 것이었다. 시스템의 피처를 아는 것은 설계를 할 때 매우 중요하다. 각각의 피처마다 성격이 다르고 처리방법도 다르다. 나는 비교적 많은 멀티미디어 어플리케이션의 명세 작업을 수행하였는데 이들간에는 많은 공통 피처들이 존재한다는 사실을 알았다. 또한, 피처들의 성격을 분석하면서 설계에 대한 감을 잡았다. 왜 요구사항 분석가를 시스템 분석가라고 부르는지 이유를 알 것 같다. 요구분석을 하는 동안 나는 시스템이 무엇이다라는 것을 구체적으로 알 수 있었다. 또한, 시스템이 가지고 있는 문제는 보통은 몇 개의 피처에 의해 발생된다는 사실도 말이다. 유스케이스 다이어그램을 그려보는 것도 꽤 도움이 된다. 보는 사람한테는 아무 것도 아닌 그림인데 그리는 사람은 엄청난 사고가 필요하다. 시스템 분석가, 도메인 분석가들은 참 존경할 만한 사람들이다.
Visitors | 2012.11.23 16:34 | PERMALINK | EDIT/DEL | REPLY

처음 SRS를 작성하는데 너무 힘들었습니다. 어떻게 작성해야 할지 모를 뿐더러.. 제품의 전반적인 설명을 서술할때 설명을 수십번 지웠다 쓰고 단어 하나에 몇시간을 고민하게 되더군요. 다행이 happying의 글을 읽고 의문점도 풀리고 너무 공감가서 좋았습니다. 경험에서 나온 뼈와 살이 되는 글 감사드립니다.
boolsee | 2014.07.22 09:41 신고 | PERMALINK | EDIT/DEL | REPLY

실제적인 사례로 정리해 주셔서 이해가 쉽습니다만 실제로 하려면 역시나 머리가 아프겠네요. 그나저나 저는 Atlassian Agile 을 사용해서 개발 구현이 필요한 내용을 (Atlassian제품에서 내세우는)Story 개념으로 나누어 놓고, 테스트를 위해서 별도 양식을 찾아 보려했었는데 이 글을 보니 그럴필요 없이기존 Story 를 기준으로 Test Case 를 만들면 조금은 수월해 지겠습니다. 물론, 교과서적인 실천 방법은 아니지만 나름의 방안이 아닐까 싶네요.
고맙습니다.
서태웅s | 2017.06.14 17:17 신고 | PERMALINK | EDIT/DEL | REPLY

10년 전 글이지만 현재 제가 개발 중인 프로젝트에 너무 필요한 정보이네요.
많이 도움이 되었습니다. 감사합니다. ^^
Name
Password / Secret
Homepage