Requirement는 개발의 시작이고, 여러 단계를 수행하면서도 계속 엮여있는 output 입니다.
그래서 New development에 대해서 한번에 complete한 output을 만드는 것은 아주 어렵고 극히 드문 경우라고 생각합니다. 물론 제품의 개발 규모, 요구사항의 복잡성 등을 고려해보면 차이가 있겠지만, 그렇다고 해도 어려운 일입니다.
개인적인 경험에서 말씀 드리면, Requirement는 최초 작성할 경우에는 Inspection과 같은 Formal verification method를 적용하는 것이 바람직하다고 생각합니다. 여러 이해관계자들이 신중하고 충분하게 시간을 가지고서 검토해야 하기 때문입니다. 이후 변경되는 범위, 중요도에 따라 Walkthrough, Peer-review, tech-review 등 다른 방법도 함께 고려하는 것을 권장 드립니다.
참고로, Requirements는 여기서 말씀 드리는 Review 하는 시점에서 최초/초기 verification 되지만, 이후에도 verification될 수 있는 프로세스 포인트는 남아 있습니다. Test plan을 작성하거나, Test case 도출 또는 FMEA, FMEDA 등을 예로 들 수 있습니다.
그러면 Review 시 대상에 따라 달라지는 Checklist를 제외하고 어떤 정보가 고려될 수 있을까요?
아래에 간략하게(?) 공통된 기본 정보를 기술해 봅니다. 참고하시기 바랍니다.
1. Work product name: Review 대상이 되는 산출물 이름
2. Document ID: 문서 번호
3. Review method/category: 적용되는 리뷰 방법 (Plan에 기술된 방법을 고려해서 결정합니다. Review 방법 뿐만 아니라 Internal review인지, External: e.g., Customer meeting인지 구분할 수 있습니다)
4. Related phase: 대상 산출물이 포함된 개발 단계는 어디인지, * Requirement는 System, HW, SW와 같은 도메인 뿐만 아니라 개발 수명 주기 동안 Proto, Pilot 등의 단계에서도 업데이트될 수 있습니다.
5. Review purpose: 최초 작성, 업데이트 검토 등 기술
6. Date Planned: 리뷰가 계획되어 있던 일자
7. Date Conducted: 리뷰가 수행된 일자
8. Review duration: 리뷰 수행 기간
9. Preparation time: 리뷰 준비 시간 (Review를 요청하거나 Moderator 하는 담당자가 기술합니다. 참고로 Tool을 사용해서 리뷰를 수행하는 경우 Ticket 발행이라든지, Checklist 업데이트라든지 준비하는 시간이 소요되게 됩니다.)
10. Review process: 표준 프로세스와 동일하다면 skip, tailoring 된 프로세스를 적용된다면 기술 또는 Plan에 포함되어 있다면 skip.
11. Review status: 리뷰 결과 상태를 간략하게 요약한다면? Yello, Green, Red 와 같은 척도를 적용할 수 있습니다. 사용한다면 직관적인 척도를 사용하는 것이 좋습니다.
12. Review Result: 리뷰 결과를 숫자로 기술합니다. Question은 몇 개, Formal issue, Minor issue, Major issue 등을 기술 합니다. 실제로 상세한 리뷰 결과는 Checklist의 Comment 또는 별도로 참고합니다.
13. Follow up is necessary: Re-inspection이 필요하다면 Yes, 아니라면 No로 기술할 수 있겠죠
14. Follow up date planned: Re-inspeciton 계획 날짜
위 내용은 필수 내용이라고 할 수는 없습니다만, 프로세스적으로 또는 Management 측면에서도 필요한 내용입니다. Review status, Review category 등과 같은 정보는 제외시키고 사용하셔도 괜찮습니다. (Optional 하게 사용)
위 간략한(?) 기본 정보에서 Participants는 빠져 있습니다. 산출물의 중요도와 검토를 위해서는 여러 이해 관계자가 포함되는 것이 좋지만, 많은 인원이 포함된다고 해서 좋은 리뷰를 수행하는 것이 아니니 반드시 필요한 인원과 추가 인원을 잘 구분하셔야 합니다.
Safety Requirements review checklist를 첨부합니다.
이 체크리스트는 Exida에서 제작한 "Functional safety an IEC 61508 SIL 3 Compliant Development Process"라는 책에서 발췌한 내용입니다.
자동차 산업에서 활용하는 그리고 Requirement가 아닌 Architecture, Source code, Test case 등 다른 대상 산출물에서 활용되는 체크리스트의 내용이 궁금하시면 개인적으로 연락 주시기 바랍니다. 단 연락 주셔도 일부 sample만 말씀 드릴 수 있는 점 양해하여 주시기 바랍니다.
이상 읽어 주셔서 감사합니다.
'기능안전(Functional Safety)' 카테고리의 다른 글
| Relationship between ISO 26262 and others (0) | 2021.03.24 |
|---|---|
| GSN: Goal Structuring Notation (0) | 2021.01.15 |
| ISO 26262 Gap analysis guideline (0) | 2019.08.09 |
| Flowchart of the ISO/PAS 21448 activities (1) | 2019.04.08 |
| Scope of ISO 26262 1st vs. 2nd Edition (0) | 2019.03.07 |