3장 기술 요구 사항

이 장에서는 기술 요구 사항 분석 중에 발생하는 일부 프로세스와 절차를 설명합니다.

기술 요구 사항 분석은 비즈니스 분석 단계에서 작성된 비즈니스 요구 사항 문서를 기준으로 시작됩니다. 비즈니스 요구 사항을 기반으로 사용하여 다음 단계를 수행합니다.

사용 사례는 설계 단계에서 논리 구조 설계의 기준으로도 사용됩니다. 논리 구조와 시스템 요구 사항은 함께 배포 시나리오를 구성하며, 이 배포 시나리오는 나중에 배포 설계 단계의 입력으로 사용됩니다.

다음 그림에서는 기술 요구 사항 단계를 비즈니스 분석, 논리 설계 및 배포 설계 단계와 비교하여 보여 줍니다.

비즈니스 분석에서와 마찬가지로 사용 분석, 사용 사례 및 시스템 요구 사항을 생성하는 기술 요구 사항 분석을 위한 마술 같은 공식은 없습니다. 기술 요구 사항 분석에는 비즈니스 영역, 비즈니스 목표 및 기본 시스템 기술에 대한 이해가 필요합니다.

사용 분석

사용 분석에서는 설계하려는 배포의 여러 사용자를 식별하고 이러한 사용자의 사용 패턴 결정합니다. 수집한 정보는 예상 로드 조건에 대한 개념을 제공하며 뒤에서 성능 요구 사항 및 기타 시스템 요구 사항을 결정하는 데 사용됩니다. 또한 사용 분석 정보는 사용 사례에 설명되어 있는 사용 사례에 가중치를 할당할 때 사용할 수 있습니다.

사용 분석 동안에는 가능하면 사용자를 인터뷰하고, 사용 패턴에 대한 기존 데이터를 조사하며, 이전 시스템의 설계자와 관리자도 인터뷰해야 합니다. 다음 표에서는 사용 분석을 수행할 때 고려해야 할 항목을 나열합니다.

표 3-1
사용 분석 항목
항목	설명
사용자 수 및 유형	배포에서 지원해야 할 사용자 수를 식별하고 필요하면 해당 사용자를 범주화합니다. 예를 들면 다음과 같습니다. B2C (기업-사용자) 배포에는 방문자가 많을 수 있지만, 비즈니스 트랜잭션에 등록 및 관여하는 사용자 수는 적습니다. B2E (기업-직원) 배포에서는 일반적으로 모든 직원을 수용해야 하지만, 일부만 회사 외부 네트워크에서의 액세스가 필요할 수 있습니다. B2E (기업-직원) 배포에서 관리자는 일반 직원이 액세스할 수 없는 영역에 대한 권한이 필요할 수 있습니다.
활성 및 비활성 사용자	활성 및 비활성 사용자의 사용 패턴과 비율을 식별합니다. 활성 사용자는 시스템에 로그인하여 시스템의 구성 요소와 상호 작용하는 사용자입니다. 비활성 사용자는 로그인하지 않았거나 로그인했지만 시스템의 구성 요소와 상호 작용하지 않는 사용자일 수 있습니다.
관리 권한이 있는 사용자	배포된 시스템을 액세스하는 배포를 모니터, 업데이트 및 지원하는 사용자를 식별합니다. 시스템 요구 사항에 영향을 미칠 수 있는 특정 관리 사용 패턴을 결정합니다. 방화벽 외부에서 배포 관리를 예로 들 수 있습니다.
사용 패턴	다양한 유형의 사용자가 시스템을 액세스하고 예상되는 사용의 대상을 제공하는 방법을 식별합니다. 예를 들면 다음과 같습니다. 사용이 급상승하는 최고 시간이 있습니까? 업무 시간은 언제입니까? 사용자가 전 세계에 분산되어 있습니까? 예상되는 사용자 연결 시간은 얼마입니까?
사용자 증가	사용자 기반 크기가 고정되어 있는지 또는 배포에서 사용자 수의 증가를 예상하는지 여부를 결정합니다. 사용자 기반이 증가할 것으로 예상되는 경우 이러한 증가를 합리적으로 예측해 봅니다.
사용자 트랜잭션	지원해야 할 사용자 트랜잭션 유형을 식별합니다. 이 사용자 트랜잭션을 사용 사례로 변환할 수 있습니다. 예를 들면 다음과 같습니다. 사용자가 수행할 작업은 무엇입니까? 사용자가 로그인하면 로그인한 상태로 남아 있습니까? 또는 대개 몇 가지 작업을 수행하고 로그아웃합니까? 공통 달력, 웹 회의실 및 내부 웹 페이지 배포가 필요한 사용자 간에 중요한 공동 작업이 있습니까?
사용자 연구 및 통계 데이터	기존 사용자 연구 및 기타 소스를 사용하여 사용자 동작 패턴을 결정합니다. 종종 기업이나 산업 조직에서는 사용자에 대한 유용한 정보를 추출할 수 있는 사용자 조사 연구를 수행합니다. 기존 응용 프로그램의 로그 파일에는 시스템 예측을 하는 데 유용한 통계 데이터가 포함되어 있을 수 있습니다.

사용 사례

사용 사례에서는 설계 중인 배포와 사용자 간의 일반적인 상호 작용을 모델링하여 최종 사용자 관점에서 전체 작업 흐름을 설명합니다. 사용 사례의 전체 집합과 관련하여 설계의 우선 순위를 정하면 예상되는 기능의 제공에 계속 초점을 맞출 수 있습니다.

각 사용 사례에는 사용자 동작에 대한 수량 예측이 포함될 수 있으며, 나중에 성능, 가용성 및 기타 서비스 품질에 대한 시스템 요구 사항을 결정하는 데 이 수치를 사용할 수 있습니다. 또한 사용 사례는 4장, "논리 구조 설계"에서 설명하는 논리 구조 설계를 위한 출발점이기도 합니다.

종종 사용 사례에 상대적인 가중치를 할당하기도 하는데 가중치가 가장 높은 사용 사례는 가장 일반적인 사용자 작업을 나타냅니다. 사용 사례의 가중치는 시스템 요구 사항을 결정하는 데 도움이 됩니다.

시스템 요구 사항

시스템 요구 사항에서는 비즈니스 분석을 통해 얻은 비즈니스 요구 사항을 충족시키기 위해 배포된 시스템에서 제공해야 하는 서비스 품질을 설명합니다. 대개 사용 분석과 사용 사례를 비즈니스 요구 사항과 같이 사용하여 시스템 요구 사항을 도출합니다.

다음 표에서는 시스템 요구 사항을 지정하기 위해 주로 사용하는 시스템 품질을 나열합니다.

표 3-2
배포 설계에 영향을 미치는 시스템 품질
시스템 품질	설명
가용성	최종 사용자가 시스템의 자원 및 서비스를 액세스할 수 있는 빈도에 대한 측정이며 대개 시스템의 가동 시간으로 표시됩니다.
잠재 용량	추가 자원 없이 비정상적인 최고 로드 사용을 처리할 수 있는 시스템의 기능입니다.
성능	사용자 로드 조건에 따라 응답 시간 및 대기 시간을 측정한 값입니다.
확장성	시간에 따라 배포된 시스템에 용량 및 사용자를 추가할 수 있는 기능입니다. 확장성은 일반적으로 시스템에 자원을 추가하는 것을 포함하지만 배포 구조 변경을 요구해서는 안 됩니다.
보안	시스템과 그 사용자의 무결성을 설명하는 요소들의 복잡한 조합입니다. 보안에는 정보의 보안 전송뿐 아니라 사용자의 인증 및 권한 부여도 포함됩니다.
서비스 가능성	시스템 모니터링, 발생한 문제 복구, 하드웨어 및 소프트웨어 구성 요소 업그레이드 등을 포함하여 배포된 시스템의 관리 용이성입니다.

배포 설계에 영향을 미치는 시스템 품질은 서로 밀접하게 관련되어 있습니다. 한 가지 시스템 품질의 요구 사항이 다른 시스템 품질의 요구 사항 및 설계에 영향을 미칠 수 있습니다. 예를 들어, 높은 수준의 보안은 성능에 영향을 미칠 수 있고, 성능은 가용성에 영향을 미칠 수 있습니다. 가용성 문제를 처리하기 위해 서버를 추가하면 유지 보수 비용(서비스 가능성)에 영향을 미칠 수 있습니다.

시스템 품질이 어떻게 연관되어 있는지 이해하고 다른 품질 간의 균형을 조절하는 것이 비즈니스 요구 사항과 비즈니스 제약 조건을 모두 성공적으로 충족시키는 시스템을 설계할 수 있는 비결입니다.

다음 절에서는 배포 설계에 영향을 미치는 시스템 품질을 자세히 조사하여 시스템 요구 사항을 공식화할 때 고려해야 할 요소에 대한 지침을 제공합니다. 서비스 수준 계약을 작성할 때 사용되는 특별한 시스템 요구 사항 집합인 서비스 수준 요구 사항에 대한 절도 있습니다.

가용성

가용성은 배포된 시스템의 가동 시간을 지정하는 방법입니다. 대개는 사용자가 시스템을 액세스할 수 있는 시간의 백분율로 측정합니다. 시스템을 액세스할 수 없는 시간(중단 시간)은 하드웨어, 소프트웨어 또는 네트워크의 오류나 시스템을 중단시키는 기타 요소(예: 정전)로 인한 것일 수 있습니다. 대부분의 경우 서비스(유지 보수 및 업그레이드)에 예약된 시간은 중단 시간으로 간주되지 않습니다.

대개 사용자가 달성할 수 있는 "9"의 개수로 가용성을 측정합니다. 예를 들어, 99% 가용성은 9가 두 개입니다. 9를 추가로 지정하면 가용성에 대한 배포 설계에 상당한 영향을 미칩니다. 다음 표는 하루 24시간 365일(8,760시간) 실행되는 시스템의 가용성에 9를 추가한 결과를 표시합니다.

표 3-3
1년 내내(8,760시간) 실행되는 시스템의 중단 시간
9의 개수	사용 가능한 백분율	중단 시간
2	99%	88시간
3	99.9%	9시간
4	99.99%	45분
5	99.999%	5분

내결함성이 있는 시스템

9가 네 개 또는 다섯 개인 가용성 요구 사항에서는 일반적으로 내결함성이 있는 시스템을 요구합니다. 내결함성이 있는 시스템은 하드웨어나 소프트웨어 오류 중에도 서비스를 계속할 수 있어야 합니다. 일반적으로 내결함성은 주요 서비스를 제공하는 하드웨어(예: CPU, 메모리 및 네트워크 장치)와 소프트웨어 모두의 중복을 통해 달성됩니다.

단일 오류 지점은 중복 구성 요소에서 백업하지 않는 하드웨어나 소프트웨어 구성 요소입니다. 이 구성 요소의 실패는 시스템의 서비스가 손실을 일으킵니다. 내결함성이 있는 시스템을 설계할 때는 잠재적인 단일 오류 지점을 식별하여 제거해야 합니다.

내결함성이 있는 시스템은 구현 및 유지 보수 비용이 많이 들 수 있습니다. 가용성에 대한 비즈니스 요구 사항 특성을 이해하고 이러한 요구 사항을 충족시키는 가용성 솔루션의 전략과 비용을 고려해야 합니다.

Sun Cluster 3.1 4/04

Sun Cluster 3.1 4/04 소프트웨어는 고가용성의 내결함성이 있는 시스템을 요구하는 배포를 위한 고가용성 솔루션을 제공합니다. Sun Cluster 3.1 4/04에서는 서버, 저장소 및 기타 네트워크 자원을 결합하여 시스템의 사용자 서비스를 방해하지 않고 신속하게 수행되는 페일오버 프로세스를 제공합니다.

서비스 가용성 우선 순위 지정

사용자 관점에서 가용성은 전체 시스템의 가용성보다는 배포된 시스템에서 제공하는 각 서비스에 적용되는 경우가 많습니다. 예를 들어, 인스턴트 메시징 서비스를 사용할 수 없더라도 대개 다른 서비스의 가용성에 거의 또는 전혀 영향을 미치지 않습니다. 그러나 많은 다른 서비스가 종속된 서비스(예: Directory Server)의 가용성은 시스템에서 폭 넓은 영향을 미칩니다.

정렬된 우선 순위 집합에 따라 가용성 요구 사항을 나열하는 것이 도움이 될 수 있습니다. 다음 표에서는 여러 서비스 유형의 가용성에 대한 우선 순위를 지정합니다.

표 3-4
서비스 가용성 우선 순위 지정
우선 순위	서비스 유형	설명
1	전략적	작업에 필수적인 서비스. 예를 들어, 많은 서비스가 Directory Server에 종속됩니다.
2	임무 결정적	최고 로드 시 사용할 수 있어야 하는 서비스. 임무 결정적으로 정의된 응용 프로그램의 데이터베이스 서비스를 예로 들 수 있습니다.
3	사용 가능해야 함	사용 가능해야 하지만 성능은 떨어져도 관계 없는 서비스. 예를 들어, Messaging Server 가용성은 일부 비즈니스 환경에서는 중요하지 않을 수도 있습니다.
4	연기할 수 있음	지정한 기간 내에 사용 가능해야 하는 서비스. 예를 들어, Instant Messaging 가용성은 일부 비즈니스 환경에서 필수적이지 않을 수도 있습니다.
5	선택 사항	무기한 연기할 수 있는 서비스.

가용성 요구 사항을 구현하는 여러 설계 전략에 대한 자세한 내용은 가용성을 위한 크기 조정을 참조하십시오.

잠재 용량

잠재 용량은 자원을 추가하지 않고 비정상적인 최고 로드 사용을 처리할 수 있는 배포 기능입니다. 일반적으로 잠재 용량과 관련된 시스템 요구 사항을 직접 지정하지는 않지만, 이 시스템 품질은 가용성, 성능 및 확장성 요구 사항을 결정하는 한 가지 요소입니다.

성능

성능 요구 사항 결정은 성능에 대한 예상 비즈니스 요구 사항을 시스템 요구 사항으로 변환하는 과정입니다. 일반적으로 비즈니스 요구 사항에서는 응답 시간을 지정하는 비기술적 용어로 성능을 표현합니다. 예를 들어, 웹 기반 액세스에 대한 비즈니스 요구 사항에서 다음과 같이 기술할 수 있습니다.

이 비즈니스 요구 사항을 출발점으로 하여 모든 사용 사례를 조사하고 이 요구 사항을 시스템 수준으로 표현하는 방법을 결정합니다. 사용 분석에서 결정된 사용자 로드 조건을 고려합니다. 각 사용 사례의 성능 요구 사항을 지정한 로드 조건에 따른 응답 시간이나 응답 시간 및 처리 능력으로 표현합니다. 허용 가능한 오류 수를 지정할 수도 있습니다.

다음은 성능에 대한 시스템 요구 사항을 지정하는 방법의 예입니다.

성능 요구 사항은 가용성 요구 사항(페일오버가 성능에 어떤 영향을 미치는지) 및 잠재 용량(비정상적인 최고 로드를 처리하기 위한 용량이 얼마나 있는지)과 밀접하게 관련되어 있습니다.

확장성

확장성은 시간에 따라 시스템에 용량과 사용자를 추가할 수 있는 기능을 설명합니다. 대개 확장성은 자원 추가를 요구하지만, 배포 구조의 설계 변경이나 자원 추가에 필요한 시간으로 인한 서비스 손실을 요구해서는 안 됩니다.

가용성처럼 확장성도 전체 시스템보다는 시스템에서 제공하는 개별 서비스에 적용되는 경우가 많습니다. 그러나 Directory Server처럼 다른 서비스가 종속되어 있는 서비스의 경우 확장성은 시스템 전체에 영향을 미칠 수 있습니다.

비즈니스 요구 사항에서 예상되는 배포의 증가를 명확하게 기술하지 않는 경우 시스템 요구 사항에서 확장성 요구 사항을 지정할 필요는 없습니다. 배포 설계 단계의 배포 구조에서는 확장성 요구 사항을 지정하지 않은 경우에도 시스템 확장을 고려해야 합니다.

확장성 요구 사항 결정은 그리 과학적이지 않습니다. 시스템 증가를 예측하는 데에는 달성할 수 없는 예상, 예측 및 추측 등이 포함됩니다. 확장 가능한 시스템을 구축하기 위한 세 가지 비결은 다음과 같습니다.

다음 표에서는 확장성에 대해 고려할 일부 항목을 나열합니다.

표 3-5
확장성 고려 사항
항목	설명
사용 분석	기존 데이터를 조사하여 현재 또는 예상된 사용자 기반의 사용 패턴을 이해합니다. 현재 데이터가 없을 경우 산업 데이터나 시장 예측을 분석합니다.
합리적인 최대 규모에 대한 설계	알려진 요구와 가능한 요구 모두에 대한 최대 필수 규모와 관련된 목표를 사용하여 설계합니다. 종종 이 규모는 기존 사용자 로드와 합리적으로 예상된 장래 로드에 대한 성능 평가를 기준으로 24개월에 대해 예측하는 양입니다. 예측 기간은 예상의 신뢰성에 따라 상당히 다릅니다.
적절한 중요 시점 설정	예상치 못한 증가를 수용하는 버퍼가 포함된 단기간 요구 사항을 충족시키기 위한 증분 배포 설계를 구현합니다. 시스템 자원을 추가할 중요 시점을 설정합니다. 예를 들면 다음과 같습니다. 자본 취득 예: 분기별 또는 년별 하드웨어 선행 시간 예: 1-6주 버퍼(증가 예상에 따라 10% - 100%)
최신 기술 통합	최신 기술(예: 더 빠른 CPU와 웹 서버)과 이 기술이 기본 구조의 성능에 미칠 수 있는 영향을 이해합니다.

보안 요구 사항

보안은 사용자 트랜잭션 및 관련 데이터의 무결성을 포함하여 시스템과 해당 사용자의 무결성에 영향을 미치는 시스템 품질입니다. 다른 시스템 요구 사항처럼 보안 요구 사항 분석은 비즈니스 요구 사항, 사용량 분석 및 사용 사례에 의해 추진됩니다.

인증, 권한 부여 및 아이디 관리는 견고한 보안 방법의 적용을 위한 기업 차원의 정책과 함께 트랜잭션을 보안하고 사이트에 저장된 데이터가 손상되지 않도록 할 수 있습니다.

인증

인증은 사용자가 자신을 시스템에 식별시키는 방법이기도 하고 시스템이 자신을 사용자에게 식별시키는 방법이기도 합니다. 인증은 무단 액세스로부터 시스템을 보호하는 시스템 무결성의 핵심 부분입니다.

배포를 위한 최상의 인증 방법을 선택하려면 사용자 요구 사항에 대해 알고 있어야 합니다. 예를 들어, B2C (기업-사용자) 배포의 경우 사용자가 사용자 이름/비밀번호 조합을 사용하여 등록할 수 있도록 할 수 있습니다. 이 사용자는 신뢰할 수 있는 인증 기관(예: VeriSign)에서 발행한 서버 인증서를 사용하여 보안 전송을 통해 판매 시스템을 인증합니다.

B2E (기업-직원) 배포에서는 대신 직원에게 기존 사용자 기반에서 제공할 수 있습니다. 회사 방화벽 내에서는 알려진 보안 위치에 대한 액세스가 허용됩니다. 방화벽 외부에서는 보안 위치에 대한 액세스가 회사 방화벽 내에서 인증 및 리디렉션을 수행하는 프록시를 통해 이루어집니다.

권한 부여

권한 부여는 인증된 사용자에 대해 특정 권한을 인정하는 것입니다. 예를 들어, 관리자 권한을 가진 사용자는 배포된 시스템에서 일반 사용자가 액세스할 수 없는 부분을 액세스할 수 있습니다.

권한 부여는 단일 사인 온(SSO)를 구현하는 배포에서도 사용됩니다. 배포에 대해 인증된 사용자는 두 번 이상 로그온하지 않고도 여러 서비스에 대한 액세스 권한을 가질 수 있습니다.

아이디 관리


주	인프라(예: 방화벽 소프트웨어 및 네트워크 설계)의 무결성에 영향을 미치는 보안 요구 사항은 일반적으로 시스템 요구 사항 분석에서 고려되지 않습니다. 대신 이러한 보안 문제는 배포 설계 중에 영향을 미치기 시작합니다.

배포된 시스템에서는 시스템 서비스를 액세스할 사용자를 추가, 수정 또는 삭제할 수 있어야 합니다. 사용자 요구 사항에 따라 아이디 관리는 권한이 있는 관리자가 수행하거나 위임된 관리 인터페이스를 통해 사용자 자신이 수행할 수 있습니다. 중소 기업이나 대기업의 배포에서는 위임된 관리 설계를 고려해야 합니다. 위임된 관리는 고객 만족도를 개선하고 시스템 관리 비용을 줄입니다.

서비스 가능성 요구 사항

서비스 가능성은 시스템 모니터링, 발생한 문제 복구, 하드웨어 및 소프트웨어 구성 요소 업그레이드 등을 포함하여 배포된 시스템을 얼마나 쉽게 관리할 수 있는지를 나타냅니다.

서비스 가능성 요구 사항을 계획할 때는 다음 표에 나열된 항목을 고려합니다.

표 3-6
서비스 가능성 요구 사항 항목
항목	설명
중단 시간 계획	특정 서비스를 사용할 수 없게 하거나 부분적으로 사용할 수 없게 해야 하는 유지 보수 작업을 식별합니다. 일부 유지 보수 및 업그레이드는 사용자 중단 없이 이루어지지만, 서비스를 중단해야 하는 경우도 있습니다. 가능하면 사용자와 함께 중단 시간이 필요한 유지 보수 작업을 예약하여 사용자가 중단 시간을 대비할 수 있도록 합니다.
사용 패턴	배포의 사용 패턴을 식별하여 유지 보수의 기회 시간을 결정합니다. 예를 들어, 대개 일반적으로 업무 시간 중에 사용량이 최고인 시스템의 경우 기회 시간은 밤이나 주말이 됩니다. 지리적으로 분산된 시스템의 경우 이 시간을 식별하기가 더 어려울 수 있습니다.
가용성	서비스 가능성은 종종 가용성 설계를 반영합니다. 유지 보수 및 업그레이드를 위한 중단 시간을 최소화하기 위한 전략의 중요한 부분은 가용성 전략입니다. 높은 수준의 가용성을 요구하는 시스템에서는 유지 보수, 업그레이드 및 복구를 위한 시간이 훨씬 적습니다. 가용성 요구 사항을 처리하기 위한 전략은 유지 보수 및 업그레이드를 처리하는 방법에 영향을 미칩니다. 예를 들어, 지리적으로 분산된 시스템의 경우 서비스 가능성은 유지 보수 기간 중에 작업 로드를 원격 서버에 라우트할 수 있는 기능에 달려있을 수 있습니다. 또한 높은 수준의 가용성이 필요한 시스템에는 사용자 간섭 없이도 시스템을 자동으로 다시 시작하는 더 복잡한 솔루션이 필요할 수 있습니다.
진단 및 모니터링	정기적으로 진단 및 모니터링 도구를 실행하여 문제 영역을 식별하면 시스템의 안정성을 개선할 수 있습니다. 이렇게 하면 문제가 발생하기 전에 방지하고, 가용성 전략에 따라 작업 로드의 균형을 조정하며, 유지 보수 및 중단 시간을 더 잘 계획할 수 있습니다.

서비스 수준 요구 사항

서비스 수준 요구 사항은 고객 지원을 제공해야 하는 조건을 지정하는 시스템 요구 사항 집합입니다. 서비스 수준 요구 사항은 대개 프로젝트 승인 중에 서명하는 서비스 수준 계약의 기준이 됩니다.

시스템 요구 사항처럼 서비스 수준 요구 사항은 비즈니스 요구 사항에서 추출되며 배포에서 충족시켜야 할 전체적인 시스템 품질에 대해 고객에게 하는 일종의 보증을 나타냅니다. 서비스 수준 계약은 사용자와 고객 간의 계약이기 때문에 서비스 수준 요구 사항을 모호하게 지정해서는 안 됩니다. 서비스 수준 요구 사항에서는 요구 사항을 검사하는 기준과 요구 사항을 충족시키는 데 실패한 것을 간주되는 경우 정확하게 정의해야 합니다.

이전 목차 다음
Sun Java Enterprise System 배포 계획 백서