요구 사항 분석은 어떻게 구현하나요?

기획 프로세스는 어떻게 진행되나요?

요구 사항 분석은 계획 프로세스에 포함되며, 다음과 같은 과정을 거쳐야 합니다:

1. A 프로젝트 최종 비전을 설명하는 제품 를 생성할 수 있습니다.
2. 목표를 달성하기 위해 무엇을 해야 하는지 설명하는 일반적인 실행 계획 또는 아이디어입니다.
3. 프로젝트의 작업 단계를 결정하는 기본 작업 목록입니다.
4. 시간 계획: 무엇을 언제 전달해야 하는지 정의합니다.
5. 3단계에서 생성된 개별 작업의 세부 계획.

요구 사항 분석은 계획 프로세스의 처음 세 가지 사항을 다룹니다.

프로젝트 비전

이 단계에서 우리는 몇 가지 기본적인 질문을 스스로에게 던져야 합니다:

1. 어떻게 할까요?

확실히이 시점에서 우리는 이미 우리가 무엇을 위해 노력하고 있는지 알고 있으며 프로젝트 아이디어는 오랫동안 제시되고 생각했지만 더 깊이 생각할 가치가 있습니다. 아마도 설명할 가치가 있는 새로운 문제를 발견할 수 있을 것입니다. 다음과 같은 이슈가 도움이 될 수 있습니다:

• 이 프로젝트는 어떤 문제를 해결해야 하나요?
• 최종 사용자는 누가 될까요?
• 사용자를 위한 인터페이스를 만들고 있나요? 향후 제작이 계획되어 있나요? 만드는 인터페이스 유형(데스크톱 또는 모바일)이 결정되었나요? RWD에 관심이 있나요?
• 비슷한 애플리케이션이 있나요? 장단점은 무엇인가요?
• 프로젝트에 대한 초기 디자인이나 목업이 아직 만들어지지 않았나요?
• 프로젝트가 외부 애플리케이션에 의존하고 있나요? 외부 애플리케이션의 한계가 있나요, 아니면 알고 있나요?
• 예상 성능과 보안 수준에 대해 알고 있는 것이 있나요?

2. 요구 사항은 무엇인가요?

이제 프로젝트에 대한 요구 사항 목록을 설정할 때가 되었습니다. 기능적 요구 사항 외에도 사용성, 응답성, 속도, 성능, 보안 등 기능과 관련이 없는 요구 사항도 지정합니다.

각 요구 사항이 다음 기준을 충족하는지 확인해 보겠습니다:

• 전체 그림이 완성되었습니다,
• 가 맞습니다,
• 가 실현 가능한지 여부와 다른 요구 사항이 이를 무효화하지 않습니다,
• 시스템 작동에 필요하거나 고객이 요구하는 경우 필요합니다,
• 는 모호하지 않고 읽기 쉽고 잘못 해석할 수 없습니다,
• 구현 후 관찰과 테스트를 통해 이 요구 사항이 충족되었는지 여부를 확인할 수 있습니다.

3. 최종 목표는 무엇인가요?

여기에서 프로젝트 운영에 대한 간단한 시각화를 만들어 볼 가치가 있습니다. 기본적인 흐름을 그리거나 차례대로 일어날 일을 칠판에 간단히 적는 것만큼 프로젝트의 아이디어를 완전히 이해하는 데 도움이 되는 것은 없습니다. 사용자 인터페이스가 있는 애플리케이션의 경우 가장 간단한 모형을 만드는 것이 가장 이상적인 상황입니다.

4. 우선 순위는 무엇인가요?

집을 지을 때와 마찬가지로 IT 프로젝트는 처음부터 처음부터 시작하여 가장 필요한 것부터 시작해야 합니다. 따라서 처음에는 요구 사항 목록을 기반으로 특정 프로젝트가 수행 할 수있는 모든 가능한 기능 목록을 지정한 다음 그중 우선 순위가 가장 높고 가능한 한 빨리 수행해야하는 기능과 "있으면 좋은"유형에 대해 동의해야합니다.

전체 프로젝트 시각화 단계의 결과는 목업을 통해든 활동의 흐름을 그려서든 프로젝트가 어떻게 작동해야 하는지에 대한 일반적인 그림이어야 합니다. 또한 주어진 프로젝트가 수행해야 할 모든 가능한 기능의 목록과 각 기능의 우선순위가 무엇인지도 파악해야 합니다.

프로젝트 시각화는 요구사항 분석의 핵심적인 순간입니다. 문제의 본질을 철저히 이해하는 데 도움이 되며, 문제를 잘 설명하는 자료일수록 다음 단계의 계획이 더 효율적으로 진행됩니다.

실행 계획

이 단계에서 우리는 이미 프로젝트 전체의 운영을 어떻게 상상할지 결정합니다. 구현을 위한 몇 가지 아이디어를 가지고 각각에 대해 생각하고 토론하며 약점과 강점을 강조하는 것이 좋습니다. 전부는 아니더라도 여기에서 선택한 아이디어를 자세히 그려보는 것도 좋습니다.

이 단계에서는 프로젝트를 어떤 언어나 프레임워크로 작성할지뿐만 아니라 어떤 추가 도구가 필요한지, 예를 들어 AWS 스택을 사용할지 아니면 다른 것을 사용할지 등 순전히 기술적인 문제도 고려해야 할 때입니다. 일부 기술 사이에서 망설이고 있거나 무엇을 사용해야 할지 모르겠다면 그러한 결정을 제때에 바꾸고 연구 작업에 위임하는 것이 좋습니다. 물론 이러한 연구로 인해 추가 계획이 방해받지 않는 경우에만 그렇게 할 수 있습니다. 그렇지 않은 경우에는 안전하게 스프린트.

주요 작업

프로젝트 계획을 수립한 후에는 주요 작업을 정의한 다음, 이를 세부적으로 논의하고 개발팀별로 더 작은 작업으로 세분화합니다. 팀 새 스프린트를 계획할 때 각 작업을 가능한 한 정확하게 설명하는 것이 중요합니다.

요약

앞서 언급했듯이 요구사항 분석 프로세스는 프로젝트의 복잡성에 따라 달라집니다. 더 쉬운 문제와 더 어려운 문제가 있으며, 이미 누군가가 해결한 문제와 완전히 새로운 문제도 있어 더 오래 고민해야 하는 문제도 있습니다. 어쨌든 명심해야 할 몇 가지 중요한 팁이 있습니다:

• 커뮤니케이션. 커뮤니케이션은 모든 프로젝트 수명 주기에서 가장 중요한 요소로, 모든 것이 명확하게 정의되고 설명되어야 합니다.
• 문제를 빠르게 이해하세요. 프로젝트 문서를 작성하는 것은 좋지만 가능한 한 간결하게 작성하고 수천 페이지가 걸리지 않도록 하세요. 각 구성원은 개발 팀 에 액세스할 수 있어야 하며 프로젝트 비전을 빠르게 이해할 수 있어야 합니다.
• 무엇보다도 단순함. 우리가 계획하는 것을 가능한 한 단순하게 만들고, 향후 쉽게 개발할 수 있는 더 간단한 솔루션을 선택하거나 필요성이 생기면 포기할 수 있도록 노력합시다.
• 필요하지 않을 것입니다. 프로그래밍에서 우리는 YAGNI 원칙에 따라 안내한다는 점을 고려할 때 여기서는 머리 뒤쪽에 있으며 너무 많이 가속하지 않습니다.
• 변화. 조만간 모든 프로젝트에 변화가 필요하니 변화를 두려워하지 맙시다. 또한, 오늘 계획한 것이 영원히 효과가 있을 것이라고 착각하지 맙시다. 동시에 변화를 나쁘고 바람직하지 않은 것으로 취급해서는 안 됩니다. 변화는 개선과 동의어여야 하며, 이것이 바로 우리가 원하는 것입니다: 프로젝트가 최고가 되는 것입니다.
• 시간. 계획이 너무 오래 걸리거나 오래 끌리지 않도록 합시다. 방해가 되는 문제가 있다면 외부에서 해결책을 찾거나 가장 쉬운 방법을 선택합시다.

위의 측면은 요구 사항을 분석할 때 항상 기억할 가치가 있으며, 그러면 원활하게 실행되고 잘 계획된 프로젝트의 기초가 될 것입니다.

자세히 읽어보세요:

• 소프트웨어 개발에 가장 적합한 프로젝트 관리 방식은 무엇인가요?
• 소프트웨어 구축을 위한 코데스트의 모범 사례. 고객 여정에 대한 접근 방식
• 나만의 마켓플레이스를 구축하고 개발하기 위한 빠른 가이드입니다. 알아야 할 사항은 무엇인가요?