구조적 분석

소프트웨어 개발에 있어 요구분석 단계는 중요하고도 어려운 단계이다. 많은 정보가 수집되어야 하며 의사소통의 어려움도 극복해야 하는 숙제 중 하나다. 이러한 작업을 증명하기 위한 방법은 매우 다양하다. 그중 프로세스 사이의 데이터 흐름을 파악하여 요구사항과 시스템을 파악하는 방법으로 구조적 분석이 있다. 구조적 분석(Structural Analysis)은 시스템의 기능적 요구사항을 구조화하고 조직화하는 단계이다. 이를 통해 요구사항 간의 관련성과 의존성을 이해하고 분해된 요구 모듈 간 관계를 분석하여 시스템의 구조를 설계할 수 있다. 구조적 분석은 데이터 흐름 다이어그램(DFD), 상태 전이 다이어그램, 클래스 다이어그램 등의 모델링 기법을 활용하여 수행된다. 전통적 방법으로서 이 단계에서는 요구사항이 어떻게 상호작용하고 구성되는지를 시각화하여 파악한다.

소프트웨어 개발 프로젝트 초기 단계부터 요구사항을 명확하게 이해하고 효과적으로 관리할 수 있는 구조적 분석은 궁극적으로 프로젝트의 성공 확률을 높일 수 있다. 이 방법은 크게 다음과 같은 단계로 수행되고 여기에 쓰이는 도구도 확인한다.

요구사항 분해
요구사항 상호 연계
요구사항 계층 구조화
요구사항 흐름도

데이터 흐름도(Data Flow Diagram, DFD):
- 사용자 요구사항 기반으로 데이터가 시스템 내에서 어떻게 흐르는지 도식화하며 프로세스(원 또는 둥근 사격형), 외부 엔티티(사각형), 저장소(열린 사각형), 데이터 흐름(화살표) 등을 기호로 하여 시스템 데이터 흐름을 구조화
- 시스템 모델링에 중요한 추상화와 단계적 분해의 원리를 적용하여 하향식 분할을 통해 복잡한 문제를 작고 독립적 문제로 나누어 하나씩 해결할 수 있는 방법으로 접근
- 서로 다른 단계 사이 자료 흐름은 표현에 일관성이 필요하고 완벽성 검사와 일관성 검사 시행
- 크기가 너무 커진다면 프로세스를 그룹화하여 단계적으로 표현하며 하나의 분석에서 한 계층의 DFD만 작성하고 프로세스는 7개 전후로 포함되도록 함
자료 사전(Data Dictionary): 시스템 내에서 사용되는 데이터 항목의 정의, 형식, 구조를 문서화하며 자료 사전은 데이터 항목들의 호환성과 일관성을 확인하고 중복을 제거
- 일반적 언어사전과 형식은 동일
- 자료요소 이름이 여러 단어 구성 시 자료사전 표제어에 밑줄 연결
- 수식은 자료요소와 연산자(+, [], |, ”, 등)로 구성
질의-응답 목록(Question and Answer List): 사전에 정해진 항목에 따라 요구사항을 구체화하는 도구로 시스템과 사용자의 상호작용을 정확하게 이해하고 구조화
- 질문: 이해 관계자에게 특정 요구사항에 관한 질문 포함
- 답변: 이해 관계자로부터 받은 답변 기록. 이 답변은 해당 요구사항에 대한 정보와 이해 관계자의 의견 표시
- 질의자: 각 질문에 대한 원래 질문자 또는 요구사항 분석을 수행한 사람의 이름 기록. 의문 사항이 생길 경우 해당 정보의 출처 확인용
- 날짜: 각 질문이나 답변이 만들어진 날짜 기록. 문서 갱신/추적용
- 참고: 다른 문서나 자료와의 연결 표시
- 상태: 질문이나 답변의 상태 표시, 추적
- 비고: 해당 질문이나 답변에 대한 추가 설명이나 주석 기록
유스케이스(Use Case): 사용자와 시스템 간의 상호작용을 나타내는 시나리오 기반 기술로 특정 목적 달성을 위한 사용자 관점에서 시스템과의 상호작용 과정 기술
- 액터(Actor): 시스템 내에서 주요 기능을 수행하는 역할 또는 시스템과 상호작용하는 주체로 시스템 사용자, 다른 시스템, 외부 장치 등
- 유스케이스 명(Use Case Name): 특정 기능 또는 시나리오의 간결하고 명확한 이름으로 유스케이스를 식별
- 설명(Description): 유스케이스의 목적과 내용을 간단 설명
- 사전조건(Preconditions): 유스케이스가 시작되기 전에 충족되어야 하는 조건 설명
- 주요 시나리오(Main Scenario): 유스케이스의 핵심적인 동작과 순서 설명으로 시스템과 액터 간의 상호작용을 순차적으로 나열
- 대안 시나리오(Alternative Scenarios): 주요 시나리오 이외의 다양한 상황에 대한 시나리오를 설명하며 주로 예외 상황이나 오류 처리 사용
- 결과(Results): 유스케이스의 완료 후 기대되는 시스템의 상태 변화나 출력물 등 결과 기록

분석 과정

구조적 분석의 세부적인 과정은 크게 4단계로 나눠볼 수 있다.

🚩 단계 1: 요구사항 수집 및 문서화

시스템에 대한 요구사항을 수집하고 구조화 및 문서화한다. 이 요구사항은 고객, 사용자, 도메인 전문가 등과의 인터뷰, 설문조사, 관찰 등 다양한 방법으로 얻을 수 있으며 최종적으로 기능적 요구사항(시스템이 수행해야 하는 작업)과 비기능적 요구사항(성능, 안전성, 보안 등)으로 구분될 수 있다. 이 과정을 통해 모호한 내용을 명확히 하고 요구사항 간의 관련성과 의존성을 파악, 중복되거나 충돌하는 요구사항을 논리적 블록으로 그룹화, 해결한다.

🚩단계 2: 데이터 흐름 다이어그램 작성

명세화된 요구사항을 기반으로 소프트웨어의 핵심 문제를 파악하고 분석할 수 있는 구조로 정리한다. 이때 데이터 흐름도(DFD), 자료사전, 프로세스 명세 등의 도구를 활용한다.

– 주요 프로세스 식별: 수집된 요구사항을 기반으로 시스템 내의 주요 기능적 프로세스 식별하며 DFD로 표현 (시스템의 입력, 출력, 처리 과정 포함)
– 데이터 흐름 식별: 프로세스 간에 주고받는 데이터(정보) 흐름 식별
– 데이터 저장소 식별: 시스템 내 사용되는 데이터 저장소를 식별하는데 이는 데이터의 정의, 속성, 구조 등을 포함하고 이를 데이터 요소 간의 관계와 종속성을 파악

🚩단계 3: 데이터 흐름 다이어그램 작성 및 분석

분석된 요구사항이 사용자의 기대와 일치하는지 검증하여 문제가 없는지 확인하는 단계로 사용자와 지속적인 의사소통으로 유스케이스 테스트나 프로토타입 방식을 사용하여 실제 사용자의 반응을 수집할 수 있다. 특히 요구사항과 부합하며 일관성 있는 모델을 구축하는 것이 중요한데 이 결과를 바탕으로 소프트웨어의 전체적인 아키텍처를 설계할 수 있다. 특히 모듈화, 계층화, 컴포넌트 구조 등을 고려하여 시스템 구조를 결정한다.

– 0레벨 DFD 작성: 주요 프로세스, 데이터 흐름, 데이터 저장소 등을 기반으로 0레벨 DFD를 작성하며 이 다이어그램은 시스템의 전체 구조를 보여주고 각 프로세스와 데이터 흐름의 관계를 가시화
– 상세화: 0레벨 DFD를 기반으로 더 상세한 1레벨 DFD를 작성하여 프로세스를 세분화하고 데이터 흐름을 더욱 구체적으로 표현
– 유효성 검사: 작성한 DFD를 검토, 논리적 오류나 모순점이 있는지 확인

🚩단계 4: 문서화 및 의사소통

작성한 DFD를 문서화하여 요구사항 명세서나 설계 문서에 포함한다. 이에 개발팀 간 의사소통을 원활하게 하고 시스템 구조를 이해하는 데 도움을 준다. 요구사항이 변경되거나 갱신이 되면 요구사항 관리를 통해 변경된 요구사항에 따른 작업의 우선순위를 조정하고 추적 관리한다. 이 문서들은 개발 및 테스트 과정에서 참고 자료로 활용한다. 다시 말해 문서화와 의사소통의 중요성은 각기 다음과 같다.

명확한 이해: 문서화로 프로젝트팀의 구성원, 고객, 스테이크 홀더 등 모두가 요구사항을 명확하게 이해 가능
기능 및 범위의 정의: 문서화로 시스템의 기능과 범위가 정확하게 정의되며 프로젝트 방향성 보장
변경 관리: 요구사항이 변경될 경우, 문서화로 변경 내역을 추적하고 관리 가능
품질 향상: 문서화된 요구사항은 개발자들이 시스템을 설계하고 구현할 때 일관성 있고 정확한 정보를 참조할 수 있도록 지원

이해 관계자 간의 의사소통: 프로젝트 구성원, 고객, 이해당사자 간 이해로 프로젝트 목표를 달성하기 위한 방향을 정하는 중요 기반
오해 방지: 의사소통으로 모든 이해 관계자들이 동일한 의미로 요구사항을 이해할 수 있도록 지원하여 오해나 혼란이 줄어들면서 프로젝트 품질 향상
피드백 수렴: 의사소통을 통해 고객이나 사용자의 피드백을 수렴하고 반영하여 요구사항의 정확성과 적절성 향상
변경 관리: 프로젝트 진행 중 요구사항이 변경 시 이를 이해 관계자들과 공유하여 일관성을 유지하고 변경에 따른 영향을 평가 가능