요구사항·개발 방법

실기 학습 목표

요구사항의 종류와 개발 모델을 사례의 핵심 단서로 구분한다.

핵심 이론

기능 요구사항은 시스템이 할 동작, 비기능 요구사항은 성능·보안·사용성 등 품질과 제약이다. 응답시간에는 부하·측정 조건·한계값을 함께 적어 검증 가능하게 한다.

요구 도출 → 분석 → 명세 → 확인의 흐름에서 이해관계자 합의와 추적성을 확인한다. 현행 시스템은 구성·기능·인터페이스·인프라 관점에서 파악한다.

폭포수는 순차 단계, 프로토타입은 시제품을 통한 요구 확인, 나선형은 반복별 위험 분석, 애자일은 짧은 피드백 주기와 변화 대응이 핵심이다.

스크럼은 애자일의 한 프레임워크다. 단지 2주 반복이라는 이유만으로 스크럼이라고 단정하지 않는다. 방법론 이름과 사례의 목적을 함께 연결한다.

요구사항은 검증 가능한 문장으로 읽는다

‘예약을 취소한다’는 동작 요구이고 ‘동시 사용자 500명일 때 95% 요청이 2초 이내’는 성능 요구다. 둘 다 중요한 요구사항이지만 기능과 품질이라는 분류가 다르다. ‘빠르게 작동한다’만으로는 충족 여부를 측정하기 어려워 검증 가능성이 부족하다.

요구사항 문제를 풀 때는 동작의 주체·입력·처리·결과를 먼저 표시한다. 이어 응답시간·보안·호환성·법규·개발 환경처럼 동작에 붙는 품질이나 제약을 찾는다. 요구 도출은 의견 수집, 분석은 충돌·우선순위 정리, 명세는 문서화, 확인은 요구가 올바르고 합의됐는지 점검하는 과정이다.

개발 모델은 사례의 목적을 연결한다. 시제품으로 모호한 요구를 확인하면 프로토타이핑, 반복마다 위험을 평가하면 나선형, 짧게 구현하고 피드백에 따라 우선순위를 바꾸면 애자일의 특징이다. 단순히 반복한다는 공통점만으로 같은 모델로 답하지 않는다. 폭포수에서도 실제 작업 중 피드백이 전혀 불가능하다는 식으로 지나치게 단정하지 않는다.

풀이 예시

제품 팀은 모든 기능을 한 번에 확정하지 않는다. 2주마다 실행 가능한 기능을 시연하고 사용자 피드백을 받은 뒤 다음 작업의 우선순위를 조정한다. 계획 변경을 수용하고 짧은 주기로 가치를 전달하는 이 개발 접근법의 포괄적인 명칭을 쓰시오. 특정 프레임워크 이름이 아니라 접근법을 답한다.

예시 정답

애자일

풀이 과정

작동하는 결과물을 짧게 반복 제공하면서 피드백과 변화에 대응하는 접근은 애자일이다. 2주라는 기간만으로 스크럼의 역할·이벤트가 모두 운영된다고 단정할 수 없으므로 문제는 상위 개념을 요구한다.

답안 점검

위 풀이 예시의 답을 가린 뒤, 핵심 이론의 규칙을 적용해 직접 풀어 보세요. 코드와 계산 문제는 중간값·단위·최종 출력의 순서를, 용어 문제는 지문의 핵심 단서와 답의 의미를 점검하세요. 해설과 다른 부분이 있으면 어느 조건을 놓쳤는지 확인하고 연결된 실기 문제로 다시 연습하세요.