[1] 요구사항 확인 😶

1-1. 소프트웨어 개발 방법론

 

[1] 소프트웨어 생명주기 모델 

 

* 소프트웨어 생명주기(SDLC)

: 시스템 요구분석 ~ 유지보수 까지 전 공정을 체계화 한 절차

 

* 생명주기 모델 프로세스

- 요구사항 분석 : 다양한 이해관계자의 요구와 조건 결정

(기능 / 비 기능)

- 설계 : 정의한 기능을 실제 수행 할 수 있도록 방법을 논리적으로 결정

(구조 / 프로그램 / 인터페이스 설계)

- 구현 : 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램 작성

(인터페이스 개발 / 자료구조 개발)

- 테스트 : 정해진 요구사항 만족여부, 예상과 실제 결과 차이 검사 평가

(단위테스트 ,통합테스트, 시스템 테스트, 인수 테스트)

- 유지보수 : 시스템이 인수되고 설치된 후 일어나는 모든 활동

 

 

* 생명주기 모델 종류

- 폭포수 모델 : 고전적 생명주기 모형, 요구사항 변경이 어려움, 단계 확실히 마무리 지은 후 다음 단계로 넘어감

- 프로토타이핑 : 고객이 요구한 주요 기능 --> 프로토 타입으로 구현, 피드백 반영하여 소프트웨어 개발

- 나선형 모델 : 위험을 최소화 하기 위해 점진적으로 완벽한 시스템으로 개발 

(계획 및 정의 -> 위험분석 -> 개발 -> 고객평가 : 개위개고) 

- 반복적 모델 : 반복적으로 개발하여 점증 완성시키는 SDLC 모델 

요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성

 

---

[2] 소프트웨어 개발 방법론

 

* 소프트웨어 개발 방법론

: 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법

 

* 소프트웨어 개발 방법론 종류

- 구조적 방법론 : 프로세스 중심의 하향식 방법론 (나씨 - 슈나이더만 차트) , 전체 시스템 기능에 나누어 개발 => 통합

- 정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기법 체계화 (개발주기 이용 => 대형 프로젝트 수행)

- 객체지향 방법론(OOD) : '객체' 라는 기본 단위로 시스템을 분석 및 설계 

- 컴포넌트 기반(CBD) : 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성 , 개발기간 단축 (생산성 향상) 

  새로운 기능 추가 쉬움(확장성, 재사용)

- 애자일 방법론 : 절차보다는 사람이 중심 => 변화에 유연, 신속하게 적응

- 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발(영역 공학 / 응용 공학)

 

* 애자일(Agile)

: 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응, 효율적으로 시스템 개발 (개발기간이 짧고 신속)

 

* 애자일 방법론 유형 

- XP 

: 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론 / 1~3주 반복 개발주기 / 5가지 가치의 12개의 실천항목이 존재

5가지 가치

[ 용기 , 단순성, 의사소통 , 피드백 , 존중 ] 

12가지 기본원리

[ 짝 프로그래밍 ,공동 코드 소유, 지속적인 통합, 계획 세우기, 작은 릴리즈, 메타포어 , 간단한 디자인 ,테스트 기반 개발, 리팩토링 , 40시간 작업 , 고객 상주, 코드 표준 ]

 

- 스크럼

: 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

백로그 : 제품 / 프로젝트에 대한 요구사항

스프린트 : 2~4주 짧은 개발 기간으로 반복적 수행으로 개발 품질 향상

스크럼 미팅 : 매일 15분정도 미팅으로 To-Do-List 계획 수립

스크럼 마스터 : 프로젝트 리더

스프린트 회고 : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록

번 다운 차트 : 남아있는 배골그 대비 시간을 그래픽적으로 표현한 차트

 

- 린

: 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소 제거, 품질 향상

  JIT(Just In Time) , 칸반 보드 사용

 

 

---

 

[3] 객체 지향 분석 방법론

 

* 객체 지향 분석(OOA)

: 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 속성과 연산, 관계를 정의하여 모델링

 

* 객체 지향 방법론 종류

OOSE(야콥슨) : 유스케이스에 의한 접근 방법 ,유스케이스를 모든 모델의 근간으로 활용, 기능적 요구사항 중심

OMT(럼바우) : 그래픽 표기법을 이용하여 소프트웨어 구성 요소를 모델링 (객체 -> 동적 -> 기능 모델링 순서로 진행) 

 객체 모델링 : 시스템에서 요규하는 객체를 찾고 객체들 간의 관계 정의하여 ER 다이어그램 만드는 과정까지 모델링

 동적 모델링 : 시간의 흐름에 따라 객체들 사이의 제어 흐름 , 동작 순서 등의 동적인 행위 표현

 기능 모델링 : 자료 흐름을 중심으로 처리 과정 표현 (자료흐름도 활용)

OOD(부치) : 설계 문서화를 강조, 다이어그램 중심으로 갭라하는 방법론 / 분석과 설계의 분리가 불가능

 

---

1-2. 비용 산정, 일정관리 모형

 

[1] 비용 산정 모형

 

* 비용 산정 모형 개념

: 소프트웨어 규모파악을 통한 투입 자원 , 소요시간 등을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식

 

* 비용 산정 모형 분류

- 하향식 산정방법 : 경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정 

(전문가 판단, 델파이 기법) 

- 상향식 산정방법 : 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식

(코드 라인 수 Loc, Man Manth, COCOMO 모형, 푸트남 모형, 기능 점수(FP) 모형)

 

* 비용 산정 모형 종류 

 

① LoC (Line of Code) 모형

소프트웨어 각 기능의 원시 코드 라인 수의 낙관치 , 중간치, 비관치 측정 => 예측치
예측치 = 낙관치 + 4 * 중간치 + 비관치 / 6
낙관치 : 가장 적게 측정 된 코드 라인 수
중간치 : 측정된 모든 코드 라인 수의 평균
비관치 : 가장 많이 측정된 코드 라인 수

② Man Month 모형

한 사람이 1개월동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정
Man Month = (Loc) / 프로그래머의 월간 생산성
프로젝트 기간 = (Man Month) / 프로젝트 인력

③ COCOMO 모형

프로그램 규모에 따라 비용 산정
비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력으로 산정
비용 견적의 강도 분석 및 견적의 유연성이 높아 개발비 견적에 널리 통용
규모에 따라 조직형 ,반 분리형 ,임베디드 형으로 나뉨
조직형 : 소규모,  5만 라인 이하의 소프트웨어 개발 
반 분리형 : 단순형과 임베디드형의 중간형 ,util 개발에 적용 , 30만 라인 이하의 소프트웨어 개발
임베디드형 : 초대형 규모의 트랜잭션 처리 시스템이나 운영체제, 실시간 처리 시스템 등의
시스템 프로그램 개발에 사용  , 30만 라인 이상의 소프트웨어 개발

④ 푸트남(Putnam)모형

개발 주기의 단계별로 요구할 인력의 분포를 가정하는 방식
생명 주기 예측 모형

⑤ 기능점수(FP)모형 

요구 기능을 증가시키는 인자별로 가중치를 부여하고 , 요인별 가중치를 합산하여 총 기능의 점수를
계산하여 비용 산정
기능점수(FP) = 총 기능점수 * [0.65+ (0.1 * 총 영향도)]

 

---

[2] 일정관리 모델

 

* 일정관리 모델 개념

: 프로젝트가 일정 기간 내에 적절하게 완료 될 수 있도록 관리

 

* 일정 관리 모델의 종류

- 주 공정법(CPM) : 여러 작업 순서가 얽혀 있는 프로젝트의 일정 계산 , 프로젝트의 시작과 끝을 나타내는 노드 와 노드 간의 연결을 통해 공정을 계산

- PERT : 비관치 , 중간치 ,낙관치 3점 추정방식을 통해 일정 관리

- 주요 연쇄 프로젝트 관리 : 주 공정 연쇄법으로 자원제약사항을 고려하여 일정 작성

 

 

 

 

 

---

2-1. 현행 시스템 분석

 

[1 - 2] 현행 시스템 파악

 

* 현행 시스템 파악 

: 현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동 

 

* 현행 시스템 파악 절차

- 1단계 : 구성 / 기능 /인터페이스 파악 

- 2단계 : 아키텍처 및 소프트웨어 구성 파악

- 3단계 : 하드웨어 및 네트워크 구성 파악

 

---

[3] 소프트웨어 아키텍처

 

* 소프트웨어 아키텍처 

: 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성 요소 간의 관계를 표현하는 시스템의 구조나 구조체

 

* 소프트웨어 아키텍처 프레임워크

: 소프트웨어의 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준

 

* 소프트웨어 아키텍쳐 4+1뷰

: 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적 접근 방법

 4개의 분리된 구조로 구성되는 아키텍처 개념 제시, 이들 4개 구조가 서로 충돌되지 않는지, 시스템의 요구사항을 충족시키는지를 

증명하기 위해 유스케이스 사용

 => 4 : 논리 뷰 , 구현 뷰 , 프로세스 뷰 ,배포 뷰 + 1 : 유스케이스 뷰

 

- 유스케이스 뷰 : 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰 (사용자, 설계자, 개발자, 테스트 관점)

- 논리 뷰 : 기능적인 요구사항이 어떻게 제공되는지 설명 (설계자, 개발자)

- 프로세스 뷰 : 시스템의 비 기능적인 속성, 자원의 효율적인 사용, 이벤트 처리 등 표현 (개발자, 시스템 통합자)

- 구현 뷰 : 개발환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰

- 배포 뷰 : 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

 

* 소프트웨어 아키텍처 패턴 

: 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식 (재사용 가능한 솔루션)

 

* 소프트웨어 아키텍처 필요성

- 고객과 의사소통을 통해 요구사항 만족, 소프트웨어 개발의 생산성 - 품질 확보 가능

- 시행착오를 줄여, 개발 시간 단축, 높은 품질의 소프트웨어 생산 가능 

- 이미 검증된 구조로 개발, 소프트웨어 개발을 안정적으로 수행

 

* 소프트웨어 아키텍처 패턴 유형

유형	설명
계층화 패턴(Layered Pattern)	- 시스템을 계층으로 구분하여 구성 - 각 하위 모듈 => 특정 수준의 추상화 제공 , 상위 계층에 서비스 제공 - 두개의 마주 보는 계층 사이에서만 상호작용
클라이언트 - 서버 패턴 (Client - Server Pattern)	- 하나의 서버와 다수의 클라이언트로 구성 - 사용자가 클라이언트를 통해서 서버에 서비스 요청 -> 서버는 클라이언트에 서비스 제공 - 서버는 클라이언트로부터 요청 대기
파이프 - 필터 패턴 (Pipe -Filter Pattern)	- 데이터 스트림 생성, 처리하는 시스템에서 사용 가능 - 서브 시스템이 입력 데이터를 받아 처리, 결과를 다음 서브시스템으로 넘겨주는 과정 반복 - 재사용성 좋고, 추가가 쉽기 때문에 확장에 용이
브로커 패턴 (Broker Pattern)	- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 컴포넌트들은 원격 서비스 실행을 통해 상호 작용 가능 - 브로커 컴포넌트 : 컴포넌트 간의 통신을 조정 - 서버는 자신의 기능을 블커에 넘겨주며 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 redirection함
모델 - 뷰 - 컨트롤러 패턴 (MVC : Model- View -Controller Pattern)	- 모델 : 핵심 기능과 데이터 보관 - 뷰 : 사용자에게 정보를 표시, 하나 이상의 뷰 정의 가능 - 컨트롤러 : 사용자로부터 요청을 입력받아 처리

 

* 소프트웨어 아키텍처 비용 평가 모델 

: 아키텍처 접근법이 품질 속성에 미치는 영향 판단 ,적합성 평가

- SAAM : 변경 용이성 ,기능성에 집중, 경험이 없는 조직에서도 활용 가능

- ATAM : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가

- CBAM : ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구 충족

- ADR : 아키텍처 구성요소 간 응집도 평가

- ARID : 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델

 

---

[4] 디자인 패턴

 

* 디자인 패턴

: 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법 정리

 

* 디자인 패턴 유형 

① 목적 (생구행)

- 생성 : 객체 인스턴스 생성에 관여 ,클래스 정의와 객체 생성 방식을 구조화, 캡슐화 수행

- 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴

- 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

 

② 범위(클객)

- 클래스 : 클래스 간 관련성(상속관계)  ,컴파일 타임에 정적으로 결정

- 객체 : 객체 간 관련성을 다루는 패턴 , 런타임에 동적으로 결정

 

* 디자인 패턴의 종류(★)

[생성 패턴]

- 빌더 (Builder) : 객체 생성 시 객체를 생성하는 방법(과정)과 객체를 구현(표현) 하는 방법을 분리함으로써 동일한 생성 절차 -> 서로 다른 표현 결과 // 생성과 표기를 분리해서 복잡한 객체 생성

- 프로토타입 (Prototype) : 일반적인 원형 --> 복사한 후 필요한 부분만 수정하여 사용하는 패턴 // 기존 객체를 복제함으로써 객체 생성

- 팩토리메소드(Factory Method) : 상위 클래스 = 인터페이스 정의 (만드는 방법만 결정) , 하위 클래스 = 인스턴스 생성(조작하는 메소드 오버라이딩 하여 실제 객체 생성) // 생성할 객체의 클래스를 국한하지 않고 객체 생성

- 추상 팩토리 (Abstract Factory) : 구체적인 클래스에 의존 X , 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공 // 동일한 주제 다른 팩토리 묶음

- 싱글톤 (Singleton) : 전역변수 사용 X , 객체를 하나만 생성, 생성된 객체를 어디서든지 참조 할 수 있도록 함 // 한 클래스에 하나의 객체

 

[구조 패턴]

- 브릿지(Bridge) : 기능클래스 / 구현 클래스 계층 연결 , 구현부에서 추상 계층 분리 ==> 추상화된 부분과 실제 구현 부분 독립적 확장 // 구현부 뿐만 아니라 추상화된 부분까지 변경해야 하는 경우 활 

- 데코레이터(Decorator) : 기존 구현되어있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴 , 기능 확장이 필요할 때 객체 간의 결합을 통해 기능을 동적으로 유연하게 확장 가능 (상속 대안) // 객체의 결합을 통해 기능을 동적으로 유연하게 확장

- 퍼싸이드(Facade) : 복잡한 시스템에 대하여 단순한 인터페이스 제공 , 시스템 간 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴, 오류에 대해서 단위별로 확인 // 통합된 인터페이스 제공

- 플라이웨이트(Flyweight) : 모두가 갖는 본질적인 요소를 클래스화 & 공유 => 클래스의 경량화 목적

- 프록시 (Proxy) : 실제 객체에 대한 대리 객체 , 실제 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 만듬 //특정 객체로의 접근을 제어하기 위한 용도로 사용 

- 컴포지트 (Composite) : 객체들의 관계를 트리구조로 구성 , 부분 -전체 계층을 표현하는 패턴 //복합 객체와 단일 객체를 동일 취급

- 어뎁터 (Adapter) : 기존에 생성된 클래스 재사용 할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴

 

[행위 패턴]

- 중재자 (Mediator) : 중재자에게 모든 것을 요구하여 통신의 빈도 수를 줄여 객체 지향의 목표를 달성하게 해주는 디자인 패턴

- 인터프리터 (Interpreter) : 언어의 다양한 해석, 구체적으로 구문을 나누고 그 분리된 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 디자인패턴 // 문법 자체를 캡슐화

- 반복자 (Iterator) : 컬렉션 구현 방법 노출 x , 그 안에 들어 있는 모든 항목에 접근할 방법을 제공하는 디자인 패턴 // 내부 구조 노출 X

- 탬플릿 메소드(Template Method) : 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조 변경 X , 특정 단계에서 수행하는 내역을 바꿈 , 상위클래스 == 골격 제공 , 하위클래스 == 메서드 세부 처리를 구체화 

- 옵저버 (Observer) : 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고 자동으로 내용이 갱신

- 상태 (State) : 객체 상태를 캡슐화하여 클래스화함 ,그것을 참조하는 방식으로 상태에 따라 다르게 처리

- 방문자(Visitor) : 처리 기능을 분리하여 별도의 클래스 생성 -> 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행 // 객체의 구조는 변경 X , 기능만 따로 추가하거나 확장할 때 사용

- 커맨드 (Command) : 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징 // 실행된 기능을 캡슐

- 전략 (Strategy) : 알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클래스로 캡슐화, 필요할 때 서로 교환해서 자유롭게 사용 할 수 있는 패턴 // 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환

- 메멘토(Memento) : 객체의 정보를 저장할 필요가 있을 때 적용하는 디자인 패턴 , Undo 기능을 개발 할 때 사용 

- 책임 연쇄(Chain of Responsibility) : 동적으로 어떤 기능이 처리되어있는 연결이 있는 경우에 따라 다르게 처리될 수 있도록 연결 //한 요청을 2개 이상의 객체에서 처리 

 

---

2-2. 개발 기술 환경 정의

 

[1] 개발 기술 환경 현행 시스템 분석

 

* 운영체제(OS) 

: 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고 ,컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램 

 

* 운영체제의 종류

① PC

- 윈도우 / 유닉스 / 리눅스 

② 모바일- 안드로이드 / IOS

 

* 네트워크

: 컴퓨터 장치들의 노드 간 연결(데이터링크)을 사용하여 서로에게 데이터를 교환 할 수 있도록 하는 기술

 

* OSI 7계층 (물데네전세표응)

계층	설명	프로토콜	전송단위
응용 계층 (Application Layer)	사용자와 네트워크 간 응용 서비스 연결, 데이터 생성	HTTP / FTP	데이터(Data)
표현 계층 (Presentation Layer)	데이터 형식 설정과 부호 교환, 암/ 복호화	JPEG MPEG
세션 계층 (Session Layer)	연결 접속 및 동기 제어	SSH TLS
전송 계층 (Transport Layer)	신뢰성 있는 통신 보장 데이터 분할과 재 조립  흐름 제어, 오류 제어, 혼잡 제어	TCP UDP	세그먼트(Segment)
네트워크 계층 (Network Layer)	단말기 간 데이터 전송을 위한 최적화된 경로 제공	IP ICMP	패킷(Packet)
데이터 링크 계층 (Data Link Layer)	인접 시스템 간 데이터 전송, 전송 오류 제어  동기화 ,흐름제어 등의 전송 기능 제공	이더넷	프레임(Frame)
물리 계층 (Physical Layer)	0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환	RS-232C	비트(Bit)

 

* 네트워크 현행 시스템 분석

: 백본망 , 라우터, 스위치 , 게이트웨이 , 방화벽 등을 대상으로 분석

- 백본망 : 다양한 네트워크를 상호 연결하는 컴퓨터 네트워크의 일부 , 각기 다른 LAN이나 부분망 간에 정보를 교환하기 위한 경로 제공

- 라우터 : 3계층 데이터 패킷을 발신지에서 목적지까지 전달하기 위해 최적의 경로 지정, 이 경로를 따라 데이터 패킷을 다음 장치로 전달하는 네트워크 장비

- 스위치 : 2계층 장비, 동일 네트워크 내에서출발지에 들어온 데이터 프레임을 목적지 MAC 주소 기반으로 빠르게 전달

- 게이트웨이 : 컴퓨터, 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 네트워크 장비

- 방화벽 : 외부로부터 불법 침입과 내부의 불법 정보 유출을 방지하고 내 / 외부 네트워크의 상호간 영향을 차단하기 위한 보안 시스템

 

* 미들웨어 

: 분산 컴퓨팅 환경에서 응용 프로그램과 응용 프로그램이 운영되는 환경 간에 원만한 통신이 이루어 질 수 있도록 제어하는 소프트웨어

ex ) WAS

 

* WAS (웹 애플리케이션 서버)

: 서버계층에서 애플리케이션이 동작 할 수 있는 환경을 제공 ,안정적인 트랜잭션 처리와 관리, 다른 이 기종 시스템과의 애플리케이션 연동을 지원

---

3-1. 요구사항

 

[1] 요구사항 개념

 

* 요구공학

: 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동 (목적 : 이해관계자 사이에 효과적인 의사소통 수단 제공)

- 요구사항의 분류 : 기능 (시스템이 제공하는 기능 ex.특정 input , 동작 처리 ) / 비 기능 (기능 이외의 사항 ex. 품질 속성 등)  

 

* 요구사항 개발 단계 (CMM)

- 도출 : 요구사항 소스 / 도출 기법 -> 요구사항 구체적 표현 , 이해관계자 식별

- 분석 : 요구사항 분류 / 개념 모델링 / 기술 구조 설계 및 요구사항 할당 -> 완전성, 일관성 확보 

- 명세 : 시스템 정의서 / 시스템 요구사항 명세서 / 소프트웨어 요구 사항 명세서 -> 문서작성단계

- 확인 : 검토 / 프로토타이핑 / 검증 / 인수테스트 -> 검증단계 , 변경사항 형상관리

 

* 요구사항 도출 주요 기법

- 인터뷰 / 브레인 스토밍 / 델파이 기법 / 롤 플레잉(연기) / 워크숍 / 설문조사

 

* 요구사항 검증 주요 기법

- 요구사항 검토 / 정형 기술 검토 활용 (동료검토 , 워크스루 , 인스펙션) / 프로토타이핑 / 모델 검증 / 테스트케이스 / CASE 도구 검증 / 베이스라인을 통한 검증 / 요구사항 추적표(RTM)

 

* 상세 정형 기술 검토 방법

- 관리 리뷰 : 프로젝트 진행 상황에 대한 전반적인 검토를 바탕을 ㅗ밤위, 일정, 인력 등에 대한 통제 및 의사결정 지원

- 기술 리뷰 : 정의된 계획 및 명세를 준수하고 있는 지에 대한 검토를 수행

- 인스펙션 : 소프트웨어 요구, 설계 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아 내는 형식적인 검토 기법

- 워크스루 : 검토 자료를 회의 전에 배포, 사전 검토 후 짧은 시간동안 회의 진행하는 형태

- 감사 : 제품 제공자, 소비자, 제 3기관 수행 , 계획 절차 준수 확인