Requirement Engineering
고객이 원하는 서비스를 만들기 위해 필요한것.
설명서
요구의 필수 속성
- 해석/이해가 되어야 한다
- 자세하고 구체적인 설명이 되어야 한다.
요구사항 종류
1. User Requirement
- 사용자들이 사용하기 위한 작동 제약
2. System requirement
- 구체화된 설명
3. Funtional requirement
- 해야되는것의 요구사항
4. Non-Functional requirements
- 언제/몇명에게 제공할지 정하기
5. Domain requirements
System stakeholder
- 최종 사용자
- 시스템 관리자
- 시스템 소유자
- 등등
Requirement
Functional Requirement
- 시스템이 반드시 제공해야 하는 서비스
- 제공하는 기능 요약
애매한 요구사항
- 기능이 자세하게 적혀있지 않으면 모호함으로 인해 문제가 생긴다.
추가 요구사항
- 요구사항은 완벽하고 일관적이야 한다.
- 완벽함
- 필요한것을 모두 작성해둔다.
- 일관성
- 설명에 충돌과 모순이 없어야 한다.
Non-Functional Requirement
- 시스템이 제공하는 서비스 혹은 기능의 제약사항
요구 되는것
- 신뢰성, 응답속도, 시간-공간 복잡도
- IDE / 언어 / 개발툴의 사용제한
- Non-Functional한 부분을 만족하지 않을시 프로그램 자체를 사용하지 못할수도 있다.
- 요구사항에 전체적으로 영향을 주거나 받는다.
- 명확하게 정의하는것은 어렵다.
Non-Functional 분류
- 제품 요구사항
- 배포되는 제품이 가져야 하는것
- 속도 / 신뢰성 / 등
- 조직 요구사항
- 프로세스 표준, 구현 요구사항
- 외부 요구사항
- 상호운용성
Domain Requirement
- 소프트웨어가 사용되는 환경에 따라 다른 요구사항
요구사항 엔지니어링 과정
Requirement Elicitation - 요구사항 추출
- 숨어있던 요구사항의 발견
- 시스템이 제공해야 하는것과 작동상 제한을 찾아야 함
- 요구당사자는 자신이 원하는것을 모르고, 충돌되는 요구를 할수 있다.
- 조직 / 법규의 영향을 받을수 있다.
- 분석 도중 요구사항이 변동될수 있다.
과정
- 발견
- 이해관계자와 요구사항을 찾고 특수적인 요구사항도 찾는다. (Domain Requirement)
- 분류
- 관련된 요구사항을 모은다.
- 우선순위 설정 / 협상
- 요구사항을 우선순위화 하고, 충돌을 해결한다.
- 상세히 기술하기
- 요구사항을 문서화 하여 다음 장으로 넘어간다.
인터뷰
Closed Interview
- 미리 정해진 질문만을 한다.
Open Interview
- 자유롭게 이야기하며 정한다.
- 기능을 살리되, 중요한 부분만 요약하는것이 중요하다.
Story
- 실제 삶에서의 예시
Scenario
- Story의 형식을 갖춘 모습
Requirement Specification - 요구사항 작성
- End user / Customer 모두가 이해 가능하게 작성한다.
- 다른 해석의 여지가 있어선 안된다.
- 상세하게 작성 할 수록 좋다.
Design
- 요구사항의 동작을 설명한다.
- 시스템의 구조 / 다른 시스템과의 연동 / 특정 상황에서 요구사항 이 들어간다.
- 컴퓨터 용어의 사용을 줄이고, 필요성에 대해 설명한다.
Natural Language
- 자연어
- 내용이 명확하지 않다
- Functional 인지 Non-Functional 인지 명확하지 않다.
- 여러 요구사항이 합쳐 표현될수 있다.
- 표/그래프 포함
Structured Natural Languate
- 특정 형식을 갖춘 자연어
- 표준만 갖추면 내용은 자유
- 임베디드 개발에 유리하다.
Degidn Description Lanugage
- Use Case Diagram
Graphical Notation
- Wireframe
- 표현력 있고 친숙하고 널리 사용된다.
Mathematical Specification
- DFA와 같은 수식적 표현
Form-Based Specification
- 기능 / 엔티티 정의
- 입력과 소스
- 출력할 곳
- 정보 처리
- 동작 설명
- 사전 / 사후 설명
- 기능의 역효과
Requirement validation
- Requirement가
- 실제 고객의 요구와 일치하는지
- 실현 가능하지
- 판단한다.
방법
- Requirement review : 글로 읽어보기
- 누구든 빨리 처리할수 있다.
- Prototyping : 프로토타입 제작
- Test-case generatrion : 테스트 가능성 확인을 위해 테스트 생성
확인 해야 하는 것
- 테스트 가능 여부
- 완전하고 모호하지 않은지
- 하나의 기능을 다른 큰 변화 없이 수정 가능한지
- 이에 대해 추적 가능한지.
요구사항 변경
EX. 새로운 하드웨어의 개발
EX. 다양한 사용자 커뮤니티의 각각 요구사항과 이들의 충돌 및 모순
요구사항 관리
- 개별 요구사항을 기록하고, 요구사항간 의존성을 관리해 요구사항 변화에 적응한다.
요점
- 요구사항 확인
- 변경점 관리
- 기록 추적 및 관리
- 도구 사용하기
만능 컴덕후 겸 번지 팬