※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※
1. 도출
설명
비즈니스 분석가가 이해관계자로부터 목표 시스테에 바라는 요구를 식별하는 단계
요구사항 도출 기법
- 인터뷰
- 직접 대화를 통해 요구사항 도출
- 개인, 소규모 그룹을 대상으로 실시 → 통제 수월
- 라포, 경청
- 범위에서 벗어나면 안됨
- 폐쇄적 X, 개방형 질문 O
- 폐쇄적 질문 : y/n과 같이 미리 정해진 해답을 가지는 질문. 보통 확인 용도
- 개방형 질문 : 답이 정해지지 않음. 상세한 정보 획득 용도
- 5 Whys 기법으로 문제의 근본 원인 식별
- 워크숍
- 이해관계자들의 협업을 통핸 요구사항 도출 및 정의
- 다양힌 이해관계자들, facilitator(촉진자), 서기 참여
- 특정 주제 기반의 의견 공유
- 다양한 이해관계자의 요구사항 동시 도출
- 의견 충돌 해소, 가능한한 빠른 합의에 도달
- 정해진 시간 집약적인 의견 교환 가능
- 설문
- 대규모 사용자 그룹의 요구를 이해하기 위한 조사 방법
- 상용 제품에 대한 피드백
- 가장 문제가 되는 영역 파악
- 우선 순위 결정같은 정량적인 데이터의 제시가 필요할 때
- 브레인 스토밍
- 짧은 시간에 소수의 그룹이 최대한 많은 아이디어를 이끌어내기 위한 방법, 집단적 창의적 발상 기법
- 4S 기법
- 비판 금지(support)
- 자유 분방(silly)
- 양산(speed)
- 결합과 개선(synergy)
- 관찰
- 업무 환경에서 사용자의 workflow를 관찰하여 현 시스템의 문제를 식별하고 신규 시스템이 더 나은 workflow를 제공하는 방법 파악
- 적극적인 관찰: 사용자가 업무중에도 질문 가능 → 사용자의 어떤 행위의 이유를 바로 이해할 수 있음
- 수동적인 관찰 : 조용히 관찰
- 문서 분석
- 시스템에 관련된 모든 문서 분석
- 기존 시스템, 신규 시스템에 대한 정보 습득
- 시스템 교체 프로젝트인 경우, 더 이상 필요 없는 기능뿐 아니라 계속 유지해야하는 기능 식별
- 문제 보고서, 개선 요구서는 시스템이 추후 제공할 아이디어 제공
2. 분석
설명
- 도출된 불완전하고 추상적인 요구사항들을 적절한 수준으로 정제하는 작업
- 고객과의 상호 작용을 통해 혼동 지접을 명확히 하고 어떤 요구 사항이 다른 요구사항보더 더 중요한지 파악
- 요구사항 모델링을 통해 보다 구체화되고 가시화되어 시스템에 대한 이해도 크게 향상 및 개발에 필요한 정보 제공
모델링
- 구조적 분석 (DFD)
- 시스템의 기능 중심으로 분석 실행
- 프로세스 도출, 및 프로세스 간의 데이터 흐름 정의
- 유스케이스 분석 보델링 (UML)
- 요구사항을 사용자 중심의 시나리오 분석을 통해 유스케이스 모델로 구축하는 것
- 유스케이스 모델에서의 상세적인 내용은 유스케이스 명세서에 작성
- System : 만들고자 한느 어플리케이션
- Actor : 시스템 외부에서 시스템과 상호작용하는 사용자 또는 다른 시스템
- usecase : 액터에게 제공해야하는 기능의 집합, 요구사항
- Relationship : 액토와 유스케이스 사이의 의미있는 관계
- 포함/확장 관계 : (시작 유스케이스)는 (도착 유스케이스)를 <<종류>>한다
- 상호작용의 상세한 내용은 유스케이스 명세서 작성
- 유스케이스 명세서
- 유스케이스 명
- 액터 명
- 유스케이스 개요 및 설명
- 사전 및 사후 조건
- 작업 흐름
- 정상흐름(Normal Flow): 해당 유스케이스가 정상적으로 수행되는 흐름을 표현하는 절차
- 대체 흐름(Alternative Flow): 유스케이스 내의 작업 흐름이 수행되는 중에 특정 시점에서 여러 가지 선택인 흐름으로 나뉘어질 경우에 발생하는 흐름
- 예외 흐름(Exceptional Flow): 유스케이스 내의 작업 흐름이 수행되는 중에 발생할 수 있는 예외 상황이나 오류를 표현하는 흐름
-
시나리오: 각 시나리오는 유스케이스의 특정한 예를 나타냄
- 사용자 스토리
- ERD
- State Transition Diagram
- Dialogue Map
3. 명세
설명
- 분석된 요구사항을 명확하고 완전하게 기록하는 것
- 시스템이 수행해야할 모든 기능과 구현상의 제약 조건 및 개발자와 사용자가 합의한 성능에 관한 사항들을 명세
- 최종 결과물 : 요구사항 명세서(SRS: sofrware Requirement Specification)
- ** IEEE 830
좋은 요구사항 작성을 위한 특성
- IEEE-STD-830 : 요구사항 명세서의 표준을 정한 문서
4. 검증
설명
- 요구사항이 정확하고 올바르게 작성되었는지 확인 (1:10:100)
- IEEE-Std-1028
리뷰
- 정적 vs 동적 : 프로그램 실행 차이 (정적 : X, 동적 : O)
- 정적 테스팅의 대상은 SRS를 포함한 모든 산출물(문서)이 대상
- 리뷰 vs 정적 분석 : 수동 or 자동화 툴 (리뷰 : 수동)
- 동적 테스팅, 정적 분석 : 코드 대상
- 리뷰 : 문서 대상
- 프로그램 실행 X
- 동료와의 협동 작업을 통한 작업 결과물 검토
- 오류 검출, 표준과의 부합 여부, 개선, 새로운 정보 교류 및 교육 목적
- SRS를 포함한 모든 산출물이 리뷰의 대상
- VS 동적 테스팅
- 이해용이성/유지보수성과 같은 품질 특성을 테스팅으로 평가할 수 있나?
- 동적 테스트는 오류의 직접적인 원인을 찾지 않음. 리뷰는 직접적인 원인 탐색
- 동적 테스트는 결함때문에 진전되지 못해도 검토는 가능
- Inspection
- 리뷰의 일종으로. 가장 형식적인 peer review(비슷한 직군의 사람들) 방법
- 참가자에게 역할 부여
- 미리 계획됨
- 참가자 역할
- 개발자(Author)
- 작업 산출 책임
- 인스펙션 요구 및 필요한 자료(인스펙션 패키지) 제출 의무
- 회의때 질문에 대한 답변
- 미팅에서 검출된 오류 등을 수정
- 주재자, 리더, 서기 불가
- 회의주재자(Moderator/Inspection Leader)
- 인스펙션 일정 계획
- 참가자 선정 및 역할 부여
- 인스펙션 패키지 취합하여 참가자들에게 미리 전달
- 재작업(rework) 검증 또는 위임
- 인스펙션 요악 보고서 작성
- 리더(Reader)
- 회의동안 발표
- 자신의 이해를 바탕으로 모델등 이용
- 질문, 코멘트, 문제 등을 이끌어 냄
- 사서와 동일인 X
- 서기(Recorder/Scribe)
- 이슈 로그 작성
- 검토인(Inspector)
- 인스펙션 패키지 검토
- 문제 발견 및 개선책 제시
- 검증인(Verifier)
- 인스펙션 회의에서 발견된 모든 결함들을 제대로 수정했는지 확인 (follow up 단계)
- 수정 안된 결함에 대해 왜 수정 안했는지에 대한 결정이 올바른지 확인
- 제기된 개선책 구현 확인
- gold plating 확인
- 최종 결과물이 형상 관리 시스템에 제공되었는지
- 재작업(rework)
- 발견된 결함 및 이슈 해결 단계
- 관련 문서도 수정
- 어떻게 처리했는지 명시
- 안했다면 안한 이유 기록
- follow up 단계
- 이슈 로그에 있는 모든 결함들이 처리가 올바르게 되었는지 확인
- 안된 결함은 개발자의 결정이 올바른지 판단
- 수정된 결과물에 대해 재작업이 잘 이루어졌는지
- 최종 결과물을 형상관리 시스템에 인도
- 실재적 결함에 대한 통계가 인스펙션 요약 보고서에 반영되어 보고
- 개발자(Author)
- WalkThrough
- 결함을 찾고 대안을 시험하고 학습수단으로도 활용
- VS Inspection
- 인스펙선: 회의 주재자는 개발자가 아닌 사람
- 워크쓰루: 개발자 본인이 보통 회의를 주재하며 개발자의 요청으로 이루어진다.
- 참가자들의 역할이 인스펙션과 같이 명확하게 구분되지 않을 수 있음. 주재자(보통 개발자)가 서기 역할을 할 수 있다.
- 체크리스트 사용은 옵션이며 사전 검토 작업을 수행
- Rework/follow-up은 요구되지 않는다.
- 인스펙션 보다는 비형식적인 리뷰 방법
프로토타이핑
- 프로토타입
- 시스템의 일부 측면을 사용자가 경험할 수 있는 도구
- 요구사항에 대한 대화 촉진
- 이해 관계자가 시스템의 요구사항에 대한 공통의 이해 달성
- 요구사항 오류나 누락 식별 용이
- 요구사항 도출 도구로도 사용
- 종류
- 범위에 따른 분류
- 수평적
- front-end만 존재하고 back-end 구현 미비
- 정해진 출력 및 오류 처리 미비
- 명확한 요구사항 파악, 요구사항 구체화, 요구사항 누락 식별, 잘못되었거나 불필요한 요구사항 파악, 대안 프로세스
- 수직적
- 특정 기능 부분을 실제 동작하도록 구현
- 기술의 타당성 평가 목적, PoC (Proof of Concept) 구현
- 충실도에 따른 분류
- fidelity : 최종 제품과 흡사한 정도
- Throwaway vs Evolutionary
- Throwaway 프로토타입
- 일회성
- 목적 달성 후 폐기
- 엄격한 개발과정 X, 빠른 구현과 수정 강조
- Evolutionary 프로토타입
- 진화형
- 프로토타입을 기반으로 점진적 개발
- 엄격한 개발과정
테스팅
- 요구사항은 테스트 케이스를 설계하는 기반
- 테.케 설계 : 예상 시스템 동작 가시화
- 모호한 요구사항 = 모호한 입/출력
- Dialog Map을 통해 예상되는 케이스를 작성한다.
'대학교 > 소프트웨어공학론' 카테고리의 다른 글
| 4. 요구사항 (0) | 2023.04.24 |
|---|---|
| 3. scrum (0) | 2023.04.24 |
| 2. rad, lean startup, agile, DevOps (2) | 2023.03.28 |
| 1. 소프트웨어 공학의 태동, 유지보수, waterfall, Iron triangle (0) | 2023.03.13 |
