진정한 요구 사항 (연습문제 33)

다음 문장들이 진정한 요구 사항인가? 
가능하다면 진정한 요구 사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라.

 

1. 응답시간은 500ms 이하여야 한다.
2. 모달창(modal window)의 바탕색은 회색이다.
3. 애플리케이션은 프론트엔드 프로세스 몇 개와 백엔드 서버로 구성된다.
4. 사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면 시스템은 입력 필드를 깜빡이고 입력을 거부한다.
5. 이 임베디드 애플리케이션의 코드와 데이터 크기는 32Mb 이내여야 한다.

 

---

[내 답변]

요구 사항인 것을 O 아닌 것을 X라고 한다면

1. X
   - 어느 환경에서 어떤 경로의 시간을 말하는 건지 모르겠다.
   - 실제 서비스 시 방화벽 등이 추가된다면 더 늘어날 수 있으니 조건을 더 명시적으로 적어야 할 것으로 보인다.
     - 이를 명확히 하기 위해선 왜 500ms가 기준인지를 알면 좋을 듯
2. X
   - 왜 회색이여야 할까? 구분이 되어야한다면 기본 윈도우 바탕색이 회색이라면 더 구분하기 힘들지 않을까?
   - 색깔 같은 것들은 테마 같은것들에 의해 바뀔수 있지 않을까. 설정으로 바꿀수 있다면?
3. X
   - 이걸 요구사항이라고 볼 수가 있나...? 그냥 아키텍처 설계로 보인다. (이런 부분까진 의뢰자가 알 수 없다.)
4. X
   - 솔깃한 요구 사항이긴 했는데... 결국 맞지 않는 데이터 값은 출력조차 하지 않겠다. 혹은 방지하겠다. 뭐 이런 의미가 더 명확하다. 
     - 깜빡이고 입력을 거부한다 -> 이런 부수적인 효과들도 설정으로 변경이 될 것 같은...
   - 좀 더 추상적으로 'invalid한 입력을 하는 것을 방지하는 장치가 있어야한다.' 였으면 요구 사항 이었을 것 같다.
5. O
   - 순간 config 같은 데이터까지 포함하는 건지? 라는 의문이 들뻔 했는데 코드+데이터 크기라면 이건 지켜야 할 것으로 보인다.

 

---

[정답]

1. O
이 문장은 진짜 요구사항 처럼 보인다. 환경 때문에 애플리케이션에 제약을 추가해야 할 수 있다.

 

2. X
이 문장 자체만으로는 진짜 요구 사항이 아니다. 하지만 진짜로 무엇이 필요한지 알아내려면 마법의 질문을 던져야 한다. “왜?”
이것이 회사의 표준일 수 있다. 그렇다면 진짜 요구 사항은 “모든 UI 요소 는 메가코퍼레이션 사용자 인터페이스 표준 V12.76을 준수해야 한다.” 같 은 것이어야 한다. 아니면 단순히 사용자가 모달 창과 다른 창을 구별할 수 있어야 하는 것 일 수도 있다. 그렇다면 더 논의해 볼 필요가 있다. 우연히 디자인팀이 좋아하는 색깔일 수도 있다. 그렇다면 디자인팀이 생 각을 바꿀 가능성도 고려해야 한다. 따라서 요구 사항을 “모든 모달 창의 바탕색은 설정 가능해야 한다. 출시될 때는 회색으로 한다”로 바꾸어야 한다. 더 범위를 넓혀서 “애플리케이션의 모든 시각 요소(색상, 글꼴, 언 어)는 설정 가능해야 한다”라고 하면 더 좋다.

 

3. X
이 문장은 요구사항이아니다. 이것은 아키텍처다. 이런 종류의 것과 마주쳤다면 사용자가 무슨 생각을 하는지 알아내기 위해 깊이 파고들어야 한다. 확장성 문제인가? 아니면 성능? 비용? 보안? 고객의 대답이 여러분의 설계를 안내할 것이다.

 

4. X
밑에 숨겨진 요구 사항은 아마 “시스템은 사용자가 필드에 올바르지 않은  값을 입력하는 것을 막는다. 올바르지 않은 값을 입력하는 경우 경고를 보낸다.”라는 문장에 더 가까울 것이다.

 

5. O
이 문장은 하드웨어의 규격에 맞춘 것 같아 보인다. 아마 꼭 지켜야 하는 요구 사항일 것이다.​

 

---

[후기]

• 1번에서 환경에 의한 제약을 추가하는 것 정도는 제약 조건으로 안 치는 모양이다.
• 옵션 등으로 조절 가능해보이는 부가 효과적인 부분은 늘 요구사항이 아닌 케이스 중 하나라고 생각하면 될 것 같다.
• 아키텍처에 관련한 요구 비슷한게 들어왔다면 사용자가 무슨 생각으로 이런 요구를 하게 됐는지를 알아내야 한다는게 놀랍고도 좀 피곤하다.자신의 의뢰 방식을 전혀 발전시키지 않는 사용자라면 매일매일이 스무고개일 것 같다.

 

 

 

 

 

 

 

​