답변.

SRS는 개발하는 시스템에 대한 모든 요구 사항을 설명하는 구조화된 문서입니다. 그 임무는 비즈니스 기대를 최대한 명확하고 완전하게 프로젝트 팀의 언어로 "번역"하는 것입니다. 주요 섹션:

1. 서론(목표, 적용 범위, 용어)
2. 제품 설명 및 비즈니스 맥락
3. 사용자 설명 및 역할
4. 기능 요구 사항(유스 케이스, 사용자 스토리)
5. 비기능 요구 사항(보안, 성능, 사용성)
6. 제약 사항
7. 인터페이스
8. 외부 의존성
9. 요구 사항 수용 기준
10. 용어 사전

주요 특징:

• SRS는 기능적 요구 사항과 비기능적 요구 사항 모두를 포함합니다.
• 요구 사항은 최소한의 모호성으로 명확하게 표현됩니다.
• SRS에는 반드시 사용 시나리오, 제약 사항, 성공 결과 기준이 반영됩니다.

완전성과 품질 관리를 위해 분석가는 검증 체크리스트, 템플릿, IEEE 830 표준 및 주요 이해관계자와의 정기적인 조정을 사용합니다.

함정 질문.

SRS를 완전하게 만들기 위해 user stories만 기술하면 충분한가요?

아니요. User stories는 기능적 측면을 보여주지만 비기능적 요구 사항, 제약 사항, 인터페이스, 예외 시나리오 및 수용 기준을 포함하지 않습니다.

문서에서 동일한 실체에 대해 서로 다른 용어를 사용해도 되나요?

아니요. 반드시 용어의 일관성을 유지해야 합니다: 이를 위해 용어 사전을 만들고 문서의 교차 검토를 수행합니다.

SRS에 보안 및 성능 요구 사항을 포함해야 하나요?

네. 비기능적 요구 사항은 매우 중요합니다: 그 부재는 기술적 부채 또는 시스템 운영 불가능으로 이어질 수 있습니다.

전형적인 오류 및 안티 패턴

• 요구 사항의 세부 정보 부족, 예제 및 수용 기준이 없음.
• 수치적 특성 없는 모호한 표현 사용: "빠름", "편리함", "신뢰성".
• 비기능적 요구 사항 무시.

실생활 예시

부정적 사례

SRS가 user stories만을 바탕으로 작성되어 성능 및 보안 요구 사항이 빠짐.

장점:

• 문서 준비가 빠름.

단점:

• 프로젝트가 보안 감사에 통과하지 못하고 필요한 동시 사용자 수를 견디지 못함.

긍정적 사례

SRS가 필요한 모든 속성 — 기능, 비기능적 요구 사항, 수용 기준, 용어집 등을 포괄함.

장점:

• 감사 준비 완료, 모든 참여자를 위한 명확한 요구 사항, 변화 관리 용이.

단점:

• 문서 준비 및 조정에 소요되는 시간 증가.