StarUML NS - 2.star rail요구사항 도출 표준

1. 요구사항 도출 표준

2. 1. 요구사항 추출
2. 요구사항 분석
3. 요구사항 명세
4. 요구사항 검증

3. 요구사항 추출

4. 1.1 개요
 요구사항 추출은 개발될 소프트웨어와 관련하여 고객이 요구하는 기
능과 제약사항을 파악하는 과정.
 요구사항 추출 기술
• 비즈니스 목표, 비전, 시스템 구축 범위를 공유하고 구성 분야별로 대표성을 갖는
이해관계자를 효과적으로 식별하여야 한다
• 고객의 요구사항은 대부분 애매모호하고 단편적이거나 실현가능성을 고려하지 않
으므로, 전체적인 과정상의 누락 부분을 체크하고 측정 가능하며 명확한 요구사항
을 추출하여야 한다
• 요구사항 분석가는 해당 분야 전문지식, 통찰력, 논리적 사고 능력, 고객 등 이해당
사자와의 의사소통 능력 및 요구사항 변경 요구에 대응할 수 있는 협상 능력을 갖
추어야 한다

5. 1.2 요구사항 추출 전략
What does the User really need?
다양한 참여자로부터
(마케팅, 개발자, 테스터)…)
고객의 추상적 요구
(Needs)
Stakeholder
Needs/Goal
구체적 요구
Stated
Requirements
(Candidate Requirements)
무엇을 개발할 것인가?
System
built
좋은 요구사항 정의를 위한 정보 획득
Find and Listen Voice of Customer Carefully
Who’s
Smart?
 추출 과정을 통하여 스스로 needs를 인식.
• 개발자 중심의 문제 접근 : 개발자가 미리 문제 해결을 예상
• “You are Smart”의 확신이 아닌 “ Stakeholder is Smart”을 인식
Care
 개발자 중심이 아닌 고객 중심의 가치로부터 요구사항을 추출
• 능동적인 참여자 투입 : 수동적 요구사항 수집이 아닌 능동적 요구사항 추출
고객 중심의
요구정보 추출

6. 1.3 요구사항 추출 절차
Analyst
현행 시스템
분석
현행 시스템 분석서
용어 정의
용어 정리집
비즈니스
요구사항 정의
사용자
요구사항 정의
요구사항 정의서

7. 1.4 요구사항 추출
1.4.1 현행 시스템 분석
 현행 시스템 현황 및 프로젝트 참여 인원 선정하는 단계
입력물
액티비티
 현행 시스템 현황
 조직도
협의/검토
 협의
출력물
 현행 시스템 분석서
1.
2.
현행 시스템 분석
프로젝트 관련자 추출
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 현행 시스템 이해 및 분석을 통한 요구사항 도출
대
중
소
-
-
-

8. 1.4 요구사항 추출
이해관계자 그룹 식별
One Stakeholder can not speak for All
•
고객 그룹
요구사항 추출 관련 다양한 소스의 존재
•
다른 기술, 배경 및 기대를 공유
관리
분석
사용자 계층 고객 대표 선정
•
요구사항 분석가와 의사소통
통로
•
참여자 역할
•
초기부터 포함하고 지속적으로 유지
•
참여자 접근 제한 / 부적절한 참여자의 포함
/ 너무 많은 참여자의 참여
•
고객의 R & R 부여
•
요구 충돌 해결을 위한 우선
순위

9. 1.4 요구사항 추출
이해관계자 관점 평가
•
프로젝트 목적에 중요한 참여자 식별
이해관계자
•
Stakeholder의 영향 수준, 상대적 우선순위 결정
우선 순위
•
요구사항 충돌 시 어느 그룹에 우선순위를 둘 것인가?
•
참여자의 요구와 기대가 충돌할 때 위험성 증가
•
낮은 중요도와 높은 영향력의 참여자 관심과 목표 충돌 시 잠재적 위험도 높음
•
핵심 참여자의 역할과 참여 시점 분석
•
Assumptions과 risks에 영향 :
이해관계자
위험도
이해관계자
참여자
 부적절한 참여자의 포함
 참여자에 대한 접근 제한

10. 1.4 요구사항 추출
이해관계자 관점 통합
시스템 이해관계자의 식별, 요구와 충돌 해결을 위한 관점과 특성 기술

이해관계자 유형
그룹
이름
소속/직위
이해관계자 특성
역할
시스템 개발
개발자
홍개발
개발 1팀
도메인전문가
김전문
기술팀 PM
참여자 사이의 불
일치 조정
김판매
영업부과장
시장 규모 및 특성
전문가
김관리
기획팀 이사
의사 결정 권한
QA 과장
테스트 가능 요구
사항의 검증 및 테
스트 계획과 테스
트 케이스 작성 지
원
마케팅
PM
품질관리
박품질
비즈니스목표
기술 제약사항
참여
도
관련기술 지식이 낮
음
영향도
중요도
상
시스템
완전성
편리한 사용
이해관계자 관계
상
50%
중
상
80%

11. 1.4 요구사항 추출
1.4.2 용어 정의
 표준,명세 또는 정규화된 문서를 층족하기 위한 표준화된 용어 정의
입력물
액티비티
출력물
 용어 정리집
-
협의/검토
수행자
1.
업무 용어 작성
 협의
 시스템 전문가
프로젝트 규모
승인
 승인
 시스템의 동작 방식 및 속성/특성 등에 대한 설명
대
중
소
-
-
-

12. 1.4 요구사항 추출
1.4.3 비즈니스 요구사항 정의
 이해관계자들이 문제영역과 시스템환경을 이해하고 공유하며, Business Vision과 범위 설정
입력물
액티비티
출력물
 요구사항 정의서
-
협의/검토
 협의
1.
2.
비즈니스 요구사항 정의
업무 프로세스 정의
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 비즈니스 요구사항 정의,참여자 식별, 초기 요구사항 추출
 이해관계자가 자신의 문제와 요구를 기술할 수 있도록 하는 환경 조성
대
중
소
-
-
-

13. 1.4 요구사항 추출
비즈니스 요구사항 - 개요
프로젝트 목적을 확립하기 위한 조직의 고수준 비즈니스 목표
Business Rationale for authorizing the project
• Vision : “최종 product가 무엇을 달성해야 하는가”의 long-term view
• Scope : product가 제공할/제공하지 않을 기능을 명확화
고객의 관점을 이해하고 조정
• “Big picture of view”: 모든 이해관계자에게 일관성 있는 관점 제공
• 시간 단축과 분쟁 감소 : 요구사항의 분기와 불일치 및 누락 방지
비즈니스 측면의 관심 요구사항과 기술 설계 측면의 관심 요구사항을 분리
• High-level Technical/Non-technical features의 business process 정의
• 비즈니스 요구사항 문서 : 개발 이유, 예상 비용, ROI 등

14. 1.4 요구사항 추출
비즈니스 요구사항 - 시스템 Vision
프로젝트 연결성 확보를 위한 궁극적인 목표에 대한 전략 수립
고객과 사용자가 문제를 확실히 알지 못함
불완전한
목표
• 문제를 단순, 비현실적 인식
• 지속적 변경 : 문제가 아닌 솔루션 검토
Concrete Goal의 정의
• Conflicting goals 인식
• “Tunnel Vision” : sensible starting
point
움직이는
목표와
추정
부정확한 또는 낙관적인(잘못된) 목표와 추정
• 잘못된 시간과 인원으로 납기/예산 추정
• 비현실적인 목표에 따른 추정과 자원 압박
: milestone, 품질 희생
• 프로젝트 진행 중 변경에 대한 미조정
통제 가능한 기대형성
• Vaporware : 고객에게 기대를
약속하고 제공

15. 1.4 요구사항 추출
비즈니스 요구사항 - 시스템 Scope
Product의 boundary 정의
실세계와 시스템의 External Interface
• 시스템 범위의 명확화 :“이것이 범위 안에 있습니까?”
• 초기에 외부 인터페이스를 정의 : 잘못된 가정에 의한 재작업 감소
합리적인 범위제한
특정 릴리즈 범위 관리
범위 확장 관리
• 개발자와 고객이 같은 expectation
• “Gold-Plate”의 방지 : 수행할 것/하지 않을 것, 포함할 것/하지 않을 것
• ”Divide and Conquer” : 단계별 개발
• Feature level : 특정 릴리즈의 범위 관리
• Endless Scope Change : 요구사항 확장의 예상과 계획
• 통제를 벗어나는 프로젝트 : 현실적인 목표보다 희망사항을 제공 (Cole, Andy)
• Needs vs.요구사항, 요구사항 vs.일정/비용/위험의 balancing

16. 1.4 요구사항 추출
비즈니스 요구사항 - Business Assumption/Constraints 정의
시스템 Goal과 Scope에 대해 특정 환경에 대한 가정과 제약
프로젝트 수행 팀/개발자에 의한 가정 : 모든 참여자에게 동의
Business
Assumption
• TBD(To Be Defined) : 불확실하거나 아직 결정되지 않은 문제
• Open Issue : 결정을 보류하거나 해결이 필요한 비즈니스 리스크
시스템의 설계/구현과 관련된 기술적 제약사항
Technical
constraints
• 시스템 개발 환경 : HW/SW/NW/DB/PL, 설계/구현 방법, 다른 SW와 인터페이스,
개발 인원/일정/비용
• 시스템 운영 환경 : 구현/설치/운영 환경 제약, 기존 시스템/데이터 호환, 서비스수준 계약(SLA)
시스템의 설계, 구현과 관련된 표준 적합성
Standard
• 조직의 정책 : 보안, 데이터 접근, 변경관리, 마이그레이션 정책 (상호운용성 제공)
Compliance
• 도메인 표준과 법률 : 공식/사실 표준과 조직의 규칙/산업 규칙, 도메인 관련 법률

17. 1.4 요구사항 추출
비즈니스 요구사항 - 요구사항 정의 사례
An Insurance Domain Project Business Requirement
Scope Item
Example
Needs
•
“보험 비즈니스에서 수입을 증대할 필요가 있다.”
Goal
•
현재 고객에 대해 보험 상품 판매를 증대시킬 수 있도록 한다.
Objective
•
Agent가 매출 기회를 더 쉽게 알 수 있도록 한다.
Business rule
•
•
주택을 보유한 보험 고객에게 자동차 보험을 판매한다.
자동차보험 가입 고객에게 주택보험을 판매한다.
•
고객이 현재 보험에 대해 문의했을 때 추가 영업 기회에 주의를 기울일 수 있도록 보험 agent
에게 완전한 고객 프로파일을 출력한다.
Agent는 추가적으로 고객에게 적합한 보험 조건을 제시하고 고객이 선택한 보험의 판매를 조
절한다.
Operation
concept
•
Assumption
•
•
자동차보험 고객은 주택을 소유하고 있다.
주택보험 고객은 자동차를 소유하고 있다.
Constraints
•
•
현재 인원을 사용한다.
현재 컴퓨터 시스템을 사용한다.

18. 1.4 요구사항 추출
1.4.4 사용자 요구사항 정의
 업무관련자 정의 후 사용자의 입장에서 현황을 파악하고 사용자가 원하는 문제 해결이 어떤 내용인지 도출
입력물
액티비티
출력물
 요구사항 정의서
-
협의/검토
 협의
1.
2.
업무 관련자 정의
업무 관련자 요구사항 추출
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 개발과 요구사항의 연결성 확보
 요구사항 재사용을 위한 자산화(Repository 구축)
대
중
소
-
-
-

19. 1.4 요구사항 추출
요구사항 추출 활동
고객 중심의 추출 기반으로 요구사항 가시화와 자산화
개발과 요구사항의
연결성 확보
• Business Vision 및 범위 설정
이해관계자 식별
• 요구사항 추적 정보의 관리
비즈니스 요구사항 정의
고객 중심의
요구사항 가시화
• Stakeholder의 관점 식별 및 분류
• 요구사항 추출 및 분류
사용자 요구사항 추출
요구사항 재사용을
위한 자산화
• 요구사항 속성 정보 관리
• Repository 구축
요구사항 추출정보 관리

20. 1.4 요구사항 추출
요구사항 추출 기법
No one technique is sufficient for realistic projects
질의(asking)
논의 및 정형화
(discussing and formulating)
재사용(reuse)
•
•
•
•
Interviews
Questionnaires
Brainstorming
Role Playing
• Reuse documents/data
표현기반
• Scenario-oriented/Goal-oriented/Use cases-driven
적절한 요구사항 추출 기법을 사용 - 고객의 표현의 문제
High
기법
• Interviews
• Role Playing
Customer
• Brain Storming
• Requirements
Workshop
• Prototyping
Low
Analysist
역할
같은 장소
같은 시간
소수 인원
주도
다른 장소
다른 시간
다수 인원
관찰
그룹세션
High
인원
설문
• Use Case
시간
인터뷰
• Surveys
• Questionnaires
장소
같은/다른
장소
같은 시간
20인 이하
보조
관찰
같은 장소
같은 시간
소수 인원
관찰

21. 1.4 요구사항 추출
요구사항 추출 기법 - Interview
Ask Question & Listen answer
• 관련자들과 직접 대화를 통하여 상세 정보를 추출
• 소수의 인원이 많은 정보를 알고 있을 때/SME가 존재할 때
• 모든 관점을 고려 - 많은 정보 획득
• lack of structure– 분석의 어려움
Closed Interview
 중립적 입장에서 자연스럽고 효과적으로 이끄는 역할 요구 : No bias
 심문이 아니라 질문을 한다 : “대체 원하는 요구사항이 뭡니까?”
 고객을 분석가의 의도대로 이끄는 질문은 피하라.
 단순히 고객의 대답을 기록하는 것이 아니다 : 상대방의 의도를 표면화
 이유를 탐색한다 : Rationale과 Source의 관리
Open-ended Interview

22. 1.4 요구사항 추출
Interview 수행 고려사항
인터뷰 前
Before
Interview
Context-free Questions
Context-Setting 관련 질문
• 인터뷰 목적과 contextual 영역을 정의
• 시스템 관련 지식, 공통 용어 수집
• 고수준(High-level) 추상적 질문
• 고객의 관점에서 요구 조사
• 인터뷰어의 attribute : bias 배제
인터뷰 中
During
Interview
• 인터뷰 대상자의 말을 경청 : Listen, listen, listen
• 앞선 질문으로부터 다음 질문을 유추
• Feedback과 이해를 위하여 모델과 sketches 사용
인터뷰 後
After
Interview
Context-free Questions
문제 이해를 높이는 질문
인터뷰 유효성에 대한 질문
• 상대방에게 그 밖에 질문할 어떤 것이 있는가?
• 빠뜨린 질문이 있는가?
• 이후에 추가 질문을 할 수 있는가?
• 유도 질문 : Do you need a larger screen, don’t you?
• 자기 응답 질문 : Are fifty items about right?
• 제어 질문 : Can we get back to my questions?
• 복잡한 질문 : I have a three part questions, …
• 방어적인 질문 : “대체 원하는 게 뭐죠?” / “요구사항이
뭡니까?”
• Unanswerable 질문 : How to tie your shoes?
• Closed ended questions : Yes/No 대답을 얻는 질문

23. 1.4 요구사항 추출
요구사항 추출 기법 - Brainstorming
소수 그룹에 의한 빠른 의견 생성
• Group Session (2~4명, 4~20명)
• 짧은 시간 동안 다수의 아이디어 자유롭게 도출
• 신선하거나 특이한 아이디어를 도출할 수 있음
• 다양한 견해를 제공 : wild, crazy or impractical 의견의 수용
생성 단계
통합 단계
(generation)
(consolidation )
• 각 메모지에 한가지 생각만을 적는다.
• 의견 분류 및 논의 : reword, 불가능 의견 삭제
• 각 메모지를 아이디어에 따라 서로 연결한다.
• w 의견 명확화 및 구조화
• 리스트에서 최고의 아이디어를 선정한다.
• w 의견 우선순위화
• 더 많은 아이디어를 적고 연결한다.

24. 1.4 요구사항 추출
Brainstorming 고려사항
• 공유성 : 참여자들의 아이디어를 합병하여 새로운 아이디어 생성
가능한 많은
의견의 생성
• 기발한 요구사항의 발견, 조사 - 편향된 사고를 피함
• 비현실적/관계 없는 의견 제시의 수용 – 변화 가능성
• 자율성 : 제시된 의견에 대한 평가나 논쟁 금지
자유로운 의견
표현
• 의견을 설명하거나 명확화 하지 말 것
• 조직문화 차이의 인정 : 팀 작업 시 개인의 능력 인정
의견 Listing &
공개
• 익명성 : 의견에 개인 이름을 붙이지 말 것
• Post-it, whiteboard 또는 large sheets에 기술
• Domination by a Few : “Five-Minute Position Statement” Coupon
효율적인 Group
• Lack of Participation by Some : “Great Idea” Coupon
Sessions
• “Cheap Shot” Coupon

25. 1.4 요구사항 추출
요구사항 추출 단계 핵심 성공 요소
1. 이해관계자들이 요구사항을 구체화할 수 있도록 가이드
요구사항 : xx 보고서 기능이 필요
응대 : 보고서의 크기는? 생성 시기는? 주기는?
2. SW 테스터들의 조기 참여
테스트 가능한 요구사항인가?
USE CASE 개발시 테스크 계획을 고려
3. 이해관계자들의 관점으로 성공을 정의하고 문서화
4. 요구사항 재사용 환경 조성
5. 요구사항과 관련된 고객사의 비즈니스 규칙을 고려
6. 요구사항 고객 승인 절차의 중요성 인식
수백 페이지의 요구사항 문서 승인을 요청하면?
- 고객의 이해없는 단순 승인은 대부분의 프로젝트에서 진행중에 문제를 야기시킴

26. 1.4 요구사항 추출
요구사항 추출 가이드
1. 요구사항 기술시 부정적이거나 전도된 표현을 피할 것
3개 이상의 계좌 소유 고객은 이동할 수 없다 => 3개 미만의 계좌 소유 고객만 이동시킬 수 있다
2. 경계 조건의 명확화
매출 백만원 이상, 매출 백만원 이하 => 이상, 이하, 초과, 미만을 적절히 사용하여 누락 방지
3. 용어 통일 및 표준화
요구사항 추출시 명확하고 표준화된 용어와 표현을 사용(필요시 용어사전 작성, 활용)
4. 대명사, 부사 등 사용시 의미의 명확화
이것, 저것, 일반적 등 모호한 표현 지양
5. A/B 같은 다중적 표현 주의
feature/function 과 같은 여러가지 해석을 초래할 수 있는 표현 지양
=> 해석 가능한 의미 1. feature 는 function 과 같은가?
2. feature 와 function 을 의미하는가?
3. feature/function 중 언급되는 것은?

27. 요구사항 분석

28. 2.1 개요
 추출한 요구사항에 대한 충돌, 중복, 누락 등에 대한 분석을 통하여 완전성과
일관성을 가지고 참여자 사이에 동의된 요구사항을 구성하는 활동
 문제기술 (또는 제안서)을 보다 세부적으로 다루어 시스템의 요구사항을 세분
화하고 그 결과를 통합하여 원하는 시스템을 기술.
 시스템이 만족시켜야 하는 기능, 성능, 그리고 다른 시스템과의 인터페이스
등을 규명한다.
 요구사항 분석 결과에 대한 고객 만족 확인이 단계의 핵심 요소임
 요구사항 분석 기준
• 분석은 시스템을 계층적이고 구조적으로 표현.
• 외부 사용자와 인터페이스 및 내부 시스템 구성요소 간의 인터페이스를 정확히 분석.
• 분석단계 이후의 설계와 구현단계에 필요한 정보를 제공.
• 기술적 지원보다 특정한 시간에 특정한 사람을 투입.

29. 2.2 요구사항 분석 전략
고객의 핵심 요구사항 확인 + 요구와 제약사항의 balance 분석
 Business owner’s View를 Architect’s View로 변환
 요구사항과 기능적 구조/ 수행 결과의 위험 평가
시스템 기능, 성능 및
인터페이스 등을 정의
참여자 요구 만족에 초점
고객의 요구에 대하여 무엇을
수행할 것인가?
불완전하고 추상적인
초기 요구사항
정확성, 일관성을 가진
동의된 요구사항
(Candidate Requirement)
(Agreed Requirements)
 요구사항 모델링 : 추상적 요구사항의 구체화
 요구사항 우선순위화 : 위험 관리/ 충돌 해결을 위한 우선순위
 요구사항 선정 : 다음 릴리즈에 포함될 요구사항 선정
고객의 가치를 중심으
로 needs 만족 확인

30. 2.3 요구사항 분석 절차
Analyst
요구사항
체계 수립
요구사항 명세서
기능 요구사항
분석
Use Case
체계 수립
Use Case Model

31. 2.4 요구사항 분석
2.4.1 요구사항 체계 수립
 요구사항 분석에서 추출 된 불완전한 요구사항에 대한 분석을 통하여 완전성과 일관성을 가지고 참여자들 사이의
동의된 요구사항 구성하는 활동.
입력물
액티비티
 요구사항 명세서
 요구사항 정의서
협의/검토
 협의
출력물
1.
2.
3.
요구사항 속성 식별
요구사항 분류
요구사항 우선순위 식별
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 개발과정에서 발생 할 수 있는 오류를 최소한으로 방지, 목표시스템 접근 기반 마련
대
중
소
-
-
-

32. 2.4 요구사항 분석
요구사항 우선 순위화
•
고객의 중요도 (How much does the customer want it?)
요구사항
•
구현 비용 (How much cost to develop?)
우선순위화
•
구현 시간 (How much time to deliver?)
영향 요소
•
구현의 기술적 용이성 (How technologically difficult?)
•
비즈니스 가치 (How much will the business benefit?)
Value 기반
Core Business
기반
• Value, Cost, Risk
• Cost, Risk 제약 안에서 Product value를 최대화
• 우선권을 가지는 사용자 계층이 요구
• 규제 준수에 필요한 기능 제공
• 다른 시스템 기능들이 의존

33. 2.4 요구사항 분석
2.4.2 기능 요구사항 분석
 목표시스템이 반드시 수행하여야 하거나 목표시스템을 이용하여 사용자가 반드시 수행할 수 있어야 하는 기능(동
작)에 대하여 정의.
입력물
액티비티
 Use Case Model
 요구사항 정의서
협의/검토
 협의
출력물
1.
2.
3.
4.
Actor 추출
Use Case 추출
요구사항과 Use Case 매핑
Use Case Diagram 모델링
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 구현되어야 할 필수적인 작업과 동작 등을 정의, 어떤 기능이 구현되어야 하는지를 설명
대
중
소
-
-
-

34. 2.4 요구사항 분석
요구사항 모델링
Business
User Requirements
Requirements
Alternative Models
Who?
Stakeholder
Categories
Actor Table
Actor Map
Dialog map
Prototypes
Dialog Hierarchy
What?
Relationship Map
Glossary
Context Diagram
Data model
Class Model
Data Dictionary
Data tables
When?
Event-Response
Table
State Diagram
State Data
Matrix
Business Rules
Decision tables
Decision Trees
Use Cases
Scenarios, Stories
Activity Diagrams
DFD
Project
Vision
Why?
Business
polices
How?
Process Map
Why the project is
being undertaken
What users will be able to do
with the product
Design & Development
High-Level &Details
Software Requirements
Scope
What developers
need to build

35. 2.4 요구사항 분석
2.4.3 Use Case 체계 수립
 이해관계자의 기능적 요구사항을 Use Case방식으로 Design을 위한 체계수립 활동
입력물
액티비티
 Use Case Model
 요구사항 정의서
협의/검토
 협의
출력물
1.
2.
Actor 체계 수립
Use Case 체계 수립
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 전체적인 시스템의 개발 범위를 결정 및 업무 진행율을 파악하는 기준.
대
중
소
-
-
-

36. 요구사항 명세

37. 3.1 개요
 합의된 요구사항을 하나 이상의 형태로 저장하여 정형화된 요구사항
을 생성하는 활동
 소프트웨어 시스템이 수행하여야 할 모든 기능과 시스템에 관련된 구
현상의 제약 조건 및 개발자와 사용자가 합의한 성능에 관한 사항 등을
명세.
합의된 요구사항
Agreed
Requirements
요구사항 명세
Requirements
Specification
정형화된 요구사항
Formal
Requirements

38. 3.2 요구사항 명세 전략
SW 개발 활동의 출발점이며, 비즈니스와 개발 활동을 연계
Communication
Baseline
•
개발자와 고객이 같은 기대와 목적을 공유
•
개발 범위 왜곡과 요구사항 폭주 방지
•
개발과 검증의 기준
•
정확성, 완전성을 가진 요구사항 정의와 변경관리/ 추적성의 보장
SW Develop Lifecycle
Market의
Needs 이해
시스템의
Behavior 산출
Requirem
ents
Business
SRS
개발자
고객
SW Product Lifecycle
•
정확성, 완전성을 가진 요구사항 정의
•
변경에 대한 관리/ 추적성의 보장

39. 3.3 요구사항 명세 절차
Analyst
Use Case 명세서
작성
Use Case Model
사용자 인터페이스
분석
Use Case Specification
요구사항 리뷰
SRS(소프트웨어 요구사항 명세서)

40. 3.4 요구사항 명세
3.4.1 Use Case 명세서 작성
 Use Case가 뜻하는 시스템의 기능을 간결하고 명확하게 기술.
입력물
액티비티
 Use Case Specification
 Use Case Model
협의/검토
 협의
출력물
1.
2.
Use Case 속성 작성
Flow of Event 작성(시나리오 작성)
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
대
중
소
-
-
-
 개요작성 시 주어는 Use Case를 사용하는 Actor로 하며 간결하게 기술, Use Case가 제공하는 모든 기능 명시.

41. 3.4 요구사항 명세
요구사항 명세 기법
사용자 중심의 요구사항 명세 : 고객 관점에서 명세한다.
사용자에게
•
최신 유행을 피한다 - 전문가의 자기중심적 특정 기법 지양
친숙한 명세
•
이해하기 쉽고 배우기 쉬운 표현 기법 사용 : Model/Picture 포함
•
긍정적인 표현 : 부정문 표현의 방지
•
능동적인 표현 : 시스템 관점에서 표현
•
충분한 정보를 제공 : 생략의 문제, 수치 범위에서 경계 값
•
모호한, 다중 의미를 가지는 용어를 피한다.
•
일관성 있는 용어 사용 및 공통의 목표에 전문성을 맞춘다.
•
Glossary 기술 : 조직, 도메인의 표준 용어 사용
읽고 이해하기
쉬운 표현
명확한 용어 사용

42. 3.4 요구사항 명세
3.4.2 사용자 인터페이스 분석
 사용자 중심의 인터페이스 식별을 통한 가이드라인 정의
입력물
액티비티
 Use Case Specification
 Use Case Model
협의/검토
 협의
출력물
1.
2.
사용자 인터페이스 식별
사용자 인터페이스 프로토타이핑
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 인터페이스 가이드라인으로써 설계 시점의 기본적 지침서 준수
대
중
소
-
-
-

43. 3.4 요구사항 명세
3.4.3 요구사항 리뷰
 요구사항의 결함 등 산출물을 검사하고 검증하는 단계
입력물
액티비티
 SRS(소프트웨어 요구사항
명세서)
 Use Case Model
협의/검토
 협의
출력물
1.
2.
3.
요구사항 정의서 리뷰
업무 용어 리뷰
요구사항 충돌 해결
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 조기 결함 발견 및 수정을 통한 개발 생산성 향상
대
중
소
-
-
-

44. 요구사항 검증

45. 4.1 개요
 요구사항명세서에 고객의 요구가 올바르게 기술되었는지 검토하고 베
이스라인으로 설정하는 활동
 검토 계획을 수립하고 이해관계자들과 협력 관계를 조성하여 다양한
시각으로 검증을 수행하고 결과를 피드백
 요구사항 검증 방법
요구사항 검토회
(Walkthrough)
요구사항 검사
(Inspection)
목적
•
•
초기서 에러발견
기술, 표준, 정보로부터 이탈을 발견
•
•
다른 조직과 관점을 공유
승인, 수정, 기각을 결정
참여자
•
프로젝트 참여자
•
절차
•
•
•
결과 개요 제공
제시된 문서 및 다른 참여자 의견 검토
발견된 에러 문서화
•
•
•
공식 검토
(Formal Review)
•
결과의 완전성과 일치성을 보장
사회자, 기록담당자, 검사자, 요구
사항 문서 작성자
•
프로젝트 리더, 프로세스 책임자,
요구사항 분석가
사회자 : 미팅 진행
기록담당자 : 모든 이슈사항 기록
검사자 : 에러발견, 논의
•
•
•
문서 상태 검토
프로젝트의 결과 검토
다음 단계 진행 인증

46. 4.2 요구사항 검증 활동
 요구사항 명세 내용 검증
명세서 내에서 사용된 용어의 일관성, 표준성 및 이해 용이성 등을 검증한
다.
 요구사항 명세 구조 검증
요구사항 명세서에 정의된 요구사항들로부터 구현되는 시스템이 사용자의
요구와 목표를 만족하는가에 대해 검증한다.
 요구사항 베이스 라인 설정
승인된 요구사항을 확정하고, 설계 및 구현 할 수 있도록 요구사항 명세
베이스라인을 설정한다. 이렇게 설정된 베이스라인은 공식적인 변경 통
제 절차에 의해서만 변경이 가능하다.

47. 4.3 요구사항 검증 절차
Analyst
요구사항 검증 팀
구성
정제된 요구사항
검증
요구사항 문서 검증
요구사항 검토 보고서
요구사항 관리
프로세스 검증

48. 4.4 요구사항 검증
4.4.1 요구사항 검증 팀 구성
 요구사항 문서 오류 및 고객요구사항이 반영되었는지를 평가하기 위한 검증 팀 구성
입력물
액티비티
출력물
-
-
협의/검토
수행자
1.
 협의
요구사항 검증 팀 구성
 시스템 전문가
프로젝트 규모
승인
 승인
 이해관계자 검증 팀 구성
대
중
소
-
-
-

49. 4.4 요구사항 검증
4.4.2 정제된 요구사항 검증
 요구사항을 보다 명확히 이해하고 , 비즈니스 목표, 이해관계자의 요구사항, 시스템 구성, 제약 사항 등에 대한 요
구사항에 대한 검증 단계.
입력물
액티비티
출력물
 요구사항 검토 보고서
-
협의/검토
 협의
1.
2.
3.
요구사항 적합성 평가
요구사항 타입간 추적성 검토
요구사항 타당성 검토
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 요구사항 적합성,타당성,추적성 등 검토
대
중
소
-
-
-

50. 4.4 요구사항 검증
4.4.3 요구사항 문서 검증
 요구사항 분석을 통한 요구사항 명세서 등 관련 산출물에 대한 검증 단계.
입력물
액티비티
출력물
 요구사항 검토 보고서
-
협의/검토
 협의
1.
2.
3.
4.
5.
업무용어사전 검토
초기 요구사항 명세서 검토
Use Case 모델 검토
비 기능 요구사항 문서 검토
기능 요구사항 문서 검토
수행자
 시스템 전문가
프로젝트 규모
승인
 승인
 요구사항 추출/분석단계의 해당 산츨물 검증
대
중
소
-
-
-

51. 4.4 요구사항 검증
4.4.4 요구사항 관리프로세스 검증
 요구사항 추출-분석-명세-검증프로세스를 통한 관리 프로세스 적합하도록 검증하는 단계
입력물
액티비티
출력물
 요구사항 검토 보고서
-
협의/검토
수행자
1.
요구사항 관리 프로세스 검증
 협의
 시스템 전문가
프로젝트 규모
승인
 승인
 요구사항 관리계획 수립에 따른 변경/추적/형상관리
대
중
소
-
-
-