일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 메카님
- 운영체제
- ret2libc
- Rr
- Security
- dtft
- DSP
- Unity #Indie Game
- pdlc
- MLFQ
- CTF
- 게임개발
- 배경 그림
- sampling theory
- AINCAA
- linear difference equation
- dirty cow
- Race condition
- STCF
- 언리얼엔진
- stride
- 유스케이스
- RBAC
- 유니티
- frequency-domain spectrum analysis
- TSet
- DP
- MAC
- Double free
- 게임 개발
- Today
- Total
다양한 기록
Requirement Engneering 본문
다양한 Task와 방법들을 통하여 고객의 요구사항들을 이해
요구사항 엔지니어링은 설계와 구축을 이어주는 기반
Requirement Engineering Tasks
- Elicitation (추출)
- Elaboration (정제)
- Negotiation (조정)
- Specification (정의)
- Validation (검증)
- Requirement management (관리) : 변화 관리
1. Elicitation (추출)
모든 stakeholder로부터 요구사항을 도출
- 문제들
* 범위(Domain)의 문제
>> 불명확하거나 불필요한 기술적 세부 사항들
* 이해의 문제
>> 컴퓨팅 환경의 제약 조건과 성능에 대한 미진한 이해, 문제 영역 전반에 걸친 이해 부족, 명확한 것으로 판단되는 정보 생략에 따른 이해 부족, 고객들의 니즈에 대한 이해 부족, 다의적이거나 테스트가 불가능한 요구사항들의 이해 부족
* 변경의 문제
>> 요구사항은 지속적으로 바뀜
2. Elaboration (정제 또는 분석)
- Elicitation을 통해 획득한 정보를 확장하고 정제
- 정제된 요구사항 모델의 개발에 초점을 맞춘 태스크
- 데이터, 기능, 그리고 동적인 요구사항들을 식별하는 분석 모델 생성
- 사용법 시나리오의 창조와 정제에 의하여 태스크가 진행
3. Negotiation (조정)
- stakeholders 간 논쟁 조정
- 요구사항들의 우선순위를 설정, 요구사항들의 비용과 리스크를 평가, 내부적 갈등 추적, 요구사항들의 삭제/결합 또는 수정의 반복적인 접근법 사용
- 개발자들과 고객들에게 실제 수행 가능한 동의를 이끌어냄
4. Specification (정의, 명세서 작성)
- 그래픽 모델들, 일반적인 수학적 모델, 사용법 시나리오, 프로토 타입 등의 명세를 작성
5. Validation (검증)
- 요구사항 엔지니어링의 결과가 올바른 품질을 가지고 있는지를 평가
6. Requirement Management (변경 관리)
- 프로젝트 팀의 식별 및 조종이 가능하고, 프로젝트가 진행되는 동안에 언제나 요구사항들을 변경하고 추적할 수 있도록 도와줌
* Validation
- 각 요구 사항은 시스템/프로덕트를 위한 전체적인 오브젝트와 일치하는가?
- 모든 요구사항들은 적절한 추상화 단계에서 명세화 되어지는가?
- 요구사항이 정말로 필요하며 시스템 오브젝트에 본질적이지 않은 추가 기능을 표현하진 않았는가?
- 각 요구사항은 적정 범위 내에 있으며 명백한가?
- 각 요구사항은 속성을 가지고 있는가?
- 서로 상충하는 요구사항은 무엇인가?
- 각 요구사항은 시스템 또는 프로덕트를 저장할 기술적 환경 내에서 달성되어질 수 있는가?
- 각 요구사항은 한 번의 구현으로 테스트 가능한가?
* V&V (Verification & Validation)
Verification: 코드를 가지고 검증, 정확하게 작동하는가? (correct)
Validation : 코드 없이 검증, 유효한가?
Stakeholders
- 개발되는 시스템으로부터 직, 간접적으로 이득을 보는 모든 사람들
- 스테이크홀더는 시스템을 보는 관점과 시스템의 성곡적인 개발을 통해 얻는 이익도 다름, 또한 개발이 실패하였을 경우 역시 각각 다른 리스크에 직면함
요구사항 정의 방법
- User story
- Use Case Diagram, Class Diagram 등 UML
- Formal Language 또는 Petri net .. Formal Methods에서 사용
- Text, Graph(diagrams), 수학적 기호, 테이블 등을 사용
Requriement Modeling Types
- Flow-oriented models (Data flow diagrams)
- Scenario-based models (Use case daiagrams)
- Class-oriented models (Class diagrams)
- Behavioral models (UML의 몇몇 다이어그램들)
- Data models (ER diagrams)
요구사항 분석 방법들
기능적 요구사항
- Structured Techniques .. flow-oriented model을 주로 사용
- Object-Oriented Techniques .. Use case, Class 등 UML 사용
Data 요구사항
- ERD
사용자 인터페이스 요구사항
- GUI tool
* flow-oriented modeling
- Dijkstra에 의해 정형화
- 구조적 개발 방법에서 주로 사용
- goto 분기 대신 3개의 논리적인 구조: 연속(sequence) 구조, 선택(selection or if-then-else)구조, 반복(Repetition) 구조
* Behavior Modeling
- 시간의 흐름에 따른 변화
- UML의 시퀀스, 액티비티 등의 다이어그램
* Data Modeling
- 자료 구조 및 데이터베이스 분석 및 설계에 사용
- ERD
* 비기능적 요구사항
- 시스템이 실행되는 환경에서 지켜야 할 제약들
- 실행 속도, 실패율, 메모리 성능, 개발 언어 등등
=> 기능적 요구사항은 오류가 있으면 수정이 쉬울 수 있으나 비기능적 요구사항을 만족하지 못하면 수정이 더 어려울 수 있음
'소프트웨어공학' 카테고리의 다른 글
구현과 재사용 (Implementation & Reuse) (0) | 2024.12.13 |
---|---|
Software Design (0) | 2024.12.13 |
CMM, CMMI (0) | 2024.12.13 |
Extreme Programming (XP) (0) | 2024.12.12 |
User story (0) | 2024.12.02 |