가이드라인: 소프트웨어 요구사항 스펙
주제
소프트웨어 요구사항 스펙은
프로젝트를 둘러싼 모든 요구사항의 수집 및 체계화에 초점을 맞춥니다. 예를 들어, 특정 제품 릴리즈에 있는
각 기능에 대한 전체 소프트웨어 요구사항을 설명하는 별도의 SRS를 원할 수 있습니다. 이것은 추가 스펙의 관련 세부 요구사항과 함께
이 기능의 기능적 요구사항을 설명하는 시스템 유스 케이스 모델의
몇 가지 유스 케이스를 포함할 수 있습니다.
이러한 요구사항을 수집하는 몇 가지 다른 툴을 발견할 수도 있기 때문에
몇 가지 다른 구조 및 툴에서 요구사항 수집을 발견할 수 있다는 것을 인식하는 것이 중요합니다. 예를 들어, 추가 스펙의 텍스트 문서 툴을 사용하여 비기능적 요구사항, 설계 제한조건 등과 같은 텍스트 요구사항을 수집하는 것이
적절하다는 것을 발견할 수 있습니다. 반면에 유스 케이스를 사용하여
기능적 요구사항의 일부(또는 전체)를 수집하는 것이 유용하며 유스 케이스 모델
정의 요구사항에 적절한 툴을 사용하는 것이 적절하다는 것을 발견할 수도 있습니다.
사용되는 툴 간의 차이점에 초점을 맞추는 것은 별 의미가 없습니다. 결국
요구사항을 수집하여 실제로 사용 가능한 툴과 무관하게 요구사항의 효과적인
수집 및 체계화에 초점을 맞추어야 합니다. 툴이 아닌 요구사항에 초점을 맞추기 때문에 SRS의 요구사항 콜렉션이
정보 패키지를 만든다고 가정합니다. 시스템에 대한 여러 가지 요구사항의 구현화는
소프트웨어 요구사항 스펙 패키지에서 이루어집니다.
SRS 패키지는 명백하게 비전 문서와
관련되어 있습니다. 실제로 비전 문서는 SRS에 대한 정보로 제공됩니다. 그러나
두 가지 결과물이 서로 다른 요구사항을 제공하므로 일반적으로
다른 작성자에 의해 작성됩니다. 프로젝트의 이 단계에서 프로젝트 초점은
광범위한 사용자 요구사항, 목표 및 목적, 목표 시장 및 시스템 기능으로부터
이러한 기능의 솔루션 구현 방식으로 이동합니다.
지금 필요한 것은 시스템의 전체 외부 작동을 설명하는 결과물의 콜렉션 또는
패키지입니다(예: 특히 "다음은 이러한 기능 전달을 위해 시스템이 수행해야 사항입니다"라고 말하는 패키지).
이것을 SRS 패키지라고 합니다.
SRS 패키지는 ISO 9000 준수를 위해 만들어져 구석으로 밀려나
프로젝트 진행 중에 무시되는 전시용 책이 아닙니다. 대신 활성 중이며
현재 사용되는 결과물입니다. 이는 개발자가 구현 노력을 시작함에 따라
매우 많이 사용되며 모든 그룹 간(예: 개발자들 사이에서 개발자와
외부 그룹(사용자 및 기타 스테이크홀더) 사이)의 의사소통의 기초로
제공됩니다. 공식적으로나 비공식적으로 여러 그룹 간에 계약 상의 합의를 보여줍니다.
즉, SRS 패키지 안에 있지 않으면 개발자는 작업해서는 안됩니다. SRS 패키지에 있는 경우
해당 기능을 제공할 의무가 있습니다.
SRS는 프로젝트 관리자의 참조 표준으로 제공됩니다. 프로젝트 관리자는 개발자가 생성하는 코드를 읽고 비전 문서와 직접 비교할
수 있는 시간, 에너지 또는 기술력을 가지고 있지 않기 쉽습니다. 프로젝트 관리자는
프로젝트팀과의 논의를 위해 SRS 패키지를 표준 참조로 사용해야 합니다.
이전에 언급한 대로 SRS 패키지는 설계 및 구현 그룹의 정보로 제공됩니다.
프로젝트 조직화 방식에 따라 구현자는 궁극적으로 비전 문서를 생성한
이전 문제점 해결 및 기능 정의 활동에 개입되어 있을 수 있습니다. 그러나
그들이 코드 구현사항을 결정하기 위해 초점을 맞추어야 하는 것은 SRS 패키지입니다. 이것은 소프트웨어 테스트 및 QA 그룹에게도 정보로 제공됩니다. 이들 그룹은 이전의 일부 논의에 개입되었어야 하며
SRS 패키지는 이들이 비전 문서에 있는 "비전"을 잘 이해하게 하는 데 명백하게 유용합니다. 그러나 그들의 의무는 개발된 시스템이 실제로 SRS 패키지에 있는
요구사항을 충족시키는지 여부를 확인하는 테스트 케이스와 QS 절차를 작성하는 것입니다. 또한 SRS 패키지는 계획 및 테스트 활동의 표준 참조용으로도 제공됩니다.
유스 케이스 모델 및
유스 케이스에서 기능적 요구사항 정의를 위해
권장되는 방법에 대한 자세한 논의는 가이드라인: 유스 케이스 모델
및 가이드라인: 유스 케이스를 참조하십시오.
시스템의 비기능적 요구사항은 결과물: 추가 스펙에
문서화되어 있어야 합니다. 다음은 이러한 요구사항 정의시 따라야 하는 가이드라인입니다.
비기능적 요구사항을 수집하고 확인할 때 가정 및 사안 목록을 유지보수하십시오.
일부 활동은 충분한 답변을 제공하지 않습니다. 이것은
정보 부족 때문이거나 단순히 답변이 설계의 실용성을 위협한다고 간주했기 때문일
수 있습니다. 따라서 두 목록을 작성하여 설계 검토 중에 유지보수하십시오.
이론적 근거 또는 사고 내용을 포함하여
요구사항 및 설계 프로세스 중에 작성한 가정은 이러한 가정 뒤에서 처리됩니다.
가정은 이 프로젝트 범위 밖 또는 이 프로젝트 이후에 있는 작업의 관련 항목 또는 서브프로젝트를
식별하는 데 사용될 수 있습니다.
주요 사안(프로세스를 중단할 수 있는 중요한 문제)
사안은 각 단계가 종료될 때마다 고객과 함께 검토해야 합니다. 각 단계가
종료될 때 가정도 검토해야 하지만 덜 중요한 사항의 경우 고객이 항상
적격이지 않을 수 있습니다.
가정 및 사안은 모든 결과물에 적용되지만 특히 비기능적 요구사항의 경우
일반적입니다.
클라이언트의 지리적 체계를 문서화하십시오.
이 시스템에서 영향받는 비즈니스 부분의 지리적 위치를
문서화하십시오. 정의에는 주요 IT 기능을 호스트하는 영향받지 않는 사이트도
포함되어야 합니다. 모바일 조직 부분은 특히 주목하십시오(예: 워크스테이션에 대해
교육받고 사용하는 영업 직원). 특수한 자국어 지원(NLS)을 제공해야 할 수 있는
지리적 위치에 유의하십시오.
요구사항에 어플리케이션 패키지 사용을 지정했습니까? 몇 가지
시스템 설계 결정사항을 강력하게 지시할 수 있는 한 가지 매우 중요한
"기정사항"은 사전 정의된 소프트웨어 논리 및 데이터 조직을 제공하는
특정 어플리케이션 패키지의 사용입니다. 일부 소프트웨어 패키지는 융통성이
있어서 상당한 사용자 정의가 가능하지만 일부는 반대입니다. 패키지는 다음과 같은
컴포넌트 및 의사결정을 지시할 수 있습니다.
- 워크스테이션 유형
- 연결 방법
- 프로세서 및 직접 액세스 기억장치 유형(DASD)
- 시스템 제어 프로그램
- 데이터 조직, 배치 및 관리
- 프로그래밍 언어
- 일괄처리 인터페이스
- 프로세스 및 데이터 관계
- 비즈니스 논리
- 화면 설계 및 일반 사용자 인터페이스
- 성능 및 가용성 특성
- 선호하는 인쇄 데이터 형식(예: PostScript, PCL, IPDT)과 같이
인쇄를 위해 필요하거나 존재하는 구조
- 자국어 지원(NLS)
해당 패키지가 설계에 미치는 영향을 이해하는 것이 중요합니다. "해당"
패키지가 있는 경우, 이 패키지에 대한 올바른 기술과 지식을 갖고 있어야 합니다. 이것은
다음으로부터 얻을 수 있습니다.
- 패키지 벤더
- 외부 컨설턴트
- 특별히 훈련된 설계팀 구성원
이 정보를 쉽게 사용할 수 있다고 가정하지 마십시오. 이것은 필요로 할
경우에만 제공됩니다.
설계의 융통성을 제한하는 요구사항의 기타 기정사항을 문서화하십시오.
이것은 설계의 융통성을 제한할 수 있는, 이전 활동에서 명시적으로 다루어지지 않은
특정 요구사항을 파악하는 것입니다. 예를 들어, 다음 사항을 찾으십시오.
- 기존 프로세서 또는 운영 체제 이미지의 사용
- 기존 워크스테이션 장비의 사용
- 기존 네트워크의 사용
- 기존 시스템 관리 경험의 사용
- 특정 모델의 사용(예: '프리젠테이션/비즈니스/데이터 액세스
논리와 그들의 인터페이스 위치 및 방식을 분명하게 보여주는 클라이언트/서버 시스템 모델을
설계에 사용해야 합니다.')
이러한 기정사항이 새 시스템에 영향을 미칩니까? 새 시스템이 기존 프로세서,
운영 체제 이미지 또는 네트워크 형상에서 실행되는 경우,
기존 플랫폼 및 워크로드의 특성이 새 시스템에 영향을 미칩니까?
기존 워크로드에 의해 이미 사용되고 있는 연결 및 처리 용량은 얼마나 됩니까?
기존 워크로드에서 사용되는 보안 제어는 무엇입니까? 이러한 사항을 적어놓고
새 시스템의 보안 요구사항을 고려할 때 두 가지를 비교하십시오.
기존 워크로드의 가용성 특성은 무엇입니까?
새 시스템의 이후 가용성 설계에 영향을 미칠 수 있는 사항을 적어 두십시오. 예를 들어,
기존 워크로드에서 밤마다 전체 프로세서를 종료합니까?
요구사항이 특수 하드웨어 사용을 지정합니까?
이것은 일반적인 용어("시스템은 고속 평면형 플로터를 지원해야 합니다")로
지정되었거나 보다 특정적("기존 Panda Corp ATM이 지원됩니다")일 수 있습니다. 가능한 한 다음 사항을
문서화하십시오.
- 하드웨어 또는 소프트웨어 전제 조건
- 벤더 및 지원 조직
- 자국어(NLS) 고려사항
- 암호화 장비
요구사항이 기존 데이터 사용을 지정합니까? 그러한 경우 이것은 시스템 설계에 영향을 미칩니다. 다음 사항을
문서화하십시오.
- 데이터가 현재 존재하는 시스템
- 구조(예: 관계형 또는 텍스트 파일)
- 크기
- 최근에 이 데이터를 사용하는 사용자 및 시스템
- 가용성 고려사항(예: 데이터베이스 유지보수 또는 일괄처리 활동으로 인해
데이터를 사용할 수 없는 기간)
- 이 데이터를 이동하거나 복사할 수 있습니까?
클라이언트가 기술 구조 또는 IT 전략 계획(또는 동등한 표준 세트)을 가지고 있습니까?
기술 구조는 대략 다음 사항에 상당합니다.
- 엔터프라이즈 기술 플랫폼
- 엔터프라이즈 기술 인프라스트럭처
- 테크놀로지 구조
기술 구조에 다음 사항 중 일부가 정의되어 있을 수 있습니다.
- 컴퓨팅 센터 수와 사용
- 엔터프라이즈의 네트워킹 연결성(WAN)
- 특정 시설의 근거리 지역 연결성(LAN)
- 클라이언트/서버 인프라스트럭처 서비스(미들웨어) 커버링
· 네트워크 자원 및 속성을 추적하는 디렉토리 및 이름 지정 서비스
· 사용자 및 권한 레벨 등록시 사용되는 네트워크 자원을 권한이 없는 사용자로부터
보호하는 보안 서비스
· 네트워크의 날짜 및 시간을 규정하는 시간 서비스
·네트워크에 있는 다양한 시스템에서 자원 복구를 조정하는 트랜잭션 관리 서비스
- 새 어플리케이션에 사용할 개발 방법
- 다음과 같이 승인된 지원 제품 세트:
· 하드웨어
· 시스템 제어 소프트웨어
· "Office"와 같은 광범위한 어플리케이션 소프트웨어
· 헬프 데스크 사용
· 보안 규칙
목록은 매우 광범위할 수 있으며 목록 안의 항목은 매우 엄격한 방식으로
관리되거나 전혀 강제되는 것이 없을 수 있습니다.
다음과 같이 특별히 하부 구조의 사용을 요청 또는 제외시키는 요구사항을 문서화하십시오.
- OSI 또는 SNA
- UNIX**
- SAA
- PS/2*(OS/2* EE 포함).
패키지화된 어플리케이션 솔루션 사용을 내포할 수 있는 특수 구조. 일부 어플리케이션 패키지는 자체 권한의 구조 정의라는 것에 유의하십시오.
클라이언트가 필요로 하는 개방 정도(벤더 독립성 및 상호 운용성)를
문서화하십시오. 기술 구조가 있는 경우 설계는 확실히 그 구조를 따라야 합니다. 기술 구조를 읽고 이 시스템 설계에 영향을 미치는 규칙을 이해해야 합니다.
클라이언트에게 이 시스템이 준수해야 하는 네트워크 구조가 있습니까? 네트워크 구조는
공통 전송 인프라스트럭처에 상위 레벨 연결을 위한 공통 규칙 세트를 더한 것입니다. 이것은 집중기 및 회선을 포함하여 백본 네트워크 정의를 포함할 수 있습니다. 이러한 구조가
있는 경우 필수적인 규칙과 토폴로지를 이해하고 다음 사항을 문서화하십시오.
물리적 토폴로지에 대한 고려사항(네트워크가 본래 시골 또는
대도시에 있는지와 네트워크 접속 장치가 밀집되어 있는지 또는 느슨하게 분산되어 있는지).
현재 네트워크 인프라스트럭처에서 지원하는 상위 레벨 연결 기능.
이러한 연결 기능을 지원하기 위해 사용하는 통신 표준(예: SNA, OSI, TCP/IP).
지원되는 프로그래밍 인터페이스.
다음과 같이 클라이언트/서버 계층 또는 기본 시스템 모델 계층 사이의 연결성에 대한
네트워크 구조 정의:
- 클라이언트 워크스테이션과 LAN 관계형 서버 간의 관계형 데이터 액세스는
특정 관계형 데이터베이스 제품의 프로토콜을 통해야 합니다.
- 프리젠테이션 논리는 항상 워크스테이션에 있어야 하고
데이터 액세스 논리는 항상 중앙 호스트 시스템에 있어야 합니다.
클라이언트에는 연결에 대한 정해진 정책이 있습니까?
기술 구조 또는 네트워크 구조가 없는 경우에도 몇 가지 연결 정책을 가지고 있을 수 있습니다.
다음과 관련된 정책을 문서화하십시오.
- 특정 프로토콜 또는 통신 설비의 사용(단일 빌딩 내부 또는 빌딩이나
조직 외부의 연결).
- 특정 프로토콜에 기존 설비 또는 소프트웨어의 지원이 내재적으로 필요한지 여부
- 기존 물리적 연결 설비의 사용 여부(케이블링, 배선, 네트워크 또는
주변 제어기, 일반 운송 설비). 그렇지 않은 경우 사용할 수 있는 물리적 설비
유형에 대한 제한조건이 있을 수 있습니다(정책, 관리 규정, 물리적 공간, 건물 소유권,
써드파티 개입). 이러한 사항을 문서화하십시오.
- 물리적 설비의 설치나 수정이 필요한 경우 하나 이상의 써드파티(계약자 또는 일반
운송업자)의 개입이 필요할 수 있습니다. 계약 또는 책임의 관리 방식을 이해하십시오. 이것은 특히 비즈니스 상호작용에 국제적 연결이 포함되는 경우 중요합니다.
- 모바일 사용자 지원.
요구사항에 명시적으로 지정되지 않은 기타 정책, 표준 또는 규칙이 클라이언트에게 있습니까? 예:
- 일반 사용자의 모든 새로운 시스템 인터페이스는 끌어서 놓기 조치를 허용하는
객체 지향 방식으로 설계되어야 합니다.
- 모든 새 시스템은 클라이언트/서버 어플리케이션 모델을 기반으로 해야 합니다.
- 모든 새 시스템은 개방형 표준으로 정의되어야 합니다.
- 자국어 지원(NLS)의 표준 및 정책(특히 오른쪽에서 왼쪽으로의 텍스트 조작과 같은 사항)
- 사용자 인증, 액세스 제어 및 데이터 보호를 위해 관리 책임 및 표준을 정의하는 보안 정책.
- 연결 또는 보안을 위해 특수 설비의 사용을 내포할 수 있는 어플리케이션 교환 표준(예: UNEDIFACT 또는 VISA).
다른 정책이 있는 경우, 설계 프로세스의 나중 단계에서 설계가 표준을
준수할 수 있도록 그러한 정책을 이해하고 액세스할 수 있어야 합니다. 패키지화된
어플리케이션 솔루션 사용에는 몇 가지 내재된 표준이 수반될 수 있습니다.
사용자 또는 부서가 자신의 로컬 프로그램을 추가하거나 개발할 수 있는
정책이 있는 위치는 다음과 같습니다.
제어를 하지 않으면 로컬 사용량은 로컬 컴포넌트가 처음에 가져온 프로덕션 시스템에서
필요로 하는 자원까지 신속하게 사용하게 됩니다. 마침내 롤아웃할 준비가 되는 시간까지
프로덕션 시스템을 설치할 수 없게 될 수 있습니다.
비즈니스 프로세스를 보다 작은 비즈니스 프로세스 또는 트랜잭션과 같은
보다 단계적인 단위로 나누기 위해 어플리케이션 개발자와 함께 작업하십시오.
이를 수행하는 이유는 다음 질문의 숫자를 파악하고 계산할 사항을 결정해야 하기 때문입니다.
비즈니스 프로세스는 보다 작은 비즈니스 트랜잭션의 몇 가지 인스턴스로 시작할 수 있으므로(예:
고객 주문별로 여러 개의 항목 주문) 숫자를 문서화할 때 이러한 배율을 기억해야 합니다. 그러나
특히 복잡한 시스템의 경우 너무 자세히 따라잡지 마십시오.
비즈니스 "프로세스"(예: "고객 주문 처리")는 일반적으로
"어플리케이션"(IT 용어)에 의해 구현되거나 둘 이상의 어플리케이션으로
확장될 수 있습니다. 각 어플리케이션 안에는 보통 많은 IT "트랜잭션"(예: "재고 레벨
조회" 또는 "고객 편지 생성")이 있게 됩니다.
여러 가지 커뮤니티는 자체 이름을 사용하여 일치하는 단위를 식별합니다. 예를 들어, "트랜잭션"은
어플리케이션 개발 배경을 가진 사람과 인프라스트럭처 팀에게 전혀 다른 것을 의미할 수 있습니다. 이름을 상관시킨 후 정보를 수집하기 위해 함께 작업하는 것이 중요합니다.
4.1: "측정 단위"의 각 단위에 대해 볼륨 및 크기 정보를 식별하고 문서화하십시오. 예를 들면, 다음과 같습니다.
- 평균 및 최대 활동 시간에 각 비즈니스 프로세스 또는 어플리케이션을 사용하는 것으로
예상되는 사용자 수
- 최대 활동 시기(매일, 매주, 매월 등)
- 평균 및 최대 활동 시간에 처리해야 하는 트랜잭션 비율
- 각 데이터 그룹 및 크기 단위로 된 데이터 요소 및 인스턴스 수
클라이언트는 일부 또는 전체 비즈니스 프로세스에 지정된 성능 기준을
가지고 있을 수 있습니다. 그러나 식별된 경우 시스템 지원 프로세스(예: 시스템 백업) 및
어플리케이션 개발 프로세스에 대한 성능 목표도 문서화한다는 사실을 기억하십시오. 각 카테고리에 대해 다음 사항을
문서화하십시오.
- 각 카테고리에 대한 응답/소요시간 요구사항
- 이러한 사항의 측정 위치
- 다른 시간(예: 비활동 시간/한밤중)에 다른 기준 승인 여부
- 복구 또는 페일백 중 기준 일치 여부
- 성능 보장 필요성 여부
- 성능 요구사항이 일치하지 않는 경우 해당 그룹에 미치는 영향
- 사용 가능성을 고려하기 위해 비즈니스 프로세스에 필요한 최소
성능 조건을 표현하십시오("속도 저하" 대신 "사용 불가능"으로
간주되는 시스템 하한선).
- 패키지화된 어플리케이션 솔루션이 이미 선택된 경우 성능 특성에 대한
액세스 권한이 있는지 확인하십시오. 현재는 전혀 필요하지 않을 수 있지만
이후 활동에서 필요로 하기 때문에 액세스 위치를 알고 있어야 합니다. 또한
써드파티는 필요로 하는 숫자를 전달하는 데 상당한 시간이 소요될 수 있으므로 지금 요청하십시오.
가용성 요구사항 설정시 권장되는 방법은 다음과 같습니다.
- 시스템의 진정한 일반 사용자, 수행하는 비즈니스 프로세스 및 일반 사용자가
이러한 프로세스를 수행하는 시간을 식별하십시오.
- 서비스 가용성(또는 비가용성)이 비즈니스 목표를 수행하는
일반 사용자 기능에 미치는 영향을 분석하십시오.
- 일반 사용자가 비즈니스 목표를 달성하는 데 필요한 사항을
직접 반영하는 가용성 요구사항을 지정하십시오.
- 패키지화된 어플리케이션 솔루션이 이미 선택된 경우
해당 구조 및 설계가 일반 사용자에게 표시되는 어플리케이션의 가용성 특성에
중요한 영향을 미칠 수 있음을 알고 있어야 합니다. 계속 작동되도록
설계되지 않은 패키지는 특히 유지보수 및 일괄처리 창에서
연속하여 작동시키는 것이 매우 어려울 수 있습니다.
가용성 요구사항을 작성할 때 다음 가이드라인을 고려하십시오.
- 전체 시스템에 대해 "글로벌" 요구사항을 지정하기 보다
낮은 레벨의 단위(예: 개별 프로세스, 사용자 그룹, 데이터 그룹 등)에서
가용성 요구사항을 지정하십시오. 이것은 설계자에게 일반 사용자 요구사항을
충족시킬 수 있는 보다 많은 융통성을 제공합니다. 이것은 특히 매우 높은 수준의
연속 가용성 요구사항을 가진 시스템의 경우 중요합니다.
몇 가지 예:
- "뉴욕과 홍콩에 있는 사용자의 편의를 위해 시스템을 하루 24시간 동안
가동시켜야 합니다"라는 문장은 "뉴욕 사용자는 뉴욕 시간으로 오전
7시부터 오후 7시까지 데이터 트랜잭션을 수행할 수 있어야 하고 홍콩 사용자는
홍콩 시간으로 오전 7시부터 오후 7시까지 데이터 트랜잭션을 수행할 수 있어야 합니다"라는
문장보다 설계자에게 훨씬 적은 설계 융통성을 제공합니다. 후자의 경우
설계자는 한 시간대가 프로덕션 도중인 동안 다른 시간대의 데이터 또는
시스템 컴포넌트에서는 유지보수를 수행할 수 있는 융통성을 확보하게 됩니다.
- ATM 어플리케이션에서 월요일 오전 3시에는 예금 및 현금 인출 서비스가
중요하고 해당 시간에 정확한 계좌 잔고를 제공하는 것은 덜 중요할 수 있습니다.
- 원하는 가용성 특성과 필요한 가용성 특성을 구별하십시오. 예를 들어, "ATM은
하루 24시간 동안 예금 및 현금 인출 서비스를 제공해야 합니다. ATM이 하루 24시간 동안
정확한 계좌 잔고 정보를 고객에게 제공하는 것은 바람직합니다. 그러나
계좌 잔고 조회 프로세스의 일시적 중단은 수용할 수 있지만 그 지속 시간은 10분
미만이어야 하고 오전 3시와 4시 사이에 발생해야 합니다".
- 특정 가용성 목표를 충족시키지 않는 것이
사용자의 비즈니스 목표 달성 능력에 직접적인 영향을 미치지 않는 경우,
해당 목표는 시스템의 가용성 요구사항으로 지정하기에 올바른 내용이 아닐 수 있습니다.
- 일반 사용자가 인식하는 대로 가용성을 간접적으로만 반영하는
가용성 요구사항(예: "IMS 제어 영역을 가동시켜야 합니다")은
수행하기에 적절하지 않을 수 있습니다(예: "은행 금전 출납 계원은
프로세스 X와 Y를 수행할 수 있어야 합니다").
각 비즈니스 프로세스와 이들을 수행해야 하는 사용자 그룹에 대해 사용자가
해당 프로세스를 수행할 수 있는 시간을 지정하십시오. 사용자 그룹과
직접 연관되어 있지 않은 프로세스에 대해서도 이를 수행해야 합니다.
다른 시간대에 사용자 그룹이 있는 경우(예: 이전 뉴욕/홍콩)
별도의 사용자 그룹으로 처리하십시오.
또한 어플리케이션이 필요하지 않을 수 있는 비즈니스 휴일과 같은
특수 기간이 있는지 표시하십시오. (이것은 설계자에게 광범위한
유지보수 기간을 사용할 수 있는 융통성을 제공합니다.) 계획된 어플리케이션 기간 동안 이러한 서비스 시간의 변경이 예상되는 것은 언제입니까?
이 시스템의 서비스 시간은 이 시스템과 인터페이스하는 다른 시스템에도 영향을 미칠 수 있습니다.
계획된 기간 동안 이 시스템의 계획된 서비스 시간은 어떻게 변경이 예상됩니까?
스케줄된 서비스 기간 중 서비스 중단과 연관된 비즈니스 영향, 금융 비용
및 위험에 대해 이해하십시오.
이 시스템의 실질적인 가용성 요구사항에 대한 중요성을 식별하려면
비즈니스 프로세스 세트와 사용자 그룹을 고려하고 다음 결과로 발생하는
비즈니스 영향을 식별하십시오.
- 스케줄된 시간 동안 수용하기 어렵게 느린 응답 시간 또는 짧은 중단 시간. 이 특정 어플리케이션과 관련시킬 때 "짧은"과 "수용하기 어렵게 느린"을
정의하십시오("비즈니스 프로세스 성능 기준" 참조).
- 위 기간 동안 여러 가지 서비스 중단 지속 시간(예: 1분, 2~3분, 15분, 30분, 1시간, 2시간, 4시간 등).
- 서비스의 광범위한 중단(교대일, 하루, 며칠 등).
- 사용자 그룹과 직접 연관되어 있지 않은 프로세스도 고려하십시오(예: 한밤중 수표 회수).
각각의 정전 영향을 평가할 때 페일백 프로시저를 식별하고
정전의 실제 비즈니스 영향을 줄일 수 있는 방법을 고려하십시오.
이 영향을 금융 용어로 수량화하십시오(인력 또는 설비 생산성 손실 비용,
현재 비즈니스 손실 가치, 고객 불만족에 따라 예상되는 장래 비즈니스 손실,
이자 비용, 벌칙금 등)..
여러 지속 시간별, 하루 중 여러 시간별, 계획 또는 비계획 여부, 영향받는
비즈니스 프로세스 또는 사용자 등의 정전과 연관된 비용 및 위험에서 차이점을
반영하기 위해 필요한 수만큼의 답변을 제공하십시오.
이 시스템의 계획된 활동 기간 동안 서비스의 중단으로 인한 비즈니스/금융
영향의 변경은 어떻게 예상합니까?
이렇게 동의된 중요한 비즈니스 프로세스 각각을 검토하여
시스템의 일부가 임시로 사용 불가능해졌을 때 이러한 프로세스 중 가장 중요한 요소를
진행시킬 수 있는 대안을 식별하십시오. 축소된 비즈니스 기능으로 일시적으로 조작하는 기능은
중요한 프로세스 및 데이터 간의 상호 의존에 의한 사용 가능성 영향을 줄이는 방법이 될 수 있습니다.
몇 가지 예:
- 전체 기능 1 재고 레코드를 읽고 갱신합니다.
- 감소된 기능 1 재고 레코드의 갱신을 입력하고 장래 갱신을 위해 큐에 넣습니다.
- 전체 기능 2 최근의 고객 잔고를 읽습니다.
- 감소된 기능 2 최신이 아닐 수도 있는 고객 잔고를 다른 소스로부터 읽습니다.
- 전체 기능 3 컴퓨터 일기를 갱신합니다.
- 감소된 기능 3 일기의 인쇄된 종이 사본을 갱신합니다.
시스템이 감소된 기능으로 작동할 때는 비즈니스 프로세스에 허용되는
한계가 있을 수 있습니다. 예를 들어, 최신이 아닌 고객 잔고는
24시간 이전 것이어서는 안됩니다.
서비스가 스케줄된 시간 동안 중단되는 경우("스케줄된 서비스 시간" 참조)
일반적으로 중단 영향은 정전 지속 기간 및 기타 조건에 따라 다양합니다. 일부 정전은
비즈니스 프로세스를 수행하는 사용자 기능에 미미한 영향을 미칠 수 있습니다(짧은 정전,
거의 사용되지 않는 시간에 발생한 정전, 사용자 그룹 서브세트에만 영향을 미치는 정전 또는
수용 가능한 수동 페일백 프로시저가 존재하는 정전). 보다 장기간 또는
"중요한" 시간에 발생하는 정전은 심각한 영향을 미칠 수 있습니다.
몇 가지 예:
- 작업이 이전에 인쇄된 작업 주문에 기초하여 계속될 수 있고 변경사항은 수동으로
기록하고 나중에 입력할 수 있으므로 제조 라인 제어 프로세스의 짧은 정전은
생산성에 미미한 영향을 미칠 수 있습니다. 그러나 6분 이상 지속되는 정전은
나머지 이동 라인의 시스템 종료로 이어질 수 있습니다.
- 최종 트레이딩 시간 동안 고액 금융 결산 시스템의 정전은 상당한 이자
비용 또는 벌칙금을 발생시킬 수 있습니다.
- 생명을 위협하는 긴급상황에 대한 경찰서 및 소방서의 응답은
발신 시스템이 사용 불가능한 경우 수동 페일백 프로시저를 사용하여 지속될
수 있습니다. 그러나 응답 시간이 증가하고 증가된 디스패처 워크로드로
인해 잠재적으로 생명이 위태로워질 수 있습니다.
- 항공사 또는 호텔 예약 시스템의 최대 활동 시간의 정전은
고객이 경쟁업체에 전화하여 예약할 수 있으므로 현재 비즈니스 손실 뿐만 아니라
고객이 다음번 이러한 서비스를 필요로 할 때
먼저 다른 항공사나 호텔에 연락하게 되므로 장래 비즈니스 손실도 발생할 수 있습니다.
"정상" 상황에 적용되는 가용성 및 복구 기준을 식별하십시오.
전체 컴퓨팅 설비의 광범위한 손실 또는 시스템 종료와 같은 "재해" 상황을 제외시키십시오.
"서비스 정전 비용"에서 식별된 비즈니스/금융 비용과 위험에 기초하여
사용자 그룹이 지정된 비즈니스 프로세스 수행을 상당히 방해하는 것을
피하기 위해 충족시켜야 하는 가용성 기준의 스펙을 개발하십시오. 이러한 기준은 다음과 같은
형식으로 지정할 수 있습니다.
- 해당 시간(분/초) 내에 복구되는 정전 백분율
- 해당 기간(주/월/년) 동안 사용자가 특정 기능을 수행할 수 없는 최대 시간량
필요한 만큼 특정화하여 계획 및 비계획 정전의 차이점, 정전 발생 시간(예:
"중요한" 기간 또는 거의 사용되지 않는 기간), 모든 사용자 또는 소수의
사용자에게만 영향을 주는지 여부 등의 요인은 반영시키십시오.
구현 비용에 상당히 영향을 줄 수 있으므로 불필요하게 엄격한 가용성 기준을
지정하지 않도록 유의하십시오. 일반적으로 해당 정전 조건 세트를 사용하여
중요한 비즈니스/금융 비용 또는 위험을 식별할 수 없는 경우, 이것은 이 정전
조건 세트가 지정된 가용성 기준에 포함되어서는 안된다는 것을 의미합니다.
"스케줄된 서비스 시간"에서 스케줄 서비스 시간이 변경되기 쉽거나
"서비스 정전 비용"에서 서비스 중단과 연관된 비즈니스/금융 비용 또는 위험이
계획된 시스템 활동 기간 동안 변경되기 쉽다는 것을 보여주는 경우,
그 결과 가용성 기준의 변경 정도를 추정하십시오.
암호화를 사용하는 경우 추가적인 복구 및 가용성 고려사항이 있게 됩니다. 예를 들면, 다음과 같습니다.
- 시스템 외부에서 보유할 수 있는 비밀 정보를 복구할 수 있는 기능.
- 암호화 기법으로 보호되는 데이터가 적절한 암호화 키의 복구와
함꼐 복구되어야 하는 필요성.
이 설계 프로젝트 범위에서 재해 복구가 필요합니까(광범위한 손실 또는
전제 컴퓨팅 설비의 시스템 종료와 같은 "재해" 상황 중의 가용성)? 그러한 경우
이러한 복구의 기준은 무엇입니까?
아마도 모든 비즈니스 프로세스에 재해 복구 기능이 필요한 것은 아니라는 점에
유의하십시오. 중요하고 재해 복구가 필요한 프로세스만 선택하십시오. 이러한 프로세스 안에서조차
일부 기능만 다루어질 수 있습니다.
- 얼마나 빨리 서비스를 복원해야 합니까? 이것은 재해 발생 시기 또는
원격 사이트로 이동하기 위한 의사결정이 이루어지는 시기로부터 측정됩니까?
- 조직이 로컬이 아닌 원격 사이트에서 복구하도록 결정하는 조건은 무엇입니까?
- 비즈니스가 계속 지속되기 위해 원격 사이트에서 데이터의 최신 정도는
어느 정도여야 합니까(완전 최신, 실패한지 얼마 안되서,
수용 가능한 이전 날)?
- 원격 사이트에서 처음에 서비스가 복원되는 시기는 언제입니까?
- 나중 시기는 언제입니까?
- 동일한 컴퓨팅 설비에 종속된 다른 비즈니스 어플리케이션과 관련하여
이 어플리케이션 세트의 원격 사이트 복구 우선순위는 무엇입니까?
재해 유형에 따라 다른 시스템 부분에 대한 다른 기준 세트가 존재할 수 있습니다.
계획된 어플리케이션 활동 기간 동에 예상되는 위 재해 복구 요구사항의 변경은 무엇입니까?
가능한 빨리 복구되는 시스템을 설계하기 위해 설계자는 어플리케이션의 기능적 요구사항을
충족시키면서 어플리케이션을 구현할 때 사용 가능한 융통성에 대해 알고 있어야 합니다. 다음은
설계자에게 유용한 몇 가지 질문입니다.
1. 필요한 유지보수 활동을 제공하기 위해 짧은 기간 동안 시스템을
작동시킬 수 있습니까?
a. 갱신이 아닌 조회를 수행합니까?
b. 유지보수 활동이 완료된 이후까지 실제로 DB 갱신이 아닌
사용자로부터의 갱신 요청을 승인합니까?
2. 데이터 복구에 필요한 정전의 경우 다음 사항 중 어느 것이 중요합니까?
c. 완전히 최신이 아닌 데이터를 사용할 경우에도 가능한 빨리
서비스를 복구해야 합니까?
d. 시간이 걸리더라도 서비스 복원 전에 최신 상태로 모든 데이터를 복구합니까?
3. 장애 중에 사용자 요청이 "처리 중"이어야 합니까?
사용자는 서비스 복구 후에 요청을 다시 입력해야 합니까?
4. 이 시스템의 가용성에 영향을 줄 수 있는 비기술적 고려사항이
있습니까(예: 프로세스 B가 사용 가능하지 않는 한 프로세스 A도
사용 가능해져서는 안된다는 것을 지시하는 비즈니스 정책)?
위 설계 고려사항 중에 변경이 예상되는 것이 있습니까?
비즈니스에 중요한 프로세스의 경우 시스템의 일부가 임시로 사용 불가능해져도
이러한 프로세스 중 가장 중요한 요소가 기능하는 것처럼 보이게 하는
대안을 식별하는 것이 유용합니다. 축소된 비즈니스 기능으로 일시적으로 조작하는 기능은
중요한 프로세스 및 데이터 간의 상호 의존에 의한 사용 가능성 영향을 줄이는 방법이 될 수 있습니다.
1. 보호할 데이터를 식별하십시오.
2. 각 데이터 유형이 노출되는 위험 유형을 식별하십시오.
- 우연한 손상 또는 파괴
- 의도적인 손상 또는 파괴
- 상업적 정보 제공
- 속임수
- 해킹
- 바이러스
1. 물리적인 보안 위험을 식별하십시오.
- 컴포넌트 도난
- 권한이 부여되지 않은 물리적 액세스
- 사용자의 물리적 안전
2. 이러한 위험의 원천이 될 수 있는 사람을 식별하십시오.
- 데이터 센터 인력
- 다른 IT 인력(예: 개발)
- 조직의 비IT 인력
- 조직 외부의 사람
3. 특히 다음과 연관된 특수 또는 예외적인 보안 요구사항을 식별하십시오.
4. 이 시스템의 보안 설계에 영향을 미칠 수 있는 정보 자유법과
같은 일반 정책이 있습니까?
5. 일부 패키지화된 어플리케이션 솔루션에 자체 보안 서브시스템이 있습니까?
"해당" 패키지가 있는 경우 해당 보안 기능을 알아야 합니다.
보안 요구사항을 설정하고 분류하기 위해 다음 방법을 사용하고자 할 수 있습니다.
1. 논리적 또는 물리적 보안에 의한 보호가 필요한 객체를 열거하십시오.
2. 각 객체와 관련된 위험 노출 상황을 식별하십시오. 일반적인 범주는 다음과 같습니다.
- 액세스(기밀성 위반) 보기(예: 계정 정보, 클라이언트 목록, 특허)
- 액세스 갱신(예: 속임수, 은폐 또는 자금 유용을 위해 데이터 수정)
- 자산 손실(누군가 손에 넣고 더 이상 소유자가 사용할 수 없게 되는 것(재해로 인한
손실과 구별됨)(예: 클라이언트 및 장래 고객 목록, 계약서 등).
모든 객체가 위의 모든 위험 노출 상황에 민감한 것은 아닙니다.
3. 사용자 환경과 관련된 모든 위험을 식별하십시오.
예를 들면, 다음과 같습니다.
- 불만을 가진 직원
- 권한이 부여되지 않은 직원
- 공용 위치에서 열려 있는 단말기 세션
- 해커
- 회선 도청
- 설비 유실(휴대용 PC)
4. 각 객체에 대해 적용할 수 있는 위험 유형을 설정하고 특정 노출 상황과
연관시키십시오.
정적 위치(예: 하드 디스크)뿐만 아니라 이동 중(예: 전송 도중)에도
객체의 보안 요구사항을 검토해야 할 수 있습니다.
설계가 객체 위치를 비보안 영역까지 확장할 수 있으므로
이 주제로 되돌아와야 할 수 있습니다.
일부 시스템 설계의 보안 측면은 매우 큰 노력이 들 수 있습니다. 이러한 사항은
설계 결정사항보다 우위에 있을 수 있습니다. 구조 및 컴포넌트 선택에 대한 다른
올바른 옵션이 적절하지 않게 될 수 있습니다. 따라서 설계하는 시스템에
특별히 중요한 보안 요구사항이 있는지 여부에 따라 명확한 선택을 하십시오. 예를 들면, 다음과 같습니다.
- 군사 기밀 시스템
- 고액 현금 전송 시스템
- 기밀 개인 정보를 다루는 시스템
특별한 보안 요구가 있는 경우 시스템의 설계 부분에 도움을 주는
보안 전문가 또는 종사자를 확인해야 합니다.
사용성 요구사항은 사용자 인터페이스 사용성 정도를 정의합니다.
사용성 요구사항은 시스템이 사용되기 위해 도달해야 하는 최저 사용성 레벨로
설정되어야 합니다. 시스템이 도달할 수 있다고 간주되는 레벨로 설정해서는 안됩니다. 즉, 사용성 요구사항을 목표(예: 상한선)로 간주해서는 안됩니다. 사용성 요구사항은
절대적인 최저 승인 가능한 시스템 사용성을 정의해야 합니다. 따라서
사용성 요구사항이 충족되었을 때에도 반드시 사용성 개선을 중지해서는 안됩니다.
시스템이 사용되기 위해 도달해야 하는 레벨은 대부분 시스템 사용의
대안이 무엇인지에 따라 달라집니다. 시스템이 대안보다 훨씬 많이 사용되어야 합니다. 대안은
다음과 같은 것을 사용할 수 있습니다.
- 기존 수동 프로시저.
- 레거시 시스템.
- 경쟁 제품.
- 이전 버전의 시스템.
사용성 요구사항은 경제적인 측면에서 새 시스템을 정당화하기 위한 욕구에서 비롯될
수도 있습니다. 고객이 새 시스템에 3백만 달러를 지불해야 하는 경우
인력 자원의 워크로드 감소로 인해 연간 1백만 달러가 절약되는 것을 내포하는
사용성 요구사항을 부과할 수 있습니다.
다음은 몇 가지 일반적인 사용성 요구사항의 예입니다.
- 최대 실행 시간 - 교육을 받은 사용자가 일반 시나리오를 실행하는 데 걸리는 시간
- 최대 오류 비율 - 일반 시나리오에서 훈련된 사용자의 평균 오류 수
측정과 관련된 오류는 복구 불가능한 오류며 조직에 부정적인 영향을 미치는 오류입니다(예:
비즈니스 손실 또는 모니터되는 하드웨어의 손상). 유일한 오류의 중요성이 수정에 시간이
소요되는 것인 경우 이것은 측정된 실행 시간에 영향을 줍니다.
- 학습 시간 - 사용자가 지정된 최대 실행 시간보다 빨리 시나리오를
실행시킬 수 있게 되는 데 소요되는 시간.
다음은 "들어오는 메일 메시지 관리" 유스 케이스에 대한 몇 가지 특정
사용성 요구사항의 예입니다.
- 메일 사용자는 한 번의 마우스 클릭으로 메일 메시지를 정리할 수 있어야 합니다.
- 메일 사용자는 한 개의 키보드 단추를 눌러 메일 메시지 텍스트를 스크롤할 수 있어야 합니다.
- 메일 사용자가 기존 메일 메시지를 읽을 때 들어오는 메일 메시지에 의해 방해받아서는 안됩니다.
|