가이드라인: 소프트웨어 요구사항 스펙
소프트웨어 요구사항 스펙(SRS)은 프로젝트에 관련된 모든 요구사항의 콜렉션 및 조직에 초점을 맞춥니다. 이 가이드라인은 SRS 개발 방법을 설명합니다.
관계
기본 설명

설명

소프트웨어 요구사항 스펙(SRS)은 프로젝트에 관련된 모든 요구사항의 콜렉션 및 조직에 초점을 맞춥니다. 요구사항 관리 계획이 있으면 이를 참조하여 요구사항의 올바른 위치와 조직을 판별해야 합니다. 예를 들어, 제품의 특정 릴리스에서 각  기능의 완전한 소프트웨어 요구사항을 설명하는 별도의 SRS를 가지는 것이 좋습니다. 여기에는 보충 스펙의 자세한 관련 요구사항 세트와 함께 이 기능의 기능적 요구사항을 설명하는 시스템 유스 케이스 모델의 여러 유스 케이스가 포함될 수 있습니다.

요구사항 수집에 필요한 여러 다른 도구가 있을 수 있으므로 여러 다른 아티팩트와 도구에서 요구사항 콜렉션을 찾을 수 있음을 인식해야 합니다. 예를 들어, 보충 스펙에서는 텍스트 문서화 도구를 사용하여 비기능적 요구사항, 디자인 제한조건 등과 같은 텍스트 요구사항을 수집하는 것이 바람직합니다. 반면에 일부(또는 전체) 기능적 요구사항은 유스 케이스에서 수집하는 것이 유용하고 유스 케이스 모델 정의에 적절한 도구를 사용하는 것이 편리함을 알 수 있습니다.

문서 또는 패키지?

사용 도구 간의 차이점에 초점을 맞춰야 할 큰 이유는 없습니다. 결론적으로 요구사항을 수집하는 것이므로 사용하는 도구와 무관하게 요구사항의 효과적인 콜렉션 및 조직에 초점을 맞춰야 합니다. 도구가 아닌 요구사항에 초점을 맞추기 때문에 여기서는 SRS의 요구사항 콜렉션이 정보의 패키지를 구성한다고 가정합니다. 시스템의 다양한 요구사항은 소프트웨어 요구사항 스펙(SRS)이라는 패키지에 포함됩니다.

비전에서 SRS까지

SRS 패키지는 비전 문서와 명백하게 관련이 있습니다. 실제로 비전 문서는 SRS에 대한 입력으로 제공됩니다. 그러나 두 아티팩트는 목적이 다르며 일반적으로 다른 작성자가 씁니다. 프로젝트의 이 단계에 이르면 프로젝트의 초점은 사용자 요구, 목적 및 목표, 대상 시장 및 시스템의 기능에 대한 광대한 설명에서 이러한 기능을 솔루션에서 구현할 방법으로 이동합니다.

현재 필요한 것은 시스템의 완전한 외부 동작을 설명하는 아티팩트의 콜렉션 또는 패키지 즉, 구체적으로 "시스템이 기능을 전달하기 위해 수행해야 하는 사항"입니다. 이를 SRS 패키지라 합니다.

살아있는 아티팩트

SRS 패키지는 ISO 9000을 준수하도록 제작된 후 프로젝트가 진행됨에 따라 구석에 묻혀 무시되는 먼지쌓인 책이 아닙니다. 이는 활성의 살아 숨쉬는 아티팩트입니다. 실제로 이는 개발자가 구현을 시작하면 많이 사용됩니다. 모든 관계자, 즉, 여러 개발자 사이 및 개발자와 이들이 커뮤니케이션해야 하는 외부 그룹(사용자 및 기타 이해 당사자) 사이의 커뮤니케이션의 기초로 사용됩니다. 공식적 또는 비공식적으로 이는 다양한 관계자 간의 계약을 나타냅니다. SRS 패키지에 없는 경우 개발자가 이에 대해 작업해서는 안됩니다. SRS 패키지에 있으면 해당 기능성을 전달해야 합니다.

프로젝트 구성원의 참조 표준

SRS는 프로젝트 관리자의 참조 표준으로 제공됩니다. 프로젝트 관리자는 개발자가 생성 중인 코드를 읽고 이를 비전 문서와 직접 비교할 시간, 에너지 또는 스킬이 없을 수 있습니다. 따라서 SRS 패키지를 프로젝트 팀과의 논의에서 표준 참조로 사용해야 합니다.

앞서 언급했듯이 이는 디자인 및 구현 그룹에 대한 입력으로 제공됩니다. 프로젝트의 조직 방식에 따라 구현자는 궁극적으로 비전 문서를 산출한 초기 문제 해결 및 기능 정의 타스크와 관련이 있을 수 있습니다. 그러나 코드의 수행 사항을 결정하기 위해 초점을 맞춰야 하는 것은 바로 SRS 패키지입니다. 이는 소프트웨어 테스트 및 QA 그룹에 대한 입력으로 제공됩니다. 이 그룹도 일부 초기 논의에 포함되어야 하며 비전 문서의 "비전"을 잘 이해하는 것이 매우 유용합니다. 그러나 이들의 특권은 개발된 시스템이 SRS 패키지의 요구사항을 실제로 이행하도록 테스트 케이스 및 QA 프로시저를 작성하는 것입니다. SRS 패키지는 계획 및 테스트 타스크에 대한 표준 참조로도 제공됩니다.

기능적 요구사항 정의

유스 케이스 모델유스 케이스 내의 기능적 요구사항 정의에 필요한 권장 접근 방식에 대한 전체 설명을 보려면 가이드라인: 유스 케이스 모델가이드라인: 유스 케이스를 참조하십시오.

비기능적 요구사항 정의

시스템의 비기능적 요구사항은 중간 산출물: 보충 스펙에 문서화되어 있어야 합니다. 다음은 이러한 요구사항을 정의할 때 사용할 가이드라인입니다.

1 일반

1.1 가정 및 문제

비기능적 요구사항을 수집하고 유효성을 검증하는 동안 가정 및 문제 목록을 유지보수하십시오.  

일부 타스크는 만족스런 응답을 제공하지 않습니다. 이는 정보 부족이거나 단순히 응답이 디자인의 실현 가능성을 위협한다고 여기기 때문일 수 있습니다. 따라서 다음 두 가지 목록을 작성해서 디자인 연구 내내 이를 유지보수하십시오.

요구사항 및 디자인 프로세스 중에 설정한 가정(그러한 가정을 작성하게 된 근거나 사고 프로세스 포함). 가정은 이 프로젝트 후 또는 이 프로젝트의 범위 밖의 작업의 관련 하위 프로젝트나 항목을 식별하는 데 사용할 수 있습니다.

주요 문제(심각한 상황을 야기할 수 있는 중요 관심사항)

문제는 각 단계의 마지막에 고객과 함께 검토해야 합니다. 가정도 각 단계의 마지막에 검토할 필요가 있지만, 보다 덜 중요한 내용을 결정하는 경우 고객이 항상 적당한 사람은 아닙니다.

가정과 문제는 모든 중간 산출물에 적용되나 특별히 비기능적 요구사항에 공통됩니다.

1.2 지리적 조직

고객의 지리적 조직을 기록하십시오.

이 시스템의 영향을 받는 비즈니스 파트의 지리적 위치를 기록하십시오. 정의에는 주요 IT 기능을 호스트하는, 영향받지 않는 사이트도 포함해야 합니다. 특히 이동하는 조직의 파트는 메모해 두십시오. 예를 들어, 여행하며 워크스테이션을 사용하는 판매 조직입니다. 특수 모국어 지원(NLS)을 제공해야 할 수 있는 지리적 위치를 기록해 두십시오.

2 기정사실

2.1 사전 선택된 응용프로그램 패키지?

요구사항에 응용프로그램 패키지의 사용이 지정되어 있습니까? 일부 시스템 디자인 결정을 강력히 지시할 수 있는 한 가지 매우 중요한 "기정사실"은 사전 정의된 소프트웨어 로직 및 데이터 조직을 제공하는 특정 응용프로그램 패키지를 사용하는 것입니다. 일부 소프트웨어 패키지는 유연해서 사용자 정의를 많이 허용하지만 일부는 매우 완고하여 이를 허용하지 않습니다. 패키지는 다음과 같은 결정과 컴포넌트를 지시할 수 있습니다.

  • 워크스테이션 유형
  • 연결 메소드
  • 프로세서 및 직접 액세스 저장영역 장치 유형(DASD)
  • 시스템 제어 프로그램
  • 데이터 조직, 배치 및 관리
  • 프로그래밍 언어
  • 일괄처리 인터페이스
  • 프로세스 및 데이터 관계
  • 비즈니스 로직
  • 화면 디자인 및 사용자 인터페이스
  • 성능 및 가용성 특성
  • 선호하는 인쇄 데이터 형식(예: PostScript, PCL, IPDT)과 같은 기존 또는 필수 인쇄 아키텍처
  • 자국어 지원(NLS)

기정사실 패키지가 디자인에 미칠 영향을 이해해야 합니다. "기정사실" 패키지가 있는 경우 이 패키지를 사용할 올바른 스킬과 지식이 있어야 합니다. 이는 다음에서 얻을 수 있습니다.

  • 패키지 벤더
  • 외부 컨설턴트
  • 특별히 훈련된 디자인 팀 구성원

이 지식을 바로 사용할 수 있다는 생각은 하지 마십시오. 필요할 때 사용할 수 있도록 준비하십시오.

2.2 기타 기정사실

디자인의 유연성을 제한할 요구사항의 기타 기정사실을 기록하십시오.

이는 이전 타스크에 명시적으로 제시되지 않았으며 다자인의 유연성을 제한할 수 있는 특정 요구사항을 찾는 것입니다. 다음을 찾아 보십시오.

  • 기존 프로세서 또는 운영 체제 이미지의 사용
  • 기존 워크스테이션 장비의 사용
  • 기존 네트워크의 사용
  • 기존 시스템 관리 사례의 사용
  • 특정 모델의 사용(예: '프리젠테이션/비즈니스/데이터 액세스 로직 및 이들이 인터페이스하는 위치와 방법을 명확하게 표시하는 디자인에 대해 클라이언트/서버 시스템 모델을 사용해야 함')

이러한 기정사실이 새 시스템에 영향을 미칩니까? 새 시스템을 기존 프로세서, 운영 체제 이미지 또는 네트워크 구성에서 실행할 경우 기존 플랫폼 및 워크로드의 특성이 새 시스템에 영향을 줍니까?

기존 워크로드가 이미 선점한 연결 및 처리 용량은 얼마나 됩니까?

기존 워크로드가 사용한 보안 제어는 무엇입니까? 이들을 기록해서 차후에 고려할 때 새 시스템의 보안 요구사항에 대해 이를 점검하십시오.

기존 워크로드의 가용성 특성은 무엇입니까?

이후 새 시스템에 대한 가용성 디자인에 영향을 줄 수 있는 사항을 기록하십시오. 예를 들어, 기존 워크로드는 매일 밤 전체 프로세서를 종료합니까?

2.3 특수 하드웨어?

요구사항에 특수 하드웨어의 사용이 지정되어 있습니까?

이는 일반적인 용어("시스템은 고속 평판 플로터를 지원해야 함")나 보다 구체적인 용어("기존 Panda Corp ATM이 지원됨")로 설명될 수 있습니다. 다음 사항을 가능한 자세히 기록하십시오.

  • 하드웨어 또는 소프트웨어 전제조건
  • 벤더 및 지원 조직
  • 자국어(NLS) 고려사항
  • 암호화 장비
2.4 기존 데이터?

요구사항에 기존 데이터의 사용이 지정되어 있습니까? 그러한 경우 이는 시스템 디자인에 영향을 줍니다. 다음을 기록하십시오.

  • 데이터가 현재 존재하는 시스템
  • 구조(예: 관계 또는 텍스트 파일)
  • 크기
  • 현재 이 데이터를 사용하는 사용자 및 시스템
  • 가용성 고려사항(예: 데이터베이스 유지보수 또는 일괄처리 타스크로 인한 데이터의 사용 불가능 기간)
  • 이 데이터의 이동 또는 복사 가능성

3 표준

3.1 기술 아키텍처/전략적 계획

클라이언트에 기술 아키텍처 및/또는 IT 전략 계획(또는 해당 표준 세트)이 있습니까?

기술 아키텍처는 대개 다음에 해당됩니다.

  • 엔터프라이즈 기술 플랫폼
  • 엔터프라이즈 기술 하부 구조
  • 기술 아키텍처

기술 아키텍처에서 다음 중 일부가 정의되어 있음을 알 수 있습니다.

  • 컴퓨팅 센터의 사용 및 수
  • 엔터프라이즈의 네트워크 연결성(WAN)
  • 특정 시설의 로컬화된 연결성(LAN)
  • 클라이언트/서버 하부 구조 서비스(미들웨어) 적용 범위

· 네트워크 자원 및 속성을 추적하는 디렉토리 및 이름 지정 서비스
· 등록 사용자 및 해당 권한 레벨이 권한 없이 사용하지 못하도록 네트워크 자원을 보호하는 보안 서비스
· 네트워크의 날짜 및 시간을 조절하는 시간 서비스
· 네트워크에서 다양한 시스템의 자원 복구를 조정하는 트랜잭션 관리 서비스

  • 새 응용프로그램에 사용할 개발 방법 
  • 다음과 같은 허용된 지원 제품 세트

· 하드웨어
· 시스템 제어 소프트웨어
· "Office"와 같은 광범위한 응용프로그램 소프트웨어
· 헬프 데스크 사용
· 보안 규칙

  • 인쇄 서브시스템 아키텍처

목록이 매우 광대할 수 있으며 목록의 항목은 매우 엄격하게 유지되거나 전혀 실행되지 않을 수도 있습니다.

다음과 같은 하위 아키텍처의 사용을 특별히 요청 또는 제외하는 요구사항을 기록하십시오.

  • OSI 또는 SNA
  • UNIX**
  • SAA
  • PS/2*(OS/2* EE 사용)

패키징된 응용프로그램 솔루션의 사용이 내포할 수 있는 특수 아키텍처. 일부 응용프로그램 패키지는 자체 권한의 아키텍처 정의임을 기억하십시오.

클라이언트에 필요한 개방성 정도(즉, 벤더 독립성 및 상호운용성)를 기록하십시오. 기술 아키텍처가 있으면 디자인을 이에 맞춰야 할 것입니다. 이를 읽고 이 시스템의 디자인에 영향을 미칠 규칙을 이해해야 합니다.

3.2 네트워크 아키텍처

클라이언트에 이 시스템이 맞춰야 할 네트워크 아키텍처가 있습니까? 네트워크 아키텍처는 높은 수준의 연결성을 위한 공통 규칙 세트 및 공통 전송 하부 구조입니다. 이는 집선기 및 회선을 포함한 백본 네트워크의 정의를 포함할 수 있습니다. 이러한 아키텍처가 있으면 기본 규칙 및 토폴로지를 이해하고 다음을 기록하십시오.

실제 토폴로지에 대한 고려사항(즉, 네트워크가 본질적으로 근거리용인지 광대역용인지 여부와 네트워크 접속이 밀집되거나 느슨하게 분산되는지 여부)

현재 네트워크 하부 구조가 지원하는 상위 레벨 연결 기능

이러한 연결 기능을 지원하기 위해 사용되는 통신 표준(예: SNA, OSI, TCP/IP)

지원되는 프로그래밍 인터페이스

클라이언트/서버 계층 또는 다음과 같은 기본 시스템 모델 계층 사이의 연결성에 대한 네트워크 아키텍처 정의

  • 클라이언트 워크스테이션과 LAN 관계형 서버 사이의 관계형 데이터 액세스는 특정 관계형 데이터베이스 제품의 프로토콜을 통해야 합니다.
  • 프리젠테이션 로직은 항상 워크스테이션에 있고 데이터 액세스 로직은 항상 중앙 집중된 호스트 시스템에 있어야 합니다.
3.3 연결 정책

클라이언트에 규정된 연결 정책이 있습니까?

기술 또는 네트워크 아키텍처가 없는 경우에도 여전히 일부 연결 정책은 있을 수 있습니다.

다음에 관한 정책을 기록하십시오.

  • 특정 프로토콜 또는 통신 기능의 사용(단일 건물 내 또는 건물이나 조직 외부의 연결에 사용)
  • 기존 장비나 소프트웨어를 지원하기 위해 특정 프로토콜이 내재적으로 필요한지 여부
  • 기존의 실제 연결 설비(즉, 케이블링이나 배선, 네트워크나 주변 제어기 및 기간 사업자 설비)를 사용할지 여부. 사용하지 않을 경우 사용 가능한 실제 설비의 유형에 대한 제한조건이 있을 수 있습니다(정책, 관리 규정, 실제 공간, 장비의 소유권, 싸드파티 관련). 이를 기록하십시오.
  • 실제 설비의 설치나 수정이 필요할 경우 하나 이상의 써드파티(예: 계약자나 기간 사업자)와 관련될 수 있습니다. 계약 또는 책임의 관리 방식을 이해하십시오. 이는 특히 비즈니스 상호작용이 국제 연결을 포함할 경우에 중요합니다.
  • 모바일 사용자의 지원
3.4 기타 정책?

요구사항에 명시적으로 제시되지 않은 기타 정책, 표준 또는 규칙이 클라이언트에 있습니까? 예제:

  • 사용자를 위한 모든 새 시스템 인터페이스는 끌어서 놓기 조치를 허용하도록 객체 지향 원칙에 맞게 디자인해야 합니다.
  • 모든 새 시스템은 클라이언트/서버 응용프로그램 모델을 기반으로 해야 합니다.
  • 모든 새 시스템은 개방 표준으로 정의해야 합니다.
  • 특히 오른쪽-왼쪽 텍스트 오퍼레이션과 같은 자국어 지원(NLS)에 대한 표준 및 정책
  • 사용자 인증, 액세스 제어 및 데이터 보호를 위한 보안 정책 정의 관리 책임 및 표준
  • 연결이나 보안을 위한 특수 장비의 사용을 내포할 수 있는 응용프로그램 교환 표준(예: UNEDIFACT 또는 VISA)

기타 정책이 있으면 이들을 이해하고 디자인 프로세스의 이후 단계에서 디자인이 표준에 맞도록 이들에 대한 액세스가 있는지 확인하십시오. 패키징된 응용프로그램 솔루션의 사용은 일부 내재된 표준을 가져올 수 있습니다.

사용자나 부서가 다음에 대해 자체 로컬 프로그램을 추가 및/또는 개발하도록 허용하는 정책은 무엇입니까?

  • 워크스테이션
  • 서버(특히, 디스크 공간 사용)

제어를 하지 않으면, 원래 프로덕션 시스템용으로 구매한 로컬 컴포넌트 자원이 로컬 사용으로 빠르게 고갈됩니다. 결국 프로덕션 시스템이 롤아웃할 준비가 되어 있을 때 프로덕션 시스템을 설치하지 못할 수 있습니다.

4 숫자

4.1 "측정 단위"

응용프로그램 개발 인력과 함께 작업하여 비즈니스 프로세스를 보다 작은 비즈니스 프로세스나 트랜잭션과 같이 세부 단위로 나누십시오.

이렇게 하는 이유는 다음 질문에서 숫자를 캡처하고 무엇을 세어야 할지 결정해야 하기 때문입니다.

비즈니스 프로세스는 보다 작은 비즈니스 트랜잭션의 여러 인스턴스(예: 고객 주문당 복수 항목 주문)를 시작할 수 있으며 사용자는 수를 기록할 때 이 승수를 기억해야 함에 유의하십시오. 그러나 너무 많은 세부사항을 파악하지는 마십시오(특히 복잡한 시스템의 경우).

비즈니스 "프로세스"(예: "고객 주문 처리")는 일반적으로 "응용프로그램"(IT 용어)을 통해 구현되거나 그 범위가 둘 이상의 응용프로그램이 될 수 있습니다. 각 응용프로그램 내에는 보통 많은 IT "트랜잭션"(예: "재고 레벨 조회" 또는 "고객 편지 생성")이 있습니다.

다른 커뮤니티는 우리가 일치시키려는 단위에 자체 이름을 사용하여 식별합니다. 예를 들어, "트랜잭션"은 응용프로그램 개발 관련 지식을 가지는 인원에게 일정한 의미를 가지지만 하부 구조 팀에게는 전혀 다른 의미를 가질 수 있습니다. 함께 작업하여 이름을 상관시킨 다음 정보를 수집해야 합니다.

4.2 "비즈니스 볼륨 및 크기"

4.1: "측정 단위"의 각 단위에 대한 볼륨 및 크기 정보를 식별하고 기록하십시오. 예를 들어 다음과 같습니다.

  • 평균 및 최대 활동 시간대에 각 비즈니스 프로세스 또는 응용프로그램을 사용할 것으로 예상되는 사용자의 수
  • 최대 활동 시간 시기(매일, 매주, 매월 등 적절히 적용)
  • 최대 활동 및 평균 시간에 트랜잭션을 처리해야 할 비율
  • 각 데이터 그룹의 데이터 요소 및 인스턴스 수와 크기
4.3 "비즈니스 프로세스 성능 기준"

클라이언트에는 일부 또는 모든 비즈니스 프로세스에 대해 지정된 성능 기준이 있을 수 있습니다. 그러나 시스템 지원 프로세스(예: 시스템 백업) 및 식별된 경우 응용프로그램 개발 프로세스에 대한 성능 목표도 기록하는 것을 기억하십시오. 각 카테고리에 대해 다음을 기록하십시오.

  • 각 카테고리에 대한 응답/소요 시간 요구사항
  • 이들의 측정 지점
  • 다른 시간대(예: 최대 활동 시간이 아닐 때/밤중)에 다른 기준이 허용 가능한지 여부
  • 복구 또는 대체 중 기준이 일치할지 여부
  • 성능 보증이 필요한지 여부
  • 성능 요구사항이 일치하지 않는 경우 관련자에 미치는 영향
  • 비즈니스 프로세스가 사용 가능한 것으로 간주되는 데 필요한 최소 성능 조건(즉, 시스템이 "느림" 대신 "사용 불가능"으로 간주되는 최소 기준 지점)을 표시하십시오.
  • 패키지 응용프로그램 솔루션이 이미 선택된 경우 성능 특성에 대해 액세스할 수 있도록 하십시오. 지금은 이들 모두가 필요하지 않을 수 있지만 이후 타스크에서 필요할 때 이들을 어디서 구해야 하는지 알고 있어야 합니다. 써드파티에서 필요한 내용을 제공하는 데에는 시간이 오래 걸릴 수 있으므로 지금 요청하십시오.

5 가용성

5.1 가용성 권고

가용성 요구사항을 설정하기 위한 권장 접근 방식은 다음과 같습니다.

  1. 시스템의 진정한 사용자, 수행 중인 비즈니스 프로세스 및 사용자가 이들 프로세스를 수행하는 시간을 식별하십시오.
  2. 사용자의 비즈니스 목표 달성 능력에 대한 서비스 가용성(또는 비가용성) 영향을 분석하십시오.
  3. 사용자의 비즈니스 목표 달성에 필요한 사항을 직접 반영하는 가용성 요구사항을 지정하십시오.
  4. 패키징된 응용프로그램 솔루션이 이미 선택된 경우 구조 및 디자인이 사용자에게 표시되는 응용프로그램의 가용성 특성에 상당한 영향을 줄 수 있음에 유의하십시오. 계속 작동하도록 디자인되지 않은 패키지는 계속 작동하기가 매우 어려울 수 있으며 특히 유지보수 및 일괄처리 창의 경우에 그러합니다.

가용성 요구사항을 형성할 때에는 다음 가이드라인을 고려하십시오.

  • 전체 시스템에 대한 "글로벌" 요구사항을 지정하는 대신 낮은 세부 레벨(예: 개별 프로세스, 사용자 그룹, 데이터 그룹 등)에서 가용성 고려사항을 지정하십시오. 그러면 디자이너가 보다 탄력적으로 사용자의 요구에 부응할 수 있습니다. 이는 특히 연속 가용성 요구사항이 매우 높은 시스템에 중요합니다.

일부 예제는 다음과 같습니다.

  • "뉴욕 및 홍콩의 사용자가 사용할 수 있도록 시스템을 하루에 24시간 가동해야 함"이라는 구문은 "뉴욕 사용자는 뉴욕 시간으로 오전 7시에서 오후 7시까지 자신의 데이터에 대한 트랜잭션을 수행하고, 홍콩 사용자는 홍콩 시간으로 오전 7시에서 오후 7시까지 자신의 데이터에 대한 트랜잭션을 수행할 수 있어야 함"이라는 구문보다 적은 디자인 유연성을 디자이너에게 제공합니다. 후자의 경우 디자이너는 다른 시간대에서는 생산 중일 때도 해당 시간대의 데이터나 시스템 컴포넌트에 대한 유지보수를 탄력적으로 수행합니다.
  • ATM 응용프로그램에서는 월요일 오전 3시에 현금 입금 및 지급을 허용하는 것은 중요하지만 이 시간에 정확한 계정 잔액을 제공하는 것은 덜 중요할 수 있습니다.
  • 원하는 가용성과 필수 가용성 특성을 구별하십시오. 예를 들어, "ATM은 하루 24시간 동안 현금 입금 및 지급을 허용할 수 있어야 합니다. ATM은 하루 24시간 동안 정확한 계정 잔액을 고객에게 제공할 수 있는 능력이 바람직합니다. 그러나 때때로 발생하는 계정 잔액 조회 프로세스의 중단을 수용할 수 있되, 그 지속 기간은 10분 미만이어야 하고 오전 3시와 4시 사이에 발생해야 합니다."와 같습니다.
  • 특정 가용성 목표에 미치지 못하는 경우의 영향이 사용자의 비즈니스 목표 달성 능력에 직접 관련되지 않는 경우 이 목표는 시스템의 가용성 요구사항의 좋은 목표가 아닐 수 있습니다.
  • 사용자가 인식한 가용성만을 간접적으로 반영하는 가용성 요구사항(예: "IMS 제어 영역을 가동해야 함")은 다른 요구사항(예: "은행 창구 직원은 프로세스 X 및 Y를 수행할 수 있어야 함")만큼 유용하지 않습니다.
5.2 "계획된 서비스 시간"

각 비즈니스 프로세스 및 이들 프로세스를 수행해야 하는 사용자 그룹에 대해 사용자가 프로세스를 수행할 수 있어야 하는 시간을 식별하십시오. 사용자 그룹과 직접 연관되지 않은 프로세스에 대해서도 이를 수행해야 함을 기억하십시오.

다른 시간대의 사용자 그룹이 있는 경우(예: 앞서 언급한 뉴욕/홍콩의 경우) 별도의 사용자 그룹으로 처리하십시오.

응용프로그램이 필요하지 않을 수 있는 기간(예: 비즈니스 휴일)이 가끔씩 있는지 여부도 표시하십시오. (디자이너는 확장된 유지보수를 위해 이 기간을 탄력적으로 사용할 수 있습니다.) 응용프로그램의 예상 수명에 대해 서비스 시간에서 예상되는 변경은 무엇입니까?

이 시스템이 인터페이스하는 다른 시스템의 서비스 시간이 이 시스템의 서비스 시간에 영향을 줄 수도 있습니다.

예상 수명에 대해 이 시스템의 계획된 서비스 시간이 어떻게 변경될 것으로 예상됩니까?

5.3 "서비스 중지 비용"

계획된 서비스 시간 중 서비스 중단과 연관된 비즈니스 영향, 금융 비용 및 위험성을 파악하십시오.

이 시스템에 정말로 중요한 가용성 요구사항을 식별하려면 사용자 그룹 및 비즈니스 프로세스 세트를 고려하고 다음에서 초래되는 비즈니스 영향을 식별하십시오.

  • 계획된 시간 중의 허용할 수 없을 만큼 느린 응답 시간 기간 또는 짧은 중단. 이 특정 응용프로그램과 관련해서 "짧음" 및 "허용할 수 없을 만큼 느림"을 정의하십시오("비즈니스 프로세스 성능 기준" 참조).
  • 위의 시간 중 서비스의 보다 긴 지속 기간 중단(1분, 몇 분, 15분, 30분, 1시간, 2시간, 4시간 등).
  • 서비스의 확장된 중단(1교대, 1일, 몇 일 등).
  • 사용자 그룹과 직접 연관되지 않은 프로세스(예: 밤중의 수표 현금화)도 고려하십시오.

각 중지 영향을 평가할 때 대체 프로시저를 식별하고 이들이 중지의 진정한 비즈니스 영향을 감소시킬 수 있는 방법을 고려하십시오.

재무 측면에서 이 영향을 수량화해 보십시오(직원이나 장비 생산성 비용 손실, 현재 비즈니스 가치 손실, 고객 불만족으로 인한 이후 비즈니스의 예상되는 손실, 규제적 불이익 등).

다른 지속 기간, 다른 시간, 계획되었는지 여부, 영향이 미치는 비즈니스 프로세스 또는 사용자의 중지와 연관된 비용 및 위험성의 차이점을 반영하는 데 필요한 대로 많은 응답을 제공하십시오.

이 시스템의 예상 수명 중 서비스 중단의 비즈니스/재무 영향이 어떤 방식으로 변경될 것으로 예상됩니까?

시스템의 일부가 일시적으로 사용 불가능한 경우 합의에 이른 각 중요 비즈니스 프로세스를 검토해서 프로세스의 가장 주요한 요소를 진행시킬 수 있는 대안을 식별하십시오. 축소 비즈니스 기능으로 일시적 작동이 가능해지면 주요 프로세스 및 데이터 간의 상호 종속성에 대한 가용성 영향을 줄이는 데 도움이 될 수 있습니다.

일부 예제는 다음과 같습니다.

  • 전체 기능 1 재고 레코드를 읽고 갱신합니다.
  • 축소 기능 1 재고 레코드의 갱신을 입력하고 이후 갱신을 위해 대기열에 넣습니다.
  • 전체 기능 2 최신 고객 잔액을 읽습니다.
  • 축소 기능 2 다른 대체 소스에서 고객 잔액을 읽습니다(정확한 현재 잔액이 아닐 수 있음).
  • 전체 기능 3 컴퓨터 다이어리를 갱신합니다.
  • 축소 기능 3 다이어리의 인쇄된 사본을 갱신합니다.

시스템이 축소 기능으로 작업 중일 때에는 비즈니스 프로세스에 허용되는 데 한계가 있을 수 있습니다. 예를 들어, 고객 잔액은 24시간 넘게 최신이 아닌 상태여서는 안됩니다.

계획된 시간 중에 서비스가 중단되는 경우("계획된 서비스 시간" 참조) 중단의 영향은 일반적으로 중지 지속 기간 및 기타 조건에 따라 달라질 수 있습니다. 일부 중지는 사용자의 비즈니스 프로세스 수행 능력에 최소의 영향을 미칠 수 있습니다(짧은 중지, 하루 중 사용이 적은 기간에 발생하거나, 사용자 그룹의 서브세트에만 영향을 주거나, 허용 가능한 수동 대체 프로시저가 존재하는 중지). 중지 기간이 보다 길거나 하루 중 "중요" 기간에 발생하는 중지는 보다 심각한 영향을 미칠 수 있습니다.  

일부 예제는 다음과 같습니다.

  • 제조 라인 제어 프로세스의 짧은 중지는 미리 인쇄된 작업 지시에 기초해서 작업을 계속하고 이후 입력을 위해 변경사항을 수동으로 기록할 수 있기 때문에 생산성에 최소의 영향을 미칠 수 있습니다. 그러나 60분을 초과하는 중지는 나머지 교대조의 라인 중지를 초래할 수 있습니다.
  • 많은 금액이 오고가는 금융 결제 시스템 거래의 마지막 시간에 중지가 생기면 상당한 이자 비용 또는 규제적 불이익을 초래할 수 있습니다.
  • 치안 및 소방 부서의 경우 디스패치 시스템이 사용 불가능하면 수동 대체 프로시저를 사용하여 생명을 위협하는 위급상황에 대해 계속해서 응답할 수 있습니다. 그러나 증가된 디스패치 시스템의 워크로드로 인해 응답 시간이 늘어나서 잠재적으로 생명을 위협할 수 있습니다.
  • 항공사나 호텔 예약 시스템의 최대 활동 시간 중의 중지는 고객이 경쟁사에 전화해서 예약을 할 때 현재 비즈니스의 손실을 유발할 뿐 아니라 고객이 다음 번에 서비스를 필요로 할 때 다른 항공사나 호텔에 먼저 전화할 정도로 불만족한 경우 미래의 비즈니스 손실도 초래할 수 있습니다.
5.4 "가용성 및 복구 기준"

"정상" 상황에서 적용할 가용성 및 복구 기준을 식별하십시오.

전체 계산 기능의 시스템 종료나 확장된 손실과 같은 "재난" 상황은 제외하십시오.

"서비스 중지 비용"에서 식별한 비즈니스/금융 비용 및 위험성을 기반으로 사용자 그룹의 지정된 비즈니스 프로세스 수행을 많이 방해하지 못하도록 충족시켜야 하는 가용성 기준 스펙을 개발하십시오. 이러한 기준은 다음과 같은 양식으로 지정할 수 있습니다.

  • 주어진 분/초 내에 복구된 중지 백분율
  • 사용자가 특정 기능을 수행할 수 없는 주어진 주/월/년에 대한 최대 시간

계획된 중지와 계획되지 않은 중지 사이의 차이점, 중지가 발생하는 시간(예: "중요" 기간 대 사용이 적은 기간), 모든 사용자 또는 일부 사용자만 영향을 받는지 여부 등과 같은 요인을 필요한 대로 구체화하여 반영하십시오.

구현 비용에 상당히 영향을 줄 수 있으므로 불필요하게 엄격한 가용성 기준을 지정하지 않도록 주의하십시오. 일반적으로 주어진 중지 조건 세트를 사용하여 중요 비즈니스/금융 비용이나 위험성을 식별할 수 없는 경우 이는 이 중지 조건 세트를 정해진 가용성 기준에 포함하면 안된다는 의미일 수 있습니다.

"계획된 서비스 시간"으로 계획된 서비스 시간이 변경될 것으로 보이고/보이거나 "서비스 중지 비용"에 서비스 중단과 연관된 비즈니스/금융 비용이나 위험성이 시스템의 예상 수명 기간에 변경될 것으로 보이는 경우, 결과적으로 가용성 기준이 어떻게 변경될지 예상하십시오.

암호화를 사용할 경우 추가 복구 및 가용성 고려사항이 있습니다. 예제:

  • 시스템 외부에 있을 수 있는 비밀 정보 복구 능력.
  • 암호로 보호된 데이터가 해당 암호 키의 복구와 함께 복구되는지 확인할 필요성
5.5 "재난 복구?"

이 디자인 프로젝트의 범위 내에서 재난 복구가 필요합니까(전체 계산 기능의 시스템 종료나 확장된 손실과 같은 "재난" 상황 중의 가용성)? 그러한 경우 복구 기준은 무엇입니까?

모든 비즈니스 프로세스에 복구 기능이 필요한 것이 아닐 수 있음에 유의하십시오. 중요하고 재난 복구가 필요한 프로세스만을 선택하십시오. 이들 프로세스 중에서도 모든 기능이 해당되는 것은 아닙니다.

  • 서비스를 얼마나 빨리 복원해야 합니까? 재난의 발생 시기에 측정됩니까 아니면 원격 사이트로 이동하도록 결정한 시기에 측정됩니까?
  • 어떠한 조건 하에서 조직이 로컬이 아닌 원격 사이트에서 복구하기로 결정합니까?
  • 비즈니스가 계속해서 작동하려면 원격 사이트의 데이터 최신성은 어느 정도여야 합니까(절대적으로 최신 상태 유지, 장애의 몇 분 이내, 이전 일의 데이터 허용 가능)?
  • 원격 사이트에서 서비스가 먼저 복원되는 때입니까?
  • 미래의 어느 시점입니까?
  • 동일한 계산 기능에 따라 다른 비즈니스 응용프로그램과 상대적으로 이 응용프로그램 세트의 원격 사이트 복구 우선순위는 무엇입니까?

시스템의 다른 파트에 대해 또는 재난의 유형에 따라 다른 기준 세트가 있을 수 있음에 유의하십시오.

응용프로그램의 예상 수명 중 위의 재난 복구 요구사항에서 어떠한 변경이 예상됩니까?

5.6 "기타 가용성 디자인 고려사항"

가능한 신속하게 복구하는 시스템을 디자인하려면 디자이너가 응용프로그램의 기능적 요구사항을 계속 충족시키면서 응용프로그램 구현 시 가능한 탄력성을 알아야 할 필요가 있습니다. 다음은 디자이너에게 가치있을 수 있는 일부 질문입니다.

1. 필요한 유지보수 타스크를 수용하기 위해, 시스템이 다음을 수행하는 짧은 기간 동안 작동할 수 있습니까?

a. 갱신이 아닌 조회 수행

b. 사용자의 갱신 요청을 승인하지만 실제로 유지보수 타스크가 완료될 때까지는 DB를 갱신하지 않음

2. 데이터 복구가 필요한 중지의 경우 다음이 중요합니까?

c. 완전히 최신 상태가 아닌 데이터의 사용을 의미하는 경우에도 가능한 신속하게 서비스를 복원함

d. 시간이 오래 걸리더라도 서비스를 복원하기 전에 모든 데이터를 최신 상태로 복구함

3. 장애 시 사용자 요청이 "진행 중"인 경우 서비스 복구 후 사용자 요청이 다시 시작될 수 있습니까?

4. 이 시스템의 가용성에 영향을 미칠 수 있는 비기술 고려사항이 있습니까(예: 프로세스 B가 사용 불가능하면 프로세스 A도 사용자가 사용할 수 없어야 한다는 비즈니스 정책)?

시간이 지남에 따라 위의 디자인 고려사항이 변경될 것으로 예상됩니까?

비즈니스에 중요한 프로세스의 경우 시스템의 일부가 일시적으로 사용 불가능할 때에도 이들 프로세스의 가장 주요한 요소는 기능하도록 할 수 있는 대안을 식별하는 것이 유용합니다. 축소 비즈니스 기능으로 일시적 작동이 가능해지면 주요 프로세스 및 데이터 간의 상호 종속성에 대한 가용성 영향을 줄이는 데 도움이 될 수 있습니다.

6 보안

6.1 "보안 요구사항"

1. 보호할 데이터를 식별하십시오.

2. 각 데이터 유형이 노출되는 위협 유형을 식별하십시오.

  • 우발적인 손상 또는 파기
  • 계획적인 손상 또는 파기
  • 상업 정보
  • 사기
  • 해킹
  • 바이러스

1. 실제 보안에 대한 위협을 식별하십시오.

  • 컴포넌트 도난
  • 권한 없는 실제 액세스
  • 사용자의 신체적 안전

2. 이러한 위협의 원인이 될 수 있는 사람을 식별하십시오.

  • 데이터 센터 직원
  • 기타 IT 직원(예: 개발)
  • 조직의 비IT 직원
  • 조직 외부의 사람

3. 특히 다음에 관한 특수 또는 일반적이 아닌 보안 요구사항을 식별하십시오.

  • 시스템 액세스
  • 데이터 암호화
  • 감사 가능성

4. 이 시스템의 보안 디자인에 영향을 줄 수 있는 정보 공개법과 같은 일반적인 정책이 있습니까?

5. 일부 패키지 응용프로그램 솔루션에는 자체 보안 서브시스템이 있습니다. "기정사실" 패키지가 있는 경우 해당 패키지의 보안 기능에 유의하십시오.

보안 요구사항을 설정하고 분류하려면 다음 접근 방식을 사용할 수 있습니다.

1. 논리적 또는 실제 보안을 사용한 보호가 필요한 오브젝트를 나열하십시오.

2. 각 오브젝트에 관련된 노출을 식별하십시오. 일반적인 카테고리는 다음과 같습니다.

  • 보기 액세스(신뢰 위반), 예: 계정 정보, 고객 목록, 특허.
  • 갱신 액세스, 예: 사기, 은닉, 자금 유용을 위한 데이터 수정.
  • 자산 손실, 즉, 다른 누군가가 점유하여 소유자가 더 이상 사용할 수 없음(재난으로 인한 손실과 구별됨). 예를 들면 고객 및 예상 고객 목록, 계약 등이 있습니다.

모든 오브젝트가 위의 모든 노출에 민감한 것은 아님에 유의하십시오.

3. 사용자의 환경과 관련된 모든 위협을 식별하십시오. 예제는 다음과 같습니다.

  • 불만이 있는 직원
  • 권한이 없는 직원
  • 공공 장소의 개방형 터미널 세션
  • 해커
  • 회선 도청
  • 장비 유실(예: 휴대용 PC)

4. 각 오브젝트에 대해 적용할 수 있는 위협을 설정하고 이를 특정 노출과 연관시키십시오.

오브젝트에 대한 보안 요구사항을 정적 위치(예: 하드 디스크) 및 이동(예: 전송 중) 시에도 검토해야 할 수 있음에 유의하십시오.

디자인으로 오브젝트의 위치가 보안되지 않은 영역으로 확장될 수 있으므로 이 주제를 다시 살펴봐야 할 수 있습니다.

일부 시스템 디자인의 보안 측면은 매우 힘든 작업일 수 있습니다. 이들은 디자인 결정을 지배하며 구조 및 컴포넌트 선택 시 다른 좋은 옵션을 사용할 수 없게 할 수 있습니다. 따라서 디자인 중인 시스템에 특별히 요청되는 보안 요구사항이 있는지 여부에 대해 지금 분명하게 결정하십시오. 예제:

  • 기밀을 요하는 군사 시스템
  • 고액권 이체 시스템
  • 기밀 개인 정보를 처리하는 시스템

특별한 보안 요청사항이 있으면 보안 전문가나 업계 종사자(practitioner)를 식별하여 시스템의 디자인 측면에 대한 도움을 받아야 합니다.

7 사용성

사용성 요구사항은 사용자 인터페이스의 사용성이 얼마나 높아야 하는지를 정의합니다.

사용성 요구사항은 시스템 사용 시 달성해야 하는 최저 사용성 레벨로 설정해야 합니다. 시스템이 달성할 수 있을 것으로 믿는 레벨로 설정하면 안됩니다. 다른 말로 하면 사용성 요구사항을 목표 즉, 상위 한계로 간주해서는 안됩니다. 사용성 요구사항은 허용 가능한 절대적 최저 시스템 사용성을 정의해야 합니다. 따라서 사용성 요구사항이 충족되더라도 반드시 사용성 개선 노력이 중단되는 것은 아닙니다.

시스템을 사용하기 위해 달성해야 하는 사항은 대부분 시스템에 대한 대안으로 무엇을 사용하는가에 따라 다릅니다. 대안보다 시스템의 사용성을 훨씬 높게 하는 것이 합리적입니다. 대안으로 다음을 이용할 수 있습니다.

  • 기존의 수동 프로시저
  • 레거시 시스템
  • 경쟁 제품
  • 시스템의 이전 버전

사용성 요구사항은 새 시스템의 필요성을 경제적으로 입증하려는 필요성에서도 나올 수 있습니다. 고객이 새 시스템에 3백만 달러를 써야 하는 경우 인적 자원의 워크로드 감소로 년간 백만 달러를 절약하는 사용성 요구사항을 강조할 수 있습니다.

다음은 일반적인 사용성 요구사항의 일부 예제입니다.

  • 최대 실행 시간 - 훈련된 사용자가 공통 시나리오를 실행하는 데 소요되는 시간.
  • 최대 오류 비율 - 훈련된 사용자가 공통 시나리오에 대해 범하는 평균 오류 수.
    측정과 관련된 유일한 오류는 복구 불가능한 오류로 이는 조직에 부정적인 영향(예: 비즈니스 손실이나 모니터할 하드웨어에 대한 손상 유발)을 줍니다. 오류의 유일한 결과가 수리 시간이 소요되는 것이라면, 이는 측정된 실행 시간에 영향을 줍니다.
  • 학습 시간 - 사용자가 지정된 최대 실행 시간보다 빠르게 시나리오를 실행할 수 있게 되는 데 걸리는 시간.

다음은 "수신 메일 메시지 관리" 유스 케이스에 대한 일부 특정 사용성 요구사항의 예제입니다.

  • 메일 사용자는 마우스를 한 번 클릭하여 메일 메시지를 배열할 수 있어야 합니다.
  • 메일 사용자는 하나의 키보드 단추를 눌러 메일 메시지 텍스트를 스크롤할 수 있어야 합니다.
  • 메일 사용자가 기존 메일 메시지를 읽을 때 수신 메일 메시지로 방해하면 안됩니다.