분류 전체보기 (279) 썸네일형 리스트형 유스케이스 기술서 정의와 실제 적용 사례 안녕하세요 시란입니다. 지난번 포스팅에서는 유스케이스 다이어그램을 만들었는데요, 이번포스팅에서는 유스케이스 기술서를 작성해 보도록 하겠습니다. 유스케이스 기술서 유스케이스 기술서는 액터가 해당 유스케이스의 목적을 달성하기 위해 시스템과 상호작용을 하는 과정을 구체적으로 묘사한 과정을 기술한 것으로 유스케이스 다이어그램에 있는 각 유스케이스에 대해 유스케이스를 작성해야 합니다. 자세한 설명은 아래 참고 링크를 확인하시기 바랍니다. https://siran.tistory.com/178 유스케이스 다이어그램 작성 방법에 대해서 및 실제 예시 안녕하세요 시란입니다. 현재 시스템개발쪽에 일을 하고 있습니다. 현 회사에서 요구하고 있는 부분은 회사의 업무 프로세스를 현재는 다양한 툴을 사용해서 기록 또는 관리를 하.. 유스케이스 다이어그램 간략한 설명과 실제 적용 예시 액터 식별 - 주 사용자와 관리자 그리고 그 외 시스템에 접근하는 사물에 대해서 정의한다. 시스템 외부에 존재하는 타 시스템이나 타 데이터베이스 서버 등을 표현하기도 한다. 유스케이스 식별 - 사용자가 시스템을 통해 얻으려는 기능을 유스케이스 단위로 식별한다. 유스케이스 다이어그램 작성 - 액터와 유스케이스 간 관계를 설정하며 유스케이스들 간 관계를 설정합니다. 유스케이스 명세서 작성 - 유스케이스명과 액터명 및 개요를 기술하고 사전 및 사후 조건과 제약사항들을 식별하고 작업 흐름과 시나리오를 동시에 도출하고 유스케이스를 포함 또는 확장 유스케이스로 구조화 합니다. 액터는 시스템 외부에 존재하는 사람 또는 사물, 그리고 시스템을 접근하는 타 시스템이나 타 데이터베이스 서버 등이 될수 있으며, 사람의 역할.. 유스케이스 다이어그램과 유스케이스 기술서 실무 적용 - 2 안녕하세요 시란입니다. 저번 포스팅에 이어서 이번 포스팅에서도 유스케이스 다이어그램과 기술서를 작성해보는 시간을 가져보겠습니다. 기술이전 관리자의 입장에서 시스템에서 필요한 기능들을 한번 정리해보았습니다. 아래 내용은 아마 포스팅을 읽으시는 분들에게 도움이 안되는 개인적인 업무 내용입니다. 내용을 패스하시는걸 추천드립니다. 참고로 공식적인 유스케이스 다이어그램은 아닙니다. 디자인에 신경을 안썼으며, 대신 설계 방면으로 좀 더 고민을 하려고 합니다. 또한 유스케이스와 액터간의 관계에 대해서도 신경쓰지 않았습니다. 대신 아래 기술서에서 설명했으니 양해 바랍니다. 현 개발할 시스템의 경우 사용자는 전 포스팅에서 언급드렸듯이 기술이전 관리자와 발명자 그리고 재재권 관리자, 기술이전수요기업들이 있습니다. 그중 이.. 유스케이스 다이어그램과 유스케이스 기술서 현 회사 내용 요구사항 분석과 사용자 입장에서 시스템 사용에 대해서 예상을 해보았습니다. 먼저 소프트웨어를 개발하는 이유에 대해서 간단하게 얘기해보겠습니다. 가장 큰 이유는 고객의 문제를 해결하기 위해서입니다. 따라서 소프트웨어 개발에 있어 가장 우선적으로 해야 할 일은 문제를 이해하는 문제입니다. 이 문제를 해결하기 위해서는 고객의 요구사항을 잘 파악해야하며 고객과의 소통이 정말 중요합니다. 그리고 고객의 언어와 프로그래머의 언어가 다름을 인정하고 고객의 입장에서 소통을 해야합니다. 당연히 고객의 입장에서는 프로그램을 모르기 때문이지요. 따라서 고객의 요구사항 분석이 필요하며 고객의 문제의 실체를 이해하고 분석해 분석 모델을 구축하고 그런 다음에 설계 모델을 통해 고객의 문제를 해결하는 해결책을 표현한 다음 그 이후.. 유스케이스 다이어그램 작성 방법에 대해서 및 실제 예시 안녕하세요 시란입니다. 현재 시스템개발쪽에 일을 하고 있습니다. 현 회사에서 요구하고 있는 부분은 회사의 업무 프로세스를 현재는 다양한 툴을 사용해서 기록 또는 관리를 하고 있습니다. 이를 통합하고 모든 사람이 볼수 있도록 또는 관리를 쉽게 할 수 있도록 통합할 시스템 제작을 요청하셨습니다. 이를 위해 사용자 입장에서 필요한 기능들을 개인적으로 한번 나열해보았어요. 그리고 이를 유스케이스 다이어그램으로 작성하고자 합니다. 그리고 유스케이스 다이어그램과 동시에 유스케이스 기술서를 작성하고자 합니다. 일단 그러기 위해서는 유스케이스 다이어그램과 유스케이스 기술서 형식에 대해서 알아봐야합니다. 일단 유스케이스 다이어그램이 뭔지에 대해서 알아봐야합니다. 참고로 유스케이스 다이어그램을 지원하는 툴은 정말 많습니다.. IT 상식 공부 - 스마트강의실과 VDI 가상화와 양방향 미러링, DLNA 개념 정리 안녕하세요 시란이에요. 금일 한 교수님의 스마트 강의실 관련 시연을 보기로 했습니다. (외근인데 퇴근시간 지나는건 안자랑 ㅠ) 스마트 강의실에 대해서 시연을 하신다고 하는데 대충 개념은 이렇습니다. 교수와 학생의 컴퓨터가 연결되고 실시간으로 학생들의 컴퓨터를 컨트롤 가능하며, 학생들의 코딩을 수정해주고 봐줄수 있는 개념이지만 정확히 어떤 기술이 들어가고 어떤 한계점과 개념이 필요한지는 모르겠더라고요. 그래서 한번 스마트 강의실에 필요한 기술들에 대해서 알아보고 개념을 한번 정리해보려고 합니다. 데스크톱의 가상화(VDI): 물리적으로 존재하진 않지만 실제 작동하는 컴퓨터 안에서 작동하는 또 하나의 컴퓨터를 만들수 있는 기술이라고 합니다. 데스크톱 가상화는 데이터센터에 있는 서버를 컴퓨터 작업을 실행 하는데.. 좋은 기능 명세를 작성하기 위한 꿀 TIP! 안녕하세요 시란입니다. 저번시간에는 명세서가 무엇인지에 대해서 포스팅 했었어요 이번 시간에는 좋은 기능 명세를 작성하기 위한 꿀팁을 한번 알아보도록 하겠습니다. 표준 명세서가 있다면 이를 따라하는것보다는 자신의 상황에 맞게 작성하는것이 중요합니다. 그리고 명세서를 읽는 사람이 편하게 읽을수 있도록 작성하는것이 중요합니다. 만약 명세서가 유쾌하고 읽기 쉽다고 해서 당신을 얕보는 회사가 있다면 다른 회사를 가는것을 추천드린다고 합니다... 또한 명세 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사합니다. 무슨말이냐면 문서를 소개하려는 대상을 감안하고 그 사람이 무엇을 이해하길 바라는지 먼저 생각하는것이 중요합니다. 즉 독자층을 배려해야 합니다. 그래야 비 전공자가 읽어도 의사소통이 가능할 것입니다. .. 소프트웨어 요구사항 명세서 (기능명세서)에 대해서 알아보자 안녕하세요 시란입니다. 이번시간에는 소프트웨어를 설계함에 있어 필요한 문서인 기능명세서에 대해서 알아보려고 합니다. 프로젝트 처음 시작할 때 아무리 시간이 없다고 해도 필요한 문서가 2가지 있습니다 문서의 양은 30~50페이지를 넘지 않는다. SRS 일명 Software Requirements Specification 과, SAD Software Architecture Document 입니다. 그중 SRS에 대해서 얘기하려고 알아보겠습니다. SRS가 중요한것은 스펙을 정함으로써 모든 개발의 모든 분야 일정 예측, 설계 구현, 테스트의 기준이 되고 개발 진행 상황파악, 의사소통이 가능해집니다. 소프트웨어 프로젝트에 있어 요구사항은 무엇을 하는 소프트웨어를 만들지 결정하는 단계입니다. 요구사항을 작성하는 목.. 이전 1 ··· 11 12 13 14 15 16 17 ··· 35 다음