자꾸 강조하는 이야기이지만 개발을 하기 전에는 사용자의 요구가 무엇인지 정확하게 파악하는 것이 중요하다.
이 단원에서는 요구사항을 어떻게 분석하는지 상대가 무엇을 요구하는지 정확하게 캐치하는 내용을 다룬다.
만약 내가 마라톤 경기를 하고 있다고 가정해보자. 가는 도중 너무 힘들어 조금 쉬었다가 갈 수도 있을것이고 운동화 끈이 풀려 끈을 묶고 갈 수도 있을 것이다.
하지만 쉬지도 않고 정말 열심히 달렸는데 도착지점이 정반대라면? 이는 정말 상상하기도 싫은 대형 사고임에 분명하다.
요구사항 분석이라는 말은 앞으로 있을 프로젝트의 방향을 정하는 것과 같다.
요구사항 분석에는 코딩, 설계와는 다른 특징을 많이 가지고 있다.
먼저 고객과의 의사소통이 가장 중요한 역할을 맡는다. 그래야만 상대가 어떤 기능을 원하고 어떤 기능은 원하지 않는지 알 수 있는 가장 좋은 방법이기 때문이다.
따라서 분석가는 성공을 목표로 하기보단 실패를 방지하는 것, 프로젝트의 초기에 중대한 실수를 최소화 하는데 목표가 있다고 할 수 있다.
분석가가 가지고 있어야 할 자질에 대해서 말해 보겠다.
- 의사소통 능력
- 컴퓨터의 기술의 지식
- 비즈니스와 응용분야에 대한 지식
가장 대표적인 것은 이렇게 3가지가 있다.
먼저 앞서 말했듯 의사소통능력은 사용자와의 미팅을 통해 무엇을 원하고 있는지 알아야하기에 그렇다고 하고 다른 2가지의 대해 설명해 보겠다.
컴퓨터의 대한 지식
컴퓨터의 대한 지식이 있어야 우리의 능력이 어디까지이고, 고객에게 우리가 어디까지 해줄수 있다는 명확한 답을 내놓을 수가 있다.
비즈니스와 응용분야에 대한 지식
분석가가 임무를 제대로 수행하기 위해서는 응용분야에 대한 지식이 필수적이다. 그래서 요즘 기업들은 컴퓨터를 전공으로 한 사람보다 응용분야를 전공하고 컴퓨터 지식을 가진 인력을 더 선호한다.
요구사항 명세서
분석을 한 최종목표이자 결과는 요구사항 명세서를 만드는 일이다. 명세서는 사용자와 개발자 모두가 이해하기 쉽도록 만들어져야한다.
명세서는 모든 제약조건의 기준을 정확하게 잡아야한다. 원하는 시스템의 품질, 상대적인 중요성, 품질의 측정 및 확인작업 등을 명시하여야하고 시스템의 포용성과 오류 조건이 명확하게 나와야 한다.
모델링
모델링은 어떤 것을 이해하기 위해 추상화하는 작업이다. 일반적으로 그림으로 표현하는 것이 문서로 표현하는 것보다 쉽다고 느낀다. 따라서 쉬운 이해를 목표를 하는 것이 모델링을 하는 이유이다.
이해를 쉽게하려면 이런저런 이야기를 구구절절 표현하기보단, 내용의 핵심만을 집는것이 중요하다. 그래서 한가지의 목적을 두고 그 목적에 맞는 필수적인 내용만 들어가는 것이 좋다.
예를 들자면 실제 지형의 고도를 알기위해선 등고선을 그려 지형도를 만들 수도 있고, 길을 찾기 위함이라면 약도를 그리는 것도 있을 것이다.
지형도나 약도를 보고 실제 모습이 어떤지 유추하기 힘든것처럼 한가지를 목적으로 둔 모델을 보고 내용을 완벽히 이해할 순 없다.
하지만 그것의 목적을 알기에는 실제 모습을 보는 것보단 이해하기 편하다. 이런 이유때문에 모델링을 하는 것이다.
모델링의 기본요소
1. 표현 : 텍스트보단 시각적인 표현이 이해하기 쉽다.
2. 규약 : 도표에 있는 기호드의 약속
3. 상술 : 시각적 표현을 텍스트화 하는 과정
소프트웨어 시스템의 3가지 관점
한 모델링을 통해 목표가 다른 여러 내용을 알기에 어렵기 때문에 3가지관점으로 보아야한다.
기능관점 : 시스템이 어떤 기능을 수행하는가 (시스템이 하는 일의 결과)
동적관점 : 시간의 변화에 따른 시스템의 동작과 제어 (시스템이 하는 일에 대한 과정 )
정보관점 : 시스템의 정적인 정보 구조를 포착 (시스템의 구조????)
관점에 대해서 이해가 너무 어렵다. 내일 복습하면서 다시 이해를 해야겠다
댓글