MORE ABOUT SOFTWARE REQUIREMENTS
"실용적인 소프트웨어 요구사항" 칼 위거스 저, 김도균 역
------------------------------------------------------------------------------
"요구사항" 정의
요구사항이란, 무엇이 구현되어야 하는가에 대한 명세이다. 요구사항은 시스템이 어떻게 동작하여야 하는지 또는 시스템 특징이나 속성들에 대한 설명이다. 요구사항은 시스템 개발 프로세스 상의 제한 사항일 수도 있다.
from 칼 위거스
나는 체계적으로 요구사항을 분석했을 때 과연 프로젝트 진행에 어떠한 효과를 볼 수 있는지 알아보고 싶다.
또한 스크럼과 XP를 이용해서 진행하려고 하는데 여기서는 "요구사항" 분석이 중요하다고 나와있었고 어떻게 하는지는
나와있지 않아서 관련책을 보고 있다.
[그림1 요구사항 다이어그램]
[비지니스 요구사항]
비지니스 요구사항(Business Requrements)은 "왜(Why)"에 해당하는 정보를 나타낸다고 보면된다. 비지니스 요구사항은 왜 해당 조직에서 프로젝트를 수행하는지를 설명하며, 개발 조직이나 조직의 고객이 제품을 개발함으로써 얻을 수 있는 이득에 대해서도 언급한다. 필자는 주로 비전과 범위(Vision and scope) 문서에 비즈니스 요구사항을 기록한다. 어떤 조직들에서는 이러한 목적으로 비지니스 강령, 게이스 또는 마케팅 요구사항 문서를 작성하기도 한다.
[사용자 요구사항]
사용자 요구사항(User Requirements)은 "무엇(What)"에 해당하는 정보를 나타내는 하나의 형태이다. 사용자 요구사항은 사용자가 제품을 이용하여 할 수 있는 "무엇"을 설명하며 사용자들이 수행하려는 업무를 예를 들 수 있다. 유즈케이스(Use cases), 시나리오(Scenarios), 사용자 스토리(User stories), 이벤트-응답표(Event-response tables) 등의 방법으로 사용자 요구사항을 표현할 수 있다. 유스케이스를 개발하고 있다면, 이들을 유스케이스 문서에 기록할 수 있다. 분석가들 중에는 유스케이스 명세를 소프트웨어 요구사항 명세서(SRS:Software Requirements Specification)에 포함시키는 것을 선호 하는 이들도 있다.
[기능 요구사항]
기능 요구사항(Functional Requirements)은 또 다른 "무엇"에 관한 정보를 나타내는 형태이며 개발자가 개발하여야 하는 것에 대해 기술한다. 때로 행위 요구사항(Behavior Requirements)이라고 부르기도 하며, 전통적으로 "~ 해야한다(shall)" 구문으로 표현되어 시스템이 반드시 수행하여야 하거나 시스템을 이용하여 사용자가 반드시 할 수 있어야 하는 것들에 관한 것이다.
기능 요구사항 및 기타 요구사항들은 소프트웨어 요구사항 명세서(SRS)상의 한 부분을 차지하게 된다. SRS는 분석가가 개발자, 테스터 및 주요 프로젝트 관련자들과 상세 요구사항 정보를 공유하는데 이용하는 중심이 되는 산출물이다.
[그림 1] 에서 화살표들이 이 세 단계의 요구사항들 사이에서 좌측 상단으로부터 우측하단으로 향하고 있다는 사실은 매우 중요하다. 제품에서 구현하려는 정확한 기능 세트를 명기함으로써 사용자들은 업무를 완수하고 목적을 달정하게 되며, 즉 비즈니스 요구사항을 만족하게 된다.
[시스템 요구사항]
여기서 말하고자 하는 시스템 요구사항은 어떤 오래된 정보 시스템을 위한 요구사항이 아니다. 필자는 "시스템 요구사항(또는 제품 요구사항)" 이라는 용어를 여러개의 서브시스템으로 구성되는 제품에 대한 최상위 요구사항을 설명하기 위해 사용한다. 요구사항 분석가는 전체 시스템에 대한 상위 요구사항에 대한 이해로부터 특정 기능 요구사항들을 생성해 낼 수 도 있다. 시스템은 소프트웨어 컴포넌트들만으로 구성될 수 있으며, 또는 소프트웨어, 하드웨어 서브시스템 두 가지 모두를 포함할 수 있다. 사람들 역시 시스템의 한 부분이다. 따라서 특정 시스템 기능들은 사람들에게 할당될 수도 있다. 소프트웨어 요구사항들은 시스템을 구성하는 소프트웨어 컴포넌트들에 할당된 기능/비기능 요구사항 부분을 나타낸다.
이와 같은 의미에서 시스템의 좋은 예로 수퍼마켓의 계산대를 들 수 있다. 계산대는 대개 저울과 연동되는 바코드 스캐너를 포함하고 있으며, 하나의 키보드와 하나 또는 두 개의 디스플레이 장치와 연결되어 있다. 고객의 신용카드 또는 직불카드 인식기, 그리고 종종 잔돈 지급기를 역시 포함하고 있다. 필자가 본 바로 최대 3개의 프린터가 있으며 이들은 고객 거래 영수증, 신용카드 지불 전표, 쿠폰 등을 출력하기 휘해 사용된다. 이 컴포넌트들은 서로 연동되고 각 컴포넌트들은 전체 시스템의 전체 기능 중 특정 부분을 구현하고 있는 셈이다.
때로 사람들은 시스템 요구사항을 제품의 특징으로 기술하곤 한다. 필자는 특징(feature)을 논리적으로 관계를 가지고 있는 기능 요구사항들의 세트로 정의하며, 사용자에게 하나의 기능을 제공하고 하나의 비즈니스 목표를 만족시키는 역할을 한다. 특징을 조사하는 것은 사용자의 목적에 기반해서 사용자 요구사항을 검토하는 것과는 매우 다른 것이다. 이상적으로 제품에 포함된 특징들은 사용자들이 제품을 이용하여 기존 작업 또는 예상된 작업을 수행할 수 있도록 할 것이다. 하지만 사용 제품의 경우 경쟁에서 이기기 위해 또는 시장을 이끌기 위해 특징을 포함시키기도 한다.
[비즈니스 규칙]
비즈니스 규칙은 회사 정책, 정부 법규, 산업 표준, 연산 알고리즘 등을 포함한다. 비즈니스 규칙은 그 자체가 소프트웨어 요구사항이 되지는 못한다. 통상 어떤 특정 소프트웨어 시스템의 경계 밖에 존재하며, 따라서 기획 단계에서 의미를 갖는 항목으로 고려되어야 한다. 그러나 때로 비즈니스 규칙은 시스템이 해당 규칙을 따르고 있는지 확실히 하기 위해 특정 기능의 구현을 요구한다. 비즈니스 규칙은 특정 유스케이스를 수행할 수 있는 사람을 지정할 수 있고 보안과 같은 품질 분야에 영향을 미칠 수도 있다. 일부 비즈니스 규칙은 데이터값들, 시스템 상태, 조건 또는 사용자 정의 기준들의 특정 조합을 근간으로 내부 시스템 프로세싱을 제어하는데 사용될 수 있다. 특정 기능 요구사항은 어떤 비즈니스 규칙으로부터 파생되는지 추적할 수 있다.
[품질속성]
품질 속성들은 제품의 특징을 다양한 형태로 제품의 특징을 설명하고 있으며 사용자, 개발자, 유지보수 요원 모두에게 중요하다. 이와 같은 특징은 적용성, 성능, 사용성, 휴대성, 무결성, 효율성, 내구성 등을 포함하여 매우 다양하다. 때로 특징들은 품질 인자 또는 서비스 요구사항 품질로 불리기도 한다.
[외부 인터페이스]
시스템과 외부 세계 사이를 연결하는 외부 인터페이스는 비기능 요구사항의 또 다른 분류로 구성된다. 이들은 다른 소프트웨어 컴포넌트들, 하드웨어 장치들, 사용자들과의 인터페이스를 포함할 뿐만 아니라 통신 인터페이스, 타 시스템들과의 정보 교환에 이용되는 프로그램들도 여기에 해당된다.
[제약사항]
끝으로 설계 및 구현 제약사항이 남았는데 이것은 합당한 이유를 근거로 개발자들의 선택사항들에 제한을 가하는 것이다. 어떤 사람들은 모든 요구사항은 제한사항으로 고려되어야 한다고 하지만 이런 식으로 일반화하는 것은 그리 도움이 되지 못한다.
요구사항 공학 활동
요구사항 개발 :
식별, 합의 그리고 기능 요구사항과 제품 특징이 요구되는 비즈니스 목표에 부합되도록 하나의 세트로 기록하는 것
요구사항 관리 :
가장 중요한 목적은 특정 형태의 제품 출시를 위해 적용되어 온 합의된 요구사항 세트에 대한 변경사항을 관리하는 것
[그림 2 요구사항 공학의 구성 요소들]
요구사항이 완벽해야 설계 및 코딩을 해야 하는 것은 아니다. 요구사항은 계속해서 바뀌기 때문에 변경되는 부분을 잘 관리하고 제품이 대응하도록 하는 것이 중요하다.
댓글
댓글 쓰기