3. 요구 분석

• 개발 프로세스의 첫단계인 요구분석

요구 분석(Requirement Analysis)

• 소프트웨어 개발의 실질적인 첫단계

cf. 전체 프로젝트에서의 첫단계는 계획 : 프로젝트 관리에 대한 부분 즉, 일정, 비용, 리스크 계획을 하여 주로 프로젝트 관리에 해당

• 사용자의 요구(what)에 대하여 이해하고 정리하는 작업

→ 사용자가 우리에게 자기가 필요한 소프트웨어를 의뢰를 할 것인데 첨에 구현하기 전에 사용자가 원하는 것이 먼지를 찾아내야 함 →원하는 기능이 무엇일까?

Ex) 집- 몇층 원해? 각 층에 머 넣을까?

• 개발자가 가장 실수하는 부분, how가 아니라 what을 넣어야 한다!!

• 어떻게 구현할것인지, 사용자 관점이 아닌 개발자 관점으로 뽑아내게 됨.(x)

  → 관점이 사용자 관점임을 알아야 한다.

-첨에 의뢰를 할 때 우리는 오라클을 무조건 써야 한다. 언어는 자바를 써주세요 등등의 제약사항은 정할 수 있다.

• 두가지 작업을 수행 :
  • 현재의 상태를 파악하고 요구를 정의
  • 명세서 작성

• 요구의 변경은 파급효과가 크다

  요구변경은 비용이 많이 드는 편

  이 단계가 중요한 이유는 분석에서 변경이 있는데 구현까지 가버렸다면 비용이 길게 된다.

cf.RUB & Agile

-RUP는 대형 프로젝트에 적합하며 프로세스를 잘 지키자는 방법론, Agile은 사용자의 요구에 빨리 대응하자는 방법론으로 둘다 객체지향을 사용

-명세서는 어떤 방법론을 사용하더라도 작성해야 한다. 테스팅단계나 유지보수 단계까지 명세서를 가지고 있어야 한다.

-명세서에서는 관계하는 이해 당사자들이 합의본 모든 사항이 다 들어가야 한다.

-에잘은 그래서 사용자한테 붙어서 바로바로 물어보는 방법

요구 분석 과정

how보다는 what에 초점을 둔다!

1) 요구 추출

기능적 요구와 비기능적 요구가 존재하며 이 두가지 조건을 추출

2) 도메인 분석

도메인 – 내가 지금 해결하고자 하는 문제 영역

Ex) 병원시스템이라면 병원이 어떻게 돌아가는지 알아야지, 학과 시스템이면 학교가 어떻게 돌아가는지 알아야 한다

• 문제 영역 안에 있는 중요한 사항들을 인식하기 위해 정보를 수집하고 배경을 분석한다.
• 엄청나게 중요하고 개발자 입장에서 어려운 편

3) 모델링

• 도메인 분석을 통해 얻은 자료를 개념화
• 도메인 정보를 가지고 uml로 시각화, 사람들이 의사소통 할 수 있도록 그래프로 그림

4) 프로토타이핑과 시험

• 분석된 기능적 요구의 타당성 시험을 위한 프로토타입 생성
• 프로토타이핑이나 시제품을 만들어 본 후 맞는지 고객과의 테스트

5)문서화 검토

• 요구 분석서를 작성

소프트웨어 요구(SW Requirements)

• 시스템이 제공해야 할 역량(capability)
  • 기본적으로 시스템이 사용자에게 제공해야 될 역량, 능력,기능
• 시스템이 외형적으로 나타내는 기능이나 성능

ex) atm 머신 - 입금, 출금, 계좌이체 등의 기능

✅요구의 종류

1)기능적 요구(functional)

• 사용자가 이 시스템에게 기대하는 바
• 시스템이 무엇을 하는지
• 시스템과 외부 요소(컴퓨터, 사용자)와의 상호작용,인터렉션
• 시스템이 어떤 상태 일 때 외부의 데이터나 명령에 대해 어떤 반응을 하는지 기술
• 기능적 요구 항목으로 제기되는 문제들은 사용자의 문제를 해결하기 위한 구현기술과는 독립적이고 사용자 입장에서 원하는 기능들을 가져오는 것

2)비기능적 요구(non-functional)

• 기능이 아닌 잘 돌아가기 위한 성능, 보안 등등
• 시스템 구축에 대한 성능, 보안, 품질, 안전, 제약사항 등에 대한 요구사항

-기능적인 요구는 개발자가 개발하는 것이고 비기능적인 요구는 아키텍처, 하드웨어나 서버에 적용되는 것들

요구 추출의 어려움

• 개발자들이 응용 도메인에 대하여 충분히 알지 못함

Ex) 학교 시스템을 만드는데 학교를 모름

• 고객과 사용자가 의뢰할 때 자신이 의뢰하면서 소프트웨어가 무엇을 하는지 또한 어떻게 요구를 표현할 지 정확히 모름

Ex) 기타가게 사장 릭 - 어 이거 여러개 나와야 하는데?

→ 개발 중간에 프로토타입을 만들면서 원하는게 맞는지 계속 확인해야 한다

• 공통배경지식이 다르며 쓰는 말이 서로 달라 개발팀과 사용자 사이의 대화장벽이 생김, 용어집에 합의가 안되면 딴짓하게 됨
• 소프트웨어 요구에 대한 명세와 구현이 불리될 수 없어 정확히 명시하기 어려움
  • 구현이 어느정도 되어야 맞나요 물어보는데 요구와 구현이 분리되어야하는데 구현되어야 확인되니까 명확하게 분리가 안됨
• 요구 추출 작업을 관리자, 사용자, 개발자 모두 과소평가하는 경우가 많은 편
  • 개발부터 하려고 하고 전체를 보지 않고 자기꺼만 봄
• 비기능적 요구를 파악하고 이해하지를 못한다
  • 초창기에는 기능적 요구가 중요해보이지만 이게 안전하게 돌아가려면 비기능적 요구가 받춰줘야 한다. 기능적 요구는 사용자가 처음부터 정확하게 해야만 루틴이 돌아가게 된다.
• 요구가 자꾸 바뀜

cf. 전체를 제어하는 사람 : 아키텍터, 용어집을 정의하고 나눠주는 역할, 이게 제일 중요, 소프트웨어도 감리를 받아서 중간중간에 제대로 되었는지 확인, 그걸 아기 전에 도고?? 그게 맞지 않으면 커밋이 안됨

-중간중간에 도장찍어서 합의됨을 인정해야 함

• 명세서가 하나도 안남음

Ex) 아리안에서도 명세서가 남아있지 않아 머가 문제였는지 확인할 수가 없었다

1. 요구 추출

• 요구 분석의 첫번째 단계

추출 세 가지 단계

• 응용에 대한 정보 출처 파악
• 응용에 대한 정보 취합
• 요구와 제한 사항의 정의

-추출할 수 있는 출처를 파악하고 거기서 정보를 취합하고 그 취합한 정보로부터 요구와 제한사항의 정의

정보 수집 방법

• 고객의 발표
• 문헌조사
• 업무 절차와 양식 조사
• 관련자들 설문지
• 사용자와의 인터뷰
• 브레인 스토밍 회의
• 사용스토리 또는 사용사례 작성(에자일의 경우)

보통 기존 시스템을 전산화함(as-is -> to-be)여기서 전산화가 안된 시스템을 사용하는 사용자에게 업무를 물어봐야 함. 근데 사용자가 잘 알려줄까?? 안알려준다 자기 직업이 짤리니까 -> 절차서랑 문서를 다봐서 파악해야 함, 관련자들에게 설문지를 해야 하며 브레인 스토밍을 해야 한다.

우선 순위에 따른 요구 구별

모든 요구를 충족할 수는 없으므로 요구들 중에서 우선순위를 두어 가장 먼저 필요한 것 먼저 우선순위에 따라서 구현해야 한다.

• 절대적으로 필요한 요구
• 요망되나 꼭 필요한 것은 아닌 요구
• 요구로 판단될 수는 있으나 제외될 수도 있는 요구

1-1. 요구 정보 출처 파악

정보 출처 유형

발주자 – 고객, 돈내는 사람

사용자 – 실제로 사용하는 사람

이해 당사자(이시스템과 관련된 모든 당사자)와 관련된 것들 문서 모두 다 보고 좋은 회사라면 템플릿이 존재하여 템플릿을 이용

As is system = 레거시 시스템, legacy system

레거시 시스템의 문서를 다 봐야 하지만 없으면 역공학해야 한다. 코드 -> 명세서

1-2. 요구 정보 취합 - 요구 추출의 두 번째 관계

출처를 정했으면 방법들을 통해 질문해서 알아낸다.

1-3. 요구와 제한의 정의

• 수집한 정보에서 요구와 제한 사항을 도출한다.
  • 수집된 정보를 분석하여 사용자의 니즈를 만족시키는 시스템 역량과 제한사항을 도출
  • 시스템 역량을 요구로 정리하고 업무 중요도에 따라 우선순위를 정함
  • 개발팀은 이런 작업 수행 시 고객과 사용자, 도메인 전문가(이해 당사자)와 같이 협력함

2. 도메인 분석

도메인이란?

요구의 배경으로 소프트웨어로 해결하고자 하는 문제의 영역, domain

추출한 요구를 지금 우리가 해결하고자 하는 문제 영역(배경)에 맞춰서 비지니스 개념(도메인에 맞는 용어)을 정의 : 업무 도메인, 도메인

• 사용자 요구를 문제의 배경으로 가져가 비지니스 개념을 발견하고 정의하는 것
• 설계 모델링에 필요한 여러 개념과 비지니스 룰을 파악
• 응용 분야에 존재하는 개념을 잘 정의하고 분석하여 시스템에 존재하는 개념으로 정립하는 단계

도메인에만 적용되는 용어, 기능 등등을 시스템에 반영하고 구현해야 하기에 이 둘을 매개하기 위해 도메인 분석을 해야 한다. 찾아낸 요구사항을 도메인 개념에 맞게 재해석해라!

도메인

객체지향 분석단계에서의 본질은 도메인을 주목할 만한 개념이나 객체로 분해하여 결국 클래스가 나와야하므로 업무영역의 개념을 클래스로 뽑아내야 한다

• 도메인 모델이란 도메인 안에 존재하는 개념적 클래스나 실제 상황의 객체를 시각적으로 표현하는 것이다.
  • 실세계에 존재하는 객체를 소프트웨어 관점이 아닌 개념적 관점에서 본 투시도이다.
• 개발자가 개발하고자 하는 비지니스에 대해서 전혀 모르고 있을 경우 도메인 모델을 만들어야 주요 개념과 용어를 이해할 수 있기 때문이다.
• 도메인 분석이란 도메인 전문가가 해당 도메인에서 중요한 것으로 인지하는 객체와 기능, 관계를 식별하려는 노력이다.

도메인 전문가(회계 시스템 - 회계사)에게 물어봐야 한다.

2-0. 도메인 정의

• 우리가 할 업무 배경에 업무작업 영역을 파악하고 범위를 정함.

환자관리가 어디까지인가, 조제는 어디까지인가 scope(범위) 정하는 것이 매우 중요함

-정보 시스템을 구축하는데 필요한 개념적인 프레임 워크를 제공

도메인 분석의 세단계

• 도메인 개념 찾기
  • 정해진 도메인 내에서 안에 객체, 기능,프로세스 찾기
• 도메인 사전 만들기
  • 용어들을 정의해서 합의
• 비지니스 규칙 정리
  • 도메인에서 진행되고 있는 비지니스 규칙을 정의

2-1. 도메인 개념 찾기

도메인 분석이란 도메인 전문가가 해당 도메인에서 중요한 것으로 인지하는 객체와 기능, 관계를 식별하려는 노력이다.

도메인의 개념은 도메인의 목적, 구조, 동작을 구성하는 객체, 프로세스, 사람, 룰 같은 것

ex) 조제같은 경우, 조제의 목적, 구성하는 구조, 동작들을  구성하는 객체, 업무 절차,규칙, 룰, 역할 등을 찾아야 한다

2-2. 도메인 사전 만들기

• 모든 이해당사자들 사이의 공통된 개념으로 용어를 사용하기 위해 도메인 사전을 작성한다
• 도메인 개념을 조직화한 결과물
• 각 항목은 용어가 사용될 떄에는 언제든 같은 의미로 통하게 하는 간결한 정의
• 도메인 정의에서 표현된 문장, 어절, 제목에 초점을 두고 개념을 추출

예약하는 프로세스를 적을려면 어떤 과정인지 명시하고 예약할 때의 환자 정보와 날짜 시간이 있다면 객체가 될 것, 그 내용 또한 명시

→ 잘 찾아내서 이해당사자 모두 공통된 개념으로 용어들을 모두 합의봐야 한다. 작성하기 전에 합의를 봐야 한다

도메인 개념은 의사, 환자, 예약 등등을 찾아내는 것 그것들을 보다보면 절차, 객체가 나오게 되는데 프로세스 기능은 유스케이스로 나오고 객체는 클래스나 db에 반영이 될 것

2-3. 비즈니스 규칙 정리

• 업무 상에서 지키기로 한 규정
• 기업이 운영되는 자세한 정책, 규정, 절차, 가이드라인, 표준의 집합

도메인에서 운영되는 정책들을 잘 찾아내야 한다.

법적인게 가장 까다로울 것

3. 모델링

• 도메인 분석이 끝나면 도메인 개념들이 나오게 될 것이고 프로세스와 기능은 시스템이 제공해야 하는 기능이 되어 (usecase, 사용사례,시스템을 사용하는 경우,사용하는 사례)으로 나오게 될 것 - 기능적 요구사항을 말함
• 이 기능,사례를 사용하는 사람(역할)은 엑터가 된다.
• 도메인 개념을 모델링 한 후 명세서 작성

사용 사례(usecase)의 소개

• 시스템이 수행될 것으로 기대대되는 기능
• 시스템의 사용자에 서비스를 제공하기 위한 상호작용의 단위
• 시스템 개발을 시작하는 요구 분석 단계에서 설계 단계를 거쳐 테스팅에 이르기까지의 모든 작업의 근간이 된다
• 시스템 설계자/ 테스트 프로그래머들이 의사교환하는데 유용
• 소프트웨어 개발자와 이해 당사자 간의 계약
  • 사용자는 코드를 보면 모르기 때문에 유스 케이스 다이어그램만 본다

ex) 요구 사항 추적 메트릭스 예시

요구사항은 아이디 붙이고 이름들마다 있음.

이게 먼지, 이게 나중에 유스케이스로 나와야 한다. 하나의 기능으로 나와야 한다.→ 유스케이스는 결국 구현해야 하므로 화면이 나오게 된다 사용자 인터페이스는 분석단계에서 나옴, 입력으로는 뭐가 들어가야 하고 출력에는 뭐가 나오는지, 실제 구현은 설계에서 하는 것→설계단계에서 컴포넌트가 나오므로 이 요구사항이 분석단계에서는 유스케이스가 두개 있어야 하는데 이게 설계단계에서는 이거야. -> 테스트 단계에서는 원했던 요구사항들을 단위테스트로 테스트 했어

⇒ 유스케이스하나로부터 나오게 되는 것

• 일괄적으로 추적이 되어야 한다.
• 이런 문서가 제대로 안되어있으면 감리가 오케이 안됨
• 기본이 유스케이스모델!!

사용 사례 구축 시 주의 사항

• 시스템 내부를 모델링 하는 것이 아니다.
• 사용사례는 비기능적 요구가 아닌 기능적 요구를 알아내야하고 흘러가는 게 아니다
• 시스템 흐름도가 아니다
• 단계적 분할이 아니다.
• 어떻게가 아니라 무엇을 시스템이 하는가!!

사용 사례 다이어 그램, 유스케이스 모델

사용자에게 제공해야 하는 기능, 사용자가 이 시스템을 사용하는 사례를 찾아낸다.

• 시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는 데 사용
• 구성
  • 사용사례, 유스케이스 : 시스템 기능
  • 액터(actor) : 시스템과 상호작용하는 것(사용자, 시스템)

-사각형이 system 바운더리이고 이를 구현해야 하는데 기능은 대여, 반납, 등록 세가지가 있고 이게 유스케이스이며 이를 사용하는 것이 엑터

-비디오를 대출하거나 반납하는 것은 고객이 하지만 시스템 입장에서의 엑터는 고객이 아니라 점원, 고객은 이 시스템을 건들지 않음 그치만 무인 시스템이라면 액터가 고객일 것

이걸 그리면 우리가 구현해야하는 것이 뭐구나(기능적 요구사항 도출 가능), 유스케이스 각각에 대해서 구체적인 설명도 필요: 사용사례 명세서

→흐름을 보고 클래스와 속성, 기능을 뽑아내고 테스트 시에는 이것대로 구현해보게 된다.

명세서 작성 전에 시나리오가 나온다(명세서 보다는 구체적)

• 그걸 일반화하여 명세서를 작성

유스케이스, 액터를 찾아내고 각각의 설명을 해서 모델링이 끝나면 요구 사항 명세서를 작성하게 된다

4. 프로토타입핑과 테스트

5. 명세서 작성

• 사용자와 개발자 간의 이해를 돕기 위함
• 요구분석서는 사용자와 개발자 모두가 쉽게 이해 할 수 있도록 써야 한다
• 요구분석서에 기술된 조건은 개발자와 사용자가 모두 동의한 것이어야 한다.
• 요구분석서는 목표시스템에 의하여 수행될 모든 기능을 정확히 기술하여야 한다.
• 요구분석서는 목표 시스템에 영향을 주는 모든 제약조건을 기술한다.
• 요구분석서는 시스템의 인수를 위한 테스트 기준을 제공하여야 한다.
• 요구분석서는 원하는 시스템의 품질과 상대적인 중요도 및 품질을 재는 방법이 기술 되어야 한다.

명세서 검토

• 요구분석서는 사용자와 개발자 모두가 쉽게 이해할 수 있도록 써야한다 – 요구분석서에 기술된 조건은 개발자와 사용자가 모두 동의한 것이어야한 다. – 요구분석서는 목표시스템에 의하여 수행될 모든 기능을 정확히 기술하여 야 한다. – 요구분석서는 목표시스템에 영향을 주는 모든 제약조건을 기술한다. – 요구분석서는 시스템의 인수를 위한 테스트기준을 제공하여야 한다. – 요구분석서는 원하는 시스템의 품질과 상대적인 중요도 및 품질을 재는 방법이 기술 되어야 한다.