소프트웨어 개발 프로세스의 요구사항 단계를 생성하는 것은 소프트웨어 요구사항 사양(SRS) (라고도 함 요구사항 문서 ). 이 보고서는 소프트웨어 엔지니어링 활동의 기반을 마련하고 전체 요구 사항을 도출하고 분석할 때 구성됩니다. SRS 고객이 해당 소프트웨어(SRS)가 자신의 요구 사항에 맞는지 검토할 수 있도록 하는 소프트웨어를 나타내는 공식 보고서입니다. 또한 시스템에 대한 사용자 요구사항과 시스템 요구사항의 세부 사양으로 구성됩니다.
SRS는 특정 환경에서 특정 기능을 수행하는 특정 소프트웨어 제품, 프로그램 또는 응용 프로그램 세트에 대한 사양입니다. 작성하는 사람에 따라 여러 가지 목표를 제공합니다. 첫째, SRS는 시스템 클라이언트에 의해 작성될 수 있습니다. 둘째, SRS는 시스템 개발자가 작성할 수 있습니다. 두 가지 방법은 전혀 다른 상황을 만들고 문서의 목적도 완전히 다릅니다. 첫 번째 경우인 SRS는 사용자의 요구와 기대를 정의하는 데 사용됩니다. 두 번째 사례인 SRS는 다양한 목적으로 작성되어 고객과 개발자 간의 계약 문서 역할을 합니다.
좋은 SRS의 특징
좋은 SRS 문서의 특징은 다음과 같습니다.
1. 정확성: 사용자 리뷰는 SRS에 명시된 요구 사항의 정확성을 제공하는 데 사용됩니다. SRS는 시스템에서 실제로 기대되는 모든 요구 사항을 충족한다면 완벽하다고 합니다.
2. 완전성: SRS는 다음 요소를 포함하는 경우에만 완전합니다.
(1). 기능, 성능, 디자인, 제약 조건, 속성 또는 외부 인터페이스와 관련된 모든 필수 요구 사항.
회사와 회사의 차이
(2). 사용 가능한 모든 상황 범주에서 실현 가능한 모든 클래스의 입력 데이터에 대한 소프트웨어의 응답을 정의합니다.
참고: 유효한 값과 잘못된 값 모두에 대한 응답을 지정하는 것이 중요합니다.
(삼). SRS의 모든 그림, 표, 다이어그램에 대한 전체 레이블 및 참조와 모든 용어 및 측정 단위의 정의.
3. 일관성: SRS는 충돌에 설명된 개별 요구 사항의 하위 집합이 없는 경우에만 일관성이 있습니다. SRS에는 세 가지 유형의 충돌이 발생할 수 있습니다.
(1). 실제 개체의 지정된 특성이 충돌할 수 있습니다. 예를 들어,
(a) 출력 보고서의 형식은 한 요구사항에서는 표 형식으로 설명되지만 다른 요구사항에서는 텍스트 형식으로 설명될 수 있습니다.
(b) 한 조건에서는 모든 등이 녹색이어야 한다고 명시하고 다른 조건에서는 모든 표시등이 파란색이어야 한다고 명시할 수 있습니다.
(2). 지정된 두 작업 사이에 합리적이거나 일시적인 충돌이 있을 수 있습니다. 예를 들어,
(a) 한 가지 요구 사항은 프로그램이 두 개의 입력을 추가하도록 결정할 수 있고, 다른 요구 사항은 프로그램이 두 입력을 곱하도록 결정할 수 있습니다.
(b) 한 조건에서는 'A'가 항상 'B' 뒤에 와야 한다고 명시하고, 다른 조건에서는 'A와 B'가 동시에 발생해야 한다고 명시할 수 있습니다.
(삼). 두 개 이상의 요구 사항이 동일한 실제 개체를 정의하지만 해당 개체에 대해 서로 다른 용어를 사용할 수 있습니다. 예를 들어, 사용자 입력에 대한 프로그램의 요청은 한 요구 사항에서는 '프롬프트'로, 다른 요구 사항에서는 '큐'로 불릴 수 있습니다. 표준 용어와 설명을 사용하면 일관성이 향상됩니다.
4. 명확성: 모든 고정 요구사항에 하나의 해석만 있을 때 SRS는 모호하지 않습니다. 이는 각 요소가 고유하게 해석된다는 것을 의미합니다. 여러 정의와 함께 사용되는 방법이 있는 경우 요구 사항 보고서는 SRS의 의미를 명확하고 이해하기 쉽도록 결정해야 합니다.
5. 중요성과 안정성에 대한 순위: SRS의 각 요구 사항에 해당 특정 요구 사항의 중요성이나 안정성을 나타내는 식별자가 있는 경우 SRS의 순위는 중요도와 안정성에 따라 결정됩니다.
일반적으로 모든 요구 사항이 똑같이 중요하지는 않습니다. 특히 생명에 중요한 응용 프로그램의 경우 일부 전제 조건은 필수적일 수 있지만 다른 전제 조건은 바람직할 수 있습니다. 이러한 차이점을 명확하고 명시적으로 나타내기 위해 각 요소를 식별해야 합니다. 요구 사항 순위를 매기는 또 다른 방법은 항목 클래스를 필수, 조건부, 선택 사항으로 구분하는 것입니다.
정렬된 배열 목록
6. 수정 가능성: SRS는 최대한 수정 가능해야 하며 어느 정도 시스템 변경 사항을 신속하게 가져올 수 있어야 합니다. 수정 사항은 완벽하게 색인화되고 상호 참조되어야 합니다.
7. 검증 가능성: SRS는 최종 소프트웨어가 해당 요구 사항을 충족하는지 여부를 확인하기 위해 비용 효율적인 시스템으로 지정된 요구 사항을 확인할 수 있을 때 정확합니다. 요구사항은 리뷰를 통해 검증됩니다.
8. 추적성: SRS는 각 요구사항의 출처가 명확하고 향후 개발 또는 개선 문서에서 각 조건을 쉽게 참조할 수 있는 경우 추적 가능합니다.
추적성에는 두 가지 유형이 있습니다.
1. 역추적성: 이는 이전 문서에서 해당 소스를 명시적으로 참조하는 각 요구 사항에 따라 달라집니다.
2. 전방 추적성: 이는 고유한 이름이나 참조 번호가 있는 SRS의 각 요소에 따라 다릅니다.
SRS의 전방 추적성은 소프트웨어 제품이 운영 및 유지 관리 단계에 들어갈 때 특히 중요합니다. 코드와 설계 문서가 수정되면 해당 수정과 관련된 전체 요구 사항을 확인할 수 있어야 합니다.
9. 디자인 독립성: 최종 시스템에 대한 여러 설계 대안 중에서 선택할 수 있는 옵션이 있어야 합니다. 보다 구체적으로 SRS에는 구현 세부 정보가 포함되어서는 안 됩니다.
10. 테스트 가능성: SRS는 보고서에서 테스트 케이스와 테스트 계획을 쉽게 생성할 수 있는 방법으로 작성되어야 합니다.
11. 고객이 이해할 수 있는 사항: 최종 사용자는 자신의 명시적 영역에 대한 전문가일 수 있지만 컴퓨터 과학에 대한 교육을 받지 않았을 수도 있습니다. 그러므로 공식적인 표기법과 기호의 목적은 가능한 한 피해야 합니다. 언어는 단순하고 명확하게 유지되어야 합니다.
정렬 목록 자바
12. 적절한 추상화 수준: SRS가 요구사항 단계에 대해 작성된 경우 세부사항을 명시적으로 설명해야 합니다. 반면 타당성 조사의 경우 더 적은 수의 분석을 사용할 수 있습니다. 따라서 추상화 수준은 SRS의 목적에 따라 수정됩니다.
좋은 SRS 문서의 속성
좋은 SRS 문서의 필수 속성은 다음과 같습니다.
간결한: SRS 보고서는 간결해야 하며 동시에 모호하지 않고 일관되며 완전해야 합니다. 장황하고 관련성이 없는 설명은 가독성을 떨어뜨리고 오류 가능성도 높입니다.
구조: 체계적으로 잘 구성되어 있어야 합니다. 잘 구성된 문서는 이해하고 수정하기 쉽습니다. 실제로 SRS 문서는 사용자 요구 사항에 부응하기 위해 여러 번 개정되었습니다. 사용자 요구 사항은 일정 기간에 걸쳐 발전하는 경우가 많습니다. 따라서 SRS 문서를 쉽게 수정하려면 보고서를 체계적으로 구성하는 것이 중요합니다.
블랙박스 보기: 시스템이 수행해야 하는 작업만 정의해야 하며 이를 수행하는 방법에 대한 언급은 삼가해야 합니다. 이는 SRS 문서가 시스템의 외부 동작을 정의해야 하며 구현 문제를 논의해서는 안 된다는 것을 의미합니다. SRS 보고서는 개발할 시스템을 블랙박스로 보아야 하며 외부에서 볼 수 있는 시스템 동작을 정의해야 합니다. 이러한 이유로 SRS 보고서는 시스템의 블랙박스 사양이라고도 알려져 있습니다.
개념적 무결성: 독자가 이해할 수 있도록 개념적 무결성을 보여주어야 합니다. 원하지 않는 사건에 대한 반응: 원하지 않는 사건에 대해 수용 가능한 반응을 특성화해야 합니다. 이를 예외적인 조건에 대한 시스템 응답이라고 합니다.
증명할 수 있는: SRS 문서에 문서화된 시스템의 모든 요구 사항이 정확해야 합니다. 이는 구현 시 요구 사항이 충족되었는지 여부를 결정하는 것이 가능해야 함을 의미합니다.