허접.강기사의 재미없는 놀이

요구사항(Requirements)을 알기 위해서 아래를 먼저 얘기해본다. Want는 구체적으로 원하는 것, 필요(Need)를 만족시킬 수 있는 어떤 제품이나 서비스 Need는 기본적으로, 근본적으로 어떤 결핍을 느끼는 것, 그리고 사람에게서 공통적으로 나타나는 현상 출처: https://keydifferences.com/difference-between-needs-and-wants.html 수많은 문제를 해결하는 과정으로 생각하면, 문제는 Wants, Needs를 말하는 것이고 문제를 해결하는 해결책 Solution은 Requirements 인 것이다. Wants --> Needs --> Requirements 출처: https://blogs.managementconcepts.com/2020/09/16/..

※ 해당 글은 "SW 요구사항 개발" 강의를 들으면서 메모하고 싶은 내용을 기록하고 공유하기 위함입니다. 저작권 및 위배가 되는 경우 해당 글은 별도의 공지 없이 삭제될 수 있습니다. 가급적 위배가 되지 않는 내용에서 글을 작성합니다. 검증(테스트)이 어려운 이유는? 이유는 요구사항을 기반으로 해야 하기 때문이다. 즉, 요구사항이 불명확거나, 요구사항이 모호하거나, 요구사항이 일치하지 않거나 충돌이 발생하는 등 모두를 포함해서 검증(테스트)가 어려운 이유이다. 위 ASPICE PAM3.1 그림에서의 V 사이클 그림을 보면 요구사항을 분석하면서 System Qualification Test 단계가 수행된다. 즉 검증(테스트)의 수행이 개발 초기에도 이뤄져야 하고 할 수 있다는 것이다. 그런데 요구사항이 실..

V-Cyclce, Process 등 많은 좋은 말(?)들이 많지만, 결국은 말하고자 하는 점은 요구사항대로 개발하고 구현하고 검증해야 한다. 일 겁니다. ASPICE에서 SYS (System) 에서는 요구사항 시작 단계에 아래와 같이 SYS.1 Requirements Elicitation 이 명기되어 있습니다. 역시 여기서도 요구사항으로 시작합니다. 오늘은 간단하게 Requirements 를 대할 때 어떻게 해야 하는지 말해보고자 합니다. Requirements는 누가 줄까요? 고객이 주는 걸까요? 고객만 주는 걸까요? 고객이 주는 요구사항(Requirements)는 충분할까요? 개발하는데 상세화는 어떤 기준으로 해야 할까요? 요구사항 명세 시 관리해야 하는 수준은 어떻게 해야 할까요? 우리 조직에서 관..

출처: Guide to the Software Engineering Body of Knowledge 참고: 블로그 주인장 마음대로 그림으로 작성하여 업로드 소프트웨어 (또는 시스템) 개발에 있어서 무엇이 개발되어야 하는지를 결정하는 공정을 요구공학 (Requirements Engineering)이라고 부른다. 요구공학은 크게, Requirements Development와 Requirements Management로 구성된다고 볼 수 있다. 쉽게 생각해서 요구사항을 개발하고 검증 (Development)하면서 이는 프로세스적으로 관리되어야 한다는 것이다. (Management) Development와 Management의 주요 단계를 보면 아래와 같다. Development 부분을 간략히 설명하면, 1...