Automotive spice SYS.1 SYS.2 (System Engineering Process)
이미지는 별도로 저작원을 생각하지 않고, 가져왔으며
문제가될시 삭제합니다.
이 글은 포트폴리오 목적으로 별도의 수익창출을 하지 않습니다.
이 글은 설명을 위해 아래의 내용을 인용하였음을 알립니다.
vda-qmc.de/wp-content/uploads/2023/02/Automotive_SPICE_PAM_31_KR.pdf
Automotive SPICE (flecsim.de)
여튼 이전글에서 다룬 내용으로는
SYS.1을 아주 잠깐 다뤄서
우리가 만들 제품의 요구사항을 이끌어내는 활동을 한다.
이부분을 확인했습니다.
그리고 MAN.3에서 우리가 만드는 제품을 정의, 범위를 정의하고 라이프사이클을 정의하고,
모니터링하는 등등의 이야기를 했습니다.
이번 시간에는 System을 한 번 확인해보도록 하죠
시스템 엔지니어링 프로세스를 살펴보면 아래와 같습니다.
SYS.1 ~ SYS.5까지 V자의 모양을 가지고 있죠
이를 V Model이라고 합니다.
SYS.1 ~ SYS.5까지 순서대로 진행하고 Software 개발로 넘어가는거라고 생각을 할 수 있을텐데
V Model을 구글에 검색해서 살펴보면 아래와 같습니다.
요구사항 수집 -> 시스템 분석 -> 소프트웨어 설계 -> 모델 설계 -> 코딩 -> 단위 테스팅 -> 통합 테스트 -> 시스템 테스트 ->
위의 순서를 거쳐서 개발을 진행한다고해서 V Model이라고 합니다.
그래서 Aspice를 다시 보면
SYS에서 왼쪽에 있는 항목이 시스템을 설계하는 과정
오른쪽에 있는 항목이 시스템을 검증하는 과정입니다.
그리고 시스템 설계가 끝나면, 해당 내용이 소프트웨어로 반영이 됩니다.
Aspice의 설명과 동시에
실제 프로젝트의 예시를 들어서 진행을 하도록 하겠습니다.
주제를 하나 정해볼까요
Automotive Software Process Improvement and Capability dEtermination(Aspice)임으로 소프트웨어가 들어가는 항목의 예를 골라봅시다.
계산기보다 조금더 간단한게 있을까요
초음파 센서를 활용한 공동현관의 자동문은 어떨까요?
참고로 저는 자동문이 실제로 어떻게 동작하는지 모릅니다.
그리고 Automotive SPICE에서 Automotive가 아니라고 뭐라하지 않았으면 합니다.
예를 들기 위해서니까요..
자동문 업체 "A"라는 회사가 있다고 합시다.
여러분에게 찾아와 이렇게 이야기 합니다.
"자동문을 초음파센서를 통해 열고 닫고 싶어요. 문은 준비되어 있으니 Hardware와 Software를 만들어주세요."
그러면 여러분들은 프로젝트를 시작할겁니다.
우선 여러분은 시스템 엔지니어를 "A"회사로 보내
"A"에서 원하는 요구사항을 얻을 것입니다.
이 과정이 SYS.1 Requirements Elicitation 입니다.
SYS.1 Requirements Elicitation
Process Purpose : The purpose of the Requirements Elicitation Process is to gather, process, and track evolving stakeholder needs and requirements throughout the lifecycle of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products.
요구사항 도출 프로세스의 목적은 필요한 작업물을 정의하기 위한 기초로 제공하는 요구사항 베이스라인을 수립하기 위해 제품 및/또는 서비스의 수명주기를 통하여 변화하는 이해관계자의 요구와 요구사항을 수집하고, 처리하고, 추적하는 것이다.
(해석본 참고)
Process Outcomes
1. 이해관계자와의 지속적인 의사소통 방법이 수립된다.
(continuing communication with the stakeholder is established)
2. 합의된 이해관계자의 요구사항이 정의되고 베이스라인이 설정된다.
(agreed stakeholder requirements are defined and baselined)
3. 변화하는 이해관계자 요구를 기반으로 이해관계자 요구사항에 대한 변경을 평가하고, 이해관계자 요구사항의 변경을 베이스라인이 설정된 요구사항으로 포함하기 위한 변경 체계가 수립된다.
(a change mechanism is established to evaluate and incorporate changes to stakeholder requirements into the baselined requirements based on changing stakeholder needs)
4) 이해관계자의 요구를 지속해서 감시하기 위한 체계가 수립된다.
(a mechanism is established for continuous monitoring of stakeholder needs)
5. 고객이 고객 요청에 대한 상태와 처분을 쉽게 결정할 수 있도록 보장하기 위한 체계가 수립된다.
(a mechanism is established for ensuring that customers can easily determine the status and disposition of their requests; and)
6. 변화하는 기술과 변화하는 이해관계자의 요구로 인한 변경이 식별되고, 관련 위험이 평가되고, 그 영향이 관리된다.
(changes arising from changing technology and stakeholder needs are identified, the associated risks assessed and their impact managed)
일단 이론적인 접근을 잠시 멈추고
예시로 든 프로젝트를 Automotive Spice에 따라서 진행해봅시다.
"자동문을 초음파센서를 통해 열고 닫고 싶어요. 문은 준비되어 있으니 Hardware와 Software를 만들어주세요."
우리는 이제 "A"회사와 계약서를 체결했습니다.
그러면 우선 "A"회사로 갑니다.
SYS.1.BP1: Obtain stakeholder requirements and requests. Obtain and define stakeholder requirements and requests through direct solicitation of customer input and through review of customer business proposals (where relevant), target operating and hardware environment, and other documents bearing on customer requirements
SYS.1.BP1: 이해관계자의 요구사항과 요청사항을 입수한다. 고객 입력의 직접적 요청이나 고객의 비즈니스 제안(관련이 있는 경우), 대상 운영 환경 및 하드웨어 환경, 고객 요구사항과 관련된 기타 문서 검토를 통해 이해관계자의 요구사항과 요청사항을 입수하고 정의한다.
비고 1: 요구사항 도출은 고객과 공급업체가 관여할 수 있다.
비고 2: 합의된 이해관계자 요구사항과 변경 사항의 평가가 타당성 연구 및/또는 비용과 시간 분석을 기반으로 수행될 수 있다.
비고 3: 각각의 고객 요구사항에 대한 추적성을 유지하는데 필요한 정보가 수집되고 문서화되어야 한다.
SYS.1.BP2: Understand stakeholder expectations. Ensure that both supplier and customer understand each requirement in the same way.
NOTE 4: Reviewing the requirements and requests with the customer supports a better understanding of customer needs and expectations. Refer to the process SUP.4 Joint Review.
이해관계자의 기대사항을 이해한다. 공급업체와 고객 양측이 각 요구사항을 같은 방식으로 이해하고 있다는 것을 보장한다.
비고 4: 고객과 함께 요구사항과 요청사항을 검토하는 것은 고객의 요구와 기대사항에 대한 더 나은 이해를 지원한다. SUP.4 공동 검토 프로세스를 참조한다
SYS.1.BP3: Agree on requirements. Obtain an explicit agreement from all relevant parties to work on these requirements.
요구사항에 대해 합의한다. 관련 모든 당사자로부터 이러한 요구사항에 대한 업무를 위한 명백한 합의를 얻는다.
ESYS.1.BP4: Establish stakeholder requirements baseline. Formalize the stakeholder's requirements and establish them as a baseline for project use and monitoring against stakeholder needs. The supplier should determine the requirements not stated by the stakeholder but necessary for specified and intended use and include them in the baseline.
SYS.1.BP4: 이해관계자 요구사항 베이스라인을 수립한다. 이해관계자의 요구사항을 공식화하고, 이해관계자의 요구사항을 프로젝트 사용과 이해관계자 요구와 비교하여 감시를 위한 베이스라인으로 수립한다. 공급업체는 이해관계자에 의해 기술되지는 않았지만, 명세된 사용과 의도된 사용에 필요한 요구사항을 결정하고, 이것을 베이스라인에 포함해야 한다.
우선 A 회사의 요구사항을 도출합니다.
"자동문을 초음파센서를 통해 열고 닫고 싶어요. 문은 준비되어 있으니 Hardware와 Software를 만들어주세요."
를 상세화한 요구사항을 얻었습니다.
1: 초음파 센서를 통해 물체를 감지하면, 문을 움직여야한다.
2: 문은 사람의 움직임에만 반응해야한다.
3: 사람이 문에 끼이면, 다시 열려야한다.
4: 전압/전류/온도 등등의 조건
BP1 ~ BP4까지는 요구사항을 수립하고, 서로 어떻게 연락하고, 일정을 수립하는 등의 프로젝트의 시작전의 활동을 의미할 것입니다.
그런데 문제가 발생합니다.
"A"에서 요구사항 변경을 요청합니다.
#1: 초음파 센서를 통해 물체를 감지하면, 문을 움직여야한다.
1: "레이더 센서"를 통해 물체를 감지하면, 문을 움직여야한다.
2: 문은 사람의 움직임에만 반응해야한다.
3: 사람이 문에 끼이면, 다시 열려야한다.
4: 전압/전류/온도 등등의 조건그래서 우리는 초음파 센서를 레이더 센서로 변경하기로 하죠
Aspice에서는 변경에 대한 BP도 정의되어 있습니다.
SYS.1.BP5: Manage stakeholder requirements changes. Manage all changes made to the stakeholder requirements against the stakeholder requirements baseline to ensure enhancements resulting from changing technology and stakeholder needs are identified and that those who are affected by the changes are able to assess the impact and risks and initiate appropriate change control and mitigation actions.
이해관계자 요구사항 변경을 관리한다. 이해관계자 요구사항 베이스라인 대비 이해관계자 요구사항에 대한 모든 변경을 관리함으로써, 기술 및 이해관계자 요구의 변경에 따른 향상이 식별되도록 보장하고, 변경에 의해 영향받는 담당자가 영향 및 위험을 평가할 수 있고, 적절한 변경 통제 및 완화 조치를 시작하도록 보장한다.
비고 5: 요구사항 변경은 예를 들면, 변화하는 기술과 변화하는 이해관계자 요구, 법적 제약 등 다양한 출처에서 발생할 수 있다.
비고 6: 합의된 이해관계자 요구사항을 정의하면서 획득된 정보 및 요구된 정보를 관리하고, 저장하고, 참조하기 위해서는 정보 관리 시스템이 사용될 수 있다
SYS.1.BP6: Establish customer-supplier query communication mechanism. Provide means by which the customer can be aware of the status and disposition of their requirements changes and the supplier can have the ability to communicate necessary information, including data, in a customer-specified language and format.
고객-공급업체 의사소통 체계를 수립한다. 고객이 요구사항 변경의 상태와 처분을 알 수 있게 하고, 공급업체가 고객의 전용 언어와 양식으로 자료를 포함하여 필요한 정보를 의사소통할 수 있는 능력을 갖추도록 하는 수단을 제공한다.
비고 7: 모든 변경은 시간, 비용, 기능적인 면에서 영향을 평가할 수 있도록 변경 이행 전에 고객에게 통보되어야 한다.
비고 8: 이것은 고객의 요구사항과 요청에 대한 상태를 검토하기 위한 고객과의 공동 회의나 공식적인 의사소통 방법을 포함할 수 있다. SUP.4 공동 검토 프로세스를 참조한다.
비고 9: 공급업체에 의해 의사소통되는 정보의 형식은 컴퓨터-지원 설계 자료와 전자 자료 교환을 포함할 수 있다.
돈이 얼마나 들고 이런거는 다 떠나서, 수정을 한다고 합시다.
"A"의 요구대로 초음파 센서를 레이더센서로 교체하기로 합니다.
이때, 우리는 이 변경으로 인한 영향과 위험을 판단해야합니다.
그래서 BP5와 BP6의 목적은 결국
요구사항 변경이 발생하는 경우 현재 우리에게 미치는 영향을 다방면으로 파악해야한다.
이러한 변경은 고객과 의사소통을 통해 모니터링(?)할 수 있게 해야한다.
결론적으로 SYS.1은 고객의 요구사항을 도출하고, 이에대해서 어떻게 개발을 할 것인지, 만약 요구사항의 변경이 발생한다면 어떻게 할 것인지를 다루는 프로세스라고 보면 됩니다.
Support는 잠시 건너뛰고
오늘 SYS.2까지 정리해보죠
사실 시스템 공학(시스템 엔지니어링)이라고 하면, 제가 지금부터 적을 내용보다
더 상세하게 접근을 해야합니다.
소프트웨어 개발에 여러 방법과 이론이 있듯이, 시스템 개발에도 다양한 방법과 이론이 있습니다.
다만, Aspice의 Process 관점에서 접근을 해야하기 때문에 시스템의 상세한 설명은 최대한 생략합니다.
1: 초음파 센서를 통해 물체를 감지하면, 문을 움직여야한다.
2: 문은 사람의 움직임에만 반응해야한다.
3: 사람이 문에 끼이면, 다시 열려야한다.
4: 전압/전류/온도 등등의 조건(일단 앞에서 설명한 변경이 발생하는 경우는, 잠시 무시합시다. 나중의 시점이라고 생각하죠)
SYS.2
Process Purpose : The purpose of the System Requirements Analysis Process is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system.
시스템 요구사항 분석 프로세스의 목적은 정의된 이해관계자 요구사항을 시스템의 설계로 인도할 시스템 요구사항으로 변환하는 것이다.
1) a defined set of system requirements is established;
정의된 시스템 요구사항이 수립된다.
2) system requirements are categorized and analyzed for correctness and verifiability;
시스템 요구사항이 범주화되고 정확성과 검증 가능성을 위해 분석된다.
3) the impact of system requirements on the operating environment is analyzed;
시스템 요구사항이 운영 환경에 미치는 영향이 분석된다.
4) prioritization for implementing the system requirements is defined;
시스템 요구사항을 구현하기 위한 우선순위가 정의된다.
5) the system requirements are updated as needed;
시스템 요구사항이 필요에 따라 갱신된다.
6) consistency and bidirectional traceability are established between stakeholder requirements and system requirements;
일관성과 양방향 추적성이 이해관계자 요구사항과 시스템 요구사항 간에 수립된다.
7) the system requirements are evaluated for cost, schedule and technical impact; and
시스템 요구사항이 비용, 일정, 기술적 영향을 위해 평가된다.
8) the system requirements are agreed and communicated to all affected parties.
시스템 요구사항이 합의되고 영향받는 모든 당사자에게 의사소통된다.
SYS.2의 목적은 우리가 가지고 있는 요구사항을 시스템 요구사항으로 변환하는 행위입니다.
시스템 엔지니어는 성공적인 제품 개발을 위해 요구사항을 취합하고 하드웨어와 소프트웨어가 서로 문제없이 작동할 수 있도록 시스템을 설계해야합니다.
시스템 문서가 어떻게 만들어질지, 이는 BP를 보면서 이해하도록 합시다.
SYS.2.BP1: Specify system requirements. Use the stakeholder requirements and changes to the stakeholder requirements to identify the required functions and capabilities of the system. Specify functional and non-functional system requirements in a system requirements specification.
SYS.2.BP1: 시스템 요구사항을 명세한다. 요구되는 시스템의 기능과 성능을 식별하기 위하여 이해관계자 요구사항과 이해관계자 요구사항에 대한 변경을 사용한다. 시스템 요구사항 명세서에 기능적, 비기능적 시스템 요구사항을 명세한다.
비고 1: 기능과 성능에 영향을 미치는 적용 파라미터는 시스템 요구사항의 일부분이다.
비고 2: 이해관계자 요구사항의 변경을 위해 SUP.10이 적용된다.
여기서 주목할 점은, 요구사항을 식별하고, 기능적요구사항과 비기능적 요구사항을 명세하라는 부분입니다.
여기서 하나 알아야하는 것은 기능과 비기능은 무엇일까요?
기능은 말그대로 문을 열고 닫는 행위를 하는 것의 요구사항입니다.
비기능은 문을 열고 닫는 행위를 하는 것을 보장하는 요구사항입니다.
(기능의 동작은 아니지만, 기능의 동작에 영향을 줄 수 있는 항목으로 요구사항으로 만들어 관리해야하는 항목)
그래서 기능적 요구사항은
"1: 초음파 센서를 통해 물체를 감지하면, 문을 움직여야한다.
2: 문은 사람의 움직임에만 반응해야한다.
3: 사람이 문에 끼이면, 다시 열려야한다."
4: 전압/전류/온도 등등의 조건1~3 항목이라고 볼 수 있습니다.
비기능적 요구사항은 전압, 전류, 온도 등일 수도 있죠
SYS.2.BP2: Structure system requirements. Structure the system requirements in the system requirements specification by e.g.
SYS.2.BP2: 시스템 요구사항을 구조화한다. 시스템 요구사항 명세서에 시스템 요구사항을 다음의 예와 같이 구조화한다.
• grouping to project relevant clusters,
• sorting in a logical order for the project,
• categorizing based on relevant criteria for the project,
• prioritizing according to stakeholder needs.
• 프로젝트 관련 군집으로 그룹화하기,
• 프로젝트를 위한 논리적 순서로 정렬하기,
• 프로젝트를 관련 기준 기반으로 범주화하기
• 이해관계자의 요구에 따라 우선순위화하기
NOTE 3: Prioritizing typically includes the assignment of functional content to planned releases. Refer to SPL.2.BP1.
비고 3: 우선순위화는 일반적으로 기능적 내용을 계획된 출시로 할당하는 것을 포함한다. SPL.2.BP1을 참조한다.
SYS.2.BP4: Analyze the impact on the operating environment. Identify the interfaces between the specified system and other elements of the operating environment. Analyze the impact that the system requirements will have on these interfaces and the operating environment. [Outcome 3, 7]
SYS.2.BP4: 운영 환경에 미치는 영향을 분석한다. 명세된 시스템과 운영 환경의 다른 앨리먼트 간 인터페이스를 식별한다. 시스템 요구사항이 이러한 인터페이스와 운영 환경에 미치는 영향을 분석한다.
이제 요구사항을 시스템 요구사항으로 만들어봅시다.
우선 BP3의 구조화라는게 무엇인지 알야아합니다.
전기전자공학도라면, 신호및 시스템이나 제어시스템을 배울텐데요. 여기서 우리가 원하는 시스템의 개념이 나옵니다.
블록선도에서 블록은 하나의 시스템이고, 화살표 방향으로 들어가는 것이 Input, Output의 개념입니다.
그러면 시스템이라는 것은 결국
Input을 받아서, Output을 내는건데요
자동문을 제어하는 우리의 제어기가
어떤 Input을 받아서 어떤 Output을 냅니다.
"1: 초음파 센서를 통해 물체를 감지하면, 문을 움직여야한다."
"2: 문은 사람의 움직임에만 반응해야한다."
"3: 사람이 문에 끼이면, 다시 열려야한다."
4: 전압/전류/온도 등등의 조건그러면 지금의 요구사항을 만족하기 위해서는
초음파 센서는 한개만 넣는다고 가정하죠
문을 움직여야하기 때문에 모터를 가진다고 합시다.
그러면 하드웨어 적으로 어떤 입력이 들어올 것인가? 이를 먼저 생각해야합니다.
그리고 하드웨어적으로 어떤 출력을 낼 것인지 고려해야합니다.
여기서는 초음파신호가 VCC, GND, Signal을 가진다고 하고
모터는 DC모터이기 때문에 P전원과 N전원을 가진다고 합시다.
그러면 이렇게 하드웨어의 입출력을 구성하면 될 것입니다.
일단 그건 그렇고
이제 시스템 요구사항을 만들어야하는데
BP1에서 구조화를 해야한다고 합니다.
기능으로 묶어봅시다.
초음파 센서에 값이 들어올 것이구요.
다만, 초음파센서가 MCU로 들어오면 이를 전처리 해야 합니다.
그 값에 따라서 Motor를 구동할 것입니다.
그러면 아래와 같이 그룹으로 묶일 것입니다.
이를 preliminary architecture라고 합니다.
그러면 시스템 요구사항을 생각할 수 있겠죠?
(제목만 기술, 기능외 내용 생략)
기능 요구사항
Input Pre Processing
1. 초음파 센서의 입력값을 처리한다.
Logic Processing
2. 초음파의 값에 따라 문을 열거나 닫는다.
Motor Output
3. 모터를 구동하여 문을 연다.
4. 모터를 구동하여 문을 닫는다.
5. 신체가 끼이는 경우 문을 열어야한다.
이렇게 구조화를 하고, 시스템 요구사항을 만들어 냅니다.
SYS.2.BP3: Analyze system requirements. Analyze the specified system requirements including their interdependencies to ensure correctness, technical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact. [Outcome 1, 2, 7]
SYS.2.BP3: 시스템 요구사항을 분석한다. 정확성, 기술적 실현 가능성, 검증 가능성을 보장하고 위험 식별을 지원하기 위해, 명세된 시스템 요구사항을 상호 의존성을 포함하여 분석한다. 비용에 대한 영향, 일정, 기술적 영향을 분석한다. [성과 1, 2, 7]
비고 4: 비용과 일정 관련 영향 분석은 프로젝트 추정치의 조정을 지원한다. MAN.3.BP5를 참조한다.
BP3의 활동은 시스템 요구사항을 리뷰 하면서 실현가능한지 문제는 없는지 확인하는 과정이라고 볼 수 있습니다.
SYS.2.BP5: Develop verification criteria. Develop the verification criteria for each system requirement that define the qualitative and quantitative measures for the verification of a requirement. [Outcome 2, 7]
SYS.2.BP5: 검증 기준을 개발한다. 요구사항의 검증을 위한 정량적 및 정성적 방안을 정의한 검증기준을 각 시스템 요구사항에 대해 개발한다. [성과 2, 7]
비고 5: 검증 기준은 합의된 제약사항 내에서 요구사항이 검증될 수 있음을 증명한다. 검증 기준은 일반적으로 시스템 요구사항의 준수를 보장하기 위한 시스템 시험 케이스나 다른 검증 방안의 개발을 위한 입력으로 사용된다.
비고 6: 시험으로 다룰 수 없는 검증은 SUP.2에서 다룬다.
BP5에 따르면 검증 기준을 작성해야합니다.
우선 알아야할게 있습니다. Aspice를 다시 보면
빨간색으로 표시한 항목이 서로 연관되어 있다고 보면됩니다.
시스템 요구사항을 분석했다면, System Qualification Test를 진행하여 이를 검증합니다.
검증에 대해서는
우리가 만든 시스템 요구사항이 검증이 가능한가? 이를 판단해야합니다.
이 말은 System Qualification Test를 할 수 있는가와 같습니다.
시스템에서 검증이 가능한가의 기준은 뭘까요?
이건 숙제로 남겨놓도록 하죠
결국 검증이 가능한지 확인을 하고, 각 시스템 요구사항에 대한 검증기준을 작성했습니다.
(제목만 기술, 기능외 내용 생략))
기능 요구사항
Input Pre Processing
1. 초음파 센서의 입력값을 처리한다.
(검증 1)
Logic Processing
2. 초음파의 값에 따라 문을 열거나 닫는다.
(검증 1, 검증 2)
Motor Output
3. 모터를 구동하여 문을 연다.
(검증 1)
4. 모터를 구동하여 문을 닫는다.
(검증 1)
5. 신체가 끼이는 경우 문을 열어야한다.
(검증 1)
다음 BP를 확인하죠
SYS.2.BP6: Establish bidirectional traceability. Establish bidirectional traceability between stakeholder requirements and system requirements. [Outcome 6]
SYS.2.BP6: 양방향 추적성을 수립한다. 이해관계자 요구사항과 시스템 요구사항 간의 양방향 추적성을 수립한다. [성과 6]
NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.
비고 7: 양방향 추적성은 커버리지, 일관성, 영향 분석을 지원한다.
SYS.2.BP7: Ensure consistency.Ensure consistency between stakeholder requirements and system requirements. [Outcome 6]
SYS.2.BP7: 일관성을 보장한다. 이해관계자 요구사항과 시스템 요구사항 간의 일관성을 보장한다. [성과 6]
NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
비고 8: 일관성은 양방향 추적성에 의해 지원되고, 검토 기록으로 증명될 수 있다.
BP6과 BP7은 Aspice에서 중요한 요소중에 하나입니다.
추적성을 수립해라.
우리가 Aspcie를 이야기할 때, V모델을 사용한다고 했습니다.
요구사항 -> 시스템 -> 소프트웨어 -> 구현 -> 검증 -> ??
"A"회사가 요구한 요구사항 있어요
이게 시스템에도 반영이되어야하고, 소프트웨어에도 반영이 되어야하거든요
그러면 V모델을 따라서 요구사항이 반영이되고 있다는 것을 증명을 해야합니다.
그러면 시스템 요구사항 분석은 이렇게되겠죠?
(제목만 기술, 기능외 내용 생략))
기능 요구사항
Input Pre Processing
1. 초음파 센서의 입력값을 처리한다.
(검증 1)
"요구사항1"
Logic Processing
2. 초음파의 값에 따라 문을 열거나 닫는다.
(검증 1, 검증 2)
"요구사항1"
~~
5. 신체가 끼이는 경우 문을 열어야한다.
(검증 1)
"요구사항3"대충 요구사항이 시스템 요구사항에 어떻게 반영되어 있는지 따라갈 수 있는거죠
근데, 현재는 아래의 요구사항이 반영되어 있다고 보기 어렵습니다.
요구사항 2: 문은 사람의 움직임에만 반응해야한다.
그러니 이에 대한 요구사항을 시스템 요구사항에 반영해야합니다.
그런데 내가 만약에 시스템 요구사항에
1: 초음파 센서를 통해 물체를 감지하면, 문을 작동해야한다
2: 문은 사람의 움직임에만 반응해야한다.
3: 사람이 문에 끼이면, 다시 열려야한다.
4: 전압/전류/온도 등등의 조건위의 내용이 아닌
문은 강아지의 움직임에 반응해 작동해야한다를 시스템 요구사항으로 만들면
이는 일관성을 잃는다고 볼 수 있을 것입니다.
그러니 문제가될 수 있겠죠
SYS.2.BP8: Communicate agreed system requirements.Communicate the agreed system requirements and updates to system requirements to all relevant parties. [Outcome 8]
SYS.2.BP8: 합의된 시스템 요구사항을 의사소통한다. 합의된 시스템 요구사항과 시스템 요구사항에 대한 갱신 내용을 관련 모든 당사자에게 의사소통한다. [성과 8]
A랑 의사소통 잘하고, 수정하게 되는 경우 관련 당사자랑 잘 의사소통해라 이런겁니다.
그래서 SYS.2는 고객의 요구사항을
시스템의 관점에서 시스셈 요구사항으로 분석하는 행위이며
구현가능해야하고, 검증가능해야하며, 추적성이 유지되도록 설계되어야 합니다.
작성을 다하고, 조금 다듬었습니다.
내용을 조금 삭제했어요..
다음은 SYS.3이 아니라
추적성, 변경 등등에 대한 내용이 지금 글에 담긴 것 같으니
Support 프로세스로 들어가보도록 하죠.