Inception 단계에서는 뭘 할까?
Inception 단계에서는 아래의 issues들을 고려해야한다.
- 이 프로젝트의 비전과 비즈니스 사례가 무엇인가?
- 실현 가능한가?
- Buy or Build?
- 대략적인 비용 추정
- 계속해야 할까 멈춰야할가?
vision을 정의하고 order-of-magnitude 추정치를 얻으려면 몇가지 요구사항 탐색이 필요한데 Inception 단계의 목적은 요구사항을 정의하는 것이 아니다.
Inception을 한마디로 정리하면 제품범위, 비전, 비즈니스 case를 구상한다. Inception의 main problem은 stakeholder들이 프로젝트 비전에 대해 기본적으로 합의하고 있으며 중요한 investigation에 투자할 가치가 있는지 이다. stakeholder와 개발자가 맞춰가는 단계라고 생각하면좋다.
Inception 단계의 의도는 프로젝트 목표에 대한 초기 공통 비전을 수립하고 실현 가능한지 판단한다. 진지하게 투자할 가치가 있는지를 결정하는 단계이다.
Inception의 Artifacts
Inception의 Artifacts는 소프트웨어 개발 과정에서 생산되는 다양한 유형의 결과물 들이다. 예를 들어 Use case, Class diagrams, UML models, 요구사항, design document이다. 일부 Artifact 들은 software의 기능, 아키텍처 및 디자인을 설명하는데 도움이 된다. 나머지 Artifact들은 프로젝트 계획, 비즈니스 사례, 과제 평가 등 개발 프로세스 자체와 관련이 있는 결과물들이다.
Requirements
Inception에서 집중해야할 것은 기능적 요구사항과 비기능적 요구사항을 설정하는 것과 UI구현, 실제 구현 가능한지를 결정하는 것이다. 또한 요구사항은 시스템, 더 광범위하게는 프로젝트가 갖춰야하는 기능과 조건이다. 요구사항의 주요과제는 문제 찾기, 소통하기, 소통한 내용 기억하이다. 이것들은 client와 개발팀 구성원에게 명확하게 전달되는 형식으로 실제로 필요한 것들이다. Requirements의 enginerring 디자인 프로세스는 요구사항을 정의, 문서화 및 유지하는 프로세스이고 이는 System enginerring과 Software enginerring에서 공통된 역할을 한다.
-
Requirements enginerring
-
비즈니스 내용 안에서 Requirements의 범위
기능적 요구사항과 비기능적 요구사항
Requirements는 기능적 요구사항과 비기능적 요구사항으로 나눌 수 있는데, 각각을 한번 살펴보도록하자.
기능적 요구사항
- 시스템이 제공해야하는 서비스에 대한 설명.
- 시스템이 특정 입력에 어떻게 반응해야 하는지 어떻게 동작해야 하는지를 나타냄.
- Use case model에서 탐색하고 기록한다.
비기능적 요구사항
- 시스템이 제공하는 서비스 또는 기능에 대한 제약.
- 시스템 전체에 적용되는 Quality 요구사항 (품질에 대한 요구사항).
- 품질 요구사항은 시스템 arcitecture에 큰 영향을 줌.
여기서 비기능적 요구사항은 기능적 요구사항이 아닌 모든것이 될 수 있으며, 비기능적 요구사항이 기능적 요구사항이 되기도 한다. 비기능적 요구사항은 신뢰도, 반응속도, 저장 용량과 같은 시스템 속성 및 제약 조건을 정의하고 다른 측면에서 기능적 요구사항보다 더 중요한 요구사항으로 시스템의 전체 설계에 영향을 미칠 수 있다.
요구사항의 Artifact는 아래와 같다 :
- Use-case Model
- supplementary specification
- clossary
- vision
- Business Rule
