SRS의 품질 특성

SRS의 품질 특성

SRS(소프트웨어 요구사항 사양) 문서의 품질 특성은 다음과 같다.

 

1. 명확성: SRS 문서는 명확하고 이해하기 쉬워야 한다. 모호함 없이 명확하고 간결한 언어를 사용해야 하며 전문 지식이 없는 이해관계자에게 불분명할 수 있는 전문 용어를 피해야 한다.

2. 완전성: SRS 문서는 포괄적이어야 하며 소프트웨어 시스템에 필요한 모든 요구 사항을 포함해야 한다. 여

모든 기능적 및 비기능적 요구 사항뿐만 아니라 소프트웨어 개발 프로세스 중에 고려해야 하는 제약이나 제한 사항이 포함되어야 한다.

3. 일관성: SRS 문서는 내용과 구조가 일관성이 있어야 한다. 상충되거나 모순되는 요구사항을 포함하지 않아야 하며, 모든 요구사항을 논리적이고 체계적으로 제시해야 한다.

4. 정확성: SRS 문서는 이해 관계자가 정의한 소프트웨어 시스템의 요구 사항을 정확하게 반영해야 한다. 요구 사항을 잘못 해석하거나 잘못 전달할 수 있는 오류, 누락 또는 오해를 포함해서는 안 된다.

5. 추적 가능성: SRS 문서는 추적 가능해야 한다. 즉, 이해 관계자 입력, 비즈니스 규칙 또는 규정과 같은 요구 사항과 소스 간의 명확한 링크를 제공해야 한다. 이를 통해 소프트웨어 개발 프로세스 전체에서 요구 사항을 보다 쉽게 ​​확인하고 검증할 수 있다.

6. 검증 가능성: SRS 문서의 요구 사항은 검증 가능해야 한다. 즉, 개발된 소프트웨어 시스템에서 요구 사항을 충족하는지 객관적으로 테스트하거나 검증할 수 있어야 한다. 각 요구 사항에 대한 측정 가능한 기준 또는 인수 테스트에 대한 확인 기준이 포함된다.

7. 타당성: SRS 문서에는 기술, 예산 및 시간 제약을 포함하여 프로젝트의 제약 내에서 실행 가능하고 달성 가능한 요구 사항이 포함되어야 한다. 비현실적이거나 비현실적인 요구 사항은 소프트웨어 프로젝트의 지연, 비용 초과 또는 실패를 초래할 수 있다.

8. 유연성: SRS 문서는 유연해야 하며 프로젝트가 진행됨에 따라 변경 및 업데이트가 가능해야 한다. 새로운 정보를 사용할 수 있거나 소프트웨어 개발 프로세스 중에 이해 관계자의 요구가 진화함에 따라 요구 사항을 쉽게 수정하거나 업데이트할 수 있어야 한다.

9. 이해 가능성: SRS 문서는 비즈니스 사용자, 개발자, 테스터 및 기타 프로젝트 팀 구성원을 포함한 모든 이해 관계자가 쉽게 이해할 수 있는 방식으로 작성되어야 한다. 해석하거나 이해하는 데 전문 기술 지식이 필요하지 않아야 한다.

10. 이해관계자 중심: SRS 문서는 최종 사용자, 고객 및 기타 프로젝트 이해관계자를 포함한 이해관계자의 요구와 기대를 충족시키는 데 중점을 두어야 한다. 최종 소프트웨어 시스템이 기대치를 충족할 수 있도록 우려, 요구 사항 및 우선순위를 명확하게 다루어야 한다.

11. 우선 순위 지정: SRS는 가장 중요한 요구 사항을 먼저 처리하여 요구 사항의 우선순위를 지정해야 합니다.

12. 높은 수준 및 낮은 수준: SRS에는 높은 수준의 요구 사항(예: 전체 시스템 목표)과 낮은 수준의 요구 사항(예: 자세한 기능 요구 사항)이 모두 포함되어야 한다.

13. 관련성: SRS는 개발 ​​중인 소프트웨어 시스템과 관련되어야 하며 불필요하거나 관련 없는 정보를 포함해서는 안 됩니다.

14. 비즈니스 목표와 일치: SRS는 조직의 전반적인 비즈니스 목적 및 목표와 일치해야 소프트웨어 시스템이 비즈니스 요구 사항을 충족할 수 있다.

 

이러한 품질 특성을 고려함으로써 개발자와 이해 관계자는 SRS 문서가 명확하고 완전하며 정확하다는 것을 확인할 수 있다. 이는 결과적으로 최종 소프트웨어 시스템이 비즈니스와 사용자의 요구를 효과적으로 충족하는지 확인하는 데 도움이 된다.

 

좋은 SRS 문서의 특징

1. 정확성

사용자 리뷰는 SRS에 명시된 요구 사항의 정확성을 확인하기 위해 사용된다. SRS는 시스템에서 실질적으로 기대하는 모든 요구 사항을 포함해야 정확하다 할 수 있다. 

 

2. 완전성

SRS의 완전성은 적절한 페이지 번호 매기기, 가능한 한 TBD(to be determined) 부분 해결, 기능적 및 비기능적 요구사항의 철저한 적용 등 다양한 측면을 포함한다. 

 

3. 일관성

SRS의 요구 사항은 요구 사항간에 충돌이 없을 때 일관성 있는 것으로 간주한다. 서로 다른 용어 사용에서 오는 차이, 보고서 및 문서 생성 기간의 충돌과 같은 논리적 불일치로 인해 충돌이 발생할 수 있다. 

 

4. 명확성

명시된 모든 요구 사항이 하나의 해석만 있는 경우 SRS는 모호하지 않은 것으로 간주한다. ER 다이어그램과 같은 모델링 기술 사용, 철저한 검토 및 동료 검토 수행, 기타 모범 사례와 같은 기술은 SRS의 모호성을 방지하는 데 도움이 될 수 있다.

 

5. 중요도 및 안정성에 대한 순위 지정

중요도와 안정성에 따라 요구 사항을 분류하는 기준이 있어야 한다. 각 요구 사항과 함께 식별자 표시를 사용하여 순위 또는 안정성을 나타낼 수 있다. 

6. 수정 가능성 

SRS는 필요에 따라 시스템을 변경할 수 있도록 쉽게 수정할 수 있도록 설계되어야 한다. SRS의 변경 사항을 쉽게 추적하고 관리할 수 있도록 수정 사항에 대한 적절한 인덱싱 및 상호 참조를 구현해야 한다. 

 

7. 검증 가능성

SRS는 시스템이 각 요구 사항을 충족하는 정도를 정량화할 수 있도록 설계해야 한다. "사용자 친화적"과 같은 주관적인 표현등 검증 불가능한 요구 사항을 피하는 것은 SRS가 검증 가능하고 효과적으로 테스트 및 검증할 수 있도록 하는 데 중요하다.

 

8. 추적 가능성

SRS는 요구 사항, 설계 구성 요소, 코드 세그먼트 및 해당 테스트 사례 간에 명확한 추적 가능한 링크를 제공해야 한다. 이를 통해 요구 사항 사양에서 설계, 구현 및 테스트에 이르기까지 소프트웨어 개발 프로세스 전체에서 각 요구 사항을 추적할 수 있도록 구성해 요구 사항 구현을 효과적으로 추적하고 검증할 수 있다.

 

9. 설계 독립성

SRS는 최종 시스템에 대해 여러 설계 대안을 고려할 수 있도록 특정 설계 또는 구현 세부 사항에 구애받지 않아야 한다. 시스템 구현 방법을 지시하기보다는 시스템이 수행해야 하는 작업을 지정하는 데 중점을 두어야 한다. 이를 통해 SRS에서 미리 정의된 설계 결정에 제약을 받지 않고 소프트웨어 개발 프로세스 중에 가장 적합한 설계 접근 방식을 유연하고 자유롭게 선택할 수 있다.

 

10. 테스트 가능성

SRS는 문서에 지정된 요구 사항을 기반으로 테스트 케이스 및 테스트 계획을 쉽게 생성할 수 있도록 작성되어야 한다. 잘 정의된 입력, 예상 출력 및 테스트 가능한 조건이 포함된 명확하고 모호하지 않은 요구 사항을 통해 소프트웨어 시스템의 기능을 확인하기 위한 효과적인 테스트 케이스 및 계획을 보다 쉽게 ​​생성할 수 있다. 이렇게 하면 소프트웨어 개발 프로세스의 테스트 단계에서 시스템을 철저히 테스트할 수 있다.

 

11. 고객의 이해 가능성

SRS는 IT 전문가가 아닐 수도 있는 최종 고객이 이해하기 쉬운 방식으로 작성되어야 한다. 공식적인 표기법과 복잡한 전문 용어를 피하고 명확하고 간단한 언어를 사용하면 고객이 요구 사항을 쉽게 이해할 수 있다. 이를 통해 고객은 요구 사항을 효과적으로 검토하고 피드백을 제공하여 시스템이 고객의 요구 사항과 기대치를 충족하는지 확인할 수 있다. 의사소통은 명확하고 간결해야 하며 최종 고객의 이해를 돕기 위해 불필요한 기술적 복잡성이 없어야 한다. 

 

12. 적절한 추상화 수준

SRS는 문서의 목적과 일치하는 적절한 추상화 수준으로 작성되어야 한다. 예를 들어, SRS가 요구 사항 단계를 위한 것이라면 요구 사항에 대한 명시적이고 자세한 정보를 제공해야 한다. 그러나 SRS가 타당성 조사 또는 높은 수준의 개요에 사용되는 경우 세부 정보를 덜 포함할 수 있다. SRS의 추상화 수준은 소프트웨어 개발 프로세스의 의도된 목적, 대상 및 단계와 일치하도록 신중하게 선택해야 한다. 이렇게 하면 SRS가 지나치게 상세하거나 모호하지 않고 특정 목적에 필요한 적절한 양의 정보를 제공할 수 있다. 이를 통해 이해 관계자는 특정 요구 사항에 대한 적절한 세부 수준에서 요구 사항을 이해할 수 있다.

 

잘 작성된 SRS(소프트웨어 요구사항 사양) 문서의 장점

ㆍSRS가 소프트웨어 시스템에 대한 요구 사항을 명확하게 정의하므로 이해 관계자와 개발자 간의 의사소통 및 이해가 향상된다.

 

ㆍSRS는 재작업 및 변경 요청의 필요성을 줄이는 데 도움이 되므로 소프트웨어 개발 프로세스의 효율성이 향상된다.

ㆍSRS를 통해 최종 소프트웨어 시스템의 품질이 향상되어 모든 요구 사항을 충족할 수 있다.

ㆍSRS는 소프트웨어 시스템이 비즈니스와 사용자의 요구를 충족하도록 도와주므로 이해 관계자 만족도가 높아진다. 

ㆍSRS를 다른 문서 및 아티팩트로 추적할 수 있고 해당 요구 사항을 테스트 및 검증할 수 있으므로 추적 가능성 및 검증 가능성이 향상된다.

ㆍ명료성과 완전성은 좋은 SRS 문서로서 소프트웨어 프로젝트에 대한 명확하고 완전한 사양을 제공하여 모든 이해 관계자가 요구 사항과 목표를 공통적으로 이해할 수 있도록 한다.

ㆍ추적성(Traceability)은 좋은 SRS 문서로서 상세한 요구사항과 사양을 포함하고 있어 소프트웨어 개발 프로세스 전반에 걸쳐 추적을 가능하게 한다.

ㆍ우수한 SRS 문서로서의 테스트 가능성은 소프트웨어가 요구 사항 및 사양을 충족하는지 확인하는 테스트 케이스 및 검증의 기초 역할을 할 수 있다.

ㆍ우수한 SRS 문서로서 개선된 커뮤니케이션시 프로젝트 관리자, 개발자, 테스터 및 고객과 같은 다양한 이해 관계자 간의 커뮤니케이션 도구 역할을 할 수 있다.

ㆍ좋은 SRS 문서로서 재작업 감소는 개발 프로세스 초기에 문제를 식별하고 해결하여 재작업의 필요성을 줄이고 소프트웨어의 전반적인 품질을 향상하는 데 도움이 될 수 있다.

 

SRS가 제대로 작성되지 않은 경우의 단점

ㆍ요구사항이 명확하게 정의되지 않았거나 모호하여 이해관계자와 개발자 간의 혼란과 오해

ㆍSRS가 소프트웨어 시스템의 요구 사항을 정확하게 파악하지 못하므로 재작업 및 변경 요청이 증가

ㆍSRS가 잘못 작성되면 요구 사항이 누락되거나 완전히 충족되지 않을 수 있으므로 최종 소프트웨어 시스템의 품질이 저하

ㆍ제대로 작성되지 않은 SRS가 비즈니스와 사용자의 요구를 정확하게 파악하지 못하기 때문에 이해 관계자의 만족도가 떨어진다

ㆍ제대로 작성되지 않은 SRS를 다른 문서 및 아티팩트로 추적할 수 없고 요구 사항을 테스트 및 검증할 수 없기 때문에 추적 가능성과 검증 가능성이 떨어진다.

ㆍSRS의 품질과 관계없이 요구 사항을 수집하고 검증하는 것은 반복적인 프로세스이며, 이 프로세스는 소프트웨어 개발 프로세스 전반에 걸쳐 지속적으로 검토 및 업데이트되어야 한다.

ㆍ시간 소모: 좋은 SRS 문서를 만드는 것은 특히 복잡한 소프트웨어 프로젝트의 경우 개발 프로세스가 지연될 수 있는 시간 소모적인 프로세스가 될 수 있다.
 
ㆍ변경 및 업데이트: SRS 문서를 변경하거나 업데이트하면 소프트웨어 개발 프로세스가 지연되고 관리가 어려울 수 있다.
 
ㆍ유연성 부족: 상세한 SRS 문서는 개발 프로세스의 유연성을 제한할 수 있으며, 신속한 변화를 위한 개발 방법론이 필요한 프로젝트의 경우 어려울 수 있다.
 
ㆍ제한적인 이해 관계자 참여: SRS 문서를 작성하는 프로세스는 소프트웨어 개발 프로세스에서 이해관계자의 참여를 제한할 수 있으며, 이로 인해 서로 다른 관점에서 협업 및 입력이 부족해질 수 있다.
 
ㆍ모호성: SRS 문서가 잘못 작성되면 모호성과 오해가 발생할 수 있으며, 이는 소프트웨어 개발 프로세스 전반에 걸쳐 문제를 일으킬 수 있다.