좋은 요구 사항 계획

그렇다면 좋은 요구 사항은 무엇입니까? 좋은 요구 사항은 가치 있고 실행 가능해야합니다. 솔루션에 대한 경로를 제공 할뿐만 아니라 필요성을 정의해야합니다. 팀원 모두가 그 의미를 이해해야합니다. 요구 사항은 복잡성에 따라 다릅니다.

좋은 요구 사항 문서는 하위 요구 사항으로 분류 된 높은 수준의 요구 사항이있는 그룹의 일부가 될 수 있습니다.
또한 최종 제품의 동작 또는 구성 요소를 설명하는 기능 요구 사항 집합을 포함하는 매우 상세한 사양을 포함 할 수 있습니다.
좋은 요구 사항은 간결하고 구체적이어야하며 "우리에게 무엇이 필요합니까?"라는 질문에 답해야합니다. 대신“우리는 어떻게 필요를 충족합니까?”
좋은 요구 사항은 모든 이해 관계자가 계획의 일부를 이해하도록 보장합니다. 부품이 불분명하거나 잘못 해석되면 최종 제품에 결함이 있거나 고장날 수 있습니다.

요구 사항이 발전함에 따라 프로세스 전반에 걸쳐 팀으로부터 지속적으로 피드백을 받으면 요구 사항의 실패 또는 오해를 방지 할 수 있습니다. 모든 사람과의 지속적인 협업 및 동의는 성공의 열쇠입니다.

요구 사항 수집 및 분석

요구 사항은 이해 관계자가 문제를 해결하거나 조직 목표를 달성하는 데 필요한 조건 또는 기능입니다. 시스템이 충족하거나 소유해야하는 조건 또는 기능.

소프트웨어 엔지니어링의 요구 사항 분석 은 다양한 이해 관계자의 가능한 상충 요구 사항을 고려하여 소프트웨어 또는 시스템 요구 사항을 분석, 문서화, 검증 및 관리하는 새로운 또는 변경된 제품에 대해 충족해야 할 요구 사항 또는 조건을 결정하는 작업을 다룹니다.

요구 사항은-

Documented
Actionable
Measurable
Testable
Traceable

요구 사항은 식별 된 비즈니스 요구 또는 기회와 관련되어야하며 시스템 설계에 충분한 세부 수준으로 정의되어야합니다.

비즈니스 분석가는 기존 시스템 관찰, 기존 절차 연구, 고객 및 최종 사용자와의 토론을 통해 정보를 수집합니다. 분석가는 또한 작동하는 시스템이 없을 때 상상력이 풍부하고 창의적인 기술을 가지고 있어야합니다. 누락 된 링크를 찾기 위해 수집 된 요구 사항을 분석하는 것이 요구 사항 분석입니다.

접근 유도

목표를 도출하려면 비즈니스 전문가, 개발 관리자 및 프로젝트 후원자에게 다음 질문을하십시오.

이 프로젝트가 달성하는 데 도움이되는 회사의 비즈니스 목표는 무엇입니까?
우리가 지금이 프로젝트를하는 이유는 무엇입니까?
나중에하면 어떻게 될까요?
우리가 전혀하지 않으면 어떨까요?
이 프로젝트의 혜택은 누구에게 있습니까?
그것으로부터 혜택을받을 사람들은 이것이 현재 가능할 수있는 가장 중요한 개선이라고 생각합니까?
대신 다른 프로젝트를해야합니까?

가능한 목표는 비용 절감, 고객 서비스 개선, 작업 흐름 단순화, 구식 기술 교체, 새로운 기술 파일럿 및 기타 많은 것입니다. 또한 제안 된 프로젝트가 명시된 목표를 달성하는 데 어떻게 도움이되는지 정확히 이해해야합니다.

다양한 유형의 요구 사항

비즈니스 분석가가 관심을 갖는 가장 일반적인 유형의 요구 사항은 다음과 같습니다.

비즈니스 요구 사항

비즈니스 요구 사항은 솔루션 독립적 인 상태를 유지하면서 조직 목표를 충족하기 위해 수행해야하는 기업의 중요한 활동입니다. BRD (비즈니스 요구 사항 문서)는 고객 요구 사항 및 기대 사항에 대한 문서를 포함하여 프로젝트의 비즈니스 솔루션을 자세히 설명합니다.

사용자 요구 사항

사용자 요구 사항은 사용자가 소프트웨어 프로젝트에서 구성 될 소프트웨어에서 기대 / 원하는 특정 요구 사항을 지정해야합니다. 사용자 요구 사항은 검증 가능하고, 명확하고, 간결하고, 완전하고, 일관성 있고, 추적 가능하고, 실행 가능해야합니다.

사용자 요구 사항 문서 (URD) 또는 사용자 요구 사항 사양은 사용자가 소프트웨어가 수행 할 수있을 것으로 기대하는 작업을 지정하는 소프트웨어 엔지니어링에서 일반적으로 사용되는 문서입니다.

시스템 요구 사항

시스템 요구 사항은 응용 프로그램의 최적 기능을 제공하기 위해 컴퓨터에 설치해야하는 소프트웨어 리소스 요구 사항 및 전제 조건을 정의합니다.

기능 요구 사항

기능 요구 사항은 개발중인 시스템의 특정 의도 된 동작을 캡처하고 지정합니다. 시스템 계산, 데이터 조작 및 처리, 사용자 인터페이스 및 응용 프로그램과의 상호 작용, 사용자 요구 사항을 충족하는 방법을 보여주는 기타 특정 기능 등을 정의합니다. 각 요구 사항에 고유 한 ID 번호를 할당합니다.

비 기능적 요구 사항

비 기능적 요구 사항은 특정 행동보다는 시스템의 운영을 판단하는 데 사용할 수있는 기준을 지정하는 요구 사항입니다. 시스템 아키텍처는 비 기능적 요구 사항을 구현하기위한 계획을 말합니다.

비 기능적 요구 사항은 시스템이 어떻게 생겼는지에 대해 말하거나 "시스템이 될 것"처럼 언급 될 수 있습니다. 비 기능적 요구 사항을 시스템의 품질이라고합니다.

전환 요건

전환 요구 사항은 기업의 현재 상태에서 원하는 미래 상태로 쉽게 전환하기 위해 솔루션이 충족해야하는 기능을 설명하지만 전환이 완료된 후에는 필요하지 않습니다.

이는 항상 일시적이고 기존 솔루션과 새 솔루션이 모두 정의 될 때까지 개발할 수 없기 때문에 다른 요구 사항 유형과 구별됩니다. 일반적으로 기존 시스템의 데이터 변환, 해결해야하는 기술 격차 및 원하는 미래 상태에 도달하기위한 기타 관련 변경 사항을 다룹니다. 솔루션 평가 및 검증을 통해 개발 및 정의됩니다.

추적 성 및 변경 관리

요구 사항 추적 성은 초기 아이디어 생성부터 테스트 단계까지 모든 요구 사항을 구성, 문서화 및 추적하는 방법입니다.

요구 사항 추적 능력 매트릭스 (RTM)는 개발 프로세스를 통해 기능 요구 사항 및 구현을 추적하는 방법을 제공합니다. 각 요구 사항은 관련 섹션 번호와 함께 매트릭스에 포함됩니다.

프로젝트가 진행됨에 따라 RIM은 각 요구 사항의 상태를 반영하도록 업데이트됩니다. 제품이 시스템 테스트 준비가되면 매트릭스에 각 요구 사항,이를 해결하는 제품 구성 요소, 올바르게 구현되었는지 확인하는 테스트가 나열됩니다.

RTM에 다음 각 항목에 대한 열 포함-

요구 사항 설명
FRD의 요구 사항 참조
검증 방법
테스트 계획의 요구 사항 참조

Example− 프로젝트 내 항목 간의 관계를 식별하기 위해 점을 연결합니다. 일반적인 하류 흐름의 연결기입니다.

아이디어 요구 사항 디자인 테스트 비즈니스 목표

각각의 요구 사항을 원래의 비즈니스 목표까지 추적 할 수 있어야합니다.

요구 사항을 추적하여 파급 효과 변경 사항을 식별하고 요구 사항이 완료되었는지 여부와 제대로 테스트되고 있는지 확인할 수 있습니다. 추적 가능성 및 변경 관리는 관리자에게 문제를 예측하고 지속적인 품질을 보장하는 데 필요한 가시성과 마음의 평화를 제공합니다.

품질 보증

요구 사항을 처음에 올바르게 제공하면 제품에 대한 품질 향상, 개발주기 단축 및 고객 만족도 향상을 의미 할 수 있습니다. 요구 사항 관리는 올바른 목표를 달성하는 데 도움이 될뿐만 아니라 팀이 개발 프로세스 전반에 걸쳐 비용과 많은 골칫거리를 절약하는 데 도움이됩니다.

간결하고 구체적인 요구 사항은 수정하는 데 훨씬 더 많은 비용이 드는 나중에가 아니라 조기에 문제를 감지하고 수정하는 데 도움이 될 수 있습니다. 또한 비용은 최대100 times 코딩 후 개발 프로세스의 후반부에 결함을 수정하는 것이 요구 사항을 조기에 수정하는 것보다 더 많습니다.

요구 사항 관리를 품질 보증 프로세스에 통합함으로써 팀의 효율성을 높이고 재 작업을 제거 할 수 있습니다. 또한 재 작업은 대부분의 비용 문제가 발생하는 곳입니다.

즉, 개발 팀은 처음에 제대로 수행되지 않은 노력에 예산의 대부분을 낭비하고 있습니다. 예를 들어, 개발자는 나중에 해당 기능에 대한 요구 사항이 변경되었음을 알기 위해 이전 사양 문서를 기반으로 기능을 코딩합니다. 효과적인 요구 사항 관리 모범 사례를 통해 이러한 유형의 문제를 방지 할 수 있습니다.

요약하면 요구 사항 관리는 복잡한 규율처럼 들릴 수 있지만 간단한 개념으로 요약하면 팀이 "우리가 구축하는 내용과 그 이유를 모두 이해합니까?"라는 질문에 답하는 데 도움이됩니다. 비즈니스 분석가, 제품 관리자 및 프로젝트 리더에서 개발자, QA 관리자 및 테스터, 관련 이해 관계자 및 고객에 이르기까지 프로젝트 실패의 근본 원인은 프로젝트 범위에 대한 오해입니다.

모든 사람이 협업하고 프로젝트 라이프 사이클 전반에 걸쳐 요구 사항과 관련된 토론, 결정 및 변경 사항에 대한 전체 컨텍스트 및 가시성을 확보 할 때, 즉 성공이 일관되게 발생하고 지속적인 품질을 유지할 수 있습니다. 또한 프로세스는 관련된 모든 사람에게 마찰과 불만이 적어 더 부드럽습니다.

Note− 연구에 따르면 프로젝트 팀은 요구 사항을 효과적으로 관리하여 프로젝트 결함의 50-80 %를 제거 할 수 있습니다. Carnegie Mellon 소프트웨어 엔지니어링 연구소에 따르면 "소프트웨어 개발 비용의 60-80 %가 재 작업에 있습니다."

요구 사항 사인 오프 얻기

요구 사항 사인 오프는 문서화 된대로 요구 사항의 내용과 표현이 정확하고 완전하다는 프로젝트 이해 관계자의 동의를 공식화합니다. 공식적인 합의는 구현 도중 또는 이후에 이해 관계자가 새로운 (이전에 만나지 않은) 요구 사항을 도입 할 위험을 줄입니다.

요구 사항 사인 오프를 얻으려면 일반적으로 각 프로젝트 이해 관계자와 함께 문서화 된 요구 사항을 직접 대면하여 최종 검토해야합니다. 검토가 끝날 때마다 이해 당사자는 검토 된 요구 사항 문서를 공식적으로 승인해야합니다. 이 승인은 물리적 또는 전자적으로 기록 될 수 있습니다.

요구 사항 사인 오프를 얻는 것은 일반적으로 Requirements Communication 내에서 마지막 작업입니다. 비즈니스 분석가는 검토 과정에서 제기 된 의견이나 이의 제기의 수용을 포함하여 공식 요구 사항 검토의 결과를 요구합니다.