Index
1. 요구사항
1.1. 요구사항
•
문제 해결이나 목적 달성을 위해 사용자가 필요로 하는조건이나 는ㅇ력
◦
고객이 원하는 것이 무엇인지?
◦
WHAT에 대한 것
•
요구 분석과 명세 단계는 요구사항을 찾아 분석하고 문서화하는 과정
◦
요구 공석
•
요구사항 명세서
◦
시스템이 제공해야하는 서비스나 제약 조건 기술
◦
개발과 유지보수 작업의 기초 문서
1.2. 요구사항의 종류
•
기능적 요구사항
◦
기능에 대한 요구사항
◦
입출력 양식, 저장 구조, 계산 능력 등 기능적 요인 정의
◦
예)
▪
사용자가 티켓을 구입할 수 있어야한다.
▪
사용자가 지방세 정보를 볼 수 있어야 한다
•
비기능적 요구사항
◦
제품의 품질, 기능상의 제약, 법률이나 표준의 준수에 관한 내용
◦
사용성, 효율성, 신뢰도, 보안 등 프로세스 관련 요구사항 및 하드웨어 사용에 관한 것
◦
예)
▪
사용자에게 1초 내로 피드백이 주어져야 한다
▪
인터페이스 색상이 회사의 공식 색상과 일관성이 있어야 한다.
1.3. FURPS+
•
HP에서 개발한 요구사항 분류 모델
•
Functionality는 기능적 요구사항
•
Usability, Reliability, Performance, Supportability와 + 는 비기능적 요구사항
◦
사용성, 신뢰성, 성능, 지원성, +(설계, 구현, 인터페이스, 물리적 제약사항)
•
비기능적 요구사항이 기능적 요구사항보다 중요함
2. 요구 공학 프로세스
2.1. 요구 공학
•
요구 공학 프로세스
◦
시스템의 목표와 기능 및 제약조건 결정 과정
◦
반복적이고 협력적인 프로세스 강조
◦
겨로가의 문서화와 변화하는 요구사항에 대한 이해를 강조한 용어
•
입력
◦
고객이 준비한 문제 기술서
•
출력
◦
요구사항 명세서 (SRS)
2.2. 타당성 조사
•
시스템이 기관의 목적에 부합하는지, 현재의 기술가 비용으로 일정에 맞춰 개발 될 수 있는지, 다른 시스템과 통합될수 있는지 판단
•
문제 기술서 → 타당성 조사 → 요구사항 수집과 분석 → 문서화(사용자/시스템 요구사항) → 검토 → 관리 → SRS
2.3. 요구사항 수집과 분석
•
요구사항 수집
◦
고객이나 사용자와 의사소통하여 시스템이 제공해야하는 서비스, 요구되는 시스템의 성능 및 제약사항 등을 찾는 것
◦
분석가가 도메인에 대한 지식을 갖고 있어야함
◦
이해 관계자
▪
시스템에 관심을 갖고 직간접적으로 영향을 받는 사람
•
요구사항 분석
◦
요구사항 분류 → 요구사항들 간의 충돌 해결 → 우선수위 선정
•
JAD (Joint Application Design)
◦
애플리케이션 설계와 개발 과정에서 고객과 사용자를 참여시키는 방법
◦
모든 관련자들이 참여하는 JAD 세션에서 요구사항 추출
◦
3~5일 정도 회의 진행
◦
최종 JAD 문서는 합의된 요구사항 명세서임
2.3. 요구사항 문서화
•
사용자 요구사항
◦
고객이나 사용자를 위해 작성
◦
고수준의 추상적 요구사항
◦
예) 제안 요청서(RFP)
•
시스템 요구사항
◦
개발자 대상으로 작성
◦
서비스와 제약조건 상세 기술
◦
설계와 개발 작업 기초가 되며 계약서의 역할
◦
시스템 모델을 사용하여 표현
2.4. 요구사항 검토
•
개발팀이 요구사항의 의미를 설명하고, 고객, 계약자, 사용자 등이 오류가 있는지 시스템 요구사항 검토
•
요구사항 명세서는 고객과 개발자 모두 상세히 검토 해야함
2.5. 요구사항 관리
•
요구사항 관리
◦
요구사항의 변화를 이해하고 통제하는 프로세스
◦
요구사항을 조직화 문서화 하고 요구사항 변경 관리
•
초기 요구사항은 불오나전하고 불일치가 존재하므로 요구사항은 변경되고 진화함
◦
문제 초기 인식 → 초기 요구사항 → 문제 이해도와 변경과 개선 → 요구사항 변경
•
요구사항이 변경될 때 영향 받는 모든 정보를 추적하여 함께 수정해야함
•
추적성 정보
◦
요구사항 변경을 관리하기 위한 정보
◦
요구사항들 간에, 그리고 요구사항, 시스템 설계, 코드 사이에는 다양한 의존 관계가 존재
◦
요구사항 변경 시 그것에 영향을 받는 관련 요구사항(또는 설계 요소)를 파악할 수 있어야 함
•
추적성 정보의 유형
◦
소스 추적성
◦
요구사항 추적성
◦
설계 추적성
3. 요구사항 모델링
3.1. 요구사항 모델링
•
시스템을 명확히 이해하거나 명세화 위해 모델 사용
•
자연언어를 이용한 명세의 문제점
◦
모호성, 요구사항 혼합, 과도한 유연성, 모듈화 어려움
•
테이블, 구조화된 언어, 설계 기술 언어 사용
3.2. 시스템 모델
•
업무 프로세스, 해결할 문제, 시스템 자체를 그래픽 사용해 표현
•
정확한 기술 방법 표현 → 검증 쉬움
•
그림은 자연언어 보다 이해 용이
•
분석과 설계 과정의 다리 역할
3.3. 객체지향 분석
•
요구사항 분석 작업에 객체 지향 방법 적용
◦
객체를 찾고, 객체 간의 관계를 바탕으로 요구사항 구조화, 정형화하여 시스템의 모델 만듦
◦
요구사항 정형화 과정
•
분석 모델
◦
객체 지향 분석의 결과물
◦
시스템을 사용자 관점에서 표현
◦
기능 모델(유즈케이스와 시나리오)은 분석 과정의 입력물이자 결과물
◦
결과물은 분석 객체 모델 (클래스 다이어그램)과 동적 모델 (상태 다이어그램, 시퀀스 다이어그램)
3.4. 구조적 분석
•
시스템 요구사항 정의를 위해 분할 정복과 하향식 분해 방법을 사용한 요구사항 분석 방법
◦
결과를 그래픽 표현에 기초한 시스템 모델로 표현
◦
시스템 모델을 사용해 분석가와 사용자가 의사 소통
◦
기능적 분해에 의해 시스템을 다루기 쉬운 조각들로 나눔
•
구조적 분석에 사용된 소프트웨어공학 원리
◦
추상화 - 핵심적인 부분만 간추림
◦
형식화 - 엄격한 접근 방법으로 단계별로 결과물 문서화
◦
분할과 정복
◦
계층화 - 분할된 모듈을 트리 구조로 구성
3.5. 데이터 흐름도
•
DFD (Data Flow Diagram)
◦
구조적 분석에서 사용되는 기능 관점의 시스템 모델
◦
시스템에서 데이터 흐름과 변환을 보여주는 네트워크 형태 다이어그램
◦
입력 데이터에 대하여 어떤 계산을 통해서 결과가 나오는지에 관한 단계적 처리를 보여줌
◦
정보 처리 시스템의 기능 명세에 주로 사용
◦
데이터 저장소에 저장되거나 프로세스 사이에서 전달되는 데이터는 데이터 사전에 정의
•
표기법
•
프로세스는 데이터의 변환 작업을 의미
•
최상위 수준의 데이터 흐름도에서 시작하여 확장됨
•
최하위 수준의 데이터 흐름도에 존재하는 프로세스를 기능 단위라 함
•
최하위 프로세스에 대해 프로세스 명세서 작성
•
프로세스 명세서는 의사 코드 등을 사용하여 프로그램 논리를 보여줌
3.6. 구조적 분석과 객체지향 분석의 비교
•
구조적 분석은 기능 관점에서 시스템을 표현
•
객체지향 분석은 기능과 데이터를 함께 캡슐화된 객체를 가지고 시스템 표현
•
구조적 분석은 기능 분해 또는 합성에 의한 표현 방법을 사용
•
객체 지향 분석은 상속 개념 사용 가능