06. 요구사항 분석과 모델링

ppt 27~32 읽기

 

요구사항 분석 단계
: 프로젝트 목표를 설정하고 이해 관계자를 파악하며 초기 요구사항을 분석하고 일정과 예산을 산정하고 프로젝트 팀을 구성하는 단계

 

SW 개발의 목적은 고객 만족이고, 고객 만족을 위해 적시성(빠른 출시), 유연성(다양한 환경에서 가능), 통합(기존 시스템과 쉽게 통합)을 만족해야한다. 또한, 고품질의 제품을 정해진 기간 내에 주어진 예산으로 개발해야한다.

 

요구사항

• 시스템이 제공해야하는 기능(ex) 덧셈)이나 시스템이 만족해야할 조건(ex) 오차 범위가 ~이내여야함)
• 요구사항 분석은 시스템의 목표를 확립하는 과정. 사용자의 요구사항을 조사하고 확인하는 과정임. 즉, 고객에게 무엇을 제공할 것인가를 정확히 기술하는 것이다. 요구사항을 발견(뽑아내기), 정제(골라내기), 모델링(표현), 명세화(문서화)하는 과정
• 기능적 요구사항과 비기능적 요구사항으로 나뉘고, 비기능적 요구사항은 품질과 제약 사항으로 나뉜다.
  기능적 요구사항: 기능이나 시스템의 서비스. 시스템이 무엇을 하는가를 기술함. ex) 목적지 설정-지도를 보여줌, 주소나 상호를 입력받음
  비기능적 요구사항: 수행 가능한 환경, 품질, 제약 사항(ex) 자바를 써야한다, 윈도우즈와 리눅스에서 모두 실행되어야한다)
• 사용자 요구사항과 시스템 요구사항으로 나눌 수도 있다.

 

 

 

요구사항 명세서(=요구 분석 명세서)

• 목표에만 초점. how는 고려 안함. 수정하기 쉽게 쓰여야한다.
• 요구사항 분석의 최종 산출물. 산출물 중 가장 중요함.
• 이걸 기반으로 설계서를 만들고 구현하기 때문에 프로젝트를 성공적으로 수행하려면 필수적임.
• 고객과 개발자 모두 쉽게 이해할 수 있어야함
• 기능과 제약 조건을 정확하게 기술하여야함
• 만들어질 시스템의 수용여부를 결정짓는 검증자료로 사용됨. 검증 기준을 제시해야함.
• 품질 측정 및 검증 방법 등을 명시해야함.
• 시스템의 포용성과 오류 조건 명시해야함.
• 개발 시작전에 요구사항을 동결해야함. = 기준 선문서
• 다이어그램 사용

 

 

사용자 요구사항과 시스템 요구사항

두개는 동일한 이야기를 하고 있어야함.

별개로 작성하는 이유는 서로 이해하기 쉬우라고.

시스템 분석 명세서는 시스템 요구사항을 설계하는데 도움이 되도록 기술적 용어, 전문적 표현을 사용한다.

 

 

 

요구사항 분석의 특징

• 요구사항 분석은 비기술적인 부분도 필요하여 쉽지 않다.
• 문제 영역에 대한 사용자의 이해력 부족, 사용자가 요구 사항에 대한 설명을 못하는 경우 문제가 된다.
• 요구사항이 계속 변하고 충돌하고 일관성이 결여되거나 불일치하는 일이 생겨서 확정적이지 못한 경우가 많다.
• 요구사항 분석은 실패를 피하려는 방어적인 활동이다.

 

요구 분석 절차

1. 자료 수집: 현행 시스템 파악, 실무 담당자와 인터뷰(전화, 설문지 포함), 사용중인 서류 검토
2. 요구사항 도출
3. 문서화: 요구 분석 명세서 작성
4. 검증

 

시스템 분석가의 자질과 업무

분석가는 사용자의 요구를 정확하고 완전하게 획득하려고 노력한다

의사소통과 협상 능력, 중재 능력이 요구된다

개발 업무 영역에 대한 지식이 있어야한다

 

 

공식 기술 검토회
고객, 분석가, 개발자, 시험자(테스트 담당)이 참여하여 결정을 내림

목표에 대한 최종 합의점 도출

요구사항 명세서 공식적으로 평가

합의점이 도달되면 사용자, 개발자가 서명하며 이 이후의 수정은 서명한 모든 사람들의 동의가 있어야함

 

 

개발의 특징

개발은 주어진 요구사항을 똑바로 해결해나가기만 하면 됨

 

 

모델링

요구사항을 표현하는 것. 여러 관점의 모델 사용

UML의 다양한 다이어그램을 이용

이해하기 쉽고 모호하지 않아야함

장점) 개발될 SW에 대한 이해도 향상, 의사소통 향상, 유지보수 쉬움

단점) 과도한 문서 작업으로 일정이 지연될 수 있음. 형식적인 산출물로 전락할 수도 있음. 

 

 

 

모델링의 기본 요소

표현, 규약, 상술

 

 

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

기능 관점, 동적 관점, 정보(객체)관점

기능 모델은 시스템이 어떤 기능, 계산을 하는지 기술. 바블 도표라고 불리는 자료 흐름도에 의해 표현됨. 구조적 분석을 한다. 

동적 관점은 동작, 제어에 초점을 맞춰 시스템의 상태와 상태를 변하게 하는 원인을 묘사한다. 상태 변화도(어디까지 진도 나갔나 알려주는 것), 사건 추적도를 사용한다. 

정보 모델은 시스템에 필요한 정보를 보여주고 정적인 정보구조를 포착한다. 시스템에 사용되는 정보 객체를 찾아내고 객체의 특성, 연관성 등을 규명. 기능이나 동적인 면을 고려하지 않으며 오직 정적인 것에만 초점을 둠. 데이터베이스를 분석할때 많이 사용됨. 객체지향 시스템 개발 방법론 사용. 객체지향 모델은 정적인 정보에 객체의 동적인 면과 기능관점을 추가하여 완벽한 객체를 구현하는게 목적(정보만 있으면 불완전)

-> 세개 다 시스템 전체를 완벽히 설명하지 못한다. 세 관점이 통합되어야 요구사항이 완벽히 표현된다. 개발하는 응용 분야에 따라서 한 관점이 시스템의 모든 모습을 다 설명할수도 있고 이런 경우엔 다른 관점은 간략해지거나 생략됨.