요구사항을 받았는데, 요구사항이 아닐 수 있습니다! 요구사항이 아니라면 사용자가 진짜로 원하는게 무엇인지 알아내야합니다. 애매한 요구사항에서 진짜 요구사항을 찾아내는 연습을 해봅시다.

(1) '연습문제 #33'을읽습니다.

(2) 1-5번까지 문제를 클라이언트가 건넨 요구사항이라 상상하며 문제를 풀어봅시다.

(3) 진정한 요구사항이 아닐 경우 어떻게 질문을 해야하는지, 무엇을 알아야 하는지, 왜 그렇게 생각하는지 등 나의 생각을 작성해보세요.

❗️ 풀이과정은 문제당 300자 이상으로 작성해주세요.

❗️ 책에 있는 해답은 참고용이며, 본인의 생각을 잘 작성해주세요.

요약 : 요구 사항은 아키텍처/ 설계 / 사용자 인터페이스가 아니다.

요구 사항은 필요를 표현하는 것이다.

사용자가 되어보아라. 의뢰인이 필요로 하는 방식이어야 한다.

정책은 메타데이터이다.

프로젝트 내내 요구사항으 수집하라. 궤도에서 벗어나지 않을 수 있다. 과정 중 계속 피드백 받으라.

프로그래머는 사람들이 원하는 바를 깨닫도록 돕는다.

자신이 원하는 바가 뭔지 아는 사람은 없다.

📌 연습문제 33

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

1. 응답시간은 500ms 이하여야 한다.

💡 나의 해답 : 응답 시간은 유저의 사용성에 있어 굉장히 중요한 요소이다. 왜냐하면 단 몇초만 delay 되어도 F5를 갈겨댈께 분명하니까! 그래서 이런 너무 당연한 사항은 요구 사항이라고 볼 수 없다. 그 어떤 클라이언트가 "응답 시간을 한~ 2600ms 로 해주세요~" 라고 하는 이상한 사람은 없을테니까.

그러니까 암튼 응답시간은 가능하다면 빠르게 유지하는게 좋겠다.

2. 모달 창의 바탕색은 회색이다.

💡 나의 해답 : 요구 사항이... 맞는 것 같다. 잘 이해 한진 모르겠지만 뭔가 사이트의 테마 색상을 지정 해주는게 아닐까? 그게 아니라면... 바탕색을 굳이 회색이라고 이야기 할 필요가 있을까?

생각 해보니 그럴바엔 "전체 사이트 테마 색상을 회색으로 생각하고 계신건가요?" 라고 한 번 물어보는게 좋을 것 같다.

3. 애플리케이션은 프론트엔드 프로세스 몇 개와 백엔드 서버로 구성된다.

💡 나의 해답 : 이거야 말로 '요구 사항은 아키텍처나 설계가 아니다'의 전형적인 케이스이다. 뭔가 당연한 말이라기 보다도 이건 개발자가 보고 판단할 영역인거지 클라이언트가 굳이굳이 딱 정해줄 그런 사항이 아닌거 같다.

4. 사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면 시스템은 입력 필드를 깜빡이고 입력을 거부한다.

💡 나의 해답 : 숫자만 입력 받게끔 제한을 두어달라고 요구하는게 더 낫지 않았을까? 필드를 깜빡이는게 중요한건지 글자가 들어오지 못하게 하는게 중요한건지 확인 해보아야겠다.

5. 이 임베디드 애플리케이션의 코드와 데이터 크기는 32Mb 이내여야 한다

💡 나의 해답 : 이것은 요구 사항이 맞다! 임베디드 같은 경우에는 하드웨어 제한을 많이 받기 때문에 그렇다. 꼭 필수적으로 크기나 메모리 할당량 등을 필수적으로 맞춰주어야 한다.

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

2. 📖 책의 해답 : 이 문장 자체만으로는 진짜 요구사항이 아니다. 하지만 진짜로 무엇이 필요한지 알아내려면 마법의 질문을 던져야 한다. ”왜?”(중략)

3. 📖 책의 해답 : 이 문장은 요구사항이 아니다. 이것은 아키텍처다. 이런 종류의 것과 마주쳤다면 사용자가 무슨 생각을 하는지 알아내기 위해 깊이 파고들어야 한다.

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

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