요구사항 분석과 모델링

Preface

 

요구사항 분석의 중요성은 이전 장에서부터 꾸준히 언급되어 왔다.

그런데 이번 장을 공부하던 도중 불현듯 요구사항 분석 단계에서 칭하는 '고객'이란 누구를 의미하는 것인가에 대한 생각을 하게 되었다.

 

나는 불과 몇 시간 전까지만 해도 '고객'이란 당연히 일반적인 소프트웨어 사용자들을 일컫는 말이라고 생각했지만, 조금만 고민을 해보니 요구사항 분석 단계에서 사용되는 '고객'이란 단어는 일반 대중이 아닌, 발주자(스폰서)를 칭한다는 것을 알 수 있었다.

 

순간 '아차' 하는 생각이 들며 조금 더 깊이, 조금 더 신중히 생각해야겠다는 마음가짐을 다질 수 있었다.

 

추가로 '정보 모델'과 'ERM' 등 같은 장에서 언급되는 용어들끼리는 서로 연관성을 띄고 있어 한 가지 개념을 정확히 이해하면 추가적인 개념들을 이해하기 훨씬 수월하겠다는 생각이 들었다. 

---

1. 요구사항 분석 정의

 

- 요구사항 분석 과정 : 시스템의 목표를 확립하는 과정

 

- 요구사항 분석 : 행동을 취하기 전 문제에 대해 연구하는 것

→ 시스템의 기능, 성능, 다른 시스템과의 인터페이스 규명 등

---

2. 분석의 특징

 

- 어떻게(how to)가 아니라 무엇(what)에 초점을 맞춘다.

 

- 분석가의 위치는 대부분 수비적이다.

 

- 성공보단 실패 및 실수 방지에 초점을 맞추어야 한다.

 

- 최근엔 청소년 시기부터 컴퓨터 교육이 실시되어 응용 분야에 대한 지식이 필요하다.

 

- 시스템 분석가(엔지니어)의 자질 및 업무

① 비즈니스 및 응용 분야에 대한 지식

② 컴퓨터에 대한 지식

③ 의사소통 능력

④ 시스템 해결 방안 제시

⑤ 요구사항 명세서 작성

 

- 요구사항 명세서 작성 조건

① 고객과 개발자가 쉽게 이해할 수 있어야 함

② 고객과 개발자가 동의한 것이어야 함

③ 시스템의 모든 기능을 명확하게 기술해야 함

④ 고객이 얻을 것이 무엇인지 구체적으로 기술해야 함

⑤ 모든 제약 조건을 명시해야 함

⑥ 확인 기준을 제시해야 함

⑦ 원하는 품질, 상대적 중요성, 품질의 층적 및 확인 방법을 명시해야 함

⑧ 시스템의 포용성 및 오류 조건이 명시돼야 함

 

- 분석이 어려운 이유

① 의사소통 문제

② 요구사항의 변화

③ 분석 도구 미비

④ 문서화의 어려움

⑤ 정치적 문제

⑥ 일 할당 문제

 

- 개발 이전 요구사항 동결(freezing)이 필요하다.

→ 기준선 문서 작성(baselined document) : 이후 변경은 개발자 및 사용자의 동의 필요

---

3. 모델링

 

- 모델링 : 만들고자 하는 대상을 특정 목적에 맞추어 사용이 용이한 형식으로 표현하는 것

→ 추상화 작업

 

- 모델 : 실제 존재를 의도적으로 불완전하게 표현한 추상적인 것

① 세부적인 사항은 생략하여 쉽고 필수적인 것만 표현

② 단순하며 모호성이 없어야 함

 

- 모델링은 도표를 사용하여 표현한다.

 

- 모델의 3요소

① 표현(representation) : 텍스트가 아닌 시각적 표현 → ex) 정보 모델

② 규약(convention) : 도표에 있는 기호들에 대한 약속

③ 상술(specification) : 시각적 표현을 텍스트화 하는 과정 → 미니 명세서, 자료 사전 등에 저장

---

4. 소프트웨어 시스템의 3가지 관점

 

- 한 모델을 통해 여러 관점을 나타내는 것은 어렵다.

 

- 모델은 불완전하며 부정확하지만 중요한 핵심은 포함하고 있다.

 

[시스템의 3가지 관점]

 

- 기능 관점(function space) : 시스템이 어떠한 기능을 수행하는가 (어떤 결과가 나오는가)

① 계산에 초점

② 계산 순서와 데이터 생성 및 도착 순서는 기술 X

③ 버블 도표(bubble charts)라 불리는 자료 흐름도를 통해 도식적으로 표현

→ 자료 흐름도 : 프로세스 + 자료의 흐름, 시스템이 제공하는 기능에 초점, 하향식 접근 방법

 

- 동적 관점(dynamic sapce) : 시스템의 상태와 상태 변화의 원인들을 묘사

① 시간 변화에 따른 시스템의 동작과 제어에 초점

② 상태 변화도(STD : State Transition Diagram) : 제어 흐름의 순서 나타내지 않음

③ 사건 추적도(event trace diagram) : 제어의 흐름이 어떻게 이동하는지 보여줌

 

- 정보 관점(information space) : 시스템에 필요한 정보를 보여줌으로써 정적인 정보 구조 포착

① 시스템에 사용되는 정보 객체를 찾아냄

② 객체의 특성과 이들 사이의 관계 및 연관성을 규명

③ 다른 두 관점보다 실세계를 정확히 묘사

④ 다른 두 관점과 달리 변하지 않고 안정감이 있음

⑤ 시스템 데이터베이스 분석에 주로 사용

→ ex) ER 모델 (Entity-Realtionship Model)

 

- 세 관점의 통합적 사용이 중요하다.

 

 

 

 

 

참고 문헌 : 윤청, 『소프트웨어 공학 에센셜』(생능출판), 2019, p.140~163.