요구 분석 - 비즈니스 프로세스 분석 방법, 요구 취합 방법

요구 분석 과정

소프트웨어 개발 생명주기(SDLC)

현재(as-is) 시스템에서 새로운(to-be) 시스템으로 옮겨가는 과정

 

모델링

실제를 축약하여 표현하는 작업

• 기능적 모델 - 사용자와 환경 ~ 외부 (유스케이스, 액티비티 다이어그램)
• 정적(구조적) 모델 - 클래스 구조 (클래스 다이어그램)
• 동적 모델 - 시스템 동작, 내부요소의 상호작용 (인터랙션, 상태 다이어그램)

---

요구

시스템이 무엇을 하여야 하는지, 어떤 특성을 가져야 하는지 기술

=> 사용자의 니즈에 초점

 

분석단계에 필요한 정보 제공, 최종 시스템 범위 정함

사용자 기대 확립

 

• 기능적 요구 : 시스템이 수행해야 할 처리나 보관하여야 할 정보
• 비기능적 요구 : 시스템이 작동되면서 가져야할 특성, 제약사항

요구 정의

기능적 요구와 비기능적 요구를 개조식으로 나열한 보고서

 

기능, 비기능 종류 결정 -> 요구 취합 -> 요구 리스트 정의

분석단계 끝까지 요구정의를 계속 발전

요구리스트 작게 유지 

요구 정의 끝없이 추가 불가

 

요구 결정

비즈니스, IT 측면에서 요구 자체 결정

사용자와 엔지니어가 정보를 나누고 이해

 

> 비즈니스 프로세스 분석 기법 사용

시스템에 담길 변화의 정도에 따라 나눔

• 비즈니스 프로세스 자동화(BPA) - 범위가 한정된 비즈니스 프로세스 문제 해결위한 원인 분석 기반 기법
• 비즈니스 프로세스 개선(BPI) - 비즈니스 프로세스의 효율 개선위한 기간 분석, 작업 비용 계산, 벤치마킹 기법
• 비즈니스 프로세스 리엔지니어링(BPR) - 비즈니스 프로세스 효과 분석, 기술 분석, 작업 삭제에 의한 프로세스 재정의

---

비즈니스 프로세스 분석

1. 현 상황 이해
2. 개선할 점 파악
3. 새 시스템 정의

 

>  비즈니스 프로세스 자동화(BPA)

업무절차 변경 X, 일부 작업에 컴퓨터 기술 도입

조직의 효울 ↑, 비즈니스 자체 영향 가치 X

 

● 문제 분석

시스템의 효율과 사용용이성 개선

비즈니스 자체의 가치를 높이지는 못함 => 문제해결정도

 

● 근본 원인 분석

문제의 현상만 건드리지 말고, 발생 원인 찾아야 함

해결책 X 문제 집중

 

>  비즈니스 프로세스 개선(BPI) 

조직의 운영하는 방법을 적절히 바꾸는 것

효율(올바른 작업), 효과(올바른 결과) ↑

BPA보다 시스템 이해에 시간 적게 할애 -> 비즈니스 프로세스 집중

 

● 기간 분석

현재 시스템에 있는 각 프로세스를 수행하는데 걸리는 시간 조사

전형적인 비즈니스 프로세스에 걸리는 총시간이 이것을 이루는 작은 단위작업 각각에 소요되는 시간의 합보다 10배 이상 차이 난다면 문제가 있는 것

 

→ 유사 성격의 작업을 근본 프로세스로 만들고, 통합하여 담당

→ 작업을 동시에 할 수 있는 것은 병렬 처리

 

● 작업 비용 분석

중요한 프로세스나 작업이 소요되는 시간보다는 비용을 조사

직접 인건비와 재료비 조사

 

→  가장 비용이 많이 드는 프로세스 찾아 개선

 

● 비공식 벤치마킹

비즈니스 프로세스를 얼마나 잘 수행하는지 다른 기관과 비교 연구

 

>  비즈니스 프로세스 리엔지니어링(BPR) 

조직이 수행하는 기본 틀을 수정

= 새 아이디어, 기술 초점 / 현재 시스템 이해 X

 

● 성과 분석

고객에게 가치를 제공하는 근본 결과를 이해

 

● 기술 분석

새로운 적용 기술을 찾고 평가

 

● 작업 제거

작업 삭제로 인한 파급 효과 분석

 

분석 방법의 비교

 

---

요구 추출 방법

시스템에 영향을 줄 수 있고 영향을 받는 관련자는 요구취합 과정에 참여

참여범위 : 프로젝트 관리자, 개발자, 스텝, 고객, 공급자, 사용자

파생효과 - 사용자와 프로젝트 팀간의 신뢰감 구축

 

>  인터뷰

사용자와 심층 대화로부터 요구를 끌어내는 방법

 

● 질문 작성

다른 곳에서 찾을 수 있는 질문 피하기

대상자가 알 수 있다고 예상되는 질문만

• 폐쇄형 : 정확한 정보 파악 목적
• 자유형 : 더 많은 정보 모을 수 있음
• 유도형 : 보다 자세히 알고자 함

 

● 준비

알맞은 순서로 질문 나열, 예상 답변 적어둠

답변자가 확실히 알고 있을 질문반복 질문 X, 미리 질문내용 알려주기

 

● 수행

대상자와 친밀감 구축왜 인터뷰 하게 됐는지, 대상자로 선발되었는지핵심쟁점, 주요 이슈사실과 의견 구별

 

● 후속 조치

48시간 이내 인터뷰 보고서 작성

 

 

>  JAD 회의

프로젝트 팀, 사용자, 관리자의 협의 회의

브레인스토밍 아이디어 회의

회의 동안 시스템 모든 참여자 시스템 요구사항 정의, 의견 조정

골고루 발언권

E-JAD : 발언의 독점, 시간 절약위해 그룹웨어 활용 (무기명)

 

> 설문

개인으로부터 정보를 취하기 위한 질의서

응답자 선정 -> 질문지 설계 -> 설문 집행 -> 후속조치

• 일관된 형식
• 사실과 의견을 묻는 질문 구별
• 관심을 끌도록 유도
• 미리 응답 일부 실시해 문장에 오해가 없는지 검토

 

> 서류분석

현재 시스템을 이해하기 위해 문서를 분석

사용한 적 없는 문서 제외

변경, 개선할 필요성 찾기

 

> 관찰

작업 과정을 지켜보면서 현재 시스템에 관한 정보 수집

인터뷰, 설문 정보 보완할 목적

 

 

요구 취합 방법 비교

---

요구 문서화

사용자와 엔지니어가 같이 볼 수 있어야 함

 

> 포함될 내용

• 제목, 버전 번호, 수정 이력
• 문제와 시스템 개요
• 배경 지식과 환경
• 기능적 요구
• 비기능적 요구
• 인수 테스트를 위한 기준

> 요구 분석서 검토

• 개발 지침 가이드라인 준수
• 개발 비용의 투자효과
• 당면한 문제 해결, 우선순위 배정
• 명확하고 통일된 표현, 능동체
• 모호한 점 X
• 일관성 : 중복기술 배제
• 품질 좋은 시스템 나올지 판단(증명)
• 실현가능성, X -> 프로토타입 필요
• 검증가능한 문구
• 식별 가능한 요구사항 이름

 

 

 

 

 

 

 

 

 

 

 

---

참고 도서 : 최은만, UML로 배우는 시스템분석설계, 생능출판사, 2020년 3월 (제2판)