[요구사항 분석] 요구사항

1. 요구사항의 이해와 정의

1-1. 요구사항이란?

💡 요구사항은 사용자 또는 이해관계자가 시스템이나 소프트웨어로부터 기대하는 기능, 서비스 및 조건을 명시하는 것이다. 

1-2. 요구사항의 목적

 💡 1. 요구사항은 프로젝트의 목표를 명확히 하고, 개발 팀이 무엇을 개발해야 할지를 구체적으로 안내한다.
      2.프로젝트의 범위를 정의하고 이해관계자 간의 의사소통을 원활하게 하는 데 중요한 역할을 한다.

 

1-3. 기능적 요구사항 VS 비기능적 요구사항

💡 1-3-1 기능적 요구사항
시스템이 수행해야 하는 구체적인 기능들을 명시한다.
ex) 사용자가 로그인 할 수 있어야 함, 결제 시스템이 신용카드를 수락해야 함 등

 

💡 1-3-2 비기능적 요구사항
시스템이 어떻게 동작해야 하는지에 대한 요구사항으로 성능, 보안, 신뢰성, 사용 편의성을 포함한다.
ex) 시스템이 사용자 요청에 3초 이내로 응답해야 함, 데이터베이스에 있는 일부 정보는 암호화해야 함

2. 요구사항 분석 및 명세서

2-1. 요구사항 분석 절차

2-1-1. 요구사항 정리 및 분류

• 설명: 프로젝트에서 필요한 요구사항을 수집한다. 그런 다음, 이 요구사항을 기능적 요구사항과 비기능적 요구사항으로 나눈다. 각각의 요구사항을 사용자 스토리 형식으로 정리한다.
• 사용자 스토리 예시: "As a [role], I want [feature], so that [reason]."
  • 예시: "As a customer, I want to be able to add items to my shopping cart, so that I can purchase multiple items at once."

2-1-2. 요구사항 검토 및 우선순위 결정

• 설명: 수집된 사용자 스토리를 검토하고, 각 요구사항의 중요도에 따라 우선순위를 결정한다. 이 과정에서 프로젝트 목표와의 일치 여부도 고려한다.
• 방법: 우선순위는 중요도, 시급성, 구현 난이도 등을 기준으로 결정한다.

2-1- 3. 모델링 및 분석

• 설명: 사용자 스토리를 기반으로 시스템의 동작을 시각적으로 표현한다. 유스케이스 다이어그램, 시퀀스 다이어그램, 활동 다이어그램 등을 사용해 요구사항을 깊이 있게 분석한다.
• 방법:
  • 유스케이스 다이어그램: 시스템과 사용자 간의 상호작용을 도식화.
  • 시퀀스 다이어그램: 시스템 내에서의 순차적인 동작 흐름을 도식화.
  • 활동 다이어그램: 작업의 흐름을 도식화.

2-1- 4. 검증 및 승인

• 설명: 생성된 사용자 스토리를 이해관계자와 함께 검토하여, 명확성과 완전성을 확인하고 승인을 받는다.
• 방법: 정기적인 회의나 워크숍을 통해 이해관계자와의 소통을 강화하고, 피드백을 반영한다.

2-1- 5. 명세서 작성

• 설명: 승인된 사용자 스토리를 바탕으로 요구사항 명세서를 작성한다. 이 문서는 개발과 테스트의 기준이 된다.
• 포함 요소: 각 요구사항의 상세 설명, 우선순위, 관련 다이어그램 등.

2-1- 6. 반복 및 정제

• 설명: 프로젝트가 진행됨에 따라 요구사항을 지속적으로 검토하고, 필요시 수정하거나 업데이트한다.
• 방법: 스프린트 회고나 정기 리뷰를 통해 요구사항의 변화를 반영한다.

 

2-2. 명세서 작성 시 지킬 사항

💡 5가지 특성
1. 명확성: 모든 이해관계자가 이해할 수 있도록 명확하고 구체적인 언어를 사용한다.
예: 전문 용어를 피하고, 이해하기 쉬운 단어와 문장을 사용한다.

2. 완전성: 모든 필수 요구사항을 포함하며, 누락된 내용이 없어야 한다.
예: 프로젝트에 필요한 모든 요구사항이 빠짐없이 포함되어 있는지 확인한다.
3. 일관성: 문서 내의 정보가 서로 모순되지 않아야 한다.
예: 요구사항 간에 충돌이나 모순이 없도록 주의한다.
4. 추적 가능성: 각 요구사항이 원본 출처로 추적될 수 있도록 한다.
예: 각 요구사항에 고유 식별자를 부여하고, 요구사항의 출처를 명시한다.
5. 검증 가능성: 요구사항이 실제로 검증 가능해야 하며, 측정 가능한 기준을 포함해야 한다.
예: 요구사항이 구체적이고, 테스트 가능하며, 명확한 평가 기준을 포함하도록 한다.

 

3. 요구사항 검증 및 유지 보수

3-1. 요구사항 검증

3-1-1. 리뷰

💡 문서화된 요구사항을 이해관계자와 함께 검토하여 정확성, 완전성, 가독성을 확인한다.

3-1-2. 테스트 케이스(Test Case)

💡 각 요구사항에 대해 테스트 케이스를 작성하고, 해당 테스트를 실행하여 요구사항이 충족되는지 검증한다.

3-1-3. 프로토타입(Prototype)

💡 초기 단계에서 요구사항을 기반으로 프로토타입을 제작하고 이를 이해관계자에게 제시하여 피드백을 받는다.

3-1-4. 시뮬레이션(Simulation)

💡 복잡한 시스템의 경우, 시뮬레이션을 통해 요구사항이 실제 운영 환경에서 어떻게 작동하는지 평가할 수 있다.

 

3-2. 요구사항 변경관리 💡

변경 요청 프로세스: 모든 변경 요청은 공식적인 프로세스를 통해 제출되어야 한다.

영향 분석: 제안된 변경이 프로젝트에 미칠 영향을 분석한다.

변경 승인: 변경 사항에 대한 승인은 이해관계자나 변경 관리 위원회가 담당한다.

변경 기록 및 추적: 모든 변경 사항은 문서화 되고 추적 가능해야 한다.

통신 및 업데이트: 승인된 변경 사항은 모든 관련 이해관계자에게 통신되며, 관련 문서 및 계획은 업데이트된다