오늘의 과제: 연습문제 풀이!
요구사항을 받았는데, 요구사항이 아닐 수 있습니다!
요구사항이 아니라면 사용자가 진짜로 원하는게 무엇인지 알아내야합니다. 애매한 요구사항에서 진짜 요구사항을 찾아내는 연습을 해봅시다.
(1) '연습문제 #33'을 읽습니다.
(2) 1-5번까지 문제를 클라이언트가 건넨 요구사항이라 상상하며 문제를 풀어봅시다.
(3) 진정한 요구사항이 아닐 경우 어떻게 질문을 해야하는지, 무엇을 알아야 하는지, 왜 그렇게 생각하는지 등 나의 생각을 작성해보세요.
요구 사항처럼 보인다. 환경 때문에 애플리케이션 제약을 추가해야 할 수 있다.
이 문장 자체만으로는 진짜 요구 사항이 아니다. 하지만 진짜로
무엇이 필요한지 알아내려면 마법의 질문을 던져야 한다. “왜?”
이것이 회사의 표준일 수 있다. 그렇다면 진짜 요구 사항은 “모든 UI 요소는 메가코퍼레이션 사용자 인터페이스 표준 V12.76을 준수해야 한다.” 같은 것이어야 한다.
우연히 디자인팀이 좋아하는 색깔일 수도 있다. 그렇다면 디자인팀이 생각을 바꿀 가능성도 고려해야 한다. 따라서 요구 사항을 “모든 모달 창의 바탕색은 설정 가능해야 한다. 출시될 때는 회색으로 한다”로 바꾸어야 한다. 더 범위를 넓혀서 “애플리케이션의 모든 시각 요소(색상, 글꼴, 언어)는 설정 가능해야 한다”라고 하면 더 좋다.
아니면 단순히 사용자가 모달 창과 다른 창을 구별할 수 있어야 하는 것 일 수도 있다. 그렇다면 더 논의해 볼 필요가 있다.
이 문장은 요구 사항이 아니다. 이것은 아키텍처
다. 이런 종류의 것과 마주쳤다면 사용자가 무슨 생각을 하는지 알아내기 위해 깊이 파고들어야 한다. 확장성 문제인가? 아니면 성능? 비용? 보안? 고객의 대답이 여러분의 설계를 안내할 것이다.
밑에 숨겨진 요구 사항은 아마 “시스템은 사용자가 필드에 올바르지 않은 값을 입력하는 것을 막는다. 올바르지 않은 값을 입력하는 경우 경고를 보낸다.”라는 문장에 더 가까울 것이다.
이 문장은 하드웨어의 규격에 맞춘 것 같아 보인다. 아마 꼭 지켜야하는 요구 사항일 것이다.