[시스템설계] 요구분석 이란?

3장 요구분석

개발생명주기

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

분석

어떤 것을 이해할 목적으로 쪼개고 나누어 구성 요소의 특징이나 기능, 관계를 파악하는 것

새로운 시스템에 대한 일반적인 요구를 분해하여 더 구체화하며 새로운 시스템이 무엇을 하여야 하는지 찾아내는 것

요구정의

현재 시스템을 파악 및 기술하고 새로운 시스템을 위한 요구(입출력,처리,성능,보안)등을 파악하기 위하여 조사하는 작업

중요성 : 요구를 결정하는 단계에서는 아직 이루어진 작업이 적어 시스템을 쉽게 변경할 수 있다

기능적모델링

정보 시스템의 기능을 사용자와 환경이라는 관점에서 작성

사용사례 단위로 파악하여 나타내고,

시스템의 비즈니스 프로세스를 액티비티 단위로 나태내는 과정 (사용사례 & 액티비티 다이어그램)

정적모델링

지원할 자료와 이를 이용하는 오퍼레이션 묶음(클래스)의 구조에 대하여 표현

분석단계에서 자세한 저장 방법, 생성 방법, 조작보다

논리적인 데이터(데이터 흐름) 오퍼레이션(함수) 구성에 초점 (클래스 다이어그램)

동적모델링

비즈니스 프로세스를 지원하는 시스템 내부의 동적인 측면

어떤 기능 수행 중 내부 요소들이 어떤 동작과 어떤 상호작용을 하는지 표시

모델링

어떤 실체를 축약하여 표현하는 작업

ex) 도로나 경사도 등 필요한 것만 축약하여 표현한 지도

아직 개발하지 않아 시스템의 실체는 없지만 여러 가지 관점에서 파악한 도면(다이어그램들)

워크스루 (Walk-through)

분석단계는 시스템에 대한 자세한 제안을 사용자, 관리자, 그 밖의 관리자가 참석한 회의에서 발표함으로써 끝난다.

3.2 요구 정의

요구란?

시스템이 무엇을 하여야 하는지 또는 어떤 특성을 가져야 하는지를 기술한 문장.

비즈니스 관점에서 시스템이 무엇을 하느냐에 초점 (사용자 니즈 {needs})

설계 단계의 요구는 개발자 관점 작성(시스템요구)

어떤 성능이 새로운 시스템에 구현될 것인지 기술적인 방법으로 발전

요구 분석 문서

• 기능적 요구ex) 시스템이 상품 재고를 탐색할 수 있다(처리중심 요구)기능적 요구는 분석 단계로 바로 넘어가 정확히 정의
• 시스템이 지출 예산과 실제 지출을 포함해야 한다 (정보 중심의 기능적 요구)
• 시스템이 수행해야 할 처리나 가져야 할 정보와 밀접하게 관련
• 비기능적 요구시스템에 대한 운용, 성능, 보안, 문화 또는 정책적 다양한 측면의 특성이다
• 시스템이 작동되면서 가져야 할 특성 ex) 성능이나 사용 용이성

요구정의

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

개조식으로 작성하되 숫자를 매겨 각 요구 하나하나 구별되어야함

우선 능적 요구와 비기능적 요구로 나누며 그 이후 요구의 타입이나 기능으로 그루핑하여 기술

비즈니스 요구는 우선순위가 있음.

중요도에 따라 ‘상’ ‘중’ ‘하’ 이런식으로 나눌수 있고, 요구 사항을 한꺼번에 만들어 넘기는 RAD (Rapid Application Development) 사용시 중요

가장 중요한 목적 시스템의 범위를 정하는 것

요구 결정

요구를 정의하기 위하여 먼저 비즈니스나 IT 측면에서 요구 자체를 결정해야함.

IT 프로젝트의 실패 원인 중 사용자 참여의 결핍이 흔한 이유

ex) 개인 주택이나 아파트에 살아 온 사람들 대부분 건물 안에 무엇이 있어야 하는지 알고 있지만,

건축에 문외한인 사람에게 당장 아무것도 없이 설계를 하라고 한다면 설계 길수과 엔지니어링 기술이 없어 꽤 어렵고 도전적인 작업이 될것이다.

비즈니스 프로세스 분석기법

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

요구 정의 작성

분석가가 요구취합 기술을 사용하여 정보를 모으고 , 시스템의 적절한 요구를 찾아내기 위하여 분석하고, 이러한 요구들을 요구 정의 보고서에 추가하는 작업을 계속한다

프로젝트 팀은 먼저 시스템에 대한 기능적 요구, 비기능적 요구인지 결정 필요

그 다음 정보를 모으기 위하여 요구 취합 기법을 사용하여 취합

마지막 요구리스트 수정

중요한점은 요구 정의를 진화시켜 나가는 것은 신중히 관리해야된다.

요구 리스트를 작게 유지하고 초점을 맞추는것이 프로젝트 성공의 관건

비즈니스 프로세스 분석

비즈니스 프로세스 자동화

어떤 업무를 컴퓨터로 자동화 할떄 BPA 사용

조직의 효율을 높일 수 있지만 비즈니스를 위한 가치 창조나 영향은 적다.

• 문제 분석
• 현재 시스템의 문제점을 물어 새 시스템에서 어떻게 이를 해결할 수 있는지 찾아내는 것
• 근본 원인 분석문제의 현상만 해결하게 된다면 다시 문제가 발생하고 원인을 찾기 더 힘들어짐가능성 : 저품질 재료 ,잘못된처리, 배달과정 중 파손비즈니스 프로세스 개선효율과 효과를 높일 수 있다.(개선 방법을 찾아내거나 새로운 시스템의 요구에 도움이 되기 위한 정도)
• ex) 프로세스에 비효율적이고 중복되는 부분이 없는지 각 작업 기간과 비용은 적당한지 따져보고 개선책을 찾음
• BPA 보다 현재 시스템에 대한 시간을 적게 할애하고 비즈니스 포로세스를 향상하는데 집중
• 기술이 제공하는 새로운 기회를 이용하거나 경쟁사를 따라 하기 위하여 조직을 운영하는 방법을 적당히 바꾸는 것
• 따라서 근본 원인 분석은 해결책 보다 문제의 원인에 집중
• ex> 인터넷 쇼핑몰 회사에서 고객에게 품질이 낮은 상품이 배달되었다
• 문제의 근본 원(root cause)를 파악하고 해결해야함.
• 기간분석처음에는 비즈니스 프로세스의 총 시간 계산후 작은 단위의 작업 각각에 소요되는 시간 측정
• 이 두값이 10 배이상 차이나면 문제있음
• 현재 시스템에 있는 각 프로세스를 수행하는데 걸리는 시간을 조사
• 작업 비용 분석인건비와 재료비 조사시간당 비용을 곱하여 계산한다. 하지만 여기에 간접 비용( 임대료, 감가상각) 등을 작업비용에 포함
• 재료비는 생산 프로세스에 쉽게 할당되나 인건비는 소요 시간을 기초로
• 주요 프로세스의 비용 조사

비즈니스 프로세스 리엔지니어링

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

현재의 비즈니스 방법을 없에고 새로운 아이디어와 기술을 이용하여 크게 바꾸는 것

• 성과 분석ex ) 보험회사에서 고객이 자동차 사고를 당했다고 하자.전통적으로 보험회사는 고객이 보험금을 빨리 타는 것으로 생각 하지만따라서 수리 대금 지급 뿐만 아니라 공인된 카센터를 소개하는 것 까지 넓힐수 있음
• 고객의 입장에서는 보험금은 수단이며, 궁극적인 성과는 자동차를 수리하는 것
• 고객 입장에서의 근본적이 성과는 무엇인가?
• 고객에게 가치를 제공하는 근본 결과가 무엇인지 이해하는 데 초점을 맞춘다
• 기술 분석그 이후 각 기술을 비즈니스 프로세스에 어떻게 적용할 수 있고 비즈니스는 어떻게 이득을 보는지 파악
• ex) 인터넷을 통한 부품 주문 자동화
• 중요하고 관심 있는 기술의 리스트를 만드는 것으로 시작하고
• 작업제거

• 분석가와 관리자가 협력하여 비즈니스 프로세스에서 작업을 삭제할 수 있는지 판단하는 것

요구취합 방법

인터뷰

인터뷰 대상자 선정 → 인터뷰 질문 작성 → 인터뷰 준비 → 인터뷰 실시 → 후속 조치

• 대상자 선정따라서 고위 하위 골고루 필요
• 조직에 있는 다양한 계층의 사람들은 시스템에 대하여 서로 다른 시각을 갖음
• 인터뷰 질문 작성
  • 폐쇄형 ( 하루에 받는 전화 주문은 몇 개인가요?) → 단답식 답변유도
  • 자유 대답형 (현재 주문을 처리하고 있는 방식에 대하여 어떻게 생각하십니까? )
  • 유도형 (예를 들어 줄수 있나요?, 더 자세히 말씀해 주시겠어요?)
• 인터뷰 준비

JAD 회의

Joint Application Development(JAD)

프로젝트 팀, 사용자, 관리자 등이 협력하여 시스템의 요구를 찾도록 도와주는 정보 취합 기술

10~20명의 사용자를 회의 주재자의 지시에 따라 만나게 하는 기법

주재자가 회의 주제를 준비하고 토의의 방향을 잡아 주지만, 주제에 대한 자신의 생각이나 의견을 말하지 않는다.

JAD회의는 일상 업무에 방해 받지 않도록 사무실에서 떨어진 곳에서 실시

U자형으로 배치하여 모든 참여자들이 서로를 쉽게 볼수 있도록함.

문제점은 다른 사람의 의견에 도전하려고 하지 않아 소수의 사람이 토의를 점유하고 다른 사람들은 참여하지 않는것.

이것을 해결하기 위해 e-JAD 라는 무기명 아이디어와 의견을 보내는 방식이 있음

 

 

• 참여자 선정

조직의 여러 계층에서 나와야 하며 새 시스템을 위한 지지층이 될 사람을 선정

참여자는 회의가 개최될 때 업무를 하지 못하므로 백업 역할 필요

주재자는 JAD에 고수여야 하며 논의할 비즈니스에 경험이 있는 사람이 적합

• 회의 설계가
• 오래걸림 why? 정보를 수집하는 차원을 넘어 분석 결과를 생성하는 작업으로 옮겨가기 떄문
• 회의 준비
• 참여자 준비 필요. 인터뷰의 수준을 넘어서며 참여자들은 어떻게 준비하는가에 더 많이 관심
• 회의 실시참여자들이 시스템 개발 과정에 사용하는 기술적 용어나 특수 용어를 이해하도록 도와 참여자들이 사용되는 분석 기술을 잘 이해할 수 있게 하여야 한다.
• 다른 사람의 의견을 존중하며 반대를 수용하고 한사람 씩 발언하는 것이 회의의 기본 규칙
• 후속 조치

설문

응답자 선정 → 설문지 설계 → 설문 집행 → 후속조치

서류 검토

관찰

작업 과정을 지켜보는 것으로 현재 시스템에 관한 정보를 수집하기 위한 좋은 방법

단점 : 관찰을 한다는 것을 알고 있으면 행동이나 작업에 매우 조심스러워지기 떄문에

거짓일 수 있음

요구 추출 방법 선택

 

• 정보의 타입 - 현재(as-is) 시스템을 이해하는 단계, 개선점을 파악하는 단계, 미래(to-be) 시스템을 개발하는 단계 중 적합한 단계가 있다.
• 정보의 깊이 - 요구 취합 방법이나 제공하는 정보가 얼마나 알차고 자세한지를 나태낸 것
• 정보의 너비 - 적용한 기법으로 모은 정보와 정보 출처의 범위
• 정보의 통합 - 요구 취합 작업에서 가장 어려운 측면 (여러 출처에서 나온 정보를 통합)
• 사용자 참여 : 새 시스템의 미래 사용자가 분석 과정에 투자하여야 하는 시간과 에너지
• 비용 - 그냥 비용

요구 문서화

프로젝트 성공하려면 요구를 잘 정리해야함

너무 간단히 기술하면 문제를 적절히 해결하지 못하는 시스템을 만들 수 있고,

반대로 너무 자세히 기술하면 시간이 낭비되고 시스템에 융통성 x

요구 문서 작성

요구 분석서에서는 먼저 제기된 문제와 시스템에 대한 개요를 기술

비기능적 요구는 시스템의 품질에 관한 요구와 프로젝트를 진행하는 과정에 대한 일정, 인력 ,자원에 대한 제약 사항을 기술한다.

모든 문서에는 제목과 버전 번호, 수정 이력을 잘 표시하여야한다.

요구 분석서 검토

• 개발 비용의 투자 효과 - 비용 대 수익을 분석해 보는 작업
• 현재 당면한 문제의 해결 - 많은 아이디어 좋지만, 우선순위가 낮은것은 과감히 삭제
• 80:20 법칙 : 사용자가 안고 있는 문제의 80%는 작업의 20%가 해결할 수 있다. (파레토 법칙)
• 명백하고 통일된 표현 - 사용자가 이해할 수 있고 다른 요구와도 통일성 있게 표시
• 모호한 점이 없게 - ex) 항공기를 선택하면 시스템은 항공편에 배정한다
• 항공기가 기종(보잉 777)을 의미하는 것인지 특정 항공기를 의미 하는 것인지 모호
• 일관성 - 작성한 요구 문서가 표준 규격에 잘 맞는지, 다른 요구들과의 일관성이 있는지,
• 상위 시스템이나 서브시스템의 요구와 잘 부합하는지 체크
• 품질 좋은 시스템을 유도 - 요구 사항들은 시스템의 사용성 안정성 , 효율성, 신뢰성, 유지 보수성을 높일 수 있어야한다.
• 실현 가능성 - 요구 사항들은 정해진 예산과 기간 내에 원하는 플랫폼에 개발팀이 구현할 수 있는 전문성과 기술을 갖고 있어야한다.
• 검증 가능성 - 시스템 설계의 기초가 될 뿐 아니라 테스트의 근거가 된다. 따라서 시스템 구현이 요구 사항에 맞게 되었는지 명확하게 결론을 내릴 수 있는 방법이 있어야 한다.
• 식별할 이름 - 개별적인 요구 사항을 부를 수 있는 이름이 있는 것이 중요하다. 요구 검토 회의에서 참여자들이 어떤 요구 사항을 토의하는지 나타낼 때 필요하다.