목차
📁 요구사항 분석 과정
'어떻게' 보다는 '무엇을'에 관점을 두어야 한다.
📁 도메인 분석
도메인 분석은 소프트웨어 엔지니어가 문제를 더 잘 이해하기 위하여 도메인에 대해 알아가는 과정이다.
도메인이란, 소프트웨어를 사용할 것으로 예상되는 고객이 일하는 분야의 비즈니스나 기술을 칭한다.
도메인 전문가는 소프트웨어가 사용된 도메인 분야에 깊이 있는 지식을 가진 사람을 말하며, 대부분 사용자이자 고객이다.
도메인 분석을 사용하게 되면 얻을 수 있는 이점
- 빠른 개발 : 이해당사자들과 더욱 효과적으로 의사소통이 가능하고, 빠른 요구사항 파악이 가능하다.
- 더 좋은 시스템 구축 가능 : 고객의 문제를 효과적으로 해결하는 솔루션을 결정할 수 있다.
- 확장 예견 : 트렌드를 예측하는 능력을 갖추고, 적응도 높을 시스템 구축이 가능하다.
🌱 도메인 분석서
1. 개요
2. 용어
3. 개괄적 지식
- 도메인 전문가가 알고 있는 중요한 사실이나 규칙
- 비즈니스 프로세스, 분석 기술, 동작 원리
4. 고객과 사용자
- 소프트웨어를 누가 구입하고 어떤 분야에서 활용하는가?
5. 환경
- 사용하는 장비나 시스템에 대한 기술
6. 작업과 수행 절차
- 인력이 담당하는 작업, 작업의 절차, 그들만이 알고있는 쉬운 방법
7. 경쟁 소프트웨어
- 이미 시장에서 판매되어 사용되고 있는지 여부, 그것의 장단점 파악
8. 다른 도메인과의 유사성
- 일반성, 특수성 이해
항공 예약 시스템의 도메인 분석
– 도메인 분석을 위한 정보 수집 • 항공편 일정이 어떻게 계획되는지 • 요금은 얼마이며 요금체계는 어떤지 • 해당 항공사와 다른 항공사의 예약 방식, 발권 방식은 어떤지 • 항공권 예약에 관련된 비즈니스 종사자, 즉 여행사와 항공사 직원들의 업무 수행 방식은 어떤지 • 현재 예약 시스템이 있다면 어떻게 작동하는지 • 이 분야의 법규, 조례 등 규정은 어떤지 • 경쟁 예약 시스템의 기능 분석 • 탑승객이 직접 항공권을 예약하게 될 경우에는 어떤 변화가 필요한지
프로젝트 착수
문제 정의와 범위 설정
문제란 고객이나 사용자가 직면한 어려움이다.
생산성이나 매출을 높일 수 있는 기회이다.
문제의 해결은 일반적으로 소프트웨어의 개발을 필요로 한다.
좋은 문제 정의서(problem statement)는 짧고 간결해야한다.
범위를 설정할 때는 시스템이 해결할 수 있는 모든 일을 상상하여 리스트를 작성한다.
범위가 너무 넓으면 일부는 배제하고,
범위가 너무 좁으면 시스템을 사용할 궁극적인 최상위 목표를 파악한다.
예를 들어 대학 수강 신청 시스템의 목표는 원활한 수강 신청이다.
문제 정의 범위 • 시스템은 교무처 직원들이 강좌, 학위 취득 요건, 수강 신청 성적 리스트 를 관리하는 것을 도와준다. 또한 학생들이 학위 취득을 위해 흥미 있는 강좌를 선택하고 신청하는 것을 도와준다. – 시스템에 포함되어야 할 기능 결정 (+ : 포함, - : 제외) • 수강료 수납 및 관련 회계, 고지서 발급 (-) • 입학을 위한 지원 (-) • 강의 리스트, 강의 해설, 선수 과목 리스트의 편집과 조회 (+) • 학위 취득을 위한 요건의 편집과 조회 (+) • 특정 학기에 개설된 강좌 리스트의 편집과 조회 (+) • 개설된 강의의 시간 배정 (-) • 학위 취득 요건, 지난 학기까지의 수강 과목, 일정, 선호도 분석을 이용한 강의 추천 (+) • 학생 등록 (+), 성적 기록 (+), 성적증명서 인쇄 (+)
요구사항 추출
요구사항(requirements)이란, 제안된 시스템이 무엇을 하는가를 나타낸 문장으로 고객의 문제가 적절히 해결되기 위해 관련자들이 동의한 것을 말한다.
짧고 간결한 정보, 예를 들어 단순 명료한 문장이나 그림으로 표현되어야한다.
시스템이 수행해야하는 작업을 기술한다.
관련자 모두(사용자, 고객, 개발자, 관리자)가 동의한 것이어야 한다.
고객의 문제를 해결하기 위한 것이다.
위와 같은 요구사항을 모아 놓은 것을 요구사항 문서(requirements document)라고 한다.
요구사항에는 두 가지 유형이 있다.
🌱 기능적 요구사항(functional reqirements)
시스템이 무엇을 하여야 하는가를 기술한 것이다.
예를 들면 ATM 시스템의 기능적 요구사항은 현금 인출, 잔액 조회, 계좌 이체, 현금 서비스 등이 있다.
1. 입력
사용자와 다른 시스템으로부터 유입되는 데이터와 명령어.
2. 출력
화면 디스플레이, 인쇄, 다른 시스템에 전달되는 정보.
3. 저장
시스템이 저장하는 데이터.
4. 컴퓨팅
시스템에서 이루어지는 계산
5. 타이밍과 동기화
하드웨어 장치 제어, 리얼타임으로 작업을 수행하는 시스템에서 중요하다.
통신 시스템, 발전소/공장 제어 시스템/자동차,비행기 제어 시스템 등
🌱 비기능적 요구사항(nonfunctional requirements)
소프트웨어 개발 과정에 지켜야 할 제약 조건을 말한다.
성능, 효율, 반응 시간, 소프트웨어 품질 특성에 대한 수준의 범위이다.
모든 사항이 검증 가능해야한다.
시스템 구현 후 요구사항의 충족 여부를 확인한다.
세가지 주요 유형이 있다.
1. 소프트웨어 품질 특성 측면 (성능, 신뢰성, 가용성, 사용성 등)
- 반응 시간 : 탐색 결과가 1초 이내 나와야 함.
- 처리량 : 분당 처리 트랜잭션 수
- 자원 사용량 : 시스템이 사용하는 최대 용량 (최대 30MB 메모리 사용)
- 신뢰성 : 시스템이 고장 없이 동작할 가능성
- 가용성 : 시스템이 항상 실행되고 준비된 상태에 있는 시간을 의미 (DT < 1분)
- 고장에서의 회복 : 고장으로 인해 영향을 받는 최대 허용치
- 유지보수성과 확장(enhancement)의 허용
- 재사용성의 허용
2. 시스템의 환경과 기술적 측면
- 플랫폼 : 시스템이 동작할 HW, OS (32MB 이상의 램, 윈도우 10 이상)
- 사용 기술 : 프로그래밍 언어, 전자정부 표준 프레임워크 등
3. 프로젝트 계획과 개발 방법에 관한 측면
- 사용하는 개발 프로세스(방법론)
- 비용과 납기일 : 시스템 개발 계약서나 별도의 프로젝트 계획서에 명시
🌱 요구사항 추출 방법
1. 관찰(Observation)
관찰 방법
문서를 읽고 사용자와 함께 요구사항에 대해 논의한다.
잠재적인 사용자들이 수행하는 복잡한 일을 관찰한다.
사용자가 하는 일을 자세히 설명해달라고 요청할 수도 있다.
비디오를 촬영한다. 예를 들면 은행의 텔러가 수행하는 업무를 비디오로 촬영하여 관찰하기 적합하다.
시간이 많이 소요된다.
2. 인터뷰(Interviewing)
미리 잘 계획해야 많은 정보를 얻을 수 있다.
가능하면 많은 당사자와 인터뷰를 진행하는 것이 좋다.
관련자 이외의 사람(경쟁 제품 사용자, 마케팅 담당자 등)과도 인터뷰하는 것이 좋다.
여유 시간을 할애해야한다.
인터뷰 절차는 아래와 같이 진행한다.
1. 대상자 선정
2. 일정 계획
3. 질문 작성
4. 인터뷰
5. 분석 및 정리
인터뷰 질문 내용은 아래 사항을 고려한다.
1. 최대, 최소, 예외 규칙, 예상되는 변동 등 자세한 사항까지 질문한다.
- 업무 프로세스를 구성하는 각 단계가 무엇인지, 단계 개수의 변경 여부
- 설계 단계에서의 확장 가능성
- 육하원칙 (누가, 언제, 어디서, 무엇을, 어떻게, 왜) 적용
2. 관련자에게 시스템에 대한 미래 비전을 질문한다.
- 어떤 융통성을 가져야 하는가.
- 다른 차선의 방법이 있는가.
- 개발 측이 가지고 있는 대안에 대해 어떻게 생각하는가.
3. 문제에 대해 최소한의 허용 가능한 솔루션이 무엇인지 질문한다.
- 너무 많은 아이디어를 얻는 경우 사용되지 않을 기능이 생성될 수 있는 가능성이 있다.
- 고객과 사용자가 기본적으로 필요한 것이 무엇인지 확인한다.
4. 다른 정보원(other sources of information)에 대해 요청한다.
- 보고싶은 문서를 요청한다.
- 유용한 지식을 지닌 다른 사람을 소개해달라고 요청한다.
5. 다이어그램 작성을 요구한다.
- 다이어그램을 통해 정보의 흐름, 명령의 순서, 기술이 어떻게 작용하는지 등을 파악한다.
- 다이어그램은 정보 수집을 촉진한다.
📁 브레인스토밍(Brainstorming)
브레인스토밍이란 아이디어를 낼 목적으로 여러명으로부터 정보를 얻기 위한 회의를 말한다.
훈련된 요원이 주재.
토론보다는 아이디어를 쏟아놓는 회의이며, 익명성이 보장된다.
🌱 JAD(Joint Applicaiton Development)
최종 사용자와 개발자가 시스템 개발을 논의한다.
격리된 장소에서 개발자는 고객과 사용자를 만나 요구사항을 정의하기 위해 공동 작업한다.
집중 브레인스토밍 세션
요구사항 분석에 필요한 기간을 획기적으로 단축할 수 있다.
🌱 브레인 스토밍 과정
1. 관련자 모두가 참여하는 회의 소집 2. 경험 많은 사람을 회의 주재자로 선정 3. 테이블에 참석자를 배석시키고 작업할 종이 준비 4. 토론을 유도할 질문을 정함 5. 질문에 대하여 답을 종이에 적되 한 장에 하나의 아이디어만 적은 후 옆의 참석자에게 넘겨줌 6. 5번 단계를 5~15분간 반복, 더 이상 아이디어가 나오지 않으면 중단 7. 종이에 적힌 아이디어 읽음. 설명이 필요하면 작성자가 간단한 설 명 (익명 진행 시 설명 생략 가능). 간단한 토의 가능 8. 모든 아이디어를 칠판에 적은 후 우선순위를 정하기 위하여 투표를 할 수도 있음
• [사례] 4번 단계: 토론을 유도할 질문 – 이 시스템에서 중요한 기능은 무엇인가? – 이 시스템에 포함되어야 할 기능은 무엇인가? – 미래에 어디서 새로운 자료가 발생할 것으로 예상되는가? – 시스템에서 어떤 출력이 생성되어야 하는가? – 도메인 모델에서 어떤 클래스가 필요한가? – 고려하지 않을 이슈는 무엇인가? – 이 프로젝트의 리스크는 무엇인가?
📁 프로토타이핑
프로토타입이란 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램을 말한다.
가장 단순한 형태는 paper prototype이다.
사용자 인터페이스를 종이에 그린 것을 말한다.
시스템의 화면을 순서대로 사용자에게 보여주는 형태로, 아이디어추출 및 피드백 받기에 적합하다.
다수의 개발자가 시스템에 대한 자신의 고나점을 병행하여 작성하고, 결과를 평가받을 수 있다.
가장 흔한 형태는 mock-up of the UI이다.
프로토타이핑 전용 언어로 작성한 것을 말한다.
컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가능하다.
시스템의 특별한 측면, 예를 들면 알고리즘이나 데이터베이스 등을 프로토타이핑하기도 한다.
📁 요구사항 문서화
두 가지 극단적인 형태가 있다.
1. 요구사항 정의(requirement definition) : 몇 문단의 글이나 다이어그램으로 요구사항의 아우트라인을 정의한 것
2. 요구사항 명세서(requirement specification) : 수천 페이지의 복잡하고 자세한 명세 리스트
대규모 시스템을 위한 요구사항 문서는 계층적으로 정리해야한다.
🌱 요구사항 문서의 상세 수준
요구사항 문서에 얼마나 자세히 기술하여야 하는가는 다음 사항을 고려하여 결정한다.
– 시스템의 크기 – 다른 시스템에 대한 인터페이스 요구 (통신 프로토콜) – 목표로 하는 독자 (일반 사용자, 전문인) – 개발을 위한 계약 (외주 계약, 정부 기관 계약) – 요구사항 취합 단계 (초기 단계 – 시스템이나 서브시스템 개요 간략) – 도메인 및 기술에 대한 경험 수준 • 혁신적인 소프트웨어 개발: 대략적인 요구사항 프로토타입 개발, 아이 디어 검증, 보유 기술의 신뢰성 검토 – 요구사항의 오류로 인한 손해 비용 • 고장으로 인해 안전이나 환경에 심각한 위험 초래 정확한 명세 필요
🌱 요구사항 문서의 구성
1. 개요 2. 배경 지식 • 요구사항을 이해하는데 도움이 되는 정보 • 도메인 분석서, 관련 표준 등에 대한 참고 문헌 3. 환경 및 시스템 모델 • 시스템이 수행될 배경 및 시스템이나 서브시스템의 개요 기술 • 외부 인터페이스 요구: 사용자 인터페이스, 하드웨어 인터페이스, 소프 트웨어 인터페이스, 통신 인터페이스 등 4. 기능적 요구사항 • 기능 요구사항 5. 비기능적 요구사항 • 품질 특성 측면 요구사항 • 시스템 환경과 기술적 측면 요구사항 • 프로젝트 계획 측면 요구사항: 자원, 인력, 일정, 비용 등과 같은 제약 조건
📁 요구사항 검토(Review)
각 요구사항이 다음을 만족하는지 검토해야한다.
• 각 요구사항이 다음을 만족하는지 검토 – 개발 비용 대비 투자 효과 • 개발, 유지보수, 하드웨어 구입, 관련자 교육 등의 비용 vs 생산성, 매출 향상 – 현재 당면한 문제가 해결되는가? • 현재 당면한 문제 중 우선순위가 낮으면 삭제 (80 대 20 법칙) – 명확하고 일관성 있게 표현 되었는가? – 모호한 점이 없는가? – 논리적으로 일관성이 있는가? • 작성한 요구사항과 다른 요구사항 간의 일관성 • 상위 시스템이나 서브시스템의 요구사항과 부합하는지 확인 – 충분한 품질의 시스템을 달성할 수 있는가? • 사용성 확보를 위해 좋은 사용자 인터페이스 설계 체크리스트 적용 – 가용 자원으로 실현 가능한가? (성능 체크 프로토타입을 통한 테스트) – 검증 가능한가? (검색 결과의 95%가 3초 이내에 나와야 함) – 식별 가능한가? (고유한 식별자) – 설계를 과다하게 제한하고 있지 않는가? (어떻게 구현할 것인지 언급 X)
📁 요구사항의 변경 관리
요구사항은 다음과 같은 경우로 인해 계속 변경된다.
- 비즈니스 프로세스의 변경
- 기술의 변경
- 문제 이해 향상
요구사항이 변경될 때 고려해야하는 사항으 ㄴ아래와 같다.
- 고객 및 사용자와 지속적으로 상호작용해야한다.
- 변경으로 인한 이익이 변경 비용을 초과하여야한다.
작은 변화는 적은 비용으로 빠르고 신속히 가능하지만, 대규모 변화는 신중하게 접근해야한다.
- 어떤 변경은 위장된 확장일 가능성이 존재한다.
시스템의 규모를 키우는 것은 피하고 오직 더 좋은 시스템이 되도록 노력해야한다.
