p.362 (전자책 기준 p.387)
다음 문장들이 진정한 요구 사항인가? 가능하다면 진정한 요구 사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라.
이 문장은 진짜 요구 사항처럼 보인다. 환경 때문에 애플리케이션에 제약을 추가해야 할 수 있다.
응답 시간이 왜 500ms 이하로 맞추어야 하는지 이유에 대해서 논의해본다. 이하로 못맞췄을 시 발생하는 문제가 있는지에 대해서 의견을 나눠본다.
이 문장 자체만으로는 진짜 요구사항이 아니다. 하지만 진짜로 무엇이 필요한지 알아내려면 마법의 질문을 던져야 한다. ”왜?”
이것이 회사의 표준일 수 있다. 그렇다면 진짜 요구 사항은 "모든 UI 요소는 메가코퍼레이션 사용자 인터페이스 표준 V12.76을 준수해야 한다."같은 것이어야 한다.
우연히 디자인팀이 좋아하는 색깔일 수도 있다. 그렇다면 디자인팀이 생각을 바꿀 가능성도 고려해야 한다. 따라서 요구 사항을 "모든 모달 창의 바탕색은 설정 가능해야 한다. 출시될 때는 회색으로 한다"로 바꾸어야 한다. 더 범위를 넓혀서 "애플리케이션의 모든 시각 요소(색상, 글꼴, 언어)는 설정 가능해야 한다"라고 하면 더 좋다.
아니면 단순히 사용자가 모달 창과 다른 창을 구별할 수 있어야 하는 것일 수도 있다. 그렇다면 더 논의해 볼 필요가 있다.
회색이라면 밝은 회색인지, 어두운 회색인지 정확한 컬러가 있어야 하지 않을까. 그리고 계속해서 색상이 바뀌는 가능성에 대해 물어보고 색상, 폰트 등을 설정하는 것이 바람직하다고 전달해본다.
이 문장은 요구사항이 아니다. 이것은 아키텍처다. 이런 종류의 것과 마주쳤다면 사용자가 무슨 생각을 하는지 알아내기 위해 깊이 파고들어야 한다. 확장성 문제인가? 아니면 성능? 비용? 보안? 고객의 대답이 여러분의 설계를 안내할 것이다.
요구 사항이기 보다는 그저 설명하는 것에 가깝다. 요구 사항으로 만들시엔 현재 만들 서비스에선 어떤 프론트엔드 프로세스가 적절한 지 논의하고, 백 서버는 어떤 서버를 사용할 지에 대한 명확한 제시를 그려나간다.
밑에 숨겨진 요구 사항은 아마 “시스템은 사용자가 필드에 올바르지 않은 값을 입력하는 것을 막는다. 올바르지 않은 값을 입력하는 경우 경고를 보낸다.”라는 문장에 더 가까울 것이다.
어느 숫자필드에 한정해서 사용할 것인지 의논한다. 그리고 이메일이나 전화번호 등 정보입력에서 필요한 사항이나, 서비스에 맞는 효율적인 입력 시스템에 대해서 말해본다.
이 문장은 하드웨어의 규격에 맞춘 것 같아 보인다. 아마 꼭 지켜야 하는 요구 사항일 것이다.
이내여야 하는 이유에 대해서 물어본다