[소프트웨어공학] 요구사항 개발 및 정의
요구사항 분석 과정
'어떻게' 보다는 '무엇을' 에 관심을 두어야한다.
1. 도메인 분석 : 문제의 배경가 성격, 범위를 파악한다.
2. 요구사항 추출: 사용자가 소프트웨어에 대해 무엇을 필요로 하는지 도출한다.
3. 분석 및 명세화: 도출된 요구사항을 분석하고 문서로 정리한다.
4. 검토 : 사용자가 요구한 사항과 일치하는지 검토한다.
이제 한 단계씩 살펴보자.
도메인 분석
: 소프트웨어 엔지니어가 문제를 더 잘 이해하기 위해 도메인에 대해 알아가는 과정이다.
도메인이란 소프트웨어를 사용할 것으로 예상되는 고객이 일하는 분야의 비즈니스나 기술을 지칭한다.
도메인 전문가는 소프트웨어가 사용될 도메인 분야에 깊이 있는 지식을 가진 사람으로 대부분은 사용자이자 고객이 된다.
도메인 분석을 수행하면
1. 빠른 개발에 이점이 있다.
: 이해 당사자들과 더욱 효과적으로 의사소통을 할 수 있어서 빠른 요구사항 파악이 가능하다.
2. 더 좋은 시스템을 구축할 수 있다.
: 고객의 문제를 효과적으로 해결하는 솔류선을 결정할 수 있다.
3. 확장 예견 가능
: 트렌드를 예측하는 능력을 갖춰 적응도 높은 시스템을 구축할 수 있다.
도메인 분석서
도메인 분석서 예시 1
https://ksp.etri.re.kr/ksp/plan-report/file?id=584
도메인 분석서 예시2
도메인 분석이 끝나면 프로젝트를 착수한다.
프로젝트 착수
문제 정의와 범위 설정
문제란 고객이나 사용자가 직면한 어려움을 지칭한다. 동시에 생산성이나 매출을 높일 수 있는 기회도 뜻한다.
문제의 해결은 일반적으로 소프트웨어의 개발을 필요로한다.
해결을 위해 문제를 정의하고 범위를 설정해야한다.
문제 해결을 위한 좋은 문제 정의서는 짧고 간결해야한다.
범위 설정은 시스템이 해결할 수 있는 모든 일을 상상하여 리스트를 작성한다. 범위가 너무 넓다면 일부는 배제하고 범위가 너무 좁다면 시스템을 사용할 궁극적인 최상위 목표를 파악한다.
예를 들어 대학 수강신청 시스템의 목표는 원할한 수강 신청이다.
요구사항 추출
요구사항은 제안된 시스템이 무엇을 하는가를 나타낸 문장으로 고객의 문제가 적절히 해결되기 위하여 관련자들이 동의한 것이다.
요구사항은 짧고 간결한 정보로 표현한다.(단순 명료한 그림이나 문장)
요구사항은 시스템이 무엇을 하는가를 나타낸다(시스템이 수행할 작업 기술)
요구사항은 관련자 모두가 동의한 것이다.( 관련자 : 사용자, 고객, 개발자, 관리자)
요구사항은 고객의 문제를 해결하기 위한 것이다.
이러한 요구사항을 모아놓은 것이 요구사항 문서이다.
요구사항에는 기능적 요구사항과 비기능적 요구사항이 있다. 기능적 요구사항은 시스템이 무엇을 하여야 하는가를 기술한 것으로 예를 들어 ATM 시스템은 현금인출, 잔액조회, 계좌 이체, 현금 서비스의 기능적 요구사항을 가진다.
비기능적 요구사항은 개발과정에 고수하여야할 제약 조건으로 성능, 효율, 반응시간, 소프트웨어 품질 특성에 대한 수준을 말한다.
비기능적 요구사항에서는 세가지 주요 유형이 있다.
1. 소프트웨어 품질 측면 : 소프트웨어는 반응 시간(탐색 결과 1초 이내), 처리량,(분당 처리 트랜잭션수) 자원 사용량(시스템이 사용하는 최대 용량)의 측면에서 우수해야하며, 소프트웨어는 신뢰할만 해야한다. 신뢰성이란 시스템이 고장없이 동작할 가능성이다. 또한 소프트웨어는 가용해야한다. 가용성은 시스템이 항상 실행되고 준비된 상태에 있는 시간으로 다운타임(DT(Downtime))이 길면 사용시간이 줄어들기 때문에 이 다운타임이 1분이내여야한다. 또한 고장에서의 회복이 가능해야하고 유지보수성과 확장이 가능해야하며 재사용성이 가능해야한다.
2. 시스템의 환경과 기술적 측면: 우리 마음대로 개발하는 데는 한계가 있다. 사용되는 기술에는 전자 정부 표준 프레임에 맞게 해야 한다. 플랫폼은 시스템이 동작하는 HW, OS 로 생각한다.
3. 프로젝트 계획과 개발 방법에 관한 측면: 사용하는 개발 프로세스에 대한 방법론과 비용, 납기일들이 포함될 수 있다. ( 비용 및 납기일은 시스템 개발 계약서나 별도의 프로젝트 계획서에 명시되어있어야함)
요구사항 추출방법
요구사항을 효과적으로 추출하고 분석하기 위해 체계화된 기술을 사용하자 .
1. 관찰
문서를 읽고 사용자와 함께 요구사항에 대해 논의한다. 잠재적인 사용자들이 수행하는 복잡한 일을 관찰한다. 이때, 사용자가 하는 일을 자세히 설명해 달라고 요청할 수 있다. 비디오 촬영을 해도 된다. 관찰은 많은 시간이 소요된다.
2. 인터뷰
인터뷰는 미리 잘 계획해야지 많은 정보를 얻을 수 있다. 가능하면 많은 당사자와 인터뷰를 진행한다. 인터뷰 시 관련자 이외의 사람과도 인터뷰를 진행하는 것이 좋다. 예를 들면 경쟁 제품 사용자나 마케팅 담당자 등이 있다. 인터뷰는 여유 시간을 할애해야한다.
인터뷰 절차는 { 대상자 선정 -> 일정 계획 -> 질문 작성 -> 인터뷰 -> 분석 및 정리} 의 절차를 가진다. 인터뷰는 (1) 최대, 최소, 예외 규칙, 예상되는 변동 등 자세한 사항까지 질문한다. 예를 들어 업무 프로세스를 구성하는 각단계가 무엇인지, 단계 개수의 변경 여부를 묻고, 설계 단계에서의 확장 가능성을 묻는다. 육하원칙(누가, 언제, 어디서, 무엇을, 왜 , 어떻게) 을 적용해야한다. 그리고 관련자에게 (2) 시스템에 대한 미래 비전을 질문한다. 예를 들어 어떤 융통성을 가져야 할지, 다른 차선의 방법이 있는지, 개발 측이 가지고 있는 대안에 대해 어떻게 생각하는지와 같은 질문이 있다. 또, (3) 문제에 대해 최소한의 허용 가능한 솔루션이 무엇인지 질문한다. 너무 많은 아이디어를 얻으면 사용되지 않을 기능을 생성할 수 있다. 이 때 고객과 사용자가 기본적으로 필요한 것이 무엇인지 확인한다.
그리고 (4) 다른 정보원에 대해 요청한다. 보고 싶은 문서를 요청하거나 유용한 지식을 지닌 다른 사람을 소개해달라 요청한다.
(5) 다이어그램 작성을 요구한다. 다이어그램을 통해 정보의 흐름, 명령의 순서, 기술이 어떻게 작용하는지 등을 파악한다. 다이어그램은 정보 수집을 촉진하는 좋은 툴이다.
3. 브레인스토밍
브레인스토밍은 아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의이다. 훈련된 요원이 주재를 하는 것이 좋다. 토론보다는 아이디어를 쏟아내는 회의에 가깝고 익명성이 보장된다.
JAD( Joint Application Development)
- 최종 사용자와 개발자가 시스템 개발 논의, 격리된 장소에서 개발자는 고객과 사용자르 ㄹ만나 요구사항을 정의하기 위해 공동 작업, 집중 브레인스토밍 세션, 요구사항 분석에 필요한 기간을 획기적으로 단축 가능
브레인스토밍 과정
4번 단계에서 토론을 유도핢 질문에는 예를 들어 "이 시스템에서 중요한 기능은 무엇인가?" " 이 시스템에 포함되어야 할 기능은 무엇인가?" " 미래에 어디서 새로운 자료가 발생할 것으로 예상되는가?" "시스템에서 어떤 출력이 생성되어야하는가?" "도메인 모델에서 어떤 클래스가 필요한가?" "고려하지 않을 이슈는 무엇인가?" "이 프로젝트의 리스크는 무엇인가?" 등이 있다.
4. 프로토타이핑
프로토타입은 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램이다. 가장 단순한 형태로는 paper prototype 이 있다. 페이퍼 프로토타입은 사용자 인터페이스를 종이에 그리고 시스템의 화면을 순서대로 사용자에게 보여주는 형태이다. 아이디어 추출, 피드백 받기에 적합하다. 다수의 개발자가 시스템에 대한 자신의 관점을 병행하여 작성하고 결과를 평가한다.
가장흔한 형태는 mock-up ot the UI 이다. 이것은 프로토타이핑 전용 언어로 작성된다. 컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가한다.
시스템의 특별한 측면을 프로토타이핑 하기도 한다. 예를들어 알고리즘과 데이터베이스가 있다.
5. 요구사항 문서화
요구사항을 문서화한다. 이 요구사항 문서는 두개의 극단적인 형태가 존재한다. 우선 몇 문단의 글이나 다이어그램으로 요구사항의 아우트라인을 정의한 것으로 요구사항 정의라고 한다. 다음은 수천 페이지의 복잡하고 자세한 명세 리스트로 요구사항 명세서라고 한다.
대규모 시스템을 위한 요구사항 문서는 계층적으로 정리한다.
요구사항 문서를 얼마나 자세히 기술하여야 하는가는 다음 사항을 고려하여 결정한다.
- 시스템의 크기, 다른 시스템에 대한 인터페이스 요구(통신 프로토콜), 목표로 하는 독자(일반 사용자, 전문인), 개발을 위한 계약(외주 계약 , 정부 기고나 계약), 요구 사항 취합 단계(초기 단계 - 시스템이나 서브시스템 개요 간략), 도메인 및 기술에 대한 경험 수준, 요구사항의 오류로 인한 손해 비용
요구사항 문서의 구성
요구사항 검토
요구사항을 검토할 때는 각 요구사항이 다음을 만족하는지 검토한다.
요구사항의 변경 관리
요구사항은 계속 바뀐다. 비즈니스 프로세스가 변경될 수도 있고, 기술이 변경될 수도 있고 문제 이해가 향상될 수도 있다. 이렇게 요구사항을 변경할 시 고려할 사항들이 있다.
요구사항 변경 시 고객 및 사용자와 지속적인 상호작용을 해야한다. 변경으로 인한 이익이 변경 비용을 초과하여야한다. 작은 변화는 적은 비용으로 빠르고 신속하게 가능하나 대규모 변화는 신중하게 접근해야한다. 어떤 변경은 위장된 확장이 가능성일 수도 있다는 점을 인지한다. 변경인지 확장인지를 잘 구분해야한다. 변경이 위장된 확장이어서는 안된다. 시스템 확장은 못하나요? 라는 질문이 있을 수도 있는데 확장은 이미 시스템이 작동하는데 기존 시스템에 새로운 요구사항을 추가하는 것이며 지금은 A라는 소프트웨어 개발하는데 B로 변경하는 문제이므로 확장과 개발은 다르다. 지금은 시스템의 규모를 키우는 것은 피하고 오직 더 좋은 시스템이 되도록 노력한다.