[요구사항 공학] 요구사항 분석하기 (4)(마지막) - 요구사항에 근거한 평가

 요구사항에 근거한 평가

 

소프트웨어 프로젝트 팀들은 프로젝트 수행에 요구되는 노력, 시간 비용을 산정해야 한다. 이런 평가 작업은 특별한 해법도 존재하지 않는 골치아픈 과정이다. 여기서는 몇 가지 평가 접근 방법과 요구사항에 기초한 평가를 생성하는 세가지 기법을 소개한다.

 

 

평가의 몇 가지 기본원칙

평가란 주어진 정보와 지식, 특정 시점에서의 조건들을 바탕으로 하는 미래에 대한 예측이다. 예측이기 때문에 불확실성을 항상 포함한다. 프로젝트 관계자들은 프로젝트 초기에 정확한 평가를 요구하지만 이것은 불가능하다.

 

 

[그림1 - 요구사항 평가]

그림에서 보는 것과 같이 프로젝트를 완료할 확율은 5개월 이내는 10%이고, 10개월 이내는 30%이며 15개월에서야 비로소 80%이상이된다. 프로젝트 관리자에서 10개월이면 됩니다. 이렇게 콕 찍어서 말하자 마라. 만약 정확히 언제쯤 제품을 출시할 수 있을지 평가하여야 한다면 평가의 불확실성에 대한 완충치를 포함시켜야 한다.

 

평가 접근 방법

상향식 (Bottom-up) : 각각 개별 요소의 요구사항, 임무, 작업내역 상의 납품물 또는 클래스, 프로그램 모듈, 테스트 케이스와 같은 항목의 개수를 정하고 이것을 모아서 평가한다. 이때 MS Project같은 툴을 이용해서 많이 했다.

 

하향식 (Top-down) : 제품이나 프로젝트에 대한 전반적인 설명으로 부터 시작한다. 평가자는 유사 프로젝트 경험에 기초하여 전체 프로젝트를 수행함에 있어서 무엇이 필요한지 판단한다. 이 같은 전반적인 평가를  근간으로 하여 하부 컴포넌트 크기 각 개별 요소개발에 필요한 노력, 시간, 비용등을 평가하게 된다.

 

비용 모델 : 많은 상용 평가 도구들을 이용할 수 있다. 뭔가 복잡한 모양이다. 제품 마다 프로젝트로 부터 파생된 알고리즘을 이용한다. 팀을 두 배로 꾸린다고 해서 일정이 절반으로 줄어들진 않는다.

 

전문가 의견 : 유사 프로젝트를 진행해온 전문가들로 부터 평가를 받는것이다.

 

유추 : 기존 프로젝트와 신규 프로젝트를 비교해서 지난번 프로젝트와 크기가 비슷한가? 지난번과 확연히 다른 차이점이 있는가?

여러 가지를 판단하여 일정, 기간, 인력을 산정한다.

 

광대역 델파이 방식 : 한 그룹의 평가관들을 포함하는데 이들은 독립적으로 기초 평가를 하고, 그런 다음 모두의 지식을 수용하여 가능한 범위의 평가 결과를 얻기 위해 반복적으로 의견을 수렴을 진행한다. 여러명이 진행하므로 한명이 판단하는 것보다 위험요소를 제거할 수 있다. 그러나 시간이 많이 걸릴 수 있겠다.

 

평가가 목적이 아니다.

평가의 목적은 그에 상응하는 노력, 비용, 시간, 구성원을 결정하는 것이라고 설명한다. 하지만 때론 평가는 다른 의미를 갖기도 한다. 만일 제품 납품일자가 절대로 변경 불가능하도록 제한된 경우, 이에 대한 평가 요소는 고정된 일정 안에 요구되는 품질의 기능이 어느 정도 제공될 수 있느냐가 된다. 관리적으로 설정된 일정이나 마케팅 측면에서 설정된 납품 일정은 평가가 아니라는 것을 반드시 인식 시켜야 한다. 이것은 목표이다. 일정 크기와 기술 수준을 겸비한 팀만이 고정된 일정 내에 고품질의 기능을 만들어 낼 수 있다.

 

[요구사항 공학] 요구사항 분석하기 (3) - 보다 나은 요구사항의 비즈니스 가치

보다 나은 요구사항의 비즈니스 가치

잘만들어진 요구사항은 어떤 가치를 가질까?

 

모든 관리자들이 요구사항 개발이 요구사항 개발이나 관리에 대한 개선의 필요성을 인정하고 있지는 않다. Standish 그룹의 "CHAOS Reports"에서 지적하고 있는 프로젝트를 망치거나 힘들게 하는 세 가지 가장 큰 요인은 다음과 같다.

• 사용자 제공 정보의 부족
• 불완전한 요구사항 및 명세서
• 변화하는 요구사항 및 명세서

e-비즈니스에서의 성공 위협 요소

• 불안정하고 계속해서 변화하는 요구사항 ( 66% )
• 미숙한 요구사항 명세 (55% )
• 승인 지연, 요구사항 변경, 부족한 의사소통 등과 같은 고객의 행위(42%)

          [표] 요구사항 결함의 상대적인 수정 비용

오류 발견 시점	상대적인 수정 비용 (배수)
요구사항 개발	1
실계	2 - 3
구현	5- 10
시스템/수락 시험	8 - 20
운용	68 - 110

보다 나은 요구사항의 효과

- 회사에서 진행할 여러가지 프로젝트 중에서 우선적으로 수행할 수 있도록 결정하는 자료가된다.

- 프로젝트를 수행함에 있어서 필요한 자원이 노력의 정도를 가늠할 수 있다.

- 시간에 쫒기는 프로젝트에서 구현해야 할 기능에 대한 우선 순위를 결정할 수 있다.

- 제품 설계에 기초가 된다.

- 시스템 테스트의 기준이 된다.

 

• 15개의 뱅킹 및 통신 프로젝트에 관한 연구 결과 이 중 가장 성공적인 프로젝트의 경우 요구사항 공학에 28%에 달하는 프로젝트 자원을 할당한 반면 평균치는 15.7%에 머물고 있다. (Hofmann과 Lehner 2001)
• NASA 프로젝트에서는 요구사항 개발에 대한 예산 비율을 높임으로써 비용과 일정 모든 면에서 초과나 지연이 줄어들었다.(Hooks와 Farry 2001)

좋은 요구사항은 몇가지 측면에서 개발을 가속화 할 수 있다. 제품 결과물을 정의함으로써 관계자들은 공동의 비전, 목표 및 기대를 공유할 수 있다. 문제점은 일찍 발견하고 고칠수록 수정 비용이 적게 든다.

 

요구사항을 얻는데 소요되는 기간

시스템의 요구사항을 얻은데 얼마의 시간이 소요될까?

여러 사람이 이에 대해 벤치 마킹을 해서 자료를 냈으나, 근거 요소가 너무 부족하여 자료로 활용하지는 않는것이 좋겠다. 다만 아래에 프로젝트 진행요소에서 기간이 단축되는 경우와 기간이 연장되는 경우를 알아보자.

여러 프로젝트를 진행하다 보면 "뭔가 잘못됐는데, 이러면 안되는데..." 고개를 갸우뚱 거릴 때가 있다.

이러한 느낌은 나만 느끼는것이 아니라, 프로젝트에 관계된 모든 사람이 느끼는 것으로 향후 프로젝트는 실패할 확률이 굉장히 커진다. 이때 누군가 이러한 요소를 해결해 준다면 프로젝트는 조기에 정상으로 회복되고 기간도 줄어들 것이다.

 

"기간 단축"

• 고도로 훈련되고 숙달된 분석가
• 적합한 사용자 대표에 의한 광범위한 고객 참여
• 과거 프로젝트 자원의 재활용
• 재빨리 질의에 응답해 주는 고객 대표자
• 명확하고 안정된 비전과 범위
• 응용프로그램 영역에 숙달된 개발자
• 구식 응용프로그램 교체
• 불명확함과 실수를 제거하기 위한 효과적은 점증 동료 검토

"기간 연장"

• 생소한 프로젝트 또는 응용프로그램 영역
• 이해 당사자들과의 지리적인 분리
• 프로젝트 참여자들 간의 언어 장벽
• 형편없는 의사 결정 프로세스
• 대규모 프로젝트
• 많거나 다양한 사용자 계층
• 소프트웨어 개발과 비지니스 프로세스 수정의 병행
• 외부 의존 요소 및 불확실성
• 하드웨어와 소프트웨어 컴포넌트 사이의 복잡한 상호작용
• 요구사항 개발 프로세스의 부재

요즘은 폭포수모델을 이용해서 개발하기 보다는 점증적 방법을 많이 사용한다.

점증적 방법은 개발 기간동안 계속해서 욕구사항 개발이 포함된다.

 

 

요구사항 유도 계획하기

요구사항 개발 역시 보이는 것 이상으로 많은 것이  내재해 있다. 분석가가 수해하여야 할 업무를 식별하고 있다면 다음에 나열된 활동들이 필요한지에 대해 고려해보자.

• 제품 챔피언(각 업무의 대표자)들과 책임에 대해 협상
• 요구사항 유도 워크숍을 개최하고 검토 작업 진행
• 기존 문서와 제품 검토
• 설문 조사의 준비, 배포, 분석 작업
• 프로토타입, 분석 모델, 기타 요구사항 조사 작업 생성과 평가
• 가능성, 위험도, 안정성, 실패 및 위해 요소에 대한 분석 수행
• 요구사항 정보의 데이터 베이스 입력작업
• 요구사항 명세 검토
• 요구사항으로부터 테스트 케이스 생성 및 테스트 케이스 검증
• 검토나 테스트 분석에 따른 요구사항 명세 수정 보완

여러분의 팀에서는 프로젝트에 대해 요구사항 유도, 분석, 명세 및 검증 작업의 일환으로 위의 모든 활동을 수행하지 않을 수도 있고, 다른 작업을 수행해야 할 수도 있다. 분석가의 실제 업무에 대한 사항들과 이 업무들의 수행 시기에 대한 지식은 앞으로 수행하게 될 프로젝트에서 요구사항 개발 노력을 평가할 수 있는 능력을 향상시켜 줄 것이다.

 

고객들은 프로젝트 발주와 동시에 결과를 보려고 안달한다. 과연 이들과 함께 요구사항을 도출하는 길고 어려운 과정을 지날 수 있는 좋은 방법은 무엇일까?

[요구사항 공학] 요구사항 분석하기 (2) - 소프트웨어 요구사항에 대한 일반적인 진리

 소프트웨어 요구사항에 대한 일반적인 진리

 

컨설턴트라면 누구나 알고 있듯이 소프트웨어에 대한 거의 모든 질문에 대한 정확한 대답은 "그때 그때 달라요"이다.

이 말이 단순히 컨설턴트의 변명이라고만 할 수  없다. 주어진 상황에 대한 최선의 대처법에 대한 조언은 프로젝트 성격, 제한사항, 조직이나 팀 내 문화, 비즈니스 환경 등에 따라 달라진다. 그렇다고 고객의 질문에 그렇게 답할 수는 없다. 그래서 요구사항의 "보편적 진리"들과 이들이 실제 요구사항 분석가 훈련 시에 어떤 의미를 갖는지 설명하도록 하겠다.

 

[요구사항 실체]

 

일반적인 진리 #1 : 제대로 된 요구사항을 얻지 못한다면, 그 이후에 프로젝트를 얼마나 잘 수행하느냐는 논할 가치도 없다.

요구사항은 뒤따르는 모든 포르젝트 업무의 토대이다.

 

일반적인 진리 #2 : 요구사항 개발은 단순히 수집하는 과정일 뿐만 아니라 탐색하고 창조하는 과정이다.

요구사항은 주변에 가만이 떨어져있는 꽃처럼 줍기만 하면 되거나 분석가가 사용자의 머릿속에서 빨아내기만 하면 되는 것으로 보인다. 분석가는 단순히 고객이 말하는 것을 받아쓰는 사람이 아니다. 분석가는 고객이 보다 활발하게 생각하고 의견을 낼 수 있도록 유도하는 사람이다.  "고객님 시스템이 XYZ 기능을 제공한다면 어떤 도움이 될까요?"와 같이 숨은 요구사항을 탐색할 수 있어야 한다.

 

일반적인 진리 #3 : 변경은 발생하게 되어 있다.

요구사항은 변할 것이라는 것은 불을 보듯 뻔한 사실이다. 시장이 변하고, 정부의 규제, 업무 규칙, 운영 환경이 변하기 때문에 수시로 변화한다. 그래서 "요구사항 변경관리"가 필요하다. 그러나 요구사항이 합의된 후에도 변경사항이 예상외로 많으면 충분한 유도작업을 하지 못했거나, 고객과 합의가 불충분 하다는 것이다. 모든 개발팀은 요청된 변경에 대해 누가 평가하고 결정권을 가지며 거부권을 갖게될지 결정해야 한다. 이러한 기능을 수행하는 그룹을 보통 변경통제위원회(CCB: Change Control Board)라고 한다. 프로젝트를 진행하면서 계획보다 규모가 커지는데, 요구사항의 증가는 월 1~3%한다. 따라서 프로젝트 일정에 불확실성에 대비한 여유시간(관리용 예비)을 넣어 두어야 한다. 만약 이 시간이 없으면 변경이 발생할 경우 처리가 어렵다.

 

이러한 문제는 애자일 개발방법론, 나선형 모델, 반복 프로토타이핑, 발전적 출시 및 점진적 접근법을 이용해 개선할 수 있다.

 

[요구사항 이해 관계자]

일반적인 진실 #4 : 모든 프로젝트 관계자들의 관심사들은 요구사항 프로세스 내에서 서로 교차한다.

컨설턴트 Time Lister는 프로젝트의 성공을 "핵심 관계자들의 기대치에 상응하는 모든 요구사항과 조건 세트를 만족하는 것"으로 정의 한 바 있다. 이해관계자는 개인 또는 그룹을 의미하며, 적극적으로 프로젝트에 개입하고 프로젝트에 의해 영향을 받거나 프로젝트산출물에 영향을 미칠수 있는 사람이다. 요구사항 분석가는 의사소통의 중심에 위치하며 모든 이해관계자들의 상호작용 할 책임이 있다. 더 나아가 분석가는 시스템 아키텍트와 함께 시스템이 모든 관계자들이 사용할 수 있게 정의되고 있는지 감독할 의무를 가지고 있다.

 

프로젝트 사작과 함께 핵심 관계자 그룹과 각 그룹의 대표자들을 식별하도록 한다. 반드시 충족되어야 하는 관심사들 간에 혼선이 있을 때 이들에게 의존할 수 있다.   그들 모두가 서로 상대에 대한 거부권을 가지고 있을 수는 없다. 재빨리 이런 혼란을 처리할 수 있는 결정권자를 찾아내어야 한다.   Christian Fahlbusch "보통 하나의 프로젝트에 한 명의 최고 결정권자가 있으며, 종종 핵심 스폰서가 이에 해당된다. 나는 그 사람을 찾아내기 전에는 맘 편히 쉴 수도 없을 것이고, 항상 그가 프로젝트 진행 상황을 알고 있게 할 것이다."

 

 

일반적인 진리 #5 : 고객 참여는 소프트웨어 품질에 가장 크게 기여하는 요소이다.

요구사항은 변할 것이라는 것은 불을 보듯 뻔한 사실이다. 시장이 변하고, 정부의 규제, 업무 규칙, 운영 환경이 변하기 때문에 수

부적절한 고객 참여가 소프트웨어 프로젝트를 실패로 이끈다.

• 사용자 계층의 식별 : 고객들은 관계자의 일부이고 사용자들은 고객의 일부이다. 누락된 사용자 그룹이 있다면 출시된 제품에 실망하는 사람들이 나타나게 될 것이다.
• 제품 챔피언 선택 : 각 고객 계층의 목소리를 대변할 사람을 결정할 필요가 있다. 이들을 제품 챔피언이라 부르고 이들은 그들이 속한 사용자 분류의 대표이다.
• 프로토 타입 제작 : 프로토 타입은 사용자 대표자들이 궁극적인 시스템의 시뮬레이션 또는 그 일부를 이용해 비교해 볼 수 있는 기능을 제공한다. 요구사항 명세서와 비교하면 훨씬 현실적이긴 하지만, 상세 요구사항의 문서화에 대한 대안이 될 수 없다. 반드시 문서를 작성하라.
• 고객 권리와 책임에 대한 합의 : 반드시 함께 일해야 하는 사람들은 협업에 관해 잘 논의 하지 않는다. 분석가는 프로젝트 초기에 고객 대표자들과 합의를 통해 요구사항 프로세스 측면에서 각 측의 책임 소재를 명확히 하여야 한다. 이와  같은 합의에 기초한 협업 정책은 참가자들 모두에게 이익이 되는 매우 강력한 수단이다.

일반적인 진리 #6 : 고객이 항상 옳은 것은 아니지만 항상 그에 따른 의미는 있다.

고객이 항상 옳은 것은 아닐 수 있지만 분석가는 이 과정에서 고객이 제품의 대해 요청하고 있는 본질은 무엇인지에 대해 파악하고 의견을 존중해야 할 필요가 있다. 다음은 고객이 잘못 된 경우의 대표적인 몇가지 예이다.

• 요구사항의 겉치레에 대한 솔루션을 제시하는 경우
• 요구사항 우선순위를 망치거나 우선권을 갖기 위해 큰소리치는 경우
• 비즈니스 규칙이나 다른 제한 사항에 ㄷ해 논의하지 않거나 회피하는 경우
• 비즈니스 프로세스 변경들을 처리하기 위해 새로운 소프트웨어 시스템을 요구하는 경우
• 요구사항 유도 작업에 적합한 사용자 대표를 참여시키지 않는 경우
• 분석가나 개발자가 제기한 문제에 대한 올바른 결정을 내리지 못하는 경우
• 기능/비기능 요구사항에 대한 조율의 필요성을 받아들이지 못하는 경우
• 불가능한 책임을 요구하는 겨웅
• 변경에 따른 비용을 수용하지 않는 경우

이러한 고객과는 일을하면 안되는 건가?

 

[요구사항 명세]

일반적인 진리 #7 : 새로이 제시된 요구사항에 대해 분석가가 가장 먼저 던져야 할 질문은 "이 요구사항이 개발 범위 내에 있는 사항입니까?" 이다.

범위 문제를 제어하기 위해서는 프로젝트 관계자들이 범위 정의 즉 주어진 제품 릴리즈를 위한 범위 내에 가능한 기능들과 그렇지 않은 것들에 대한 경계에 동의하도록 하여야 한다. 그런다름 새로운 요구사항에 대해 "범위내에 있는 것인가요?"

어떤 특정 요구사항이 처음에는 범위 밖에었다가 이후에 포함되기도 하고 다시 범위 밖으로 제외되는 등의 혼란이 발생한다면 프로젝트 범위 경계가 제댈 확립되지 못함을 뜻하는 증상으로 범위 혼란 문제에 봉착할 가능성을 시사한다.

 

일반적인 진리 #8 : 아무리 뛰어난 요구사항 문서도 사람 사이의 대화를 대신 할 수 없고 또 그래서도 안된다.

제아무리 최고의 요구사항 명세서라고 해도 개발자와 테스터의 업무를 수행하는데 필요한 모든 정보를 담고 있을 수는 없다. 옳건 그르건 관계자들 사이에 암묵적으로 당연시되는 항목들이 있게 마련이다. 명확한 항목은 반드시 SRS에 명기되어야 한다.

사용자 대표자들이나 다른 의사 결정권들과의 잦은 협의가 불가능할 경우 요구사항 명세서는 보다 상세할 필요가 있다.

 

일반적인 진리 #9 : 요구사항이 모호할지도 모르지만 제품은 명확할 것이다.

요구사항을 완벽하게 정의하는 것은 너무나도 어렵다. 무엇인가 새로운 것을 만들고 있는  중인데, 그 누구도 이 제품이 어떻게 되어야 하며 또 어떤 기능을 해야 하는지 모르고 있다. 대로 모호한 요구사항에 만족해한다. 그렇다고 개발자가 모호한 요구사항에 대해 마음대로 구현하면 안된다. 모호함을 인지하고 프로토타이핑과 같은 방법을 동원하여 구체화시키도록 노력한다. 요구사항을 명세하는데 도움이 될만한 방법은 적합성 기준(fit criteria)을 정의하는 방법인데, 이렇게 함으로써 사용자나 테스터는 이 기준에 의거하여 해당 요구사항이 적절하게 의도대로 구현되었는지 판단할 수 있다.

 

일반적인 진리 #10 : 완벽한 요구사항은 없다.

요구사항은 끝나거나 완료되지 않는다. 빠뜨린 요구사항이 없다는 것을 확인하는 방법은 없으며 분석가가 기록할 필요성을 느끼지 못해 빼먹는 요구사항은 항상 있게 마련이다. 요구사항에 대해 "완성본"이라고 표기하기보다는 특정 시점에서 [베이스라인]을 작성하도록 한다. 일단 베이스라인이 준비되면 요구사항을 변경할 때는 변경 제어 프로세스 따르고 변경에 따른 영향성을 인식하도록 한다.

 

완벽한 SRS를 작성했다고 해서 프로젝트가 성공하는 것이 아니다. 현실적인 관점에서 요구사항 개발이란 설계를 진행하거나 구현하고 테스트할만한 정도의 위험성 범위를 만족하는 수준의 요구사항을 이끌어 내는 것이다. 여기서 위험성이란 큰 비용이 소요되고 필요 없는 재작업이 투입되어야 하는 경우의 가능성이다. 자신의 작업에 근간을 이루는 요구사항에 대해서는 해당 팀원이 직접 검토하도록 하여 이어지는 작업에 혼선이 없도록 한다. 고품질의 요구사항을 추구할 때 항상 "충분한 괜찮은 수준"이라는 실용적인 목표를 머릿속에 간직하도록 하라.

[요구사항 공학] 요구사항 분석하기 (1) - 실용적인 소프트웨어 요구사항

 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 요구사항 공학의 구성 요소들]

 

요구사항이 완벽해야 설계 및 코딩을 해야 하는 것은 아니다. 요구사항은 계속해서 바뀌기 때문에 변경되는 부분을 잘 관리하고 제품이 대응하도록 하는 것이 중요하다.