요구공학 Flashcards
요구사항
[정의] 시스템이 제공해야 할 서비스와 제약사항에 대해 정의한 문장
[관리 필요성] 요구사항과 FP 연계, 규모/비용 산정 타당성 확보, 과업 변경 최소화로 납기 준수
[분류]
1. 기능적 (기자입사)
- 기능(시스템 수행기능/운영시간), 자료(입출력 형태, 자료정확도), 입/출력(데이터형태, 타 시스템 연계), 사용자(시스템 사용자, 사용자 IT 숙련도)
2. 비기능 (성품안보)
- 성능(시스템 속도/반응시간, 처리되는 자료크기), 품질(평균가동시간, RPO/RTO), 안전(계좌도용 방지책, 재난 방지책), 보안(접근통제방법, 물리적 보안 대책), 사용성
3. 기타
- 프로젝트 지원, 프로젝트 관리
요구공학
[리드] 요구사항 최적관리를 위한 공학적 접근
[정의] 요구사항에 맞는 SW개발 위해 기능/비기능 품질 속성 도출,정량화,추적 통한 요구사항 도출 및 관리 기법
[기존문제점/필요성]
- (문) 문제 영역의 이해 부족, 참여자가 이해 문제, 의사소통 문제, 잦은 요구사항 변경
- (필) 업무 이해도 향상, 요구변화 대응, 비용절감
[프로세스]
* 요구공학 프로세스는 크게 요구사항 개발과 요구사항 관리로 구분
절차/주요기법/산출물
1. 요구사항 추출 : 델파이,인터뷰, 마인드맵, Check List (요구관리대장/요구사항명세서)
2. 요구사항 분석 : UML, 구조적 분석, 객체지향분석 (Usecase Diagram, DFD, 품질속성 시나리오)
3. 요구사항 명세화 : Z-notaion, FSM (사용자 및 시스템 요구사항(SRS), ERD)
4. 요구사항 검증 : 확인&검증(V&V), Inspection, Semantic/구문 증명 (Baseline, 표준용어집)
5. 요구사항 추적 : 요구사항 추적표관리, 감리 (변경요청서, 회의록 )
6. 요구사항 변경관리 : CCB, 회귀테스트 (변경관리대장, 변경 Baseline)
[요구사항 평가기준/ 품질속성]
- 정확성/명확성, 완전성/일관성, 중요도, 특이성, 검증 가능성, 이해 가능성, 추적성, 수정 용이성
요구사항 도출기법
[정의] 요구사항 소스, 인터뷰 등 도출 기법 활용, 문제 해결 또는 목적달성을 위해 시스템이 가져야 하는 서비스 제약사항을 파악하는 활동
[필요성] (고객측면) 사용자 요구 이해, 비기능 요구 파악, (개발측면) 요구 Baseline 기준 제시, 의사소통 수단
* CMMI 레벨 3 의 요구사항 개발 활동 영역
[기법]
- 경험 기반 : 설문조사, 관찰, Role Playing(시나리오 기반 역활극), 인터뷰
- 프로세스 기반 : 유즈케이스, 벤치마킹, Workshop, 브레이밍 스토밍, Prototyping
* 요구사항 도출, 분석의 개발 활동과 함께 체계적인 요구관리 중요
요구사항명세(SRS)
[정의] 요구사항과 스펙 정리한 요구분석단계의 산출물로써, 소프트웨어 프로젝트 중심이 되는 문서
[필요성] 명확한 기준 마련, 합의 도출, 공정 계약, 정당한 대가
[역할] 사업관점(발/수주자간 합의, 명세기능 세분화), 개발관점(재설계방지, SW검증과 테스트기준)
[구성항목]
- 개요 : 범위(요구사항 범위), 목적(명세서 작성 목적), 시스템 개요(전반적인 내용 요약), 일반적 제약사항
- 기능 요구사항 : 기능요구사항, 외부 I/F
- 기타제약 요구사항 : 성능, HW요구 사항, 논리적DB 요구사항, SW 시스템 속성
- 인수조건 : 기능 및 시험 성능
* IEEE Std. 830 및 1012를 기반으로 요구 명세 작성
[SRS 평가기준]
- 요구기능측면 : 완전성, 일관성, 정확성, 명확성
- 운용측면 : 검증가능성, 추적용이성
* ISO/IEC/IEEE 29148 기반으로 SRS작성 및 JIRA, Redmine OSS활용 요구사항 관리프로세스 통한 성공적프로젝트 수행
요구사항 품질속성
[정의] SW가 요구하는 기능적, 비기능적 Needs 및 제약으로 정의되는 시스템이 제공해야 할 역량
* 요구사항 명세서(SRS) 작성 후 요구사항 품질속성을 기준으로 평가 수행
[품질 속성]
- 완전성(요구기능/요구 품질 완전성), 정확성(요구기능/요구 품질 정확성) 명확성, 일관성(내부,전방,후방 일관성), 특이성(중요도,난이도 표시), 검증 가능성, 수정 용이성, 추적성(내부,전방,후방), 이해 가능성
페르소나 통한 분석
[리드] 가상인물 역할 설정
[정의] 서비스 사용 목표인구 집단 내 사용자유형 대표하는 가상인물(메타포) 이용한 요구사항 도출 방법
[필요성] 사용자 기반의 프로젝트 의사결정, 사용자에 대한 관점 유지
[분석 프로세스] (범단세 우페평작)
1. 사용자 범주파악 2.주요 단서분류 3.세부 범주파악/기간구조 잡기 4.기간구조 평가 및 우선순위 선정 5.페르소나 작성 6.페르소나 평가 7.설문조사를 통한 프로파일 작성
* 1~6 단계 반복, 최종 7을 도출
베이스라인
[정의] SDLC 상 형상 Freezing, 추적/변경의 기술적 통제 시점 및 산출물 관리 기준선
[필요성] SW 가시성&추적성 확보, 산출물의 일관성, 변경/처리 과정의 투명성
[유형] (기분설시제운)
1. 기능 베이스라인 : 요구사항 명세 및 기능 정의 산출물 (프로젝트계획서, 개발표준)
2. 분배 베이스라인 : 요구 기능에 대한 기본 설계 산출물 (요구사항정의서, DFD, WBS, 요구 추적 매트릭)
3. 설계 베이스라인 : 개발을 위한 상세 설계서 산출물 (SRS, ERD, UI명세서)
4. 시험 베이스라인 : 단위 기능 시험 산출물 (원시코드, 실행코드)
5. 제품 베이스라인 : 통합 기능, 성능 시험 산출물 (통합테스트계획서, 결과서)
6. 운용 베이스라인 : 인수,운영 시험 산출물 (매뉴얼, 이관소스)
정형기법
[정의] 수학적, 논리적 명세 및 검증기술 활용, 시스템 설계/검증 통한 고신뢰성 시스템 개발 기법
[특징] 시스템의 간결성, 정확성, 가시성 향상 통한 SW 안전성 확보 방안
[등장배경]
- 소프트웨어 위기 : 규모/복잡성 해결 필요, CASE Tool, CMMI “정형기법(Formal methods)”이 대안으로 등장
- 소프트웨어 실패 : 개발 요구와 인도물 상이, 명세화 개선 방안으로 UML, “정형기법” 등장
[유형]
1. 정형명세 : 수학적 정의 언어 사용, 요구/설계 명세 - Z-notation, State chart, Petri-net
2. 정형검증 : 증명방법을 통한 요구사항 만족여부 - 정리증명, 모델체킹, 동등비교, SAT
정형명세
[정의] 개발하려는 하드웨어 또는 소프트웨어의 요구사항을 수학적이거나 논리 이용해 기술하는 명세기법
[유형] (명-오대수)
1. 오토마타 기반 정형 명세
- (장) 대상 시스템 행위 표현 용이, 세만틱스 명확
- 시각적 언어 기반
- State와 Transition 통한 시스템 행위 묘사
- 기법 : Finite State Machine, Statechart(FSM + 계층), UPPAAL(FSM + 시간), SCADE(원자력, 자동차 분야에서 사용)
2. 대수(Algebra) 기반 정형 명세
- (장) Parallilism(병렬성)과 Concurrency(동시성) 설명 용이
- 기법: CCS(Pi-calculus, 모바일), CSP(보안, 이론적 -> 언어화 한 것이 CASPER), ACSR (University of Pennsylvania, Linear Logic의 리소스를 표현)
3. 수리, 논리 기반 정형 명세
- (장) 시스템 상태 변수의 타입 명세 용이 (단) 수학적 기호 사용 난이도
- Function 전후 상태 명세
- 기법: Z notation, B method(떼제베 철도 신호 제어 시스템에서 사용됨), 이벤트 기반의 Event-B, Galina
- 논리 언어: First-Order Logic, Propositional Logic, Temporal Logic, …
정형검증
[정의] 수학적, 논리적 증명방법을 통해 시스템 설계와 요구사항의 만족여부를 증명
[유형] (검-구의SA)
1. 의미론적 증명(semantic)
- 시스템 모델이 특정 속성을 만족하는지 상태를 추적하여 확인
- 오토마타 기반 명세를 대상
- 자동화가 가능
- 기법: model checking(모델 체킹) - SMV, SPIN
2. 구문적 증명(syntactic)
- 시스템 모델이 특정 속성을 만족하는지 구문적 규칙을 적용하여 증명
- 논리 기반의 명세를 대상으로 한다.
- 사람이 직접 step-by-step으로 증명해야 하며, 이 과정 중 도구의 도움을 받을 수 있다.
- deductive system을 이용하여 증명한다.
- 기법: theorem proving(정리 증명) - HOL, PVS
3. SAT Solver, SMT(SAT + Modeling Theories) Solver, …
- Z3 + Python 패키지
RFI
[정의] RFP 작성 전 프로젝트 계획 및 수행 필요 정보 수집 목적, 다수 공급업체 대상 발주 업체 요구, 정보 요청서
[특징] 소프트웨어산업진흥법 제24조
[항목구성] (사발주)
1. 사업개요 : 사업명, 추진배경/목적, 사업범위, RFI 제출 요령, 발주업체정보, 주요요구사항 작성
2. 발주업체정보 : 일반현황, 정보시스템현황, 개선사항
3. 주요요구사항 : 세부업무관련 요구사항, 기술적 요구사항, implementation
[RFI 이후 수행 절차]
- RFI 기반 RFP 작성 > 도입 시스템 BMT 선정 > Pilot 통한 Site 최적화
RFP
[정의] 명시된 시스템, SW 및 SW서비스 사업 발주 목적, 입찰대상자에게 제공하는 발주자 요구사항 명시 문서
[특징]
- 사업개요, 현황 및 문제, 사업추진방안, 제안요청내용
- 공급업체의 제안서 평가를 통해 고객이 원하는 서비스를 얻기 위한 목적
[항목] (사현추제)
1. 사업개요 : 제안배경, 추진목적
2. 현황 및 문제 : 기술적 환경 정의 - 보유기술 내역, 시스템 아키텍쳐
3. 사업 추진방안 : 제안프로젝트 일정(제안서 제출마감일정 및 발표일정, 업체선정 발표일, 개략적 프로젝트)
4. 제안요청내용:
- 추진일정 정보요구내역 : 서비스제공자명, 업체조직 및 인력구조, 관련 분야 추진 내역
- 제안서 관련 요구사항 : 제안목차, 공급업체의 핵심인력 및 참고자료, 제안형식 및 제출 부수등
H/W 규모산정
[정의] 정보시스템 도입시 기본적인 용량과 성능 요구사항에 대한 시스템 요구사항으로 변환하는 시스템 관점 수행 절차
[유형] (수참시)
- 수식 계산법 : 수요기반 용량 수치 계산 후 보정치 적용 (산정 용이, 초기 계획 가능 / 보정치 오류 영향 큼)
- 참조법 : 기본 데이터 기반 시스템 규모 비교하여 비슷한 규모 산정 (경험기반, 유사 산업 유리 / 근거 부족)
- 시뮬레이션법 : 작업 부하를 모델링 후 시뮬레이션 (모델링 수행, 높은 정밀도 / 높은 시간과 비용)
[대상] CPU, Memory, Disk, Storage
[절차도] 구축 방향 및 기초자료 조사 → 기초자료 및 업무 분석 → 참조모델 결정 및 서버 규모 산정 → 참조 모델별 가중치 적용
