[정보처리기사 실기 최신문제집] 요구사항 확인

네번째 섹션입니다. 요구사항 확인이라고 되어 있구요. 우리가 지금까지 소프트웨어 개발 방법론 배우고 그 다음에 그 방법론을 테일러링 하고요. 그 다음에 이런 방법론을 활용해서 데이터를 또는 소프트웨어를 개발할 그런 환경을 분석했죠. 그러니까 이제 이렇게 분석된 환경, 식별된 환경 위에서 소프트웨어 개발을 이제 본격적으로 시작을 해야 되죠. 소프트웨어 개발의 가장 첫 번째 단계가 바로 요구사항 확인입니다. 천천히 한번 보도록 할게요. 여기 또 공학이라는 말이 나와 있네요. 요구공학이라고 여전히 제가 빨갛게 처리를 해놨죠. 공학이라는 것은 제가 앞에서도 계속 말씀을 드렸지만 효율이에요, 효율. 요구공학도 마찬가지죠. 요구사항을 효율적으로 관리하는 여러가지 이런 작업들을 이야기 하겠죠. 소프트웨어 개발의 기초가 되는 요구사항이라는 것을 정의도 하고, 문서화도 하고, 관리도 하는 여러가지를 요구공학이라고 한다는 거죠. 이해 관계자들에게 효과적인 소통 수단을 제공하고 불필요한 비용을 절감시킬 수 있다고 되어 있습니다. 이것도 마찬가지죠. 효율 때문에 이런 것들을 할 수 있다는 거죠. 여기 이해 관계자들이 조금 어려울 것 같아서 제가 체크해놨는데 이걸 뭐 암기를 해야 되는 부분은 아니고요. 이해 관계자라는 부분에서 이해를 빼면 이해가 좀 편해요. 그냥 관계자들이라고 생각하시면 됩니다. 어떤 소프트웨어 개발, 어떤 프로젝트 이런 것들과 관계되어 있는 사람들 이렇게 생각하시면 돼요. 어찌됐건 넘어가서 구조화된 요구사항으로 요구사항 변경, 추적이 가능하고요. 요구사항 손실도 최소로 줄일 수가 있다. 요구공학 덕분에 좀 더 효율적으로 개발을 할 수 있게 된다 뭐 그런 얘기죠. 다음에 요구공학 프로세스 도출, 분석, 명세, 검증. 간단하게 표시가 되어 있는데 쉽게 말해서 요구사항을 도출한 다음에 도출한 것들을 분석하고 그 다음에 분석된 걸 명세, 기록하고요. 그 다음에 기록된 내용이 올바르게 기록되어 있는지 검증을 하는 거죠. 이런 단계를 거치는 거고요. 우리가 공부도 이 단계로 진행을 합니다. 요구사항을 이제 효율적으로 관리를 하기 위해서는 우리보다는 사람보다는 기계나 소프트웨어 힘을 빌리는 게 훨씬 좋은데 이 아래쪽에 요구사항 관리 도구라고 나와 있습니다. 요구사항 관리 도구가 하는 일은 당연히 요구공학에서 원하는 또는 요구하는 장점들 이런 것들을 할 수 있는 도구가 되겠죠. 그러니까 간단하게 읽어보시면 될 것 같고요. 굳이 다시 똑같은 내용을 또 체크하고 할 필요는 없을 것 같아서 이대로 보고 그냥 넘어가겠습니다. 자 그래서 요구공학 프로세스 중에 도출에 대해서 먼저 보도록 하죠. 요구사항을 도출한다는 게 어떤 의미인지 이해가 되시면 공부하는 데 굉장히 수월하실 거예요. 요구사항 도출 소프트웨어가 해결해야 할 문제 소프트웨어를 만드는 이유이기도 하죠. 그거를 이해하는 첫 번째 단계로 요구사항을 어디에서 어떻게 수집할 것인지를 결정하는 단계다라고 되어 있는데요. 이건 말이 좀 어렵죠. 쉽게 말해서 그겁니다. 보통 소프트웨어를 개발한다라는 것은 개발자들이 자기들이 필요한 소프트웨어를 개발하는 경우도 물론 있지만 보통은 클라이언트가 요구하는 거에 대한 소프트웨어를 만드는 경우가 대부분이겠죠. 그러면 소프트웨어 개발을 요청하는 클라이언트는 당연히 개발자보다 이런 개발에 관련된 지식이 적을 수밖에 없어요. 그렇기 때문에 이 클라이언트들이 말하는 부분이 정확하게 어떤 기능을 수행했으면 좋겠는지 개발자들의 생각과 클라이언트의 생각이 다를 수가 있죠. 그렇기 때문에 이 공통점을 찾아서 아 그러면 이런 것들을 원하시는 거예요? 라든지 이렇게 정리하고 소통을 해나가면서 최종적으로 아 그럼 이런 이런 이런 기능이 필요하신 거죠? 라고 정리를 하는 단계라고 생각하시면 돼요. 상담 같은 거라고 보시면 되겠죠. 자 그래서 여기 제가 빨갛게 표시를 해놨습니다. 의사소통이 중요하다 이렇게 되어 있죠. 다양한 의사소통을 통해서 요구사항을 도출할 수 있기 때문인데 의사소통 방법이 굉장히 또 많습니다. 이거는 기억해 두셔야 돼요. 우리가 이미 알고 있는 여러 가지 단어들도 있지만 어쨌든 한 번씩 보겠습니다. 인터뷰는 여러 가지 의견을 듣고 이제 받아 적고 뭐 이렇게 할 수 있는 것들이죠. 질문하고 그 다음에 이제 설문은 대면이 아니라 종이로 질문하고 종이로 대답할 수 있게끔 하는 이런 형태고요. 그 다음에 사용자 스토리라는 거는 사용자가 어떤 요구사항을 얘기할 때 보통 이렇게 딱딱하게 표현을 하는 게 아니라 자기들의 여러 가지 말투를 그대로 써서 표현을 하겠죠. 예를 들어서 뭐 회원관리 폼을 만들어 주세요. 뭐 이런 식으로 회원관리 폼에서 뭐 전화번호 검색이 되게끔 만들어 주세요. 이런 식으로 가볍게 이야기 형태로 이야기를 할 거 아니에요. 그런 것들을 사용자 스토리라고 이야기를 합니다. 뭐 그렇고요. 아래쪽에 업무 절차 조사는 뭐 단어 그대로죠. 그 다음에 브레인스토밍 여러 명이 최대한 많은 의견을 내가지고 거기에서 이제 여러 가지 의견이라든지 아이디어를 도출하는 걸 브레인스토밍이라고 하고요. 그 다음에 프로토타이핑은 앞에서 몇 번씩 봤던 내용이죠. 그리고 유스케이스 마지막으로 유스케이스까지 나와 있는데 유스케이스가 이제 이 요구사항을 기능과 관계를 통해서 이제 표현을 하는 도표 뭐 이런 것들입니다. 이 유스케이스가 가장 많이 쓰이는 부분이기 때문에 유스케이스에 대해서 더 자세하게 공부를 하게 될 거예요. 내려가서 유스케이스 같이 보겠습니다. 유스케이스는 사용자와 다른 외부 시스템들이 우리가 만들고자 하는 목표 시스템을 이용해서 어떤 기능을 수행하는지 사용자 관점에서 표현했다라고 되어 있어요. 사용자 관점이라는 거는 이걸 요청한 이 소프트웨어를 요청한 사용자가 이 소프트웨어를 바라봤을 때 이런 식으로 만들어질 거예요라고 사용자가 볼 수 있게 간단하게 표현을 한 겁니다. 어쨌든 그렇고요. 이따가 한번 보여드릴 거예요. 시스템의 범위를 파악할 수가 있고요. 그 다음에 외부 요소와 시스템 간의 상호작용이 어떻게 이루어지는지 이런 것들을 대략적으로 파악을 할 수가 있습니다. 그리고 아래쪽에 고속 요소에 대해서 나와 있는데 여러분들이 필기 공부를 만약에 했다 그리고 좀 기억이 나고 있다고 하면은 이 요소들이 기억이 나실 거예요. 그런데 기억이 안 나실 수도 있으니까 그림을 같이 보면서 한번 이야기를 해 보도록 하죠. 자 요거는 제가 제가 쓴 다른 책에서 이미지를 가지고 온 건데 요걸 유스케이스라고 합니다. 제가 그림을 못 그린 게 아니라 실제로 이런 식으로 간단하게 표현을 해야 됩니다. 천천히 볼게요. 일단은 시스템 관련 유스케이스들을 사각형으로 묶어서 표현한다고 되어 있습니다. 요게 우리가 만들 시스템인 거예요. 도서 대여점. 그래서 이 도서 대여점 안에 여러 가지 요소들이 들어 있죠. 가장 눈에 띄는 게 요 타원이죠. 요 타원. 회원 등록, 사용자 인증 뭐 이런 것들이요. 요게 유스케이스예요. 설명을 보면 사용자 관점에서 제공하는 서비스나 기능을 단순하게 표현을 했다. 기능의 이름을 써놨다 뭐 그런 얘기라고 생각하시면 돼요. 그래서 이제 회원 등록 유스케이스. 그냥 회원 등록 기능이라고 생각하시면 되겠죠. 사용자 인증 기능, 포인트 사용 기능, 도서 대여 기능, 도서 검색, 회원 검색 기능 이런 것들이 포함이 될 거다. 사용자가 딱 봤을 때 직관적으로 파악할 수가 있죠. 요게 이제 유스케이스의 장점입니다. 어쨌든 그렇고요. 계속해서 보겠습니다. 여기 시스템까지 봤고 다음으로는 이제 사용자, 액터, 주 액터라고 보통 표현을 합니다. 상호작용을 통해 이득을 얻는 대상, 보통은 클라이언트가 되겠죠. 요기 요런 애들. 사용자나 관리자가 이제 이 시스템을 통해서 어떤 정보를 얻는다라는 거를 여기서는 이득을 얻는다라고 이야기를 하고 있는 거예요. 어쨌든 그렇고요. 이 왼쪽을 표현을 하고요. 오른쪽에는 이제 부 액터가 있죠. 부 액터는 이 주 액터의 목표 달성을 위해서 우리가 만들진 않았지만 외부에서 얻는 정보들을 외부에서 제공받는 정보들, 그 주체를 부 액터라고 이야기합니다. 여기서 보면은 회원관리 시스템과 도서관리 시스템이 별도로 개발이 되어 있는 거예요. 그 시스템에서 받아오는 정보를 가지고 우리가 목표하고 있는 시스템에서 여러 가지 작업을 한 다음에 주 액터한테 정보를 넘기는 이런 형태가 되는 거죠. 그리고 얘네들의 관계를 이렇게 선으로 표현을 하고 있습니다. 여기 화살표 같은 거는 조금 이따가 다시 한 번 볼 거예요. 이런 것들이 이제 유스케이스다. 이렇게 보시면 되겠습니다. 조금 이따가 다시 한 번 더 볼게요. 그리고 아래쪽에 보면은 유스케이스 기술서라고 되어 있는데 뭐 간단하게 매뉴얼 같은 거라고 보시면 됩니다. 조금 더 구체적으로 내용을 기술한 거다라는 거 정도 보면 될 것 같고요. 이거에 대해서 문제가 나오지는 않을 것 같아요. 계속해서 보겠습니다. 유스케이스 기술서에 대한 구성 요소예요. 읽어보면은 특별하게 어려운 내용은 없습니다. 시나리오 같은 게 써 있는 겁니다. 그래서 이제 어떤 버튼을 누르면 어떤 기능이 수행되고 어떤 값을 입력해야 되고 이런 것들 있죠. 그런 거에 대한 내용이 나와 있는 거기 때문에 간단하게 읽어보시면 좋을 것 같고요. 여기서 헷갈리거나 조금 어려울 수 있는 부분은 제가 이렇게 형광펜으로 처리를 해놨습니다. 특별하게 어려운 내용까지는 아닌데 살짝 이해가 안 될 수도 있는 뭐 그런 것들을 한번 체크를 해놓은 거니까 이거 같은 경우에 다른 부분도 마찬가지 이해가 안 되는 부분이 있다고 하면 질문 게시판에 남겨주시면은 조금 더 자세하게 안내를 드릴게요. 아마 필기하면서 다 공부를 하셨을 거예요. 자 그리고 나서 유스케이스 다이어그램의 관계에 대해서 나와 있습니다. 이게 문제 사실 더 많이 나오죠. 관계가 총 세 가지가 있는데 한번 같이 그림을 보면서 좀 보도록 할게요. 일단은 포함관계, 필수적이라는 말도 씁니다. 공통으로 사용되는 기능을 별도로 추출해서 새로운 유스케이스를 생성하고 연결을 한 관계라고 되어 있고요. 기존 유스케이스에서 새로 만든 유스케이스 방향으로 점선 화살표를 연결하고 include라는 걸 표기하면 된다고 되어 있습니다. 그러니까 include가 붙어 있으면 포함관계다 이렇게 생각하시면 되겠죠. 여기 이미지에서 한번 볼게요. include를 일단 찾습니다. 이거랑 이거잖아요. 이거랑 이거. 자 그러면 오른쪽에 있는 이 점선이겠죠. 이 점선이 이렇게 가 있죠. 이 방향으로. 자 그러면 이 화살표가 있는 화살표를 이렇게 그리면 안 되는데 저는 그냥 일단 이렇게 했습니다. 이 화살표가 이렇게 붙어있는 이 놈이 새로 생긴 거예요. 그러니까 새로 생겼다는 얘기는 얘가 공통기능이라는 뜻이죠. 정리를 하자면 회원 등록 기능 또는 도서대여 기능에서 사용자 인증이라는 기능이 함께 포함이 되어 있었는데 도서대여와 회원 등록이 공통적으로 이 기능을 쓰니까 별도로 추출해서 이렇게 include를 시켜놨다. 포함을 시켜놨다. 이렇게 이야기를 하고 있는 겁니다. 자 다음 넘어갈게요. 다음은 일반화 관계예요. 유스케이스 간의 상위, 하위 관계를 표현한다고 되어 있습니다. 하위 유스케이스에서 상위 방향으로 속이 빈 실선 화살표를 연결한다고 되어 있습니다. 이거예요. 제가 아까 이거 화살표 이렇게 하면 안 되는데 라고 말씀드린 게 이것 때문에 그래요. 여기서는 화살표가 이렇게 그냥 안 닫혀 있는 열린 화살표로 표시가 되어 있고요. 얘 같은 경우에는 화살표가 닫혀 있기도 하고 안이 비어 있기도 합니다. 이런 부분에 차이가 좀 있기 때문에 제가 이거 할 때 이렇게 하면 안 되는데 라고 말씀을 드린 거예요. 어쨌든 그래서 이제 일반화 관계일 때는 상위 방향으로 속이 빈 삼각형이 붙어있는 화살표를 해줘야 된다. 뭐 그런 얘기죠. 그래서 도서검색과 회원검색 유스케이스의 상위 유스케이스가 도서되어다. 이렇게 보시면 되겠습니다. 그리고 확장관계 선택적이라고 되어 있습니다. 얘는 필수적이었죠. 선택적은 특정 조건에서만 실행되는 유스케이스를 생성하고 연결한 관계라고 되어 있습니다. 확장에서는 원래의 유스케이스 방향으로 점선 화살표를 연결하고 익스텐드를 표기한다고 되어 있어요. 화살표의 모양은 똑같아요. 그래서 인클루드 또는 익스텐드 이런 것들을 표기를 하고 있는 거죠. 그래서 요거는 확장이다 라고 이야기를 하고 있는 거죠. 원래의 자 그러면 요걸로 해석을 해보자면 도서되어 기능에 포인트 사용 기능이 확장돼서 달라붙은 겁니다. 그런데 도서되어 할 때 무조건 포인트를 사용하는 건 아니잖아요. 포인트가 없을 수도 있고 포인트 사용을 하기 싫을 수도 있죠. 그러니까 선택적으로만 사용하는 게 포인트 사용 기능이에요. 그렇기 때문에 익스텐드가 붙고 그 다음에 도서되어 쪽으로 점선 화살표가 붙은 겁니다. 그런데 회원 등록과 도서되어는 어때요? 회원 등록을 할 때도 마찬가지지만 도서되어 할 때도 무조건 사용자 인증을 거쳐야 됩니다. 이거는 선택적으로 하는 게 아니죠. 그렇기 때문에 필수적인 거고요. 그렇기 때문에 인글루트가 붙은 거예요. 구분이 되시죠? 이 정도로 해석을 할 수 있으시면 될 것 같아요. 넘어가도록 할게요. 여기서도 추가적으로 궁금한 부분이 있으시면은 언제든지 영상 댓글 말고요. 질문 게시판에 카페에 질문 게시판이 오셔서 질문을 남겨주시면 되겠습니다. 방금 요구사항 도출 포인트에서 인터뷰 여러가지 브레인스토밍도 있었고 프로토타이핑 그 다음에 마지막에 유스케이스까지 해서 여러가지 요구사항을 도출한 다음에 그거를 도표로 정리하는 것까지 진행을 했어요. 그러면 이제 요구사항이 올바르게 도출이 됐는지 분석이 필요합니다. 그래서 이제 다음 포인트가 요구사항 분석이에요. 요구사항 분석은 기능 및 특성을 조정해 나가는 활동이라고 되어 있어요. 이 조정이 포인트예요. 도출된 요구사항 중 명확하지 않거나 서로 상충되는, 서로 어긋나는 요구사항 등이 있으면 분석해서 문제점을 찾아서 해결을 해야 된다. 뭐 그런 얘기죠. 자 이거를 하는 이유 빨갛게 제가 표시를 해놨습니다. 요구사항을 나중에 바꾸게 되면 굉장히 많은 비용이 들어요. 요구사항의 변경은 개발 전체에 영향을 끼치기 때문에 정확하게 분석을 할 필요가 있습니다. 자 그래서 여러가지 분석 기법 같은 게 있겠죠. 첫 번째로 요구사항을 분류합니다. 시스템이 제공해야 할 역량, 성능, 기능 제공이라고 했지만 개발자들 입장에서는 구현이죠. 어떤 성능을, 어떤 기능을, 어떤 역량을 이제 소프트웨어 안에다가 구현을 해야 되는데 이 구현을 우리가 마음대로 하는 게 아니라 요구사항을 기반으로 구현을 한다는 거죠. 자 이 요구사항을 일단 분류를 합니다. 자 그래서 내용에 따라 분류를 하거나 아니면 관점에 따라 분류를 하게 되는데 내용에 따라 분류를 할 때는 기능과 비기능으로 나눠요. 기능은 말 그대로 기능에 관련된 연산에 관련된 요구사항을 이야기 합니다. 어떤 기능이 필요해요? 예를 들어서 뭐 회원 검색 기능이 필요합니다. 이런 게 기능적 요구사항이에요. 비기능적 요구사항은 뭐냐면 최적인 성능이나 또는 보안, 품질, 안정성 등에 대한 요구사항입니다. 예를 들어서 이런 겁니다. 방금 기능적 요구사항 같은 경우에는 회원 검색 기능이 있어야 한다. 이게 이제 기능적 요구사항이었잖아요. 그러면 비기능은 뭐냐면 회원 정보를 검색할 때 예를 들어 2초 이내에 검색이 되어야 한다. 이게 비기능이에요. 이게 품질이나 성능에 관련된 부분이 될 수 있겠죠. 이런 부분에 대해서 정리를 하는 게 비기능입니다. 이렇게 두 가지 형태로 구분을 하는 경우가 있고요. 그다음에 관점 및 대상에 따라서 요구사항을 구분하는 경우 또는 표현하는 경우가 있어요. 사용자 요구사항, 시스템 요구사항이 있는데 사용자 요구사항은 사용자가 보기 편하게 표현을 하는 거고요. 시스템 요구사항은 개발자가 보기 편하게 표현을 하는 겁니다. 그러니까 사용자가 보기 편하려면 친숙해야 되고요. 그다음에 시스템, 개발자가 보기 편하려면 기술적, 전문적인 용어로 표현을 하는 게 좋겠죠. 그래서 분류는 이 정도 보면 될 것 같고요. 그다음에 다른 분석 기법이 뭐가 있냐. 개념 모델링이라고 있습니다. 개념, 이 개념이라는 말이 굉장히 많이 나올 거예요. 모델링도 마찬가지지만 사실 여기서 포인트는 모델링이긴 하죠. 분석된 요구사항을 기반으로 실체를, 실체들의 관계를 모델링, 모델화하는 거다라는 거예요. 현실의 문제를 모델링하는 것으로 요구사항 분석의 핵심 단계라고 되어 있습니다. 이건 어떤 느낌이냐면 예를 들어 업무 시스템을 아까 봤던 이미지를 다시 한번 볼까요? 도서대여점. 사실 도서대여점이라고 하는 시스템은 이 일 말고도 굉장히 다양한 일이 있겠죠. 예를 들어서 사용자 인증을 한다고 하면 사용자 인증이 예를 들어 틀린다든지 인증이 안 되어 있거나 아니면 회원 등록이 안 되어 있는데 갑자기 저 여기 회원이에요 뭐 이렇게 얘기하는 경우도 있을 거고 굉장히 예기치 못한 일이 굉장히 많이 벌어지겠죠. 그런 자잘한 일들을 다 빼고 이 시스템의 핵심 알맹이만 남겨두는 겁니다. 그거를 모형화, 모델링한다고 표현을 해요. 나중에 거기에 살을 붙이는 거죠. 그래서 이렇게 핵심적인 기능들만 딱 모델링을 시켜서 우리가 개발해야 되는 핵심 기능이 뭔지 그거를 파악하는 걸 모델링이다 이렇게 이야기를 합니다. 자 다시 돌아와서 개념 모델은 문제가 발생하는 상황에 대한 공통의 이해와 해결책을 제시한다. 이 문제라는 거는 아까도 말씀드렸듯이 요구사항을 이야기하는 거예요. 요구사항에 대한 공통의 이해. 이걸 딱 보면 서로 오해할 수가 없는 거예요. 누가 봐도 이건 이 기능을 표현한 거구나 라고 정확하게 표현할 수 있게끔 그래서 모델링을 하는 거고요. 그러니까 공통적으로 똑같은 생각을 하게 되니까 해결책도 마찬가지 공통적인 부분이 나오겠죠. 이런 부분을 개념 모델링이라고 하는데 이 모델링은 말 그대로 모형화를 시키는 거기 때문에 이 모형화 된 걸 보여줘야 되잖아요. 그러니까 이 모델링을 표현을 해야 되는데 표현하는 방법이 굉장히 많아요. 근데 이 중에 UML을 가장 많이 사용합니다. 이렇게 기억을 하고 계시면 돼요. 그러니까 UML을 나중에 또 자세하게 배우겠죠. 이렇게 정리를 하시면 될 것 같고요. 모델링은 요정도 보고 모델링이라는 말은 계속 나올 거예요 앞으로. 다음은 요구사항 할당입니다. 요게 약간 우리가 알고 있는 개념이랑 아니면 여러분이 생각하는 개념이랑 약간 다를 수 있어요. 두 문장이지만 볼게요. 정리된 요구사항을 만족시키기 위한 구성요소들을 식별한다. 요구사항을 만족시킨다는 거 말이 좀 어려운데 요구사항을 구현하기 위한 이라고 생각하시면 편할 것 같아요. 요구사항을 정확하게 구현하면 당연히 만족이 되겠죠. 그러니까 요구사항을 실제로 개발하기 위한 구현하기 위한 구성요소들을 식별하는 거 그럼 이걸 구현하기 위해서는 뭐가 필요하지? 이건 거죠. 이거를 생성하는 과정이다 라고 생각하시면 되고요. 구성요소들의 상호작용을 분석해서 추가적인 요구사항을 발견할 수도 있다고 되어 있습니다. 예를 들어서 A라는 요구사항을 구현하기 위해선 가, 나가 필요한데 이 가, 나를 움직이기 위해서는 새로운 다가 필요할 수 있어요. 이런 것들을 추가적인 요구사항이라고 이야기를 하는 거죠. 어떤 느낌인지 아시겠죠? 이런 것들을 요구사항 할당이라고 이야기한다는 거죠. 할당하는 과정에서 추가적으로 요구사항이 발생될 수 있다. 이렇게 정리가 되어 있는 겁니다. 다음은 요구사항 협상입니다. 협상은 서로 뭔가 맞지 않는 부분이 있어서 그걸 조정하는 걸 협상이라고 이야기하죠. 요구사항들이 서로 어긋나서 전부 만족을 못하는 거예요. 이걸 만족시키려면 얘를 만족 못시키고 저걸 만족시키려면 얘네들을 만족 못시키고 이런 경우가 있다는 얘기죠. 그럴 경우에 이거를 합의를 통해서 조정을 해야 되는데 상충하는 경우가 있어요. 이렇게 세 가지가 있습니다. 이해관계자가 요구하는 게 서로 다른 경우 또는 요구사항에서 어떤 자원을 필요로 하는데 이 자원을 필요로 하는 애가 또 하나 있는 거예요. 그럼 자원은 하나인데 필요한 애가 둘이죠. 그러면 어떤 거 하나는 문제가 생길 거 아니에요. 이런 부분 또는 기능적, 비기능적 요구사항이 서로 충돌되는 경우 이 기능을 구현하면 다른 기능에 대한 비기능적 요구사항이 만족이 안 되는 거죠. 이런 부분 이런 것들이 있다. 이 세 가지에 대해서 기억을 좀 해주시면 좋을 것 같고요. 이어서 정형 분석이라고 되어 있습니다. 요구사항 분석 프로세스의 마지막 단계 방금 위에서 했던 거 여러 가지 정리도 하고 구분도 하고 그 다음에 할당도 하고 그 다음에 상충되는 거 합의도 하고 여러 가지 했죠. 그럼 이제 정리가 됐을 거 아니에요. 이 정리가 된 걸 새롭게 표현을 해야 되는데 이때는 명확하게 표현을 해야 됩니다. 정리된 요구사항을 정확하고 명확하게 표현을 할 수 있게끔 그래서 정형 분석이라는 표현을 씁니다. 정확하고 명확하게 표현을 하려면 구문과 의미를 갖는 정형화된 언어를 이용해서 요구사항을 수학적 기호로 표현한다고 되어 있는데 수학적 기호라고 해서 무조건 더하기 빼기 이런 것까지는 아니고요. 더하기 빼기가 들어갈 수 있지만 어떤 기호라든지 어떤 단어를 썼을 때 딱 그 단어가 한 가지의 의미로만 해석될 수 있게끔 정형화된 언어를 사용해야 된다는 뜻이에요. 누가 봐도 오해가 생기지 않게끔 그게 정형 분석의 핵심입니다. 그래서 구문과 의미라는 용어를 사용하는 거고요. 이 정도까지 보시면 되겠습니다. 그러니까 정형 분석을 하는 이유는 오해가 생기지 않게끔 하겠다. 뭐 그런 뜻이 되는 겁니다. 자 다음 정형 분석까지 통해서 완벽하고 깔끔하고 명확하게 요구사항이 정리가 됐어요. 자 이때 사용을 하는 게 구조적 분석이에요. 구조적 분석의 개념은 구조적 개발 방법론 우리가 앞에서 잠깐 봤죠? 그거랑 같은 의미를 가집니다. 그러니까 구조적 개발 방법론에서 나왔던 여러 가지 도표라든지 다이어그림이라든지 그런 것들이 다시 나오겠죠. 한번 볼게요. 정형화된 분석 절차에 따라서 요구사항을 파악했어요. 그 다음에 도형 중심으로 이제 이걸 표현하는 거예요. 구조적 분석의 기본 원리 4가지 나와 있는데 일단 첫 번째 추상화 객체들의 공통된 성질을 추출하여 중요한 특징만 간단하게 표현한다고 되어 있어요. 우리가 어떤 기능을 간단하게 표현할 때 어떻게 썼죠? 유스케이스를 사용했죠? 유스케이스 내부에서도 공통된 기능을 뽑아서 인클루드 했었잖아요. 요런 게 추상화의 개념이라는 거죠. 그리고 우리가 여러 가지 업무 프로세스라든지 업무 절차에서 자잘한 건 다 빼고 핵심적인 알맹이만 남기는 거를 개념 모델링이라고 이야기 했잖아요. 그런 것도 마찬가지 이 추상화의 개념에 포함이 되는 부분인 거죠. 요렇게 보시면 되겠습니다. 그 다음 정형화는 볼 것도 없죠? 위에서 그대로 내려온 내용이에요. 오른쪽에 설명이 문제로 나오진 않을 것 같은데 어쨌든 설명을 읽었을 때 이 왼쪽에 있는 4가지 항목이 생각이 나야 되니까 제가 이해를 돕기 위해서 좀 길게 설명을 했습니다. 앞으로도 계속 나오는 개념이고요. 넘어가서 이제 다음은 구조적 분석도구 여러 가지 종류 앞에서 잠깐 봤던 애들이 좀 있을 거예요. 일단 자료 흐름도입니다. 데이터의 흐름 자료가 데이터잖아요? 데이터의 흐름을 도형으로 표현한 건데 이 흐름이 시간이 아니에요. 그냥 이 데이터가 연산이 돼서 그 다음 데이터가 되고 이 데이터는 어디에 저장이 되고 이런 것들을 파악하는 겁니다. 데이터 흐름에 중심을 두는 거다라는 거고요. 제어 흐름이 아니라 데이터가 어떻게 흘러가는지 이런 부분을 파악할 수 있는 자료 흐름도 자 그래서 구성 요소가 나와 있는데 이것도 기억을 해주시는 게 좋습니다. 어려운 형태는 아니라서 굳이 예시를 들 필요까지는 없을 것 같고요. 다음으로는 자료 사전이에요. 자료 흐름도에 사용된 데이터 데이터가 어디로 흐르고 어디에 저장되고 이렇게 했었잖아요? 그러면 어디에 저장될 때 그 저장되는 저장소는 어떤 식으로 구성이 되어 있는지를 표현한 게 데이터 사전입니다. 자료 사전이요. 자 그래서 데이터의 이름과 속성 등을 표기한 자료라고 하고요. 이런 것들을 메타데이터라고도 한다고 되어 있습니다. 메타데이터도 문제에 나온 적이 있어요. 자 그리고 이걸 표현하는 규칙이 나와 있습니다. 자료의 명명 뭐 다른 두 데이터를 연결하고 복수의 데이터 중 이것들을 선택하고 이것도 이미지를 하나 보여드릴까요? 자 이것도 다른 이론 기본서에 있는 이미지를 가지고 왔는데요. 여기에서 나와 있는 부분에 대한 예시가 나와 있어요. 간단하게 좀 볼까요? 이제 대여번호를 정의하고 있습니다. 여기 등호가 보이죠? 대여번호를 정의하고 있는데 대여번호가 어떻게 만들어지나 봤더니 오른쪽에 대여일 데이터와 회원번호 데이터와 일년번호 데이터가 연결돼서 만들어집니다. 라는 뜻이에요. 여기서 이제 이걸로 볼 수가 있는 거죠. 이제 4월 24일 이번 회원의 첫 번째 대여 값을 이렇게 표현한다는 거예요. 아래쪽에 이것도 좀 볼게요. 선택 이게 지금 이렇게만 남아 있어서 헷갈릴 수 있는데 기억이 안 나시는 분들은 이렇게 표현한다는 거예요. 회원 등급 데이터를 정의하는데 회원 등급은 G나 S나 B 중에 하나를 선택해서 등록을 할 수 있다. 뭐 이렇게 이야기하는 거고요. 그 다음에 여기 아래쪽에 보면은 별, G, S, B가 각각 어떤 의미를 가지는지 적어 놨죠. 이 별 사이에 붙어 있는 거는 데이터를 설명하고 있는 거예요. 주석이라고 표현하는 그런 형태라고 보면 되고요. 그 다음에 주소 데이터는 회원의 거주지 주소를 입력받으면 되는데 괄호가 되어있죠, 소괄호가. 이러면 선택적으로 생략이 가능하다. 뭐 그런 얘기가 되는 겁니다. 이런 식으로 이제 표현이 가능하다는 거고요. 굳이 이렇게까지 공부를 하실 필요가 없을 것 같긴 한데 어쨌든 이해를 하시면 공부하는 데 도움이 되니까요. 한번 보여드렸습니다. 다음은 NS차트예요. NS차트는 이 키워드가 딱 이 세 개입니다. 순차, 선택, 반복의 제어 구조를 명확하게 도형으로 표현합니다. 이걸 NS차트라고 이야기를 하고요. 이건 제가 그림으로 간단하게 표현을 해보면 순차는 이런 겁니다. 예를 들어서 직사각형인 거죠. 직사각형으로 이렇게 순차로 뭔가 진행돼야 되는 것들은 이렇게 입력이 되고요. 그 다음에 반복 같은 경우에는 기억자예요. 이렇게 이런 식으로 표현이 됩니다. 그러니까 기억자 안에 있는 걸 전부 반복하세요. 이런 의미가 되는 거죠. 그 다음에 이제 선택 같은 경우에는 이렇게 삼각형 형태로 작업이 이루어집니다. 이렇게요. 그래서 여기에 어떤 조건이 붙고요. 그 다음에 일로 갈 건지 일로 갈 건지를 결정하는 거죠. 그럼 여기에도 또 이제 직사각형들이 여러 가지가 있겠죠. 그래서 이거에 따라서 일로 이렇게 해서 순차가 진행되거나 이렇게 해서 순차가 진행되는 이런 것들이 계속 반복되는 이런 형식으로 표현이 되어 있으면 이렇게 생각하시면 됩니다. 직관적이기 때문에 프로그램 구현이 굉장히 쉬워요. 이 정도까지 특징이 있고요. 그 다음에 히퍼라고 해서 기능과 데이터의 관계를 계층 계층이 포인트입니다. 여기 계층이라는 말이 써 있습니다. 계층이 포인트고요. 기능과 자료의 의전성을 동시에 표현할 수 있다라고 되어 있는 부분 핵심이고요. 그 다음에 세 가지가 있대요. 가시적, 총체적, 세부적 의미도 외워주시면 제일 좋긴 한데 그것까지 아직은 힘드시면 일단은 세 가지 분류가 있다. 가시, 총체, 세부 이렇게 기억을 해주시면 되겠습니다. 아마 문제로 나온다고 하면 설명이 되어 있고 그 설명을 보고서 가시적인지 총체적인지 이렇게 찾는 이런 느낌으로 나오는 경우가 많을 겁니다. 그렇게 해서 정리를 하시면 될 것 같아요. 그리고 다음 포인트는 요구사항 명세입니다. 우리가 지금까지 자료 흐름도라든지 자료 사전 이런 것들은 이런 것들을 이용해서 표현해야 된다라는 지식을 배운 거고요. 여기서부터는 실제로 이런 것들을 이용해서 기록하는 거예요. 기록을 하는 이유는 체계적으로 검토하고 승인하고 이런 것들을 하기 위해서죠. 보고서 같은 거죠. 요구사항 명세 방식은 정형이 있고 비정형이 있대요. 정형은 제가 방금도 말씀드린 부분이잖아요. 다시 올라가서 보면 구문과 의미를 가진다. 일단 이게 포인트인데 결국에 수학적 기호 딱딱한 표현이라는 뜻이에요. 그래서 수학적 표현으로 요구사항을 정확하게 표현할 수 있긴 한데 비교적 좀 어렵기 때문에 전문가가 보기에는 편한데 좀 이해하는데 많은 시간이 필요할 수도 있다. 뭐 이렇게 써 있는 거고요. 비정형 같은 경우에는 자연어 기반으로 좀 자연스럽게 친숙하게 표현을 한다. 라는 거지만 완전한 검증이 어렵다. 왜냐하면 정확하게 하나로만 이해가 되지 않기 때문이에요. 정형과 비정형의 차이입니다. 정형은 좀 딱딱하고 어렵지만 해석은 딱 한 가지로만 되는 형태고요. 비정형은 받아들이기는 쉬운데 오해가 생길 수 있다는 거죠. 그런 차이가 있다라는 거 보시면 될 것 같고요. 그 다음에 아래쪽에 명세서 작성 시 고려사항에 대해서도 나와 있는데 이거는 굳이 암기를 하실 필요가 있을까 싶습니다. 그냥 당연히 좋은 긍정적인 키워드들만 나와 있겠죠. 특별하게 정의하실 건 없을 것 같습니다. 넘어갈게요 이거는. 마지막으로 요구사항 검증입니다. 힘들게 도출하고 분석하고 그 다음에 명세도 했는데 결국에 한 번 더 최종적으로 검증을 해야 돼요. 정의 보겠습니다. 요구사항을 기반으로 생성된 산출물을 대상으로 요구사항이 올바르게 정확하게 반영되었는지 그 명세를 보면서 다시 한 번 판단을 하는 거예요. 잘못된 요구사항을 기반으로 개발된 소프트웨어를 나중에 수정하려면 이 단계를 또 반복해야 돼요. 그러니까 비용이 두 배로 들겠죠. 엄청난 비용이 소모된다고 되어 있죠. 이것 때문에 한 번 더 검증 시작하기 전에 이게 맞아? 다시 한 번 체크하는 거죠. 이렇게 보시면 되겠습니다. 이 다섯 가지에 대해서 중점적으로 체크를 한다고 되어 있고요. 내려가서 이 검증 기법을 좀 봐야겠죠. 이 요구사항 검증 기법은 딱 여기에만 국한이 되는 게 아니라 여러 가지 여러 가지 문서를 검증하는 데 있어서 여러 가지 방면에서 쓰여요. 참고하시고 일단 요구사항 검토가 있습니다. 검토가 세 가지가 있네요. 동료 검토는 말 그대로 동료들이 이해관계자들이 서로 검토를 하는 거고요. 워크스루 같은 경우에는 미리 요구사항 명세서를 검토하라고 주는 겁니다. 그래서 검토를 미리 해오고 그래서 짧은 회의를 통해서 결함을 분석하는 겁니다. 그래서 내가 보고 왔는데 이런 이런 부분은 문제가 있을 것 같다. 바로 듣고 바로 피드백 받고 이렇게 진행하는 걸 워크스루라고 하고요. 그 다음에 인스펙션은 전문 검토 그룹이 별도로 있는 겁니다. 얘네들이 상세하게 분석을 해주는 거 이걸로 인스펙션이라고 합니다. 동료들이 검토하는 거 미리 보고 오는 거 그 다음에 전문 검토 그룹이 검토해주는 거 이렇게 구분을 한다고 보시면 되겠죠. 넘어가서 자 프로토타이핑 또 나왔습니다. 시제품을 신속하고 간단하게 개발해서 일단 검증을 한다고 되어 있죠. 실제 시제품이지만 어쨌든 간에 제품이기 때문에 즉각적인 피드백이 가능하고요. 단점으로는 반복될수록 어쨌든 이걸 계속 만들어야 되는 거니까 비용이 증가하겠죠. 그리고 사용성이 과대평가될 수 있다고 되어 있어요. 요거는 이제 조금 생각해 보면 상식적으로 맞는 이야기이긴 한데 예를 들어서 우리가 개발해야 되는 기능이 뭐 요정도 있는데요. 프로토타입 같은 경우에는 이 중에 일부분만 개발을 해보고 이걸 테스트 해보는 거예요. 그 다음에 또 일부분 개발해서 테스트 해보고 이런 식으로 쪼개서 테스트를 해보거든요. 시제품이니까 자 그러면 각각 요렇게 요렇게 요렇게 요렇게 개발을 해서 테스트를 해봤을 경우에는 완벽할 수 있잖아요. 자 그런데 이거를 하나로 합치는 과정에서 문제가 생기거나 그런 부분도 당연히 있을 수 있죠. 그런데 이런 걸 테스트 했던 입장으로 봤을 때는 아니 완벽했던 게 갑자기 왜 이렇게 됐어? 이렇게 될 수 있다는 거죠. 요게 이제 사용성이 과대평가될 수 있다. 요런 개념이에요. 다음으로 모델 검증 있습니다. 이 모델은 아까 우리가 개념 모델링 배웠잖아요. 그 개념 모델링을 통해서 나온 게 개념 모델일 텐데 이 모델 자체를 검증해 보는 겁니다. 각각의 모델들이 요구사항을 정확하게 도출했는지 반영했는지 모델 자체를 검증하는 거예요. 굳이 적어보자면 요구사항을 모델링해서 모델을 만들고요. 그 다음에 이 모델을 구현을 해서 소프트웨어를 만드는 건데 이 단계가 아니라 여기서 체크를 하는 겁니다. 그러니까 당연히 구현이 안 됐잖아요 아직. 그러니까 실제 실행을 통해서 검증할 수가 없어요. 모델의 구조나 또는 의사소통이 어떻게 진행됐는지 그런 것들만 파악을 한다는 거죠. 여기 밑에 보면은 이제 실행을 통해서 검증하는 걸 동적, 움직이니까요. 동적이라고 하고요. 그 다음에 움직이지 않는 상태에서 어떤 구조라든지 그런 것들을 파악하는 걸 정적이라고 한다라고 되어 있죠. 이것도 굉장히 자주 나오게 될 거예요. 이 정도 보고 마지막으로 인수 테스트입니다. 인수 테스트는 인수자가 이 프로그램을 의뢰한 인수자가 직접 테스트해서 요구사항을 만족하고 있는지 내가 요구한 것들이 다 지금 이루어져 있는지를 검사하는 방법인데요. 중요한 건 아까도 이야기를 했지만 이런 것들을 요청하는 사람들은 이 프로그램에 대한 또는 개발에 대한 지식이 없기 때문에 어떻게 테스트를 해야 되는지도 정확하게 모를 거란 말이죠. 그렇기 때문에 별도의 계획을 세워야 됩니다. 이런 이런 이런 부분을 확인해 보세요라고 여러 가지 쭉 리스트를 만들어서 이렇게 수행을 해보세요 하면은 이제 아 이렇게 수행을 하면서 아 이런 기능이 제대로 되어 있구나 이런 것들을 확인할 수 있다는 거죠. 계획을 세워야 된다가 포인트입니다. 인수자가 테스트를 하기 위해서 요정도까지 요구사항에 대해서 같이 공부를 해봤습니다.