개념 한 쪽
요구분석기법은 사용자가 무엇을 원하는지 밝혀 '무엇(What)을 만들지'를 정의하는 단계의 도구들이다. 정보처리기사에서는 워크스루, 정형·비정형 명세, DFD와 자료 사전이 자주 나온다.
이 개념을 문제로 확인하고 싶으면 이 개념 문제 10개 풀기 회원용
가입 없이 오늘의 10문제 바로 풀기 →
출제기준 단원 「요구분석기법」의 공개 문제 3개를 묻는 꼴별로 나누면 이렇습니다.
| 묻는 꼴 | 문제 수 | 무엇을 묻나 |
|---|---|---|
| 활동·범위 포함 여부 판정 | 1 | 요구분석 단계에 속하는 작업인지 판단 |
| 요구분석 진술의 옳고그름 판단 | 1 | 특성·역할·난점에 관한 진술 중 옳지 않은 항목 |
| 비기능 요구의 내용 판정 | 1 | 제시된 문장이 비기능적 요구인지 판단 |
요구사항 분석은 시스템의 기능적·비기능적 요구사항을 도출하고 명세화하는 단계다. 타당성 조사와 비용·일정 제약 설정이 포함되고, 최종적으로 요구사항 정의 문서화가 이루어진다. 설계 명세서 작성은 '어떻게(How)' 구현할지 정하는 설계 단계의 활동이므로 요구사항 분석과 구분된다.
이 단계에 필요한 기술은 이해관계자와의 인터뷰, 관찰, 질문 기술 등으로 정보를 수집하는 것과 수집된 정보를 모델로 작성해 구조화하는 것이다. 반면 설계 및 코딩 기술은 요구사항이 정해진 뒤 시스템을 실제로 구축하는 구현 단계의 기술이라 분석 단계와 거리가 멀다.
작성된 요구사항 명세서를 검토하는 대표 방법이 워크스루다. 워크스루는 검토회의 전에 명세서를 미리 배포해 사전 검토한 뒤, 짧은 검토 회의로 오류를 조기에 검출하는 비공식적 방법이다. 복잡한 절차나 엄격한 형식 없이 참여자들이 자유롭게 의견을 나누며 실수를 잡는 것이 핵심이고, 동료 검토·개발자 검토보다 덜 구조화되어 있다.
명세기법은 두 갈래다. 비정형 명세는 자연어를 사용해 이해하기 쉽지만 모호할 수 있고, 정형 명세는 수학적 원리를 사용해 표현이 간결하고 정확하지만 배우기 어렵다. 정형 명세의 대표 기법으로 Z가 꼽힌다. 분석 결과를 문서화하는 도구로는 자료흐름도(DFD), 자료 사전, 소단위 명세서(Mini-Spec)가 쓰이며, 이렇게 문서화된 결과는 시스템 유지보수에 유용하게 쓰인다. 다만 개발 비용이 가장 많이 소요되는 단계는 구현 및 테스트 단계이지 요구 분석 단계가 아니다.
시험에서는 '요구사항 분석과 거리가 먼 것은?' 꼴로 설계 명세서 작성이나 설계·코딩 기술을 보기에 섞어 낸다. '무엇을 정의하는 분석'과 '어떻게 구현하는 설계'를 가르는 것이 출제 포인트다. 워크스루는 "명세서를 미리 배포해 짧은 회의로 오류를 조기 검출"이라는 문구가 나오면 바로 답을 고르는 유형으로 자주 출제된다. 명세기법 문제에서는 Z를 비정형 명세로 소개하는 보기가 오답으로 등장하는 패턴이 반복된다.
소프트웨어 개발 방법 중 요구사항 분석(requirements analysis)과 거리가 먼 것은?
정답 ④ · 이 문제는 소프트웨어 생명주기 중 요구사항 분석 단계에서 수행하는 활동과 산출물을 구분할 수 있는지 묻고 있다. 요구사항 분석 단계에서는 사용자의 요구를 파악하고 타당성을 조사하며 비용과 일정 등의 제약사항을 도출하여 요구사항 명세서로 문서화한다.
요구사항 분석은 '무엇을' 할지 정의하는 단계이며, 설계 명세서 작성은 '어떻게' 구현할지 결정하는 설계 단계의 핵심 산출물이다.
소프트웨어 개발 단계에서 요구 분석 과정에 대한 설명으로 거리가 먼 것은?
정답 ② · 소프트웨어 개발 단계 중 요구사항 분석 단계는 사용자의 요구를 정확하게 파악하여 향후 설계 및 구현 단계의 기반을 마련하는 중요한 작업입니다. 이 과정에서 자료 흐름도(DFD)와 자료 사전(DD), 소단위 명세서(Mini-Spec) 등의 도구가 효과적으로 활용되며, 결과물을 문서화하여 추후 유지보수에 유용하게 사용합니다.
요구 분석 단계는 설계의 기반을 마련하지만, 실제 개발 비용이 가장 많이 소요되는 단계는 구현 및 테스트 단계이므로 해당 설명은 거리가 멉니다.
요구사항 분석이 어려운 이유가 아닌 것은?
정답 ② · 요구사항 분석이 어려운 이유가 아닌 것을 고르는 문제이다. 요구사항 분석이 어려운 대표적 이유로는 개발자와 사용자 간의 지식과 표현 차이, 사용자 요구의 모호성과 불명확성, 개발 중 요구사항의 지속적 변경 등이 꼽힌다.
사용자의 요구사항은 예외 상황이 많고 모호하며 자주 변경되므로, 예외가 거의 없다는 설명은 요구사항 분석의 어려움과 반대된다.
정보처리기사 풀이 세트에서 이 개념의 문제 10개를 바로 풀어 보세요.