✅요구분석

• 소프트웨어에서 가장 중요한 단계
• 솦프트웨어 프로젝트 계획 이후에 소프트웨어 시스템이 가져야할 기능이나 성능 등의 특징을 찾아내서 이것을 분석하고 정리해서 요구사항으로 잘 정리 한 것

---

• 소프트웨어 개발의 실질적인 첫 단계
• 사용자의 요구에 대해서 이해하고 정리한느 작업
• 두 가지 작업
  • 현재의 상태를 파악하고 요구를 정의
  • 명세서 작성
• 요구의 변경은 파급 효과가 큼

✔요구분석 과정

1. 요구추출 - 기능적인 요구와 기능 이외의 조건 추출
2. 도메인 분석 - 요구에 대한 정보를 수집하고 배경 분석
3. 모델링 - 도메인 분석을 통해 얻은 자료를 개념화
4. 프로토타리핑과 시험 - 분석된 기능적 요구의 타당성 시험을 위한 프로토타입 생성
5. 문서화 검토 - 요구분석서를 작성

🔽요구

• 시스템이 제공해야할 역량
• 외형적으로 나타내는 기능이나 성능

✔요구와 연관된 사람들

• End Users : 최종적으로 이 서비스를 사용할 사람
• Domain Experts : 도메인 관련한 약관 등을 관리해줄 전문가들

→ 이처럼 정말 많은 유형의 사람들이 관련되어 있기 때문에 요구사항을 아주 정확하게 추출해내는 것이 중요함.

🔽기능적 요구

• 시스템과 외부 요소들 간의 인터랙션 (사용자들에게 보여주는 서비스)
• 시스템이 어떤 상태일 때 외부의 데이터나 명령에 대해 어떤 반응을 하는지 기술
• 기능적 요구 항목으로 제기되는 문제들은 사용자의 문제를 해결하기 위한 구현 가술과는 독립적인 사항

✔기능적 요구사례

특성, 자료, 입출력, 사용자

✔기능적 외적 요구(성능)

• 비기능적 요구 : 시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구사항
• 성능 - 시스템의 처리량(1분당 몇개를 처리하는지, 반응 속도가 어떤지..)
• 품질 - 신뢰성, 가용성, 사용시 오류 발생률
• 안전 - 의도하지 않은 오퍼레이션으로 인해서 원치 않는 상태에 있는 것을 방지하는 역량
• 보안 - 시스템의 자원을 악의적인 공격으로부터 보호할 수 있는 역량
• 사용성 - 인터페이스. 동작, 보고 느끼는 것

🔽요구 추출의 어려움

• 개발 팀이 응용 도메인에 대해서 충분히 알지 못함.
• 고객과 사용자가 소프트웨어가 무엇을 하는지 또한 어떻게 요구를 표현할지 모름
• 공통 배경지식 부족으로 개발 팀과 사용자 사이의 대화 장벽이 생김
• 소프트웨어 요구에 대한 명세와 구현이 분리 될 수 없어 정확히 명시하기가 어려움 (그래서 요구에 대한 명세를 아주 확실하게 정확하게 정해놔야함, 요구 추출할때는 어떻게가 아니라 무엇을 추출 해야하는지를 결정하는 것이다. Not How, WHAT!)
• 요구 추출 작업을 관리자, 사용자, 개발자 모두 과소평가하는 경우가 많음.
• 비기능적 요구를 파악하고 이해하지 못함.
• 요구가 계속해서 변경됨

✔요구 추출

• 추출 세 가지 단계
  • 응용에 대한 정보 출처 파악 (* 정보출처 : 다양한 이해관계자들의 요구를 파악하는 것.)
  • 응용 대한 정보 취합
  • 요구와 제한 사항의 정의
• 정보수집 방법
  • 고객의 발표, 문헌 조사, 업무 절차와 양식 조사,
  • 관련자들 설문지, 사용자와의 인터뷰, 브레인 스토밍 회의, 사용 스토리 또는 사용사례 작성

✔요구 우선순위

• 우선 순위에 따른 요구 구별
  1. 절대적으로 필요한 요구
  2. 용망되나 꼭 필요한 것은 아닌 요구
  3. 요구로 판단될 수 있으나 제외될 수돌 있는 요구

✔요구 정보 출처

• 정보출처 유형
  • 고객(혹은 나 자신)
  • 도메인 전문가 - 비즈니스 도메인을 지원하는 시스템을 구축하기 위해 필요한 사람
  • 이해당사자(stakeholder) - 시스템 운용으로 인해 영향 받는 사람
  • 사용자(end user) : 시스템을 직접 사용하는 사람
  • 역공학 : 이미 있는 시스템들을 잘 분석

🔽정보 수집 방법

• 고객의 발표

  • 개발팀이 구축하는 시스템에 대해 초기에 개념을 잡을 수 있음
  • 효과적인 가이드라인 – 고객 업무를 잘 알고 있는 운영 책임자나 관리자가 발표
    – 발표하기 전 개발 팀원이 필요한 정보가 있는지 검토
    – 의심이 가는 부분을 질문하여 명확히 할 것
    – 구현과 관련된 토의는 배제
    – 발표 내용의 복사본을 팀원과 공유
    – 2시간 이상의 발표회는 지양
    

• 문헌 조사

  • 유사한 프로젝트를 조사 (현재 개발할 시스템에 대한 통찰 제공)
  • 업무문서나 양식을 조사(현재 업무나 시스템 정보에 대해 깊은 이해가능)
  • 산업 및 기업 표준 조사 → 도메인 전문가 같은 사람들ㅇ
  • 관련 정부 정책/규제 조사

• 업무 절차와 양식조사

  • 업무 관련 문서, 절차, 양식, 운영 메뉴얼 조사
  • 내부 표준 조사
  • 정부, 산업, 기억의 특수정책이나 규정 조사

• 관련자들 설문지

  • 관리자나 사용자와 같은 이해 당사자를 대상
  • 이해 당사자들이 의사결정 과정에 포함
  • 무기명 설문 : 감추어진 정보를 끌어내기 쉬움
  • 유의사항 : 질문은 간단 중요이슈에 집중

• 사용자와의 인터뷰

  • 가이드라인 – 가능하면 많은 당사자와 인터뷰
    – 여유로운 인터뷰 일정
    – 인터뷰 약속 시간을 넘기더라도 여유롭게
    – 중요한 관련자와는 여러 차례 인터뷰
    

• 브레인 스토밍 회의

  아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의
  훈련된 요원이 주재
  토론보다는 아이디어를 쏟아놓는 회의, 익명성 보장
  서로 자극이 되어 열정을 가지고 아이디어를 창안
  JAD(Joint Application Development) – 집중 브레인스토밍 세션
  

• 프로토타이핑

  • 프로토타입 : 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램
  • 가장 단순한 형대 : paper prototype
  • 가장 흔한 형태 : 모의 사용자 인터페이스

• 사용 스토리 또는 사용사례 작성

  • USECASE 유즈케이스
    • 어떤 기능이 있고 어떻게 흐름이 구성되어있는지까지 다 나와있음.
    • 최근에는 애자일 프로세스가 유즈케이스로 많이 쓰임
  • 사용자 스토리 (개발자에게 모든 것을 맡기는 경우임)
    • 사용자/개발팀간의 대화를 이끌어내는 도구
    • 사용자들이 시스템에 바라는 역량 및 기능을 간단히 기술
    • 하지만 기능만 기술이 되어있기 때문에 어떤 기능이 어떤 흐름을 가지고 이용할 수 있는 지를 정의하지 못함.

✔요구 제한의 정의

• 수집한 정보에서 요구와 제한 사항을 도출
• 요구도출과정(사용자 니즈 파악, 요구 도출)

🔽도메인

✔도메인 분석

• 도메인 : 요구의 배경
• 설계 모델링에 필요한 여러개념과 비즈니스 룰을 파악
• 응용 분야에 존재하는 개념을 잘 정의 하고 분석하여 시스템에 존재하는 개념으로 정립하는 단계

1. 도메인 정의

• 업무작업 영역을 파악하고 범위를 규정 : 정보 시스템을 구축하는데 필요한 개념적인 프레임워크 제공
• 서브시스템이라고 생각하면 됨.
• 넓은 범위의 개념을 더 좁은 범위의 지식들로 체계홯하는 작업

2. 도메인 분석

• 도메인 배경파악
• 도메인 개념
  • 도메인의 목적, 구조, 동작을 구성하는 객체, 프로세스, 사람, 룰 같은 것임. (* 객체는 하나의 클래스를 이루는 것을 말함, 프로세스 : 이런 것들이 어떻게 흘러가는지 정리, 사람: 액터, ***룰: 규칙)
  • 도메인 개념을 발견을 위한 주의사항
    • 요구의 핵심을 발견해야함
    • 요구가 해결될 것 같은 문제를 발견
    • 문제의 요소를 발견
    • 관련된 도메인의 개념을 발견

3. 도메인 사전

• 도메인 개념을 조직화한 결과물
• 각 항목은 용어가 사용될 때는 언제든 같은 의미로 통하게하는 간결한 정의
• 요구, 인터뷰, 메뉴얼로 추출
• 도메인 정의에서 표현된 문장, 어절, 제목에 초점을 두고 개념을 추출
• 진료와 검사 의료서비스의 성격에따라 의사, 간호사,검사원이 환자에게 적절한 예약된 의료 서비스를 제공
• 도메인 개념, 의료서비스, 의사, 간호사, 검사원 ,환자, 예약

4. 비즈니스 규칙

• 업무에서 지키기로 한 규정
• 정책, 규정, 절차, 가이드라인, 표준의 집합
• 사용자에게 요구해도 준비된 전체 목록을 받기 어려움
• 종류
  – 사실(fact) – 개념이 무엇인지 설명
  – 추론(inference) – 다른 사실로 부터 얻은 사실
  – 액션 구동자(action enabler) – 조건이 일치되면 액션이 수행
  – 제약(constraints) – 시스템이나 외부 요소가 수행할 또는 수행하지 않을제약을 가하는 규칙
  – 계산(computation) – 공식이나 알고리즘