이득:
- 기능적 요구사항과 비기능적 요구사항을 구별하고 인공지능의 지원을 통해 명확하고 측정 가능한 요구사항 표현을 작성하는 능력
- 인터뷰 노트에서 사용자 스토리, 수용 기준 및 범위 제한을 추출하기 위해 구조화된 프롬프트와 함께 인공 지능을 사용하는 기능
- AI가 생성한 요구사항의 모호성, 모순, 누락된 규칙을 확인하고 이해관계자와 확인하는 습관을 들이세요.
요구사항 분석은 시스템이 수행해야 하는 작업을 완전하고 명확하며 검증 가능한 방식으로 정의하는 작업입니다. MIS 전문가가 가장 많은 가치를 창출하는 단계 중 하나입니다. 왜냐하면 여기서 실수는 프로젝트가 끝날 때 기하급수적으로 커지기 때문입니다. 요구사항 분석에는 두 가지 기본 유형이 있습니다. 기능 요구 사항은 시스템이 수행해야 하는 작업을 설명합니다. "시스템은 주문을 확인할 때 고객에게 이메일을 보내야 합니다." 비기능적 요구사항은 성능, 보안, 유용성, 접근성 등 시스템의 품질을 설명합니다. "보고서 화면은 평균 로드 시 2초 이내에 열려야 합니다"는 비기능적 요구 사항입니다.
좋은 요구사항에는 세 가지 특성이 있습니다. 명확함(단일 해석 있음), 측정 가능함(테스트 가능한 임계값 있음), 추적 가능함(비즈니스 요구 사항이 무엇인지 명확함)입니다. "시스템은 빨라야 합니다"는 이들 중 어느 것도 충족하지 않습니다. "빠름"은 주관적이므로 측정할 수 없고 테스트할 수 없습니다. 이 단계에서 AI는 요구 사항 초안을 작성하고 모호한 문구를 포착하는 데 강력한 도움이 됩니다. 하지만 이해관계자만이 어떤 비즈니스 규칙이 실제인지 결정합니다.
사용자 스토리 및 승인 기준
현대 요구 사항 작성의 일반적인 형식은 "[역할]로서, [목적]을 위해 [기능]을 원합니다."라는 사용자 스토리입니다. 예: "영업 담당자로서 현장에서 빠르게 견적을 작성할 수 있도록 모바일 화면에서 할인 계산을 원합니다." 이야기는 짧고 비즈니스 지향적입니다. 기술적인 해결책을 강요하지 않습니다.
모든 이야기에는 수용 기준이 있어야 합니다. 즉, 이야기가 "괜찮다"고 간주되기 위해 충족되어야 하는 테스트 가능한 조건입니다. 자주 사용되는 패턴은 "주어진/언제/다음" 패턴입니다. "주어진: 고객이 VIP 세그먼트에 있습니다. 시기: 10,000TL 이상 주문. 그런 다음: 시스템이 5% 할인을 적용합니다." 이 패턴은 조건과 예상 결과를 명확하게 연결하므로 모호성을 제거합니다.
팁: 인공지능에 사용자 스토리를 작성할 때 "각 스토리에 대해 Give/When/Then 형식으로 최소 2개의 승인 기준을 생성하세요"라고 말하세요. 모델이 강제로 벤치마크를 생성하게 되면 요구사항에 숨겨진 격차가 드러납니다.
단계별: AI 지원 요구사항 추출
1단계 - 원시 입력을 수집합니다. 통화 기록, 이메일, 기존 스크린샷, 불만 사항 목록. 실제 입력이 많을수록 제작이 줄어듭니다.
2단계 - 첫 번째 스토리 세트를 추출합니다. 인공 지능에 원시 입력을 제공하고 사용자 스토리 초안을 생성하도록 합니다. 이 단계는 전체 목록이 아니라 첫 번째 단계입니다.
3단계 - 승인 기준을 추가합니다. 각 스토리에 대해 주어진/언제/다음 기준을 생성합니다. 기준을 제시할 수 없는 이야기는 실제로 그것이 충분히 정의되지 않았다는 것을 의미합니다.
4단계 - 모순과 공백을 검색합니다. AI에게 "이러한 요구 사항 사이에 모순, 중복 또는 정의되지 않은 상황이 있습니까?"라고 물어보세요. 물어보고 확인해 보세요. 결과를 인간으로 필터링합니다.
5단계 - 우선순위를 정하고 확인합니다. 비즈니스 가치와 긴급성을 기준으로 이해관계자와의 스토리 우선순위를 정하세요. 우선순위 결정은 AI가 아닌 사업부에 속합니다.
비기능적 요구사항을 잊지 마세요
대부분의 프로젝트는 기능적 요구사항을 작성하면서 기능적이지 않은 부분을 잊어버리기 때문에 현장에서 어려움을 겪습니다. 보고서는 "올바르게" 작동할 수 있지만 여는 데 45초가 걸리면 아무도 이를 사용하지 않습니다. 다음 표는 일반적으로 간과되는 비기능적 요구사항 유형과 측정 가능한 작성 예를 보여줍니다.
장르
나쁜 표현
측정 가능한 표현
성능
"빨리야 해"
"평균 로드에서 쿼리 응답 < 2초"
접근성
"누구나 사용할 수 있어야 한다"
"WCAG 2.1 AA 규격, 전체 키보드 탐색"
보안
"안전해야 해"
"개인 데이터는 저장 시 암호화되며 액세스는 역할 기반입니다."
가용성
"쉬워야 해요"
"신규 사용자는 교육 없이 3단계로 주문을 완료합니다."
가용성/연속성
"충돌하면 안 돼"
"월간 가동 시간 ≥ 99.5%"
세 가지 미니 케이스: 숫자로 알아보기
사례 1 — 측정할 수 없는 필요의 대가. "신고 화면은 빨리 열려야 한다"는 요구 사항으로 은행에서 개발한 화면은 현장 로드 시 22초 만에 열렸다. 개발자는 자신의 환경(2초)에 "fast"라는 단어를 제공하고 있다고 생각했습니다. 요구 사항이 "최대 피크 시간에 < 3초, 실제 처리량"으로 작성되었다면 테스트에서 문제가 발견되었을 것입니다. 재개발 비용은 3주가 소요되며 상당한 추가 비용이 발생합니다.
사례 2 - 허용 기준에 따라 포착된 격차. 전자상거래 프로젝트에서 '시스템 할인 적용' 스토리에 대한 승인 기준을 작성하는 동안 이해관계자는 할인이 쿠폰과 충돌하고 VIP 할인이 발생하면 어떤 일이 발생하는지 전혀 논의되지 않는다는 점에 주목했습니다. 단일 Give/When/Then 질문으로 실행 전 이중 할인 오류가 방지되었습니다. 이 오류로 인해 유사한 프로젝트에서 심각한 수익 손실이 발생했습니다.
사례 3 — AI가 만든 규칙. HR 프로젝트에서는 AI가 요구사항 초안에 '퇴직 요청은 24시간 이내에 자동 승인된다'는 문구를 추가했다. 회의에서는 그러한 자동 승인이 논의되지 않았습니다. 그 모델은 “합리적”으로 보이는 규칙을 만들어 냈습니다. 전문가는 각 요구사항 옆에 “출처: 어떤 인터뷰/문서?”라고 적습니다. 열을 추가하여 출처가 없는 문장 4개를 제거했습니다.
약한 프롬프트 / 강한 프롬프트
약한 프롬프트:
이 프로젝트에 대한 사용자 스토리를 작성하세요.
강력한 프롬프트:
귀하의 역할: 귀하는 MIS 비즈니스 분석가입니다. 아래 인터뷰 노트에서 사용자 스토리를 추출하십시오. 규칙:- 형식: "[역할]로서, [목적]을 위해, 나는 [기능]을 원합니다."- 각 스토리에 대해 최소한 2개의 승인 기준을 주어진/때/다음 형식으로 작성하십시오.- 각 스토리 옆에 "소스" 열을 추가하십시오: 어떤 문장에서 나온 것입니까?- 노트에서 명확하지 않은 규칙에는 [불확실] 라벨을 붙이십시오. 피팅.- 측정 가능한 비기능적 요구사항(성능, 보안, 접근성)을 별도의 섹션에 작성합니다. 인터뷰 메모:[텍스트]
강력한 프롬프트는 스토리 형식, 승인 기준, 소스 추적성 및 비기능적 요구 사항을 모두 한 번에 적용합니다. 이렇게 하면 출력을 더 쉽게 제어할 수 있습니다.
복사 가능한 템플릿 4개
1) 요구사항 설명:
아래 요구 사항을 검토하세요. 모호하거나, 통약할 수 없거나, 둘 이상의 해석이 가능한 각 진술에 표시하고 각각에 대해 명확한 질문을 작성하십시오. 답을 지어내지 마세요. 요구사항: [텍스트]
2) 모순 스캐닝:
아래 요구사항 목록에서 서로 모순되거나, 반복적이거나, 논리적 공백을 남기는 항목을 찾아보세요. 항목 번호와 한 문장으로 된 근거를 포함하여 각 결과를 보고합니다. 목록: [텍스트]
3) 승인 기준 생성:
제한 및 예외 사례를 포함하여 다음 사용자 스토리에 대한 허용 기준을 주어진/때/다음 형식으로 4개 이상 작성하세요. 또한 명확하지 않은 사항도 나열하십시오. 스토리: [텍스트]
4) 범위 개요:
다음 요구 사항에 따라 "범위 내" 및 "범위 외" 항목의 초안을 2열 테이블로 작성합니다. 확실하지 않은 항목에는 [확인 필요]라는 라벨을 붙입니다. 요구사항: [텍스트]
일반적인 실수
- 해결책이 필요하다고 생각합니다. "드롭다운 메뉴 추가"는 필수 사항이 아니라 해결책입니다. 요구 사항에는 "사용자가 정의된 목록에서 국가를 선택할 수 있어야 합니다"라고 나와 있습니다. IT 팀이 솔루션을 설계합니다.
- 기능하지 않는 항목은 건너뜁니다. 단순히 “무엇을 해야 할지”만 적고 “어떻게 해야 할지”(속도, 보안, 접근성)를 잊어버리는 것이 가장 흔하고 비용이 많이 드는 허점입니다.
- 측정할 수 없는 형용사를 사용합니다. "빠르고, 쉽고, 안전하고, 사용자 친화적"과 같은 단어는 임계값이 없으면 유효하지 않습니다.
- AI가 만들어낸 규칙을 인지하지 못하는 것. 모델은 "합리적인" 규칙을 추가할 수 있지만 실제로는 그렇지 않은 규칙을 추가합니다. 모든 필요에 맞는 리소스를 요청하세요.
- 우선순위를 AI에 맡깁니다. 가장 먼저 해야 할 일은 비즈니스 가치 결정입니다. 사업부는 이것을 제공합니다.
주의: 요구 사항 분석에서 가장 위험한 문장은 "모든 사람이 이미 이것을 알고 있습니다"입니다. 무언의 가정은 문서에 포함되지 않으며 코드에 포함되지 않으며 현장에 나타납니다. AI에게 “이 요구 사항에 가정되어 있지만 기록되지 않은 것은 무엇입니까?”라고 물어보세요. 이러한 숨겨진 가정을 가시화합니다.
요약하면
요구사항 분석은 시스템이 수행해야 하는 작업을 명확하고 측정 가능하며 추적 가능한 방식으로 정의합니다. 기능적 요구사항은 직무를 설명하고, 비기능적 요구사항은 자질을 설명하는데, 후자는 종종 잊혀집니다. 사용자 스토리와 주어진/언제/다음 수용 기준은 불확실성을 제거하는 강력한 도구입니다. 인공 지능은 스토리보드 생성, 승인 기준, 충돌 감지 및 질문 명확화를 크게 가속화합니다. 그러나 비즈니스 규칙의 정확성, 범위 및 우선 순위 결정, 각 문장의 출처는 인간의 책임입니다. 출처가 없고 측정할 수 없는 요구 사항을 마무리하지 마세요.
응용과제
가상의 "온라인 약속 시스템"에 대한 한 문단의 비즈니스 요청을 작성합니다(예: "고객은 온라인으로 약속을 잡을 수 있어야 하고 직원은 달력을 볼 수 있어야 합니다"). (1) 이 요청에 대한 강력한 프롬프트를 통해 최소 5개의 사용자 스토리와 각각에 대한 2개의 승인 기준을 만듭니다. (2) 모델이 생성한 기준(예: 동시 이중 약속, 취소 규칙)에서 숨겨진 공백을 2개 이상 찾습니다. (3) 측정 가능한 형태로 비기능적 요구사항을 3개 이상 포함합니다. (4) "범위 외" 항목을 3개 이상 식별합니다. (5) 모델이 만들어낸 규칙을 표시하고 이를 어떻게 확인할 것인지 작성하세요.
체크리스트
- [ ] 기능적 요구사항과 비기능적 요구사항을 별도로 작성했습니다.
- [ ] 모든 요구사항은 명확하고 측정 가능하며 테스트 가능합니다.
- [ ] 각 이야기에는 주어진/언제/그때 승인 기준이 있습니다.
- [ ] 각 요구사항의 출처(대화/문서)를 추적할 수 있습니다.
- [ ] AI가 만들어낸 가능한 규칙을 표시하고 확인을 위해 남겼습니다.
- [ ] 우선순위화는 사업부서와 함께 했습니다.