<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="http://valley.egloos.com/rss/style/style.xsl" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>이글루스 '요구사항' 태그 최근글</title>
		<link>http://valley.egloos.com/tag/요구사항</link>
		<description>요구사항</description>
		<language>ko</language>
		<pubDate>Thu, 19 Jan 2012 22:02:09 +0900</pubDate>
		<generator>Egloos</generator>
		<item>
	<title><![CDATA[메모장 - 요구사항 (1)]]></title>
	<link>http://smallhuman.egloos.com/2837033</link>
	<guid>http://smallhuman.egloos.com/2837033</guid>
	<description>
	<![CDATA[ 
0. 사용목적 : 철저하게 '개인용' 자료 정리 및 보관. 5년 단위로 축적되는 메모가 1만 5천개를 넘지 않음. (1500개나 쓰면 잘 쓴거지 ㄱ-...)  1. 모든 메모는 트리형태로 정리가 가능해야 함.  2. 웹브라우저로만 동작함  3. 모바일환경에서도 쉽게 사용할 수 있어야 함.  4. 개발언어는 PHP / 자바스크립트. DB는 MySQL.  5. 백업 및 이주가 간단해야 함.  6. 로그인 유지 기능 지원  7. 메모 간 상호 참조가 간편해야 함.  8. 간단한 수준의 위키형 문법 지원. (꼭 Media Wiki 문법인 것은 아님.)  9. 파일 업로드 및 다운로드가 가능해야 함.  10. 프레임 사용 금지.  11. 태그 지원.  12. 태그의 검색이 쉬워야 함. (알파벳 순 정렬)  13. 메	]]>
	</description>
	<pubDate>Thu, 19 Jan 2012 22:02:09 +0900</pubDate>
	<dc:creator><![CDATA[별 거 있으면 안 되는 블로그]]></dc:creator>
</item>
<item>
	<title><![CDATA[요구받은 전투반경을 채우지 못한 F-35A 전투기]]></title>
	<link>http://dunkbear.egloos.com/3167537</link>
	<guid>http://dunkbear.egloos.com/3167537</guid>
	<description>
	<![CDATA[ 
<img 
				src="http://thumb.egloos.net/100x76/http://pds22.egloos.com/pds/201105/13/63/e0055563_4dcc8d427ba9b.jpg"  
				alt="요구받은 전투반경을 채우지 못한 F-35A 전투기" 
				width="100px"  
				height="76pxpx"
				align="left"
				style="border:1px solid #DDDDDD;margin:0 10px 10px 0px;"
				/> F-35A may need mod's to fix range shortfall (기사 링크)    Flightglobal 기사로, 유출된 2010년 F-35 선정 도입 보고서 (Selection Acquisition Report, 이하 SAR)  에 따르면, 록히드 마틴 (Lockheed Martin)사에서 개발 중인 F-35A JSF (Joint Strike Fighter) 모델이  요구되는 전투반경을 채우지 못해 프로그램 관계자들이 전투기 개량을 고려 중이라는 소식입니다.        (지난 5월 6일에 초도비행을 실시한 F-35A의 세번째 양산형인 AF-8의 모습.© Lockheed Martin)    전투반경 (combat radius)은 무장과 연료를 완전히 장착한 상태에 서 출격해서 도달 가능한 	]]>
	</description>
	<pubDate>Fri, 13 May 2011 11:10:44 +0900</pubDate>
	<dc:creator><![CDATA[파리 날리는 dunkbear의 블로그 2.0!!!]]></dc:creator>
</item>
<item>
	<title><![CDATA[개발 마무리... 무상 유지보수기간 돌입]]></title>
	<link>http://Madrax.egloos.com/4875417</link>
	<guid>http://Madrax.egloos.com/4875417</guid>
	<description>
	<![CDATA[ 
...  근데 기존 시스템 갈아엎어서 메뉴부터 새로 짜야하고,  새로운 시스템이 추가되어 들어가야 하는 이유는 뭘까...  내일이 사용자교육인데!!!   젠장...ㅠ.ㅠ	]]>
	</description>
	<pubDate>Wed, 17 Nov 2010 14:32:01 +0900</pubDate>
	<dc:creator><![CDATA[Noir]]></dc:creator>
</item>
<item>
	<title><![CDATA[소프트웨어 생애주기와 각 단계별 계약 ]]></title>
	<link>http://hjkim348.egloos.com/1068064</link>
	<guid>http://hjkim348.egloos.com/1068064</guid>
	<description>
	<![CDATA[ 
소프트웨어 생애주기와 각 단계별 계약    소프트웨어는 생애주기를 가집니다. 요구사항 수집과 명세 작성부터 시작해서 개발, 배치(구매와 설치) 그리고 유지 보수까지. 처음 몇 단계의 경우 계약 및 법과 관련하여 중점적으로 문제되는 사항들은 주로 소프트웨어 개발 조직의 문제입니다. 소프트웨어의 구매자(사용자)는 구매시점부터 유지 보수에 이르기까지 소프트웨어 계약과 만나게 됩니다.    이하에서 설명하는 것은 소프트웨어 생애주기의 주요 단계들과, 각 단계에서 중요하게 문제되는 계약 및 법적 쟁점들입니다.    1. 요구사항 수집과 명세 작성    소프트웨어 개발팀이 소프트웨어가 어떠한 특성을 가져야 하는지, 어떠한 기술적 구조를 사용해야 하는지를 결정하는 단계입니다. 이때 사용하는 분석 및 모델링 소프트웨어 툴	]]>
	</description>
	<pubDate>Wed, 14 Jul 2010 20:55:06 +0900</pubDate>
	<dc:creator><![CDATA[웹을 여행하는 히치하이커를 위한 법률 지침서]]></dc:creator>
</item>
<item>
	<title><![CDATA[소프트웨어, 솔루션 및 서비스를 구매하는 방법 ]]></title>
	<link>http://hjkim348.egloos.com/1009817</link>
	<guid>http://hjkim348.egloos.com/1009817</guid>
	<description>
	<![CDATA[ 
소프트웨어, 솔루션 및 서비스를 구매하는 방법    주문서, 자료의뢰서(RFI), 제안의뢰서(RFP), 견적요청서(RFQ) 및 계약      기업은 여러가지 방법으로 소프트웨어, 하드웨어 및 솔루션을 구매합니다.    배포용 표준 소프트웨어나 하드웨어를 구매하는 일은 간단합니다. 판매자에게 주문서(Purchase orders)를 보낸 후 소프트웨어나 하드웨어를 수령하면 됩니다.    주문서(Purchase orders)는 구매자가 발급하는 법적 구속력있는 문서입니다. 주문서에 명시된 계약조건에 따라 상품에 대한 대가를 지불하겠다는 의사표시가 담겨 있습니다. 주문서를 보내면 공급자는 상품을 보낼 것이고, 구매자는 상품의 대금을 지불한 의무를 집니다. 주문서를 보냈다면 의사표시에 책임을 져야 합니다. 공급자는 	]]>
	</description>
	<pubDate>Mon, 12 Jul 2010 12:29:42 +0900</pubDate>
	<dc:creator><![CDATA[웹을 여행하는 히치하이커를 위한 법률 지침서]]></dc:creator>
</item>
<item>
	<title><![CDATA[[잡생각] 지금 프로젝트의 딜레마]]></title>
	<link>http://zeous.egloos.com/2545279</link>
	<guid>http://zeous.egloos.com/2545279</guid>
	<description>
	<![CDATA[ 
오늘 점심때 지금 단독 진행하는 프로젝트의 1차 리뷰가 있었다.   이 프로젝트는 내가 처음부터 시작한 것은 아니라서 나를 딜레마에 빠지게 하는 원인이 되기도 한다.같은 팀에 있던 팀원이 진행을 하던 것인데.. 아마 내 기억에 시작도.. 그냥 팀장님이 한번 해봐라.. 해서그 팀원이 시작을 하고 진행을 한것 같은데 조직개편으로 그 팀원의 이적이 결정되면서 졸지에 내가 하게 되었다  프로젝트 시작전에는 프로그램적인 부분보다는 시스템적인 부분과 환경설정이 주가 되는 프로젝트라 많이 해보지 않은 것이라 좀 땡겼고그 팀원이 좀 오랫동안 진행을 한것이라 마무리만 해주면 될것 같아서 선뜻 받아드렸다.   막상 뚜껑을 열어보니.. 제길 ㅠㅜ 마무리가 아니라 이제 시작이다. ㅠㅜ 이번 프로젝트를 끝내고 리플레쉬 휴가를 다녀	]]>
	</description>
	<pubDate>Fri, 19 Feb 2010 16:50:19 +0900</pubDate>
	<dc:creator><![CDATA[결론에 가보기]]></dc:creator>
</item>
<item>
	<title><![CDATA[ 성공적인 요구사항 관리를 위하여 해결해야 할 과제 ]]></title>
	<link>http://lunarboys.egloos.com/2051431</link>
	<guid>http://lunarboys.egloos.com/2051431</guid>
	<description>
	<![CDATA[ 
<img 
				src="http://thumb.egloos.net/100x76/http://pds15.egloos.com/pds/200911/23/70/f0093870_4b0a1a081500e.jpg"  
				alt=" 성공적인 요구사항 관리를 위하여 해결해야 할 과제 " 
				width="100px"  
				height="76pxpx"
				align="left"
				style="border:1px solid #DDDDDD;margin:0 10px 10px 0px;"
				/> &amp;lt;어린아이의 화장은 귀엽기만 하다&amp;gt; 딸이나 조카를 가진 사람이라면 누구나 공감할 만한 것이 있다.바로 아이들의 화장품 장난이다.여성의 아름다움을 강조하기 위한 방법의 하나로, 보통은 성인 여자정도 되야 제대로 배워서 할 수 있다.물론 요즈음에는 중고생도 화장을 많이 하고 다니고 적절히 화장기술도 늘어가는 추세이지만,그래도 성인 여성에게서 느껴지는 원숙함을 벗어날 수는 없다. 유아용 화장도구를 가지고 노는 어린 여자 아이에게 좋은 화장품과 화장기술을 가르쳐 줄 수 있는 선생님 등 최선의 지원을 제공한다 할지라도, 그 아이는 화장을 잘 할수가 없다. 왜냐하면, 화장품이 아이의 연한 피부에 맞지 않을 뿐만 아니라, 그 아이는 화장을 해야 할 필요성을 전혀 느끼지 못하기 때문이다.    &amp;lt;립스틱을 	]]>
	</description>
	<pubDate>Mon, 23 Nov 2009 14:15:04 +0900</pubDate>
	<dc:creator><![CDATA[IT doesn't matter]]></dc:creator>
</item>
<item>
	<title><![CDATA[ 엔터프라이즈2.0시대의 요구사항관리의 필요성 ]]></title>
	<link>http://lunarboys.egloos.com/2051396</link>
	<guid>http://lunarboys.egloos.com/2051396</guid>
	<description>
	<![CDATA[ 
<img 
				src="http://thumb.egloos.net/100x76/http://pds17.egloos.com/pds/200911/23/70/f0093870_4b0a14fac7662.jpg"  
				alt=" 엔터프라이즈2.0시대의 요구사항관리의 필요성 " 
				width="100px"  
				height="76pxpx"
				align="left"
				style="border:1px solid #DDDDDD;margin:0 10px 10px 0px;"
				/>    엔터프라이즈 2.0의 시대가 도래했다.    의미는 기업의 가치 창출을 위해 웹 2.0 도구들을 기업 경영에 적용하는 것으로서,  검색, 연결, 제작, 태그, 확장성, 신호를 제시하고, 웹 2.0의 기업적 활용 측면을 강조하고 있다.  인터넷의 기술과 문화가 개인적 차원을 뛰어넘어 기업 및 비즈니스 영역으로 파급되면서 소셜 소프트웨어(SW) 플랫폼은 기업의 직원과 외부 파트너, 고객이 함께 이용해 기업 경영과 가치 창출에 기여하게 한다.  참여와 공유를 기반으로, 엔터프라이즈 2.0은 기업의 가치 창출이 동반되어야 한다는 전제조건이 필수적이다.    오늘은 엔터프라이즈 개념의 6가지 신호와 고객과 기업의 요구관리가 어떻게 적용되는지 알아 보도록하겠다. 먼저 그전에 짚고 넘어가야 할 것이 있다. 혹시, 	]]>
	</description>
	<pubDate>Mon, 23 Nov 2009 13:55:40 +0900</pubDate>
	<dc:creator><![CDATA[IT doesn't matter]]></dc:creator>
</item>
<item>
	<title><![CDATA[요구 관리 시장의 현황과 요구사항관리 솔루션의 필요성]]></title>
	<link>http://lunarboys.egloos.com/1985153</link>
	<guid>http://lunarboys.egloos.com/1985153</guid>
	<description>
	<![CDATA[ 
<img 
				src="http://thumb.egloos.net/100x76/http://pds16.egloos.com/pds/200911/20/70/f0093870_4b065484ca41f.jpg"  
				alt="요구 관리 시장의 현황과 요구사항관리 솔루션의 .." 
				width="100px"  
				height="76pxpx"
				align="left"
				style="border:1px solid #DDDDDD;margin:0 10px 10px 0px;"
				/> 비용의 손실, 프로세스 과정의 문제? 지난주에 e-bay에서 물건을 샀다. 해외 구매대행이다 보니 주문 후 배송까지 꽤나 오랜 시간이 걸렸다. 환율차이로 인해 그다지 좋은 가격은 아니지만, 국내보다 싸게 살 수 있다는 점 하나에 꽤나 많은 시간을 기다렸다.                                              &amp;lt;tubeman&amp;gt; 휴거스 tubeman이라는 preamp였는데, 내가 원한 건 신형 neon이 들어오는 모델이었는데,정작 배송이 된 모델은 구형모델에 grove 진공관이 달린 모델이었다. 외관상의 차이가 없기에 아마 주문자가 잘못 모델을 보내온 듯 했다.   사실 이전에도 이런 일이 몇 번 있었다. 특히 custom guitar을 제작할 때 내가 생각했던 옵션과 다	]]>
	</description>
	<pubDate>Fri, 20 Nov 2009 17:37:06 +0900</pubDate>
	<dc:creator><![CDATA[IT doesn't matter]]></dc:creator>
</item>
<item>
	<title><![CDATA[스타플을 써보면서 바라는 한 가지]]></title>
	<link>http://entireboy.egloos.com/4203590</link>
	<guid>http://entireboy.egloos.com/4203590</guid>
	<description>
	<![CDATA[ 
심심할 때면 스타플에 들어가서 이것저것 해보고 있다. 내 기록이라는 시간 개념이 나에게는 정말 재밌다. 사실 미투데이 같은 경우는 글을 쓸 때 글 쓴 시간을 수정할 수가 없어서 불편하다. 나같은 경우는 기억력이 좋지 않기 때문에 &quot;밥먹어야지~~&quot;해도 화장실 갔다 오면 기억하지 못 하고 다시 컴퓨터 앞에 앉아 버리는 경우가 많다. 때문에 어떤 글을 쓰려고 해도 제 때 시간 맞춰 쓰기란 쉽지 않아 시간 설정이 되지 않는 서비스는 불편하다.    어쩌면 미투데이는 사용자에게 은연중에 이런 제약 사항을 걸고 핸드폰과 같은 모바일 기기를 통해 수시로 글을 쓸 수 있는 서비스를 파는건지 모르겠다. 나처럼 기억력 좋지 않은 사람은 생각날 때 마다 그 서비스를 사용할테니.. (미투데이에서 핸드폰 문자로 글을 쓰기 위해서는	]]>
	</description>
	<pubDate>Tue, 04 Aug 2009 11:31:21 +0900</pubDate>
	<dc:creator><![CDATA[Sigel's house made of ice 。。。]]></dc:creator>
</item>
<item>
	<title><![CDATA[사용자 스토리]]></title>
	<link>http://testings.egloos.com/5065569</link>
	<guid>http://testings.egloos.com/5065569</guid>
	<description>
	<![CDATA[ 
<img 
				src="http://thumb.egloos.net/76x100/http://pds15.egloos.com/pds/200908/01/30/c0081530_4a7403d9cd983.jpg"  
				alt="사용자 스토리" 
				width="76px"  
				height="100pxpx"
				align="left"
				style="border:1px solid #DDDDDD;margin:0 10px 10px 0px;"
				/>  나에게 요구공학에 대한 다른 세계를 열어준 책이다.  이 블로그에 있는 시미즈 요시오 씨의 요구사항을 캐는 방법은 상당히 유저를 압박하는 방식이다. 사용자들에게 어떤 양식을 주고 이를 채워가는, 그리고 이를 개발자가 도와주는 형태로 요구사항을 이끌어 내고 있다.  그러나 이 책에서는 사용자 중심이다. 어떤 양식을 만들어 채우는 게 아니라 고객을 정하고 이 고객이 요구 사항을 카드에 스토리 형식으로 적어 가는 방법이다.   시미즈 씨의 방법과 사용자 스토리 방법 중 어느게 더 나을까?   답은 없다. 기업의 형태에 따라 사용자를 압박하는 방식이 좋을 수도 있고 사용자 스토리 방식이 더 좋을 수도 있다.  	]]>
	</description>
	<pubDate>Sat, 01 Aug 2009 18:08:55 +0900</pubDate>
	<dc:creator><![CDATA[S/W Testings]]></dc:creator>
</item>
<item>
	<title><![CDATA[소프트웨어 요구사항 정보형태들의 관계]]></title>
	<link>http://relab.egloos.com/2238575</link>
	<guid>http://relab.egloos.com/2238575</guid>
	<description>
	<![CDATA[ 
&lt;p style=&quot;text-align: center&quot;&gt;&lt;img src=&quot;http://pds13.egloos.com/pds/200902/18/48/d0018248_499bf3c051576.jpg&quot; alt=&quot;&quot;/&gt;&lt;span style=&quot;font-size:15pt&quot;&gt;&lt;strong&gt;  			&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-size:15pt&quot;&gt;&lt;strong&gt; Functional&lt;/strong&gt;&lt;/span&gt;&lt;span style=&quot;font-size:12pt&quot;&gt;  		&lt;/span&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Business Requirement&lt;/strong&gt;   비즈니스 요구사항은 간단하게 말하자면, 프로젝트의 범위와 목적을 서술한다. 그리고 요구사항의 서술 형식은 요구사항들을 &quot;	]]>
	</description>
	<pubDate>Wed, 18 Feb 2009 20:37:59 +0900</pubDate>
	<dc:creator><![CDATA[Requirement Engineering Lab.]]></dc:creator>
</item>
<item>
	<title><![CDATA[시스템 개발에서 모두가 이해가능한 문서 작성.]]></title>
	<link>http://relab.egloos.com/2237116</link>
	<guid>http://relab.egloos.com/2237116</guid>
	<description>
	<![CDATA[ 
  전규현님의 블로그에서 읽은 포스팅을 배경으로 트랙백 날립니다. 먼저 전적으로 공감하는 전규현님의 글을 읽고 실제 프로젝트 상황에서 요구사항 관리상의 관련 활동에서 가장 기초적이고 끝까지 잃지 말아야 하지만, 그게 쉽지만은 않은 전제조건이 무엇일까 하는 물음에 다음과 같이 4가지로 정리를 해봤습니다.  1. 프로젝트의 범위와 목적을 명확하게   엄청엄청 중요한 조건이 아닌가 생각을 합니다. 프로젝트 착수 후, 프로젝트의 범위와 목적이 나오게 됩니다.(조직 환경에 따라 범위와 목직이 나온 후 프로젝트가 착수되기도 합니다.) 범위와 목적(Scope &amp;amp; Goal)은 개발 대상의 프로덕트의 특성 및 전체 프로젝트 스케쥴, 예산 규모에 막대한 영향을 끼치게 됩니다. 그렇기 때문에, stakeholder간의 	]]>
	</description>
	<pubDate>Tue, 17 Feb 2009 10:19:44 +0900</pubDate>
	<dc:creator><![CDATA[Requirement Engineering Lab.]]></dc:creator>
</item>
<item>
	<title><![CDATA[요구사항 동결을 없앨 경우 장단점.]]></title>
	<link>http://cavin.egloos.com/4784290</link>
	<guid>http://cavin.egloos.com/4784290</guid>
	<description>
	<![CDATA[ 
요구사항이 추가되거나 변경되는 것은 두가지 경우.첫째, 범위를 넘어서 추가되는 요구사항 둘째, 분석설계과정에서 찾아내지 못한 은닉된 요구사항. 경험상 범위를 벗어나는 요구사항 추가나 수정은 극히 일부. 대부분은 고객이 진정으로 원하는 것을 제공하지 못해서 생기는 경우.freeze는 미흡한 해결안에 대해 침묵(고객,수행팀)을 강요하는 경향으로 변질되곤 함. 이런 경향의 결과는 고객만족도 저하.  불만이 후반에 일거에 분출되는 경우 한계비용 초과로 대처불가 상황 발생하곤 함.  이런 상황에서 requrement freeze를 없애게 되면?- 장점. 고객만족도 향상에 충분히 기여할 수 있음 - 단점, 고객이 원하는 것을 찾지 못하고 프로젝트 후반에 당도할 경우           수행사가 비용을 부담하는 별도 계약	]]>
	</description>
	<pubDate>Sat, 20 Dec 2008 21:38:40 +0900</pubDate>
	<dc:creator><![CDATA[상실의시대]]></dc:creator>
</item>
<item>
	<title><![CDATA[고객이 시스템에 원하는 것 vs 고객이 시스템으로 하는 것]]></title>
	<link>http://classpath.egloos.com/4647251</link>
	<guid>http://classpath.egloos.com/4647251</guid>
	<description>
	<![CDATA[ 
The customer tests should capture the essence of what the customer wants the system to do.    이 포스트는 XUnit Design Pattern 중 위 문장을 번역하다 떠 오른거예요(참고로 번역은 &quot;고객 테스트는 고객이 시스템에 원하는 것이 무엇인가에 대한 정수를 담아야 한다&quot; 라고 했지요. ㅎㅎ )    사실 언뜻보면 제목의 두 구절은 비슷하죠.  시스템으로 하는 것이나 원하는 것이나... 그런데 사실 그렇게 보는 관점이 프로젝트 말미에 있는 요구사항 레볼루션 같은 큰 사건을 일으키는 것이 아닌가 해요. 우리는 주로 엔지니어의 입장에서 고객이 시스템으로 하는 것에 주안점을 두지요. 그래서 특정 업무를 구현할 경우 오프라인의 장표를 온	]]>
	</description>
	<pubDate>Thu, 02 Oct 2008 12:13:51 +0900</pubDate>
	<dc:creator><![CDATA[상상할 수 있는 힘이 모자라다]]></dc:creator>
</item>
	</channel>
</rss>

