개념: 요구사항 관리
주제
요구사항 관리는 시스템 변경 요구사항을
찾아 문서화하고 구조화하며 추적하기 위한
체계적인 접근 방법입니다.
요구사항은 다음과 같이 정의됩니다.
시스템이 준수해야 하는 조건 또는 성능.
요구사항 관리에 대한 공식적인 정의는
요구사항 관리가 다음에 대한 체계적인 접근 방법이라는 것입니다.
- 시스템의 요구사항 도출, 구조화 및 문서화
-
고객 및 프로젝트 팀 간에 시스템 변경 요구사항에 대한
계약 수립 및 유지보수
효율적인 요구사항 관리의 핵심에는
각 요구사항 유형에
적용 가능한 속성과
다른 요구사항 및 다른 프로젝트 결과물에 대한
추적성과 함께
요구사항에 대한 명확한 설명을
유지보수하는 것이 포함됩니다.
요구사항 수집은 다소 간단한 타스크처럼 느껴질 수도 있습니다.
그러나 실제 프로젝트에서는 다음과 같은 이유로 어려움에 처하게 됩니다.
- 요구사항이 명확하지 않을 수 있고, 여러 소스에서 수집될 수 있습니다.
- 요구사항을 말로 명확하게 표현하기 쉽지 않습니다.
- 여러 세부 레벨에 있는 많은 다른 유형의 요구사항이 있습니다.
- 제어되지 않는 경우 요구사항의 수를 관리할 수 없을 수 있습니다.
- 요구사항이 서로 연관되어 있고
소프트웨어 엔지니어링 프로세스의 다른 인도물과도 연관되어 있습니다.
- 요구사항이 고유 속성 또는 등록 정보 값을 가집니다. 예를 들어,
각 요구사항 충족의 중요도가 서로 다릅니다.
- 많은 이해 관계자가 있습니다. 다시 말해,
요구사항이 여러 기능을 가진 그룹들에 의해 관리되어야 합니다.
- 요구사항이 변경됩니다.
그러면 조직이 이런 어려움을 관리하는 데 도움을 주려면
어떤 기술을 개발해야 하시겠습니까?
다음과 같은 기술이 마스터에게 중요한 것으로 알려져 있습니다.
문제점 분석은 문제점 및 초기 스테이크홀더 요구를 이해하며,
상위 레벨 솔루션을 제안하기 위해 수행됩니다.
이것은 "문제점 뒤의 문제점"을
찾기 위한 원인 추론 및 분석 행위입니다.
문제점 분석 중에
실제 문제점 및 스테이크홀더가 누구인지에 대한
동의를 얻게 됩니다.
또한 비즈니스 관점에서 솔루션의 경계와
솔루션에 대한 비즈니스 제한조건을 정의합니다.
또한 빌드 중인 시스템에 기대되는 투자 수익을 올바로 알 수 있도록
해당 프로젝트에 대한 비즈니스 케이스를 분석해야 합니다.
워크플로우 세부사항: 문제점 분석을 참조하십시오.
요구사항은 여러 소스(예: 고객, 파트너, 일반 사용자 및 도메인 전문가)에서
수집될 수 있습니다.
최적의 소스를 판별하고 이 소스에 액세스하는 방법 및
이 소스에서 정보를 도출하는 방법을 알아야 합니다.
이 정보에 대한 1차 소스를 제공하는 사람을
프로젝트의 스테이크홀더라고 합니다.
회사에서 내부적으로 사용될 정보 시스템을 개발하는 경우
일반 사용자 경력자 및 비즈니스 도메인 전문가를
개발 팀에 포함시킬 수 있습니다.
자주 시스템 레벨보다는 비즈니스 모델 레벨에서
논의를 시작합니다.
시장에 판매할 제품을 개발하는 경우
해당 시장의 고객 요구를 더 잘 이해할 수 있도록
마케팅 담당자를 다양하게 활용할 수 있습니다.
도출 활동은 인터뷰, 브레인스토밍, 개념적 프로토타이핑,
질문서 및 경쟁 분석과 같은 기술을 통해 발생할 수 있습니다.
도출의 결과는 텍스트 및 그래픽으로 설명되며
서로 상대적인 우선순위가 제공되는
요청 및 요구 목록입니다.
워크플로우 세부사항: 스테이크홀더 요구 식별을 참조하십시오.
시스템 정의는 식별된 스테이크홀더 요구를
빌드될 시스템에 대한 의미있는 설명으로 변환하고 조직화하는 것입니다.
시스템 정의 초기에
요구사항 문서 형식, 언어 형식, 요구사항 특수성 정도(요구사항 수 및 세부사항),
요청 우선순위 및 예상되는 노력(보통
별도의 실습을 수행한 서로 다른 사람들로부터 지정된 상이한 두 가지 평가),
기술 및 관리 위험, 초기 범위를 구성하는 것에 대한 결정이 이루어집니다.
이 활동의 일부에는 가장 중요한 스테이크홀더 요청과 직접 관련된
초기 프로토타입 및 설계 모델이 포함될 수 있습니다.
시스템 정의의 결과물은 시스템에 대한 설명으로,
자연어 및 그래픽 언어 모두로 표시되어 있습니다.
워크플로우 세부사항: 시스템 정의를 참조하십시오.
프로젝트를 효율적으로 실행하려면
모든 스테이크홀더로부터의 입력에 기반하여 주의 깊게
요구사항의 우선순위를 정하고 요구사항의 범위를 관리해야 합니다.
너무 많은 프로젝트에서 개발자들이
프로젝트의 위험을 완화하거나 어플리케이션의 구조를 안정화하는
타스크에 먼저 중점을 두기 보다,
"이스터 에그"(Easter egg; 개발자가 흥미롭고 도전적이라고
생각하는 기능)라는 것에 집중하여
어려움을 겪고 있습니다.
프로젝트에서 가능한 빨리 위험을 해결하거나 완화하도록 하려면
각 단계별로 주의 깊게 시스템 요구사항을 선택하여
점진적으로 프로젝트의 알려진 위험을 완화하는 시스템을 개발해야 합니다.
이를 수행하려면 프로젝트 스테이크홀더와 범위(또는 각 반복)에 대해
협의해야 합니다. 일반적으로 여기에는
여러 단계에 있는 프로젝트의
결과물 기대치를 관리하는 데 능숙한 기술이 필요합니다.
또한 요구사항의 소스를 제어하고
개발 프로세스 자체뿐 아니라
프로젝트 인도물의 형태도 제어해야 합니다.
워크플로우 세부사항: 시스템 범위 관리를 참조하십시오.
시스템의 세부 정의는
스테이크홀더가 이런 정의를 이해하고 동의하며 여기에 서명할 수 있는 방법으로
표시되어야 합니다.
기능성뿐만 아니라 법률 또는 규정 요구사항, 유용성,
신뢰성, 성능, 지원 가능성 및 유지보수 가능성도 다루어져야 합니다.
자주 범하게 되는 오류는
빌드하기에 복잡하다고 생각되는 것에는
복잡한 정의가 필요하다고 믿는 것입니다.
이로 인해 프로젝트 및 시스템의 목적
설명이 어려워질 수 있습니다.
사람들에게 감동을 줄 수 있지만
이해하지 못하므로 입력을 잘하지 못할 것입니다.
시스템을 설명하기 위해 생성한 문서를
청중을 이해하도록 많은 노력을 기울여야 합니다.
다른 청중에 대해 다른 유형의 설명을 생성해야 할 수 있습니다.
비주얼 프로토타입과 조합되는 유스 케이스 방법은
시스템의 목적을 전달하고 시스템의 세부사항을 정의하기에
매우 효율적인 방법입니다.
유스 케이스는 요구사항을 컨텍스트에 위치시키는 데 도움을 주고,
시스템 사용 용도를 알려줍니다.
시스템 세부 정의의 또 다른 컴포넌트는
시스템의 테스트 방법을 설명하는 것입니다.
어떤 테스트가 수행될지에 대한 테스트 계획 및 정의를 통해
어떤 시스템 성능이 확인될 것인지 알 수 있습니다.
워크플로우 세부사항: 시스템 정의 정제를 참조하십시오.
요구사항을 정의하는 데 아무리 주의를 기울여도
변경되는 것이 항상 있습니다.
요구사항 변경 관리를 복잡하게 하는 것은
변경된 요구사항이 특정 새 기능을 구현하는 데 더 많거나 적은 시간이
소요되어야 함을 의미한다는 것뿐 아니라,
하나의 요구사항을 변경하면 다른 요구사항에
영향을 미칠 수 있다는 것입니다.
변경에 탄력적인 요구사항 구조를 제공하는지,
요구사항과 개발 라이프사이클의 다른 결과물 사이의
종속성을 표시하기 위해 추적성 링크를 사용하는지 확인해야 합니다.
변경 관리에는
기준선 수립, 종속성이 추적성에 중요한지 판별,
관련 항목 간의 추적성 수립 및 변경 제어와 같은
활동이 포함됩니다.
워크플로우 세부사항: 변경 요구사항 관리를 참조하십시오.
이 주제에 대한 자세한 정보는 다음에서 찾을 수 있습니다.
개념: 요구사항
개념: 요구사항 유형
개념: 추적성
백서: 유스 케이스로 요구사항 관리 적용
|