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

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

-

완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 빼낼 것이 없을 때 얻게 되는 것이다. - 생택쥐페리

-

요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀져 있다.

-

요구사항을 수집하지 말고 채굴하라.

-

어느 것이 진정한 요구사항인지 어떻게 분간할 수 있을까?

요구사항이란, 어떤 것이 성취되어야 한다는 진술이다.

ex) 

직원 기록은 지명된 사람들만 볼 수 있다.

    해당 직원의 관리자와 인사부에서만 그의 기록을 열람할 수 있다. -> 비지니스 정책이 내포된 진술로 수시로 바뀔 수 있다. 요구사항에 이를 고정하는 건 그리 좋은 생각이 아니다.

실린더헤드 온도는 임계값을 넘으면 안 되며, 이는 엔진마다 다르다.

에디터는 편집하는 파일의 종류에 따라 별도로 선택된 키워드를 강조 표시한다.

-

정책은 수시로 바뀐다.

요구사항 속에 정책을 고정하는 건 그리 좋은 생각이 아니다.

정책들을 요구사항에서 분리해 문서화하고, 양자를 하이퍼링크하는 것이 추천된다.

요구사항은 최대한 일반적 진술로 만들고, 나머지 정책에 관한 정보는 개발자에게 구현에서 지원해야 할 것들의 한 예로 넘겨주어야 한다.

결국 정책은 앱에서 메타데이터로 포함될 것이다.

-

상대적으로 미묘한 구분이지만, 개발자에게 심오한 의미가 있다.

만약 요구사항이 “인사과에서만 직원 기록을 열람할 수 있다”는 식으로 되어 있다면 개발자는 앱이 이 파일들을 접근할 필요가 있을 때마다 그것이 가능한지 확인하는 코딩을 할 것이다.

하지만, “권한이 부여된 사용자만이 직원 기록에 접근할 수 있다”는 식으로 요구사항이 만들어졌다면 개발자는 아마도 접근 관리 시스템을 설계하고 구현할 것이다. 그러면 정책이 바뀔때 그 시스템의 메타데이터만 업데이트하면 된다. 실제 이런 식으로 요구사항을 수집하면, 메타데이터를 지원하도록 잘 분리된(factored) 시스템 구현이 가능하다.

-

“시스템은 대출 기한을 선택할 수 있도록 해줘야 한다” 는 것은 요구사항의 진술이다.

“대출 기한 선택을 위해서 리스트 박스가 필요하다”는 것은 요구사항의 진술일 수도 있고, 아닐 수도 있다.

만약 사용자들이 절대적으로 리스트 박스를 필요로 한다면 요구사항.

하지만 뭔가 선택할 수 있는 기능을 설명하느라 리스트 박스를 한 가지 예로 사용하고 있다면 그것은 요구사항이 아니다.

-

사용자들이 어떤 작업을 현재 “어떻게” 하느냐는 것을 알아내는 것보다, “왜” 그걸 하는지 그 내재적 이유를 알아내는 것이 더 중요하다.

개발을 통하여 마지막에는 그들이 진술한 요구사항을 충족하는 것이 아니고, 그들의 실질적 비지니스 문제를 해결해야 하는 것이다.

요구사항 이면의 이유들을 문서화해 놓으면, 여러분의 팀은 나날이 구현 관련 의사결정을 할 때마다 이루 말로 할 수 없는 값진 정보를 얻게 되는 셈이다.

-

사용자의 요구사항 내면 깊이 들어갈 수 있는 (그러나 많이들 쓰지 않는) 단순한 기법이 있다.

사용자가 되어 보는 것이다.

사용자처럼 생각하기 위해 사용자와 함께 일하라.

-

요구사항을 갈무리하는 유스 케이스(use case) 개념이 좋다.

유스 케이스는 시스템의 특정한 사용을 설명한다.

사용자 인터페이스의 차원에서가 아니고, 좀 더 추상적인 차원에서의 얘기다.

-

요구사항 문서를 만들 때 생기는 큰 위험은 지나치게 자세히 서술하는 것이다.

좋은 요구사항 문서는 추상적이다.

요구사항에 관한 한 비지니스에 필요한 사항을 정확히 반영하는 가장 간단한 진술문이 최고다.

모호하게 하라는 말은 아니다.

밑에 깔려 있는 의미론적 불변식을 요구사항으로 잘 갈무리하고, 구체적인 작업관행이나 현재의 작업관행을 정책으로 문서화해야 한다.

-

요구사항은 아키텍처가 아니다.

요구사항은 설계가 아니며, 사용자 인터페이스도 아니다.

요구사항은 필요다.

-

구체적인 것보다 추상적인 것이 더 오래간다.

-

많은 프로젝트들이 범위(scope)의 증가 때문에 실패한다고 알려져 있다.

요구사항이 슬슴슬금 추가되는 것을 어떻게 막을 수 있을까?

많은 프로젝트가 요구사항을 적극적으로 추적하지 않는다.

이는 범위의 변화에 대해서 보고할 길이 없다는 의미가 된다. 

여기서 범위의 변화란 누가 기능을 요청했고, 누가 승인했으며, 승인된 요구사항은 몇 개인가 등이다.

-

요구사항 증가 관리의 핵심은, 새 기능이 일정에 미칠 영향을 프로젝트 후원자에게 인식시키는 것이다.

요구사항이 언제 어떻게 늘어났는지에 대해 정확하고 완전한 그림을 갖고 있는 것이 크게 도움이 된다.

-

프로젝트 용어 사전(glossary)를 만들고 유지하라.

그것은 프로젝트에서 사용되는 모든 용어와 어휘를 모아 놓은 단일한 장소여야 한다.

최종 사용자에서 보조 직원까지 프로젝트에 참가하는 모든 사람이 일관성을 위해 동일한 용어 사전을 사용해야 한다.

이렇게 되려면 용어사전에 여러 사람이 접근하기 쉬워야 하며, 웹 기반 문서를 사용하는 것이 좋은 방법이다.

-

아무도 읽지 않고 그저 종이에 잉크가 칠해지는 순간 과거의 자료가 되어버리는 전형적인 요구사항 분석이라는 베개만큼 두꺼운 바인더는 웹 기반 배포를 통해 방지할 수 있다.

glossary, use case, [실용주의 프로그래머] 요구사항의 구렁텅이, 메타데이터, 사용자 되어 보기, 완성은 더 이상 더할 것이 없을 때가 아니라 더 이상 빼낼 것이 없을 때 얻게 되는 것이다, 유스 케이스, 정책 분리 문서화, 정책은 수시로 바뀐다, 좋은 요구사항 문서는 추상적이다, 프로젝트 용어 사전, 하이퍼링크