Lost practice : Requirement analysis

Facebook @권용훈 2015.02.21

Agile Manifesto 공정과 도구 보다 개인과 상호작용..

공정과 도구도 가치있다.

.

User story

도메인 A

도메인 B

도메인 C

요구사항을 정의했다. 사용자-개발자간 소통은 늘 충분했다. 개발자간 소통은?

대규모, 복잡하게 얽힌 시스템의 경우 스토리 사이의 관계를 이해하기 어렵고, 구조화하기 힘들다.

User Story Applied, Chapter 3. <Mike. Cohn>

Story Mapping이 대두되는 이유

기능간 연계는 블랙박스?

수집은 문제가 아냐 기능 분류, 통합, 연계, 이관.. 어떻게 하지?

• 개인이 이해하고 구현을 담당하는 도메인은 극히 일부. • 전문화 도메인 영역일 경우 어떻게 처리해야 하는 지 모름. 롤 바깥 부분.

• 이 요구사항은 어떤 기능을 어떻게 사용해야 하는 걸까? • 어떻게 할당해야 하는 할까, 누가 어떻게 구현해야 하는걸까?

대규모, 복잡한 협업, 전문화된 도메인에서 골치아프게 하는 건 기술이 아니다. 도메인이 가장 중요하고 복잡한 문제

Domain-Driven Design, <Eric Evans>

사용자 요구사항

사용자요구사항 그대로 구현 각자 구현한 내용을 모아놓고 보니..?!!

대규모/복잡한 협업시스템? 정리도구 필요..

비즈니스 컨설팅 결과 획득

업무 분류

담길 내용

담길 내용

업무 분류

담길 내용

담길 내용

업무 분류

담길 내용

담길 내용

고객사 현업이 요구사항 정의

고객요구사항

고객요구사항

고객요구사항

고객요구사항

미정의된 내용

미정의된 내용

사용자 요구사항 목록의 한계점 • 비즈니스 관점으로 표현 • 요구사항 구현에 필요한 기능을 정확히 알 수 없음 • 시스템 구현범위를 명확히 알 수 없음 • 요구사항간 연계관계 정의가 어려움 • 공통도출이 어려움 • 요구사항 구현에 드는 비용을 명확히 알 수 없음. • 어플리케이션 아키텍처 도출, 원칙정의가 어려움

“사용자 요구사항 취합”이상의 활동 필요

• 고객요건을 만족시키기 위한 시스템 전체기능 도출. • 기능을 분류하고 통합. • 기능간 연계 정의 및 공통도출 • 어플리케이션 아키텍처 정의. 기능간 의존성 원칙 정의 • 시스템 전체 구현 범위와 비용 확인. 위험 예측

문제와 필요한 것 구현 전에 시스템 형태와 기능에 대한 활발한 소통이 필요..

요구공학 돌아보기 과거 기법중에 쓸만한 게 있지 않을까?

.

.

“요구사항 분석” 수집 이후가 중요.

어플리케이션 아키텍처 정의 기능의 분할과 통합, 의존성 정의

분석중 갑자기 툭 튀어나온다는..

시스템 전체 기능 가시화

취합, 통합, 중복 Conflict 해결, 재정의, 우선순위, 의존성

최근의 “User Story Mapping”에 해당하는 내용 기능을 도출 > 분할과 통합, 의존성 정의하며 아키텍처 아웃라인 정의 > 시스템 전체기능 가시화

SWEBOK V3

기능 도출 기능도출, 취합, 분류, 할당, 연계정의, 구조화

• 고객의 To-be 이미지 취합

• 시스템 구현에 필요한 기능 도출 : 범위확정, 문제영역 확인

Architecture 아웃라인 정의 기능, 업무전략, 아키텍처 원칙 참고

패키지

패키지

• 시스템, 개발자간 협업/소통에 아웃라인 제공 - 내가 처리해야 하는 요구사항, 프로세스, 로직, 데이터 - 기능의 올바른 위치 - 기능 이관, R&R 의사결정 가이드 라인 • 요구사항 시뮬레이션 - 요구사항 구현에 필요한 요소 누락여부 확인 - 기술요소 확인 - 성능에 문제되는 지점 예측/대처

시스템 분석은 옵션 룰, 인터페이스, 배치, 개념컴포넌트

기능별 시스템 구성요소 도출

로직

로직

로직

로직

로직

패키지

패키지

패키지

패키지

엔터티 엔터티 엔터티

엔터티 엔터티

엔터티 엔터티

엔터티

엔터티 엔터티

요구사항부터 구현기능까지 연계 검증 프로세스(,value chain) – 요구사항 – UI초안 – UI가 호출하는 기능

프로세스

프로세스

프로세스

고객요구사항

고객요구사항

고객요구사항

고객요구사항

미정의된 내용

미정의된 내용

UI 초안

UI 초안

UI 초안

UI 초안

UI 초안

구현될 기능

구현될 기능

구현될 기능

구현될 기능

구현될 기능

패키지

패키지

패키지

패키지

DB 논리 엔터티

DB 논리 엔터티

DB 논리 엔터티

DB 논리 엔터티

DB 논리 엔터티

Requirement Analysis 협업이 필요한 대규모/복잡한 시스템 구축할 때 시도해보자

내부처리 90% 외부처리 10%

A처리 B처리

C 처리

B 처리시 필요

A컴포넌트 테이블1,2

B컴포넌트 테이블 3,4,5

C컴포넌트 테이블 6,7

8번타입 EAI

메인화면1 리포트2

고객님의 요구사항은 늘 심플..

내가 담당하는 부분

연계요청, B과장님 무서운데;;

EAI담당자 한테 무슨 패턴써야하는지 물어보자

부록. 개발자 머릿속 요구사항을 들었을 때 생각흐름 샘플.