요구사항 관리는 시스템의 변하는 요구사항을 찾아서 문서화, 구성 및 추적하기 위한 조직적인 접근 방식입니다.
요구사항을 다음과 같이 정의합니다.
시스템이 준수해야 하는 조건 또는 기능
요구사항 관리에 대한 공식적 정의는 다음에 대한 조직적인 접근 방식이라는 것입니다.
-
시스템 요구사항 이용, 구성 및 문서화
-
시스템의 변하는 요구사항에 대한 고객과 프로젝트 팀 사이의 계약 설정 및 유지보수
효과적인 요구사항 관리를 위한 주요사항에는 요구사항
유형마다 적용 가능한 속성과 다른 요구사항 및 다른 프로젝트 중간 산출물에 대한 추적성과 함께 요구사항의 명백한 문장을 유지하는 것이 포함되어 있습니다.
요구사항을 수집하는 것은 오히려 수월한 타스크처럼 들릴 수 있습니다. 그러나 실제 프로젝트에서는 다음과 같은 이유로 실행하기가 어렵습니다.
-
요구사항은 항상 명백하지 않고 많은 소스에서 제공될 수 있습니다.
-
요구사항은 항상 단어로 명백하게 표현하는 것이 쉽지 않습니다.
-
세부사항의 여러 레벨에서 서로 다른 많은 유형의 요구사항이 있습니다.
-
제어되지 않을 경우 여러 가지의 요구사항이 관리 불가능하게 될 수 있습니다.
-
요구사항은 서로 관련되며 소프트웨어 엔지니어링 프로세스의 다른 중간 산출물에도 관련됩니다.
-
요구사항은 고유한 특성 또는 특성 값을 가지고 있습니다. 예를 들어, 요구사항을 동일하게 중요하지 않거나 충족시키는 것이 동일하게 쉽지 않습니다.
-
이해 관계자(interested party)가 많이 있습니다. 이는 다기능 그룹에서 요구사항을 관리해야 함을 의미합니다.
-
요구사항은 변경됩니다.
따라서, 이와 같은 어려움을 관리하는 데 도움을 주기 위해 조직에서의 개발에 필요한 스킬은 무엇입니까? 학습을 통해 다음과 같은 스킬을 숙지하는 것이 중요하다는 것을 알았습니다.
문제점 분석은 문제점, 초기 이해 당사자(stakeholder) 요구를 이해하고 상위 레벨 솔루션을 제안하기 위해 수행됩니다. 이 분석은 "문제점 뒤의 문제점"을 찾기 위한 추론 및 분석 조치입니다. 문제점을
분석하는 동안, 실제 문제점과 이해 당사자에 대한 합의를 얻게 됩니다. 또한 비즈니스 관점에서 솔루션 경계가 무엇이고 솔루션에 대한 비즈니스 제한조건이 무엇인지 정의합니다. 또한 빌드하는 시스템에서의 투자에 대해
예상되는 수익을 제대로 이해할 수 있도록 프로젝트의 비즈니스 사례를 분석해야 합니다.
활동: 문제점 분석도 참조하십시오.
요구사항은 많은 소스(예: 고객, 파트너, 사용자 및 도메인 전문가)로부터 제공됩니다. 소스가 무엇이어야 하는지 가장 잘 판별하고 그 소스에 대한 액세스를 확보하는 방법과 그 소스의 정보를 최대한 도출하는 방법을
알아야 합니다. 이 정보의 기본 소스를 제공하는 개인을 프로젝트에서는 이해 당사자(stakeholder)라고 합니다. 회사에서 내부적으로 사용할 정보 시스템을 개발하고 있을 경우 개발 팀에 사용자 경험이 있는
인원과 비즈니스 도메인 전문가를 포함시킬 수 있습니다. 아주 종종 시스템 레벨이 아닌 비즈니스 모델 레벨에서 논의를 시작합니다. 시장에 판매할 제품을 개발 중이면 시장에서 고객의 요구사항을 제대로 이해할 수 있는
마켓팅 인원을 광범위하게 기용할 수 있습니다.
도출 활동은 인터뷰, 브레인스토밍, 개념 프로토타입 생성, 질문지 조사 및 경쟁적 분석과 같은 기법을 사용하여 발생할 수 있습니다. 도출 결과는 텍스트와 그래픽으로 설명되고 서로 상대적으로 우선순위가 지정된 요청
또는 필요사항 목록이 됩니다.
활동: 이해 당사자의 요구 이해도 참조하십시오.
시스템을 정의하는 것은 이해 당사자(stakeholder)의 요구 이해를 빌드하는 시스템의 의미있는 설명으로 변환하여 구성하는 것을 의미합니다. 시스템 정의 초기에, 요구사항 구성, 문서 형식, 언어 형식성,
요구사항의 특수성 정도(얼마나 많이, 어느 정도로 자세하게), 요청 우선순위 및 예상 노력(개별 연습에서 보통 다른 인원이 지정하는 두 가지의 아주 다른 평가), 기술 및 관리 위험성, 초기 범위를 결정합니다. 이
활동의 일부로, 가장 중요한 이해 당사자(stakeholder) 요청에 직접 관련되는 초기 프로토타입 및 디자인 모델이 포함될 수 있습니다. 시스템 정의 결과는 자연어 및 그래픽으로 된 시스템 설명입니다.
활동: 시스템 정의도 참조하십시오.
프로젝트를 효율적으로 실행하려면, 모든 이해 당사자(stakeholder)로부터의 입력을 기반으로 요구사항에 주의하여 우선순위를 지정하고 그 범위를 관리해야 합니다. 너무 많은 프로젝트에서 개발자는 프로젝트에서
위험성을 완화하거나 응용프로그램의 아키텍처를 안정시키는 타스크에 일찍 초점을 맞추는 대신 소위 "부활절 달걀"(개발자가 관심있어 하며 도전하고자 하는 기능)에 대해 작업하고 있습니다. 프로젝트에서 가능하면 초기에
위험성을 분석하고 완화하도록 하려면 시스템을 점진적으로 개발하여 프로젝트에서 알려진 위험성을 완화하는 각 증분마다 주의하여 요구사항을 선택해야 합니다. 이와 같이 하려면 프로젝트 이해 당사자와 함께 (각 반복의)
범위를 협상해야 합니다. 이 때 일반적으로 서로 다른 단계에서의 프로젝트 산출물에 대한 예상을 관리하는 좋은 스킬이 요구됩니다. 요구사항 소스, 프로젝트의 중간 산출물의 형태 및 개발 프로세스 자체에 대한 제어도
필요합니다.
활동: 활동: 시스템 범위 관리도 참조하십시오.
시스템의 자세한 정의는 이해 당사자가 이해, 합의 및 승인할 수 있는 방식으로 표시해야 합니다. 정의는 기능 뿐만 아니라, 법적 또는 규제 요구사항, 사용성, 신뢰성, 성능, 지원 가능성 및 유지보수성에 대한
준수에 대해서도 다뤄야 합니다. 종종 범하는 잘못은 복잡하다고 느끼는 것은 복잡한 정의가 수반되어야 한다고 믿는 것입니다. 이로 인해 프로젝트 및 시스템의 목적을 설명하는 데 어렵게 됩니다. 사람들은 좋은 인상을
받았을 수 있지만 이해하지는 못했으므로 좋은 입력을 제공하지 못합니다. 시스템을 설명하기 위해 생성하는 문서를 독자가 이해하도록 많은 노력을 기울여야 합니다. 종종 다른 독자에게는 다른 유형의 설명을 생성해야 할
수도 있습니다.
종종 단순한 시각적 프로토타입과 조합한 유스 케이스 방법론이 시스템 목적을 알리고 시스템 세부사항을 정의하는 데 아주 효율적인 방법이라는 사실을 알았습니다. 유스 케이스는 요구사항을 컨텍스트로 만드는 데 도움이
됩니다. 유스 케이스는 시스템 사용 방법에 대한 이야기를 들려줍니다.
시스템 자세한 정의의 또 다른 컴포넌트는 시스템을 테스트해야 하는 방법을 알리는 것입니다. 테스트 계획 및 수행할 테스트 정의는 확인할 시스템 기능을 알려주는 것입니다.
활동: 시스템 정의 정제도 참조하십시오.
요구사항 정의에 아무리 많은 주의를 기울여도 항상 변경되는 요구사항이 발생합니다. 변하는 요구사항으로 인해 관리가 복잡해지는 것은 변경된 요구사항이 특정의 새 기능을 구현하는 데 다소 시간이 소요되어야 함을 의미할
뿐만 아니라 하나의 요구사항에 대한 변경으로 다른 요구사항에도 영향이 미친다는 사실 때문입니다. 변경사항에 대해 원상 복구가 쉬운 구조를 요구사항에 제공했는지, 그리고 추적성 링크를 사용하여 요구사항과 개발
라이프사이클의 다른 중간 산출물 사이의 종속성을 표시하는지 확인해야 합니다. 변경 관리에는 기준선 작성, 추적에 중요한 종속성 판별, 관련 항목들 사이의 추적성 설정 및 변경 제어와 같은 활동이 포함됩니다.
활동: 요구사항 변경 관리도 참조하십시오.
이 주제에 대한 자세한 정보는 다음을 참조하십시오.
개념: 요구사항
개념: 요구사항 유형
개념: 추적성
백서: 유스 케이스로 요구사항 관리 적용
|