요구 사항과 사양의 차이점은 무엇입니까? [닫은]

나는 우리 그룹이 시작하는 프로젝트에 대한 요구 사항과 사양을 개발하는 임무를 맡았습니다.

나는 그 차이를 모른다는 것을 깨달았다. 구글 검색은 저를 더 혼란스럽게 만들었습니다. 어떤 사람들은 사양 이 요구 사항이지만 더 낮은 수준 이라고 말합니다 .

딱딱한 대답은 요구 사항이 프로그램에서 수행해야하는 사양이고 사양은 계획하는 방식입니다.

그것을 보는 또 다른 방법은 요구 사항이 사용자 또는 비즈니스 전체의 관점에서 응용 프로그램을 나타내는 것입니다. 사양은 기술 팀의 관점에서 응용 프로그램을 나타냅니다. 사양과 요구 사항은 대략 동일한 정보를 전달하지만 완전히 다른 두 대상에게 전달됩니다.

요구 사항은 필요한 것을 문서화합니다-방법을 지정하지 말고 무엇을 지정해야합니다.

사양은 요구 사항을 달성하는 방법을 문서화합니다. 방법을 지정해야합니다.

많은 곳에서이 문서들은 분리되어 있지 않으며 상호 교환 적으로 사용됩니다.

저는 항공 우주 분야의 시스템 엔지니어로서 두 용어가 광범위하게 사용됩니다. 구별은 명확하고 다른 사람들이 만드는 것만 큼 복잡하지 않습니다.

사양은 예를 들어 F-14에 대한 주요 항목 개발 사양 시스템 또는 제품을 지정하는 문서입니다. 사양에는 요구 사항, 정의, 참조 문서, 용어집, 검증 정보 등 많은 섹션 / 컨텐츠가 있습니다.

요구 사항은 제품 또는 시스템이해야 할 일의 하나의 문입니다. 스펙에는 수백 가지 요구 사항이있을 수 있습니다. 구식 방법론에 따르면 요구 사항 설명은 요구 사항을 사실 또는 정의와 구분하기 위해 "shall"이라는 단어를 사용해야합니다. (새롭고 번민 한 애들이이 모든 것을 지키는 지 아닌지는 확실하지 않습니다. 까다 로움은 사용되지만 때때로 까다로울 수 있습니다.)

따라서 사양은 요구 사항과 기타 지원 및 보조 정보로 가득 찬 문서입니다.

요구 사항 :

다양한 이해 관계자의 상충 될 수있는 요구 사항을 고려하여 새로운 제품 또는 변경된 제품을 충족시킬 필요성 또는 조건을 결정하십시오.

사양:

시스템을 효율적으로 설계하고 설계 대안 비용을 추정 할 수 있도록 해결해야 할 문제에 대한 정확한 아이디어를 제공합니다. 각 기술 요구 사항의 검증 (자격)을위한 테스터에게 지침을 제공합니다.

인용문은 "Systems Engineering Fundamentals ^* "입니다.

요구 사항은 이해 관계자의 요구를 기반으로하며 사양은보다 상세하고 기술적 인 문서입니다. 그들은 다르지만 같은 것에 대해 이야기합니다.

_{국방 취득 대학 출판사, 2001. PDF 버전 의 텍스트.}

요구 사항은 완제품이 눈으로 무엇을 해야하는지에 대한 사용자의 설명입니다.

사양은 일반적으로 솔루션에 대한 기술적 인 설명으로 요구 사항 등을 포함합니다 (예 : 비용, 기술, 문제 등).

따라서 주요 요점 중 하나는 사양을 작성하기 전에 요구 사항이 우선되어야한다는 것입니다.

( 제품 과 솔루션 이라는 용어 는 동일하지만 다른 관점에서 볼 수 있습니다 ...)

요구 사항-시스템 또는 하위 시스템이 수행해야하는 작업

사양-구성 요소, 서브 시스템 또는 시스템이 무엇인가.

요구 사항 (입력)에 대해 검증을 수행해야 유효한 사양 (출력)이 있음을 입증해야하기 때문에 이는 의료 기기 제조 산업에서 중요합니다. 이 산업의 일반적인 함정은 회사가 (1) 요구 사항을 정의하는 것을 잊어 버리는 것입니다 (요구 사항과 스펙의 차이를 이해하지 못하기 때문에). (2) 사양에 대해서만 확인을 수행하고 (3) 요구 사항이 하위 어셈블리 및 구성 요소 사양으로 정확하게 변환되는지 확인하지 마십시오.

이 작업이 모두 완료되면 제품의 사용자 요구 사항이 충족되었는지 확인해야합니다.

아마도 혼란은 사양이 비즈니스 요구 사항 사양 문서 또는 IEEE 표준 SRS ​​(Software Requirement Specification) 문서를 참조한다고 들었습니다.

IEEE 표준 SRS ​​템플릿 예

또한 사양 이라는 용어는 설계 결정 및 구현 계획을 설명 하는 기술 사양 을 보다 비공식적으로 지칭 한다고 들었습니다 .

편집 : 방금 링크가 잘못되었음을 알았습니다 ... 곧 올바른 링크를 게시 할 것입니다.

사양은 타당성을 통과하여 구현할 준비가 된 요구 사항입니다. 디자인 단계로 발전한 요구 사항입니다.

다시 말해:

• 요구 사항은 "계획된대로"또는 "원하는대로"행동 (또는 비 동작)입니다.
• 사양은 동작 (또는 동작하지 않음) "구축"또는 "구축"

예:

• 요구 사항 : 1. 사용자가 확인 버튼을 누릅니다 2. 시스템 송장을 인쇄
• 사양 : 1. 사용자가 확인 버튼을 누릅니다. 2. 시스템 송장을 인쇄합니다

보시다시피, 둘 다의 내용은 동일 할 수 있습니다. 차이점은 요구 사항이 분석 결과라는 점입니다. 사양은 디자인 아티팩트입니다.

최종 빌드 문서에서는 일반적으로 요구 사항이 사양으로 변환되었으므로 "요구 사항"대신 "사양"이라는 단어가 있습니다.

비고 : 위의 예에는 디자인 제약으로 인해 디자인 요소가 포함되어 있습니다.

요구 사항은 응용 프로그램이하는 일입니다

사양은 응용 프로그램이 수행하는 방식입니다.

그들은 직교해야합니다!

제품 관리자는 요구 사항을 작성하고 헤드 엔지니어는 사양을 작성합니다.

그것을 보는 한 가지 방법, 아마도 올바른 방법은 아닙니다.

요구 사항 은 사용자에게 가치를 제공하는 기능 (기능, 기능, 동작 등)입니다. 내부와 관련이 없습니다. 여기서는 상자의 입력 및 출력 (및 크기, 모양 및 색상) 만 중요합니다.

사양 은 사용자에게 그 가치를 부여하는 기능 (기능, 기능, 동작 등)입니다. 위에서 언급 한 외부 인터페이스 및 특성과 함께 전체 시스템을 정의하기 때문에 상자 내부가 중요합니다.

연구 결과, 특허 및 주택 건설 (계약의 일부)에 사용되는 사양을 찾았습니다.

Webster의 Unabridged Dictionary (3rd New Int'l Ed.)의 요구 사항 정의는 다음과 같습니다.

a) 필요하거나 필요한 것 : 필요성 b) 요구되거나 요구되는 것 : 필수 또는 필수 조건 : 요구되는 품질, 과정 또는 종류의 훈련

위의 내용이 분명히 다르다는 것을 보여줍니다. 나는 당신이 spec의 하위 레벨 요구 사항을 부를 수 있다고 생각하지만 그것이 요구 사항 imho라는 용어의 왜곡이라고 생각합니다.

상용 제품을 만드는 이전 회사에서는 다음과 같은 차이점이있었습니다.

요구 사항은 시스템이 수행해야하는 것입니다. 더 낮은 수준의 세부 요구 사항 일 수 있으며 기능적이거나 기능적이지 않을 수 있습니다.

사양은 시스템이 실제로 구축 된 것들입니다. 예를 들어, 시스템이 –10 ° C에서 동작 X를 가져야한다는 요구 사항이있을 수 있습니다. 시스템의 실제 사양은 시스템이 –5 ° C에서 X를 수행하는 것일 수 있습니다. 이것은 잠재적 인 고객이 시스템을 구매하려고 할 때 전송되는 시트에 있습니다.

이 경우 NB는 사양이 요구 사항과 같지 않습니다.

당신은 육지에 고층 건물을 지을 것이라고 생각하십시오.

이제 시작하기 전에 다음과 같은 요구 사항을 고려해야합니다.

1. 건축 또는 설계 엔지니어
2. 토양 테스트 엔지니어
3. 풍압 시험팀
4. 철거 자
5. 파는 사람
6. 인력
7. 상수도
8. 근로자 생활 / 휴게실
9. 충분한 기금
10. 프로젝트 관리
11. 품질 관리
12. 보안 및 안전 관리

기타.

위의 내용은 고층 빌딩 건설 요구 사항의 일부입니다. 위 팀에서 기술 결과를 얻습니다. 기술 결과는 직업의 일부로 유지됩니다.

이것은 소프트웨어 산업에서 일어나고있는 일입니다. 누군가 UI 디자인, OO 디자인, 데이터베이스 디자인, 그래픽 디자인, 테스트 케이스 디자인, 코딩, 통합과 같은 기술 사양을 작성하는 데 필요한 지식을 제공하는 전문가 그룹입니다. 배포 팀 등

위의 단락은 기술 사양에 전화 할 수있는 핸드북의 일부입니다.