요구사항의 구렁텅이 [실용주의 프로그래머]

LEE KYU WON·2021년 2월 15일
0

"요구사항의 수집" 은 "수집" 이라는 단어를 사용해서 이미 널려있는 요구사항을 주워담기만 하면 된다는 느낌을 주지만 실제로는 "수집" 의 느낌보다는 요구사항은 보이지 않는 땅속에 묻혀있는것과 같아 "채굴" 에 더 가깝다고 한다.

요구사항 채굴하기

요구사항은 어떤 것이 성취되어야 한다는 진술이다. 다음은 요구사항의 예 이다.

  • 직원 기록은 지명된 사람들만 볼 수 있다.
  • 실린더헤드 온도는 임계값을 넘으면 안 돼며, 이는 엔진마다 다르다. (기계공학 엔지니어링의 경우..)
  • 에디터는 편집하는 파일의 종류에 따라 별도로 선택된 키워드를 강조 표시한다.

하지만 대개의 요구사항은 이보다 복잡하다.

위의 예시에서 첫번째 요구사항에 관해 "사용자는 해당 직원의 관리자와 인사부만이 그의 기록을 열람 할 수 있다." 라고 말했을 수 있다. 이 진술이 진정한 요구사항은 아닐 수 있다. 이 진술에는 "정책이 포함되어 있기 때문이다.

관리자와 인사부만이 기록을 조회 할 수 있다는 사실은 고객사의 현재 "정책" 이며, 이는 언제든지 바뀔 수 있다. "정책"은 요구사항에서 분리해 문서화하고, 요구사항과 분석을 하이퍼링크하는것을 권장한다. 정책은 어플리케이션에서 메타데이터로 분리되도록 하면 나중에 정책이 바뀌었을때 메타데이터만 변경해서 시스템을 유지 할 수 있다.

만약 도서관 사서 프로그램 개발 프로젝트 요구사항 수집에서 "리스트박스로 대출기한을 선택하게 한다." 는 인터뷰 결과를 얻었다면 이는 요구사항이 될 수도 있고 아닐수도 있다. 대출기한을 선택하게 해야한다는 기능을 표현하기 위해 단지 리스트박스라는 단어를 사용했을수도 있고 그들이 진정으로 리스트박스로 대출기한을 선택하는것을 원하는 경우였을 수 있기 때문이다.

그들의 진정한 요구사항을 확인하기 위해서는 사용자의 관점이 되어 보는것이다. 가장 좋은것은 방해하지 않는 선에서 일주일간 같이 일해보는 것이다. 이는 또한 사용자와 신뢰를 구축하고 의사소통을 원활하게 할 수 있다. 만약 상황이 여의치 않으면 최소한 그들이 현재 사용하는 시스템을 사용 해 볼 수는 있어야 한다.

요구사항 문서화

사용자와 요구사항에 관해 얘기 하다보면 그들이 묘사하는 몇가지 시나리오를 얻게되고 이를 기록해서 관계자 (사용자, 후원자, 개발자 등) 과 토론 할 때 사용 할 귀중한 자료를 만들 수 있다.

Iva Jacobson 은 요구사항을 갈무리하는 유스케이스(Use case) 를 제안했다. 하지만 그가 제안한 유스케이스가 어떠해야 하는가는 세부사항이 애매모호 하기에 Alistair Cockbum 이 제안한 유스케이스 템플릿을 사용해 볼 수 있다.

http://www.cs.otago.ac.nz/coursework/cosc461/uctempla.htm

이러한 템플릿을 비망록으로 사용하므로서 발생 가능한 에러와 예외같은 비기능적인 요구사항을 빠뜨림 없이 포함 할 수 있다. 또한 유스케이스를 계층적으로 정리 할 수 있다.

그 외에 요구사항을 문서화 하며 고려 할 점은 여러가지 다이어그램을 사용할 수 있다는 점, 너무 지나치게 자세한 명세를 지양하고 추상적인 요구사항을 만들라는 점이 있다.

엔티티의 추상화

Y2K 문제가 발생한 이유는 뭘까? 연도의 앞 두자리를 줄여 메모리를 줄이려고 한 개발자의 문제일까? 그보다는 시스템 분석가와 설계자의 문제이다. 날짜를 단지 number 로 저장하지 않고 Date 라는 추상화를 사용하고 이게 연도를 두자리로 표현한것이라고 명시한다면 이렇게 문제가 복잡해지지는 않았을 것이다.

이처럼 연도에 관한 데이터를 추상화하고 Date 추상화시에 좀 더 다양한 유스 케이스를 고려한 클래스 요구사항을 고려해서 구현했다면 나중에 유지보수가 더 쉬울 수 있다.

프로젝트 관리 면에서의 요구사항

요구사항 추적하기

많은 프로젝트들이 프로젝트의 범위 증가로 인해 (기능이 지속적으로 추가된다던지) 실패한다고 알려져 있다. 많은 경우 버그 보고, 수정, 결함의 밀도, 기능 점수, 코드 라인등 이런 메트릭 metric 들을 수기로든 툴을 사용하든 위의 항목들을 추적하고 있다 . 하지만 많은 프로젝트들이 요구사항을 적극적으로 추적하지 않는다. 이는 누가 기능을 요청했고, 누가 승인했으며, 승인된 요구사항이 몇개인가 등이다.

요구사항 증가 관리의 핵심은, 새 기능이 일정에 미칠 영향을 프로젝트 후원자에게 인식시키는 것이다. 만약 프로젝트가 1년 이상 뒤쳐지고 비난이 오고갈 즈음이면, 요구사항이 언제 어떻게 늘어났는지에 대해 정확하고 완전한 그림을 갖고 있는것이 크게 도움이 될 것이다.

용어사전 만들기

특정 도메인에서 사용하는 소프트웨어의 경우 특수한 용어를 사용하기도 한다. 예를 들어 "클라이언트" 와 "커스터머" 를 다르게 사용하는 분야에서는 이를 시스템에서 일상에서 사용하듯이 하는것은 부적절하다. 따라서 프로젝트 용어사전(glossary) 를 만들고 관리할 수 있다. 프로젝트에 필요한 모든 용어와 어휘를 모아놓은 단일한 장소여야 하고 최종 사용자부터 보조 직원까지 프로젝트에 참가하는 모든 사람이 일관성을 위해 동일한 용어사전을 사용해야 한다. 이를 위해 용어사전을 웹 기반으로 만들면 관리가 수월하다.

웹 기반 문서 만들기

모든 프로젝트 참가자가 문서에 쉽게 참여하기 위해서는 어떻게 하는게 좋을까? 요구사항을 웹에 올리는것을 추천한다. 잉크가 칠해지는 순간 과거의 자료가 되어버리는 종이 문서보다 관리가 훨씬 수월하다는 장점 또한 있다.

profile
벼랑끝에서 성장하는 개발자 이규원입니다.

0개의 댓글