FLOW 01 · INFORMATION PROCESSING
DIRECTION 01 · 정보가 숫자가 되는 순간 · 요구사항 · UML · UI · 설계
사용자가 원하는 것을 어떻게 찾아낼까
요구사항 · UML · UI · 설계
책 p.21–24 DIRECTION 01
QUESTION · 질문에서 시작합니다요구사항은 기다린다고 저절로 나타나지 않는다. 개발자가 질문하고, 관찰하고, 비교하면서 찾아내야 한다.
“필요한 기능을 전부 말씀해 주세요.”
이렇게 물으면 사용자가 모든 것을 한 번에 말해 줄 것 같지만
실제로는 그렇지 않다.
매일 하던 일을 너무 당연하게 생각해서 말하지 않을 수도 있고,
지금 쓰는 방식이 불편한데도 다른 방법을 떠올리지 못할 수도 있다.
질문“예약 취소는 언제까지 가능한가요?”사용자가 알고 있는 규칙을 직접 듣는다.
관찰직원이 취소 사유를 별도 메모장에 적는다.말하지 않았던 실제 업무를 발견한다.
비교전화 예약과 온라인 예약의 차이를 본다.현재 방식에서 바뀌어야 할 지점을 찾는다.
질문하는 방법에 따라 답이 달라진다
직접 묻는다
사용자와 대화하면서 현재 업무와 원하는 기능을 확인한다.
가장 자연스럽고 많은 정보를 얻을 수 있지만,
질문하는 사람의 능력에 따라 결과가 달라질 수 있다.
실제로 일하는 모습을 본다
말로는 설명하지 않았던 행동이 보인다.
종이에 따로 적어 두거나,
같은 정보를 여러 번 입력하는 불편함도 발견할 수 있다.
기존 문서를 살펴본다
업무 규정, 신청서, 기존 프로그램 화면,
보고서 같은 자료를 보면 빠뜨린 요구사항을 찾는 데 도움이 된다.
여러 사람이 함께 이야기한다
서로 다른 입장의 사용자가 함께 의견을 내면
요구사항의 충돌을 더 빨리 발견할 수 있다.
상황먼저 써볼 방법얻고 싶은 것
사용자가 원하는 기능을 빠르게 파악인터뷰직접 표현한 요구
말하지 않은 불편까지 찾기관찰실제 행동과 숨은 문제
기존 시스템을 개선문서 분석현재 규칙과 업무 흐름
서로 다른 요구를 함께 정리워크숍충돌과 우선순위
요구사항은 서로 충돌하기도 한다
예약 서비스 담당자는 말한다.
“사용자가 로그인하지 않아도 바로 예약할 수 있었으면 좋겠어요.”
보안 담당자는 다른 말을 한다.
“누가 예약했는지 확실히 확인할 수 있어야 합니다.”
둘 다 틀린 요구는 아니다.
하지만 그대로는 동시에 만족시키기 어렵다.
기술 이름
요구사항을 찾아내고, 분석하고, 문서로 정리하고,
사용자와 다시 확인하는 과정은
도출 → 분석 → 명세 → 확인의 흐름으로 정리할 수 있다.
01목적을 확인한다편의성과 보안 중 무엇을 왜 원하는지 다시 묻는다.
02제약을 찾는다법·보안·일정·비용처럼 바꿀 수 없는 조건을 확인한다.
03합의 가능한 규칙으로 만든다예: 예약은 빠르게, 예약 조회는 본인 확인 후 허용한다.
조정된 요구사항
예약 생성은 로그인 없이 허용하되, 예약 조회·변경·취소는 본인 확인 후 허용한다.
두 요구 중 하나를 지우는 것이 아니라, 충돌하는 목적을 분리해 함께 만족시키는 규칙으로 바꾼다.
말로만 남기면 다시 애매해진다
회의에서는 모두 이해한 것 같았다.
그런데 며칠 뒤 개발자가 다시 묻는다.
“취소는 예약 시간 몇 분 전까지 가능한 거였죠?”
사람의 기억은 다르고,
말은 쉽게 바뀐다.
그래서 요구사항은 기록되어야 한다.
누구나 같은 의미로 이해할 수 있게 작성하고,
나중에 변경되었을 때 무엇이 달라졌는지도 추적할 수 있어야 한다.
다음 비밀
글만으로 복잡한 시스템을 설명하다 보면 또 다른 문제가 생긴다.
구조와 관계를 한눈에 보여줄 방법은 없을까?
요구무엇을 원하는가
→
명세어떤 조건으로 정했는가
→
설계어디에 반영했는가
→
테스트제대로 구현됐는가
REQUIREMENT EXAMPLE
IDREQ-RES-01
명세예약 취소는 예약 시작 120분 전까지 가능해야 한다.
검증120분 전은 허용, 119분 전은 거부되는지 경계값으로 확인한다.
더 찾아보고 싶다면846면 학습 아카이브에서 검색하세요.