4. 요구사항분석

4.1 요구사항 정의(Requirements Definition)

소프트웨어 요구사항: 목표시스템의 기능, 특성, 서비스, 제약조건의 명세

• 사용자 입장에서 아는 것, 모르는 것, 알려진 것, 숨겨진 것, 기대되는 것, 기대되지 않는 것 전부 요구사항이다.
• 분류
  1. 비즈니스 요구사항
  2. 사용자 요구사항
  3. 소프트웨어 요구사항
     1. 기능적 요구사항
     2. 비기능적 요구사항
     3. 도메인 요구사항

4.1.1 기능적 요구사항

시스템이 무엇을 하는지에 대한 요구사항

• 입력, 연산, 출력 형태로 표현
• 사용 시나리오, 사용사례 파악에서 시작
• 목록
  1. 시스템이 수행할 기능
  2. 계산식
  3. 데이터 조작: 입력, 저장, 갱신, 검색, 출력
  4. 업무 처리 내용
  5. 사용자와의 상호작용
  6. 사용 시나리오, 사용사례
  7. 작업 처리 흐름도(workflow)

4.1.2 도메인 요구사항

특정 프로젝트의 고유한 요구사항과 제약조건, 그 분야라면 반드시 갖춰야할 필수 기능

• 산업별 규정과 표준을 지켜야함 -- 기능적일 수도, 비기능적일 수도 있다
• 사용자에 따라 바뀌지 않는다
• 주요 분야: 군사, 의료, 금융

4.2 비기능적 요구사항

시스템이 작업을 어떻게 수행하는지에 대한 요구사항

분류

• 환경 제약사항: 운영성·이식성·호환성(실행환경), 경제성(예산·기간·인력)
• 품질 요구사항: 성능, 신뢰성·활용성, 사용성, 확장성·유지보수성, 보안성, 안정성
• (슬라이드는 두 분류 이름만 있고 어느 게 어디 속하는지는 안 나눔. 위 배정은 내용 보고 나눈 것)

4.2.1 성능 요구사항

기능을 수행하는데 필요한 최소 요구조건

• 요구사항 항목: 반응시간, 처리·컴퓨팅 능력, 운영 능력, 유지보수성, 저장 공간

4.2.2 운영성, 이식성, 호환성 요구사항

실행환경에 대한 요구사항

4.2.3 사용성 요구사항

좋은 UI평가: 편한지, 일관적인지, 빠른지 등등

사용자 인터페이스 요구사항과 같은 취급 가능

4.2.4 신뢰성, 유지보수성, 활용성 요구사항

• 신뢰성: 얼마나 자주 고장나는지(고장이 안나는 것이 목표)
• 활용성: 실제 사용 가능 시간이 어떻게 되는지(고장 후 빠른 복구가 목표)
• 요구사항 항목: 실패 빈도 허용 범위, 최대 복구 시간, 가용 시간과 다운타임의 차이

4.2.5 보안성 요구사항

시스템이 해커 공격으로부터 얼마나 보호되는지에 대한 요구사항

4.2.6 안정성 요구사항

위험 요소를 줄이려고 정의하는 요구사항

4.2.7 확장성 요구사항

높은 부하에서 성능 요구사항을 충족하는지

• Scale-up(수직): 단일 컴퓨터 사양
• Scale-out(수평): 비슷한 서버 여러대 추가 -- 로드밸런싱 필요

4.2.8 경제성 요구사항

예산, 인적, 장비, 시간 등등의 자원에 대한 제약

4.2.9 비기능적 요구사항의 테스트 방법

비기능적 요구사항은 항목마다 별도의 테스트 단계를 거친다

테스트 목록: 부하·스트레스, 볼륨, 설치, 제거, 복구, 문서

4.3 요구사항 엔지니어링(RE) 프로세스

요구사항을 정의하고, 문서화하고, 유지 관리하는 체계적인 프로세스

도출·타당성 분석 → 정제 → 명세 → 검증

4.3.1 1단계: 요구사항 도출 및 분석

개발자와 이해관계자가 만나는 데서 시작. SW가 왜 필요한지, 어떤 문제를 푸는지, 어떤 제약이 있는지를 찾는 작업

• 다뤄야 할 항목
  1. 개발 목표와 내용
  2. 기능적 요구사항
  3. 비기능적 요구사항
  4. 기대되는 특성
  5. 개발 항목 우선순위 결정 여부
  6. 개발·운영 제약사항

4.3.2 2단계: 요구사항 정제

4.4의 기법(인터뷰, 포커스 그룹, 워크숍, shadowing, 설문, 프로토타입 테스트)들로 모은 요구사항을 철저히 분석해서 확인하는 단계

• 기준: 명확한가, 실행 가능한가, 달성 가능한가, 검증 가능한가
• 목적: 이해관계자의 실제 요구를 분명히 하고 합의하는 것

4.3.3 3단계: 요구사항 명세(Software Requirements Specification, SRS)

정의된 요구사항을 바탕으로 기술 문서로 작성하는 것

항목 (상황 따라 가감)

• 개발 목표와 세부 내용, WBS, 용어 설명
• 기능적·비기능적 요구사항
• 사용사례 다이어그램, 사용사례 명세
• 클래스 다이어그램, DB 스키마 테이블 명세
• UI 명세
• 사용사례별 시퀀스 다이어그램
• 클래스 메소드 알고리즘 명세

명세 작성 지침

• 사용자 요구사항 → 자연어
• 기술적 요구사항 → 구조적 언어(도구)
• 알고리즘 → 의사코드(pseudo code)
• 폼, GUI → 설계해서 기술

4.3.4 요구사항 검증

Why?: 사용자는 불법이거나 비현실적인 걸 요구할 수 있고, 전문가는 요구를 잘못 이해할 수 있기 때문에 When?: SRS 작성을 끝낸 뒤 반드시 해야함

평가질문

• 실제로 구현 가능한가
• 고객 요구 기능, 도메인에 적합한가
• 모호성 없는가
• 완전한가
• 데모로 보여줄 수 있는가

4.4 요구사항 분석 방법

대표방법 10개: 이해관계자 분석, 문서 분석, 인터뷰, 포커스 그룹, 인터페이스 분석, 관찰, JAD, 설문조사, 브레인스토밍, 프로토타이핑

4.4.1 이해관계자 분석

요구사항 분석은 여기서 시작한다. 시스템과 관계되거나 영향을 주는 사람을 먼저 찾는다.

4.4.2 인터뷰

• 개방형 질문: 자유로운 답
• 폐쇄형 질문: Yes or No(주로 답을 확인할 때)

4.4.3 문서 분석

업무 환경을 기술한 문서를 모아서 검토하는 방법

• 대상: 사업계획, 기술문서, 문제 보고서, 기존 요구사항 문서
• 마이그레이션 프로젝트(기존 시스템을 고치거나 바꾸는 것)에 특히 유용
• AS-IS(기존 문서)를 TO-BE(미래 업무 프로세스) 모형과 비교

4.4.4 인터페이스 분석

구성요소끼리 정보를 어떻게 주고받는지 파악하는 방법

시스템, 이해관계자, 프로세스를 확인하는 데 사용

초점 질문 5개

• who: 누가 쓰나
• what: 무슨 데이터를 주고받나
• when: 언제 교환하나
• how: 어떻게 구현하나
• why: 왜 필요한가

4.4.5 포커스 그룹

주제 전문가를 포함한 그룹이 특정 주제를 토의해서 요구사항을 끌어내는 방법

새 요구사항을 만들고, 이미 찾은 요구사항을 검증하고 정제

4.4.6 설문조사

미리 정한 질문과 선택지가 담긴 설문지를 모든 이해관계자에게 돌려서 답을 모으는 방법

질문은 위험도 우선순위가 높은 것부터 넣는다.

4.4.7 관찰

남이 하는 활동, 작업, 쓰는 도구, 이벤트를 이해하려는 방법

4.4.8 브레인스토밍

새롭고 창의적인 아이디어를 끌어내는 그룹 토의 방식

비평은 절대 금지

4.4.9 프로토타이핑

모형을 만들어서 데모하고, 다이어그램으로 업무 프로세스를 설명하면서 요구사항을 파악하는 방법

눈으로 보여줄 수 있고, 피드백이 빨리 온다

4.4.10 Joint Application Development (JAD)

최종 사용자, PM, 개발자가 동시에 같이 참여해서 요구사항을 정의하는 프로세스 지향적 방식

비즈니스 프로세스 개선 워크숍: 기존 프로세스를 분석해서 개선점을 찾는다. 공식 워크숍보다 비공식적.

장점

• 몇 시간 만에 요구사항 문서가 나온다
• 단기간에 대규모 그룹의 요구를 모으고 다 같이 있는 자리에서 합의한다.

단점

• 이해관계자가 빠지면 실패할 수 있다
• 진행자 역량에 따라 성공이 좌우된다
• 사람이 너무 많으면 목적을 이루지 못한다

벤치마킹(추가로)

업계 최고와 비교

4.4.11 가장 인기 있는 6가지 요구사항 분석 방법

인터뷰, 포커스 그룹, 브레인스토밍, 관찰, 프로토타이핑, JAD(요구사항 워크숍)

4.6 시스템 제안서(System Proposal) 작성 방법

개발 계획(ch3)이랑 요구사항 분석(ch4)을 다 마친 뒤 쓰는 프로젝트 본 사업계획서