* 요구 공학 (Requirements Engineering)
☞ 시스템 요구사항 문서 생성, 검증, 관리하기 위해 수행되는 구조화된 활동 집합
☞ 이해관계자 사이에 효과적인 의사소통 수단 제공하고 요구사항에 대한 공통 이해 설정
☞ 요구사항 손실 방지 및 에러 감지로 불필요한 비용 절감하고 요구사항 변경 추적 가능케 함
▶ 개발 절차
▷ 타당성 조사
- 시스템 구축 가능성 평가 : 비용, 일정, 기술, 법률 제약 사항
- 활용 기법
= 질문지(AS-IS 문제점, 통합 시 문제점), SWOT 분석
▷ 도출 (Elicitation)
- SW가 해결해야 할 문제 이해하고 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있음
- 활용 기법
= 인터뷰, 포커스 그룹, 집단 창의력 기법, 설문조사, 관찰, 문헌조사, 프로토타입, 벤치마킹, 스토리텔링
▷ 분석 (Analysis)
- 요구사항들 간 상충 해결하고, SW 범위 파악하며 SW가 환경과 어떻게 상호작용 하는지 이해
- 활용 기법
= 구조적 분석 : DFD(Data Flow Diagram), Data Dictionary, mini Spec, ERD
= 유즈 케이스 기반 분석 : UML, 모델링
▷ 명세 (Specification)
- 체계적으로 검토, 평가, 승인될 수 있는 문서 작성하는 것 의미
- 활용 기법
= ER 모델링, FSM (Finite State Machine), SADT(구조적 분석과 디자인 기술)
= SRS, IEEE std 830-1998
▷확인/검증 (Validation/Verification)
- 분석가가 요구사항 이해했는지에 대한 확인 필요하고, 요구사항 문서가 조직 표준에 부합하고 이해 가능하며 일관성 있고 완전한지에 대한 검증 중요
- 활용 기법
= Verification(검증) : SW 개발 라이프 사이클 각 단계 산출물이 이전 단계에서 설정된 개발 규격과 요구들 충족시키는 지 여부 판단하기 위한 활동
= Validation (확인) : SW 개발 라이프 사이클 각 단계 산출물이 최초 사용자 요구 또는 SW 요구에 적합한지 입증하기 위한 활동
1. 요구사항 도출
- 사용자들로부터 제시되는 추상적 요구에 대해 관련 정보 식별 및 수집하여 구체적 요구사항으로 표현하는 활동
▶ 요구사항 도출 기법
▷ 인터뷰
- 요구사항 도출한 사용자 대상으로 인터뷰 수행
- 많은 사용자로부터 인터뷰 하는 것이 좋고 회의록 작성 필수
- 필요 시 인터뷰 내용 녹음하여 반복 청취하는 것 좋음
▷ 포커스 구룹
- 선별된 전문가 집단의 대화식 토론으로 요구사항 수집하는 방법
▷ 집단 창의력 기법
- 요구사항 식별 위해 여러 가지 그룹 활동 통해 창의적인 아이디어 도출
- 브레인 스토밍
▷ 이해관계자 설문조사
- 사용자와 대면 조사가 어려울 때에 설문 형식으로 조사
- 현행 시스템 개선 의견 끌어냄
▷ 관찰
- 개인 업무처리 방법이나 절차에 대해 직접적으로 관찰하는 방법
- 요구사항 명확히 설명하기 힘들거나 어려움 있는 경우 사용하는 방법
▷ 문헌 조사
- 유사 프로젝트 및 업무 문서나 양식 조사하여 현재 시스템 정보에 대한 이해 도출
- 산업 및 기업 표준, 정부 정책, 규제 및 법규도 조사
- 개발팀은 업무 도메인 교육이나 튜토리얼에 참가
▷ 프로토타입
- 요구사항에 대한 이해 위해 기본적인 기능만 빠르게 구현하여 사용자로부터 피드백 받는 기법
- 개발자 아이디어를 사용자로부터 조기에 피드백 받고자 할 때 사용
- 프로토타이핑 전용 언어로 모의 사용자 (Mock-up) 인터페이스 만들어 사용
▷ 벤치마킹
- 경쟁 제품, 성공 사례 및 업무 절차 참조하여 유사한 수준의 효과 낼 수 있는 기능 요구 사항 정의
▷ 사용자 스토리텔링
- 사용자 요구사항을 이야기 형식으로 기술해 자연스럽게 개발자가 요구사항에 대한 이해 가도록 구성
- 주로 애자일 방법에서 사용하는데 개발자와 사용자가 서로 긴밀이 대화하면서 요구사항 함께 만듦
▷ 업무절차 및 양식 조사
- 업무 관련 문서, 절차, 양식, 운영 메뉴얼 등을 조사함으로써 업무 절차와 처리 입출력의 이해
- 기업 내부 표준 검토함으로써 요구와 제한 사항 찾아 시스템 요구 분석서 제한 사항으로 적용
▷ 설문
- 이해 당사자들로부터 요구 찾는 도구
- 이해 당사자들을 의사결정 과정에 포함하여 관심, 내부 정보, 개선 의견 이끌어 냄
▷ 브레인 스토밍
- 여러 명으로부터 정보 얻는 효과적 방법
- 인터뷰와 같이 수행하면 더 많은 정보 추출 가능하며 훈련된 요원 주재로 과정 정돈하는 것이 중요
- JAD(Joint Application Development) : 사용자와 개발자 공동참여하여 프로토타입 기반 작업 수행함으로써 비즈니스 요구사항 명확히 도출하고 그에 따라 시스템 설계 및 개발
2. 요구사항 분석
- 도출된 요구사항들 간 상충 해결하고 SW 범위 파악하며 SW가 환경과 어떻게 상호작용하는지를 분석하는 과정
- 사용자의 요구 정확하게 추출하여 목표 정하고 어떤 방식으로 해결할 것인지 결정
- 사용자 요구사항 정확하고 일관성 있게 분석하여 문서화
- SW 분석가에 의해 요구사항 분석 수행
ㄱ. 구조적 분석방법론
- 도형화된 도구 이용해 정형화된 분석 절차에 따라 사용자 요구사항 파악하고 문서화하는 분석 기법
a. 자료 흐름도 (DFD : Data Flow Diagram)
- 시스템 처리 과정을 자료 흐름에 중점 두어 기술하는 분석용 도구
- 시각적으로 업무와 데이터 흐름 쉽게 볼 수 있어 프로그램 구현에 도움이 됨
- 작성 시 시스템 레벨별로 단계적 상세화 하며 자료 흐름 일관성 유지
▶ 자료 흐름도 구성요소
| 구성 요소 | 설명 | 표기법 |
| Process (프로세스) | 자료 처리/변환 과정 표현 |  |
| Data Flow (자료 흐름) | 자료 흐름 표현 |  |
| Data Store (자료 저장소) | 파일, DB 등 저장소 위치 표현 |  |
| Terminator (단말 | 자료 출처와 도착지 표현 |  |
b 자료 사전 (DD : Data Dictionary) (= 메타 데이터)
- 자료 흐름도 대상이 되는 모든 자료에 대한 기본사항들을 더 자세히 정의하기 위해 사용되는 도구
▶ 자료 사전 작성 규칙
▷ =
- 자료의 정의 (A는 ~로 구성되어 있다)
▷ +
- 자료의 연결 (A와 B 연결)
▷ ( )
- 자료의 생략 ( 없어도 되는 자료)
▷ [ | ]
- 자료의 선택 (A 이거나 B)
▷ { }
- 자료의 반복
▷ **
- 자료의 설명
※예시
- 고객 파일 = *구성은 주민등록번호에 따라 순차적임* = {주민등록번호 + 고객 명세 +
고객 신용 + {입금상황}}
- 고객 명세 = 고객 성명 + 고객주소 + 거래 개시일
- 입금 방법 = [현금 | 수표 | 신용카드]
c. 상태 전이도
- 시스템에 어떤 일이 발생할 경우 시스템 상태와 상태 변화를 모델링하는 것
▶ 상태 전이도 구성요소
▷ 시스템 상태
- 시스템이 수행중인 상태 의미하는 것
- 표기 : 직사각형
▷ 상태 변화
- 시스템이 어떤 상태에서 다른 상태로 변환되는 과정
- 표기 : 화살표
- 화살표 시작은 상태 변화 일으키는 사건 의미하고, 끝은 사건 결과로 발생하는 내용
▷ 조건과 행동
- 상태 변화를 일으키는 조건과 상태 변화시킬 때 시스템이 취하는 행동 명시
ㄴ. 유즈 케이스 기반 분석방법론
- 사용자 요구사항을 시나리오 기반으로 나타내기 위해 유즈 케이스 다이어그램 주요 사용. 모델링 표기법은 UML.
a. 유즈케이스 다이어그램
- 시스템이 제공하는 기능과 서비스 및 관련된 외부 요소를 사용자 관점에서 표현하는 UML 다이어그램
| 구성요소 | 내용 | 표기법 | |
| Actor (행위자) |
- 사용자가 시스템에 대해 수행하는 역할 - 시스템과 상호작용하는 사람 또는 사물 |
 |
|
| Use Case (유즈 케이스) |
- 시스템이 제공해야 하는 서비스 - Actor가 시스템 통한 일련의 행위 |
 |
|
| Relation (관계) |
액터와 유즈 케이스 간 관계 표현 | ||
| 연관 (Association) |
엑터와 유즈 케이스 간 상호작용 관계 표현 |  |
|
| 확장 (Extend) |
기본 유즈 케이스 수행 시 특정 조건 만족할 때 수행하는 유즈 케이스 표현 |  |
|
| 포함 (Include) |
유즈 케이스 실행 위해 반드시 포함해서 실행되어야 하는 유즈 케이스 표현 |  |
|
| 일반화 (Generalization) |
유사한 유즈 케이스들이나 액터들 모아 추상화하여 표현 |  |
|
| 그룹화 (Grouping) |
여러 개 유즈 케이스 단순화 하여 표현 |  |
|
| System (시스템) |
- 전체 시스템 영역 표현 - 특별한 의미 가지지 못함 |
 |
|
3. 요구사항 명세
- 도출된 요구사항 분석하여 정의하는 단계
- 요구사항 명세서는 이 단계에서 작성되는 최종 산출물
ㄱ. 요구사항 명세서
- SW가 수행해야 할 기능과 제약조건 등이 기술되어 있으며 이 후 진행되는 설계, 개발 및 테스트 완료 승인에 대한 기준으로 사용
- SRS : SW 요구사항을 어떻게 작성하는지 정의해 놓은 국제 표준 (IEEE std 830-1998)
▶ SRS 구성요소 예시
▷ 개요
- Introduction, 시스템 필요성과 비즈니스 목적에 대해 기술
▷ 용어
- Glossary, 사용되는 기술 용어에 대한 기술
▷ 시스템 모델
- 시스템 컴퍼넌트와 관계 설명
▷ 기능적 요구사항 정의
- Functional Requirement Definition, 제공되는 기능에 대한 설명
▷ 비 기능적 요구사항 정의
- Non-Functional Requirement Definition, 시스템 제약조건과 시스템 프로세스에 대해 설명
▷ 시스템 진화
- 시스템이 근거하고 있는 기초적인 가정과 예상되는 변화 기술
▷ 요구 명세
- Requirement Specification, 기능적 요구사항에 대한 상세한 설명
▷ 부록
- Appendix, 시스템 하드웨어 플랫폼, DB 모델 설명
▷ 색인
- Index
▶ 기능적 요구사항과 비 기능적 요구사항
▷ 기능적 요구사항
- 시스템에서 제공되어야 할 특정 기능 정의
- 데이터 모델 : 개념적인 모델 상태를 구체화한 것으로 생성, 삭제 등 실행 정의
- 데이터 흐름 처리 모델 : 시스템 행위가 어떻게 이루어지는가 표현하여, 데이터 모델 입출력이 데이터 일부분으로 사용함
- 프로세스 모델 : 병행, 상호작용, 다른 프로세서들 간 동기화 등 사건과 활동 서술
▷ 비 기능적 요구사항
- 시스템 전체적 품질이나 기능적 요구사항 구현 시 고려해야하는 제약사항
- S/W뿐만 아니라 시스템 전체에 대한 요구 사항
- 성능 : 응답 속도, 자원사용량
- 보안 : 침입 대응, 사용자 인증/권한
- 아키텍처 : 확장성, 유연성
- 안정성 : 장애 대응, 서비스 연속성
▶ 요구사항 명세 원리와 내용
▷ 명확성
- 각각 요구사항 명세 내용은 하나의 의미만 부여
▷ 완전성
- 기능, 성능, 속성, 인터페이스, 설계 제약 등에 관한 모든 시스템 요구사항 포함됨
▷ 검증가능성
- 요구사항 내용 충족 여부와 달성 정도 확인 가능
▷ 일관성
- 명세 내용 간 상호간 모순 없어야 함
▷ 수정용이성
- 요구사항 변경 시 쉽게 수정 가능해야 함
▷ 추적 가능성
- 각 요구사항 근거에 대한 추적과 상호참조 가능해야 함
▷ 개발 후 이용성
- 시스템 개발 후 운영 및 유지보수에 효과적인 이용 가능해야 함
▶ 요구사항 검토 방법
▷ 동료 검토 (Peer Review)
- 2~3명이 진행하는 리뷰 형태
- 요구사항 명세서 작성자가 요구사항 명세서 설명하고 이해관계자들이 설명 들으면서 결함 발견하는 형태로 진행
▷ 워크 스루 (Walk Through)
- SW 시스템 개발 단계마다 실시하는 비정형 검토 회의
- 오류 조기 검출에 목적 두고 리뷰 통해 오류 검출하고 문서화
▷ 인스펙션 (Inspection)
- SW 요구, 설계, 원시 코드 등 저작자 외 다른 전문가 또는 팀이 검사하여 오류 찾아냄
- SW 품질 높이는 방법의 하나
4. 요구사항 확인/검증
- 사용자 요구가 정확하게 요구 사항 명세서에 기술되었는지 검토하고 베이스라인으로 설정하는 활동
▶ 요구사항 검증 방법
▷ 요구사항 검토
- 요구사항 검토 담당자들이 요구 사항 명세서를 수작업으로 분석하는 방법
- 요구사항 명세서에 오류 없는지, 불명확한지, 표준 준수했는지 등 검토
▷ 프로토타이핑
- 개발할 시스템에 대한 주요 기능이나 일부분을 약식으로 개발하여 최종 사용자나 고객 대상으로 시연하면서 시스템이 작동하는 모습 경험할 수 있게 하고 요구 사항 확인
▶ 테스트 설계
- 요구사항 테스트할 수 있도록 테스트 케이스 생성하여 추후 요구 사항이 현실적으로 테스트 가능한지 검토
- 인터페이스 요구 사항에 대한 테스트 케이스는 송/수신 시스템에서 확인해야 할 사항 각각 도출하고, 송/수신 시스템에서 각각 개별 데이터 유효값을 체크하는 테스트 케이스와 송/수신 데이터 간 연관 관계 체크하는 테스트 케이스로 구별해서 작성
- 송/수신 데이터가 코드성 데이터일 경우, 코드 유효값 체크할 수 있도록 테스트 케이스 작성
- 수신 시스템에서 전송받은 데이터를 운영 DB에 반영하는 과정에서 오류 발생 않는지, 송/수신 시스템에서 참조하는 테이블에 데이터 없거나 데이터 갱신 및 등록 오류 발생하는지 점검 가능토록 테스트 케이스 작성
▶ 요구사항 관리
- 모든 요구공학 프로세스 단계와 동시에 수행
- 요구사항에 대한 변경 제어하고 시스템 완성도에 대해 이해관걔자와 합의 역할 및 책임 부여
■ 요구사항 관리 절차
□ 요구사항 협상
- 가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능 협상하기 위한 기법
□ 요구사항 기준선
- 공식적으로 검토되고 합의된 요구사항 명세서
□ 요구사항 변경 관리
- 요구사항 기준선 기반으로 모든 변경 공식적으로 통제하기 위한 기법
□ 요구사항 확인
- 구축된 시스템이 이해관계자가 기대한 요구사항에 부합되는지 확인하기 위한 방법
▶ 요구사항 관리 도구
- 요구사항 기반으로 프로젝트 관리, 설계, 개발, 테스트 등 수행 가능한 역할 지원하는 도구
■ 요구사항 관리 도구 주요 기능
□ 프로젝트 생성
- 프로젝트 타입 및 기본 모듈 템플릿, 속성, 역할별 뷰 설정하여 프로젝트 생성 도와주며 이를 저장하여 재사용할 수 있도록 할 수 있음
□ 요구사항 작성
- 모든 요구사항에 고유 ID 생성, 부여되고 이 ID는 사용자에 의한 임의 변경 될 수 없도록 함
□ 요구사항 Import/Export
- 요구사항 일괄 등록 및 추출위해 Plain Text, Rich Text 등 다양한 형식 파일 Import/Export 기능 제공
□ 요구사항 이력관리
- 요구사항 별로 히스토리 관리 기능 제공하여 변경 이력 관리 가능
□ 요구사항 베이스라인
- 요구사항 확정되고 관리 시작점이 되는 요구사항 베이스라인 기능 제공
□ 요구사항 추적성
- 어느 요구사항이 베이스인지 구분 위한 기능
- 현재 요구사항 기반으로 작성된 요구사항인지, 타 요구사항 기반으로 현재 요구사항 작성되었는지 알려줌
□ 협업 환경
- 하나의 요구사항 문서를 여러 명이 작성 가능토록 하는 협업 기능
- 일반적으로 공유 모드 제공하고 선점 사용자 외에는 수정 및 삭제 권한 제한
□ 외부 연동 환경
- 요구사항대로 설계되었는지 파악 위해 설계도구와 연동 지원하며, 요구사항대로 구현되었는지를 확인하기 위해 형상 관리도구와의 연동 지원
□ 확장성
- API 등 통해 타 시스템과의 연동 기능 제공
* 요구사항 추적 매트릭스 (RTM : Requirement Traceability Matrix)
☞ 최종 인도물에 요구사항 반영되기까지 프로젝트 생애주기 전 과정을 추적하는 도표
☞ 프로젝트 끝날 때 요구사항 문서에 승인된 요구사항이 인도되도록 지원하며, 제품 범위에 대한 변경 관리하는 데 유용한 체계 제공
▶ 요구사항 추적 매트릭스 구성 요소
▷ Project 정보
- Project Name : 프로젝트 명
- Project Manager Name : 프로젝트 관리자 명
- Project Description : 프로젝트에 대한 간단한 설명
▷ ID
- 요구항목 구별 가능한 식별자
▷ Associated ID
- 요구항목 추적 위해 사용하는 Utility와 관계된 식별자
▷ 기술적 가정
- 기능적 요구사항과 연결된 기술적 가정이나 고객의 필요성
▷ 우선순위
- 요구사항 우선순위
▷ 기능적 요구
- 기능적 요구사항
▷ 상태
- 기능적 요구사항 현재 상태
▷ 아키텍처/설계 문서
- 기능적 요구사항과 관계된 Architectural/Design 문서
▷ 기술적 사양
- 기능적 요구사항이 만족해야 하는 Technical Specification
▷ System Component
- 요구사항과 관련된 시스템 구성 요소
▷ SW Module
- 요구사항 구현에 사용되는 SW 모듈
▷ Test Case Number
- 기능적 요구사항 검토 위한 Test case 번호
▷ Verification
- 기능적 요구사항 검토 문서 관련 설명
▷ Additional Comments
- 추가적인 부연 설명
▶ 요구사항 추적 매트릭스 작성 방법
▷ 업무 구분
- 요구사항 및 업무 내용 도출할 해당 업무명 기재
- 고객 담당업무 분류하여 작성
- 요구사항이 특정 업무에 종속되는 경우 반드시 업무명 기재하고, 종속되지 않고 전체 없무와 관련된 경우 생략 가능
▷ 요구사항 ID
- 도출된 요구사항을 각각 구분하기 위한 식별자 기재
▷ 요구사항
- 해당 업무 구현하기 위한 세부 요구사항 기재
▷ 해결방안
- 요구사항 만족시키기 위한 해결방안 또는 처리내용 기재
▷ 출처
- 도출된 요구사항 출러 기재
▷ 분석
- 해당 요구사항 반영한 분석 단계 산출물 기입
▷ 설계
- 해당 요구사항 반영한 설계 단계 산출물 기입
▷ 개발
- 해당 요구사항 반영한 개발 단계 산출물 기입
▷ 테스트
- 해당 요구사항 반영한 테스트 단계 산출물 기입
* 요구사항 분석 도구/모델
1. CASE ( Computer Aided Software Engineering)
① Diagram 작성 도구 : SW 명세서 정의, 설계 결과 표현
② 설계 분석기 : 설계 명세서 정확성, 일치성, 모호성에 대한 검사
③ 코드 생성기 : 명세서로부터 프로그래밍 언어로 된 모듈 코드 생성
④ Repository : CASE 도구 중심, SDLC 동안 정보 저장
⑤ 프로젝트 관리 지원 도구
⑥ 재공학 도구 : 기존 시스템 설계 명세서 작성 지원
⑦ Prototyping 도구 : 초기 UI 작성 지원
▶ CASE 도구 분류
▷ Upper CASE
- 계획 수립, 요구 분석, 기본 설계 단계 지원하고 이를 다이어그램으로 표현
▷ Middle CASE
- 새 설계 작업 지원하며 화면/출력 등 작성 지원
▷ Lower CASE
- 시험, 유지보수 작업 지원하며 소스코드와 시스템 명세서 획득
▷ I-CASE
- 위 세 가지 통합한 것으로 Rational ROSE, COOL 등이 국내에서 사용 중
ㄱ. HIPO (Hierarchical Input Process Output) 모델
- 하향식 SW 개발 위한 문서화 도구
- 기능과 자료 의존 관계 동시 표현 가능해 보기 쉽고 이해 쉬움
- 1970년대부터 쓰인 시스템 분석용 디자인 도구 및 문서화 기법
- 시스템 표현하는 모듈들 계층적으로 나타내고 모듈들 문서화하기 위해 사용됨
▶ HIPO 도표 구성
▷ 가시적 도표 (Visual Table of Contents)
- 시스템 전체적인 기능과 흐름 보여주는 Tree 형태 구조도
▷ 총체적 도표 (Overview Diagram)
- 프로그램 구성하는 기능 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보 제공하는 도표
▷ 세부적 도표 (Detail Diagram)
- 총체적 도표에 표시된 기능 구성하는 기본 요소들을 상세히 기술하는 도표
☞☞☞ Part01-01-2. 요구사항 확인 (2)
'정보처리기사 > 필기' 카테고리의 다른 글
| [정보처리기사] Part01-01-3. 분석모델 확인 (1) (0) | 2022.02.24 |
|---|---|
| [정보처리기사] Part01-01-2. 요구사항 확인 (2) (0) | 2022.02.24 |
| [정보처리기사] Part01-01-1. 현행 시스템 분석 (0) | 2022.02.21 |
| [정보처리기사] Part05-01-1. 소프트웨어 개발방법론 선정 (1) (0) | 2022.02.16 |
| [정보처리기사] Part04-02-3. 라이브러리 활용 (0) | 2022.02.16 |
댓글