GCP Cloud Engineer - 68

요구사항 분석

• ㅁ 누가: 시스템의 사용자, 개발자, 이해관계자 등을 포함하여 시스템에 영향을 주는 모든 주체들을 식별

• ㅁ 무엇: 필요한 기능의 주요 영역을 명확하고 모호하지 않게 설정

• ㅁ 왜: 시스템이 필요한 이유, 다루거나 해결하려는 문제의 정의, KPI, SLO, SLA 정의에 도움

• ㅁ 언제: 실제적인 타임라인 설정과 범위 유지

• ㅁ 어떻게: 시스템이 지원해야 할 사용자 수, 서비스 요청의 평균적인 페이로드 크기, 지연 시간 요구사항 등을 포함한 기능 이외의 요구사항 해결

디자인 활동

• ㅁ 사용자 역할 정의: 사용자의 목표를 나타내며, 사람 뿐만 아니라 시스템의 다른 행위자(예: 다른 마이크로서비스에 액세스 중인 마이크로서비스 클라이언트)도 포함

• ㅁ 역할 브레인스토밍: 가능한 많은 역할 작성 및 단일 사용자로 간주하여 초기 집합 정리

• ㅁ 역할 통합: 중복되거나 관련된 역할 식별 및 그룹화하여 역할 통합 및 압축

사용자 캐릭터의 중요성

• ㅁ 사용자 역할에 캐릭터 부여: 사용자의 특징을 가상으로 나타내어 설계자와 개발자가 고려

• ㅁ 예시: 은행 애플리케이션의 바쁜 워킹맘 조슬린이 시간과 비용을 절약하면서 일반적인 은행 업무를 온라인으로 처리하는 요구사항 반영

사용자 사례의 작성

• ㅁ 구조화된 방식: '[사용자 유형]으로서', '[행위]를 통해 [혜택을 얻고자] 합니다'

• ㅁ 목적 보여주는 제목 부여 및 사례 간결한 설명

INVEST 기준 적용

• ㅁ Independent: 사례가 독립적이어야 하며 우선순위 지정 및 계획 문제 방지

• ㅁ Negotiable: 고객과 개발자 간의 명확한 합의까지 활발한 논의와 협업 필요

• ㅁ Valuable: 사례가 고객에게 실질적인 가치 제공

• ㅁ Estimatable: 사례가 예측 가능해야 하며 세부정보 충분히 포함

• ㅁ Small: 사례가 간단하고 범위가 좁아야 하며 빠른 피드백 지원

• ㅁ Testable: 사례의 테스트 가능하여 요구사항 충족 및 완료 확인 가능