• 한국IT서비스학회:학술대회논문집
• /
• 2005.11a
• /
• pp.391-399
• /
• 2005

시스템 개발의 성공과 실패는 요구사항 정의의 명확함에 따라 좌우된다고 해도 지나침이 없다. 요구분석은 요구분석을 수행하는 프로세스 측면과 요구사항을 정의하는 방법적인 측면으로 나눌수 있다. 프로세스 측면은 점증적으로 요구사항을 명확하게 정의하기 위한 것이며, 방법적인 측면은 논리와 근거를 갖춘 형태로 요구사항을 정의하기 위한 것이다. 즉, 요구분석 단계와 요구사항 정의 방법이 요구된다. 본 논문에서는 이벤트 프로세스 모델링의 요구분석 5단계와 요구사항 변경을 예방하는 방법을 제시한다. 요구분석 완료 기준을 제시하고, 이벤트와 프로세스 방법으로 요구사항을 정의하는 방법을 설명한다.

• The Journal of Society for e-Business Studies
• /
• v.8 no.1
• /
• pp.35-54
• /
• 2003

소프트웨어 개발공정 상의 요구사항 문서적 분석에 치중되어 있던 요구사항 분석에 관한 논의는 기업 통합을 더욱 효과적으로 하기 위해 소프트웨어적 차원을 넘어 기업 아키텍처 기반의 정보시스템 개발 및 통합의 필요성에 대한 논의로 확대되고 있다. 본 연구에서는 궁극적으로 기업 아키텍처의 효과적인 수립을 지원하는 요구사항 분석, 관리 프레임 웍과 분석 프로세스를 제시한다. 요구사항 분석 프로세스는 기업 아키텍처의 개념을 바탕으로 다양한 사용자와 관점이 구별하고, 이를 다시 요구사항 추출을 위해 업무적 관점과 정보시스템 관점으로 구분한다. 이러한 요구사항 분석을 위한 프로세스는 기업 아키텍처의 수립을 효율적으로 지원할 것이다.

• Proceedings of the Korean Information Science Society Conference
• /
• 2004.10b
• /
• pp.484-486
• /
• 2004

CMMI는 조직의 역량 성숙도를 향상시키기 위한 소프트웨어 프로세스 개선(SPI) 모델이다 CMMI의 단계적 형태(Staged Representation)의 2레벨을 획득하기 위해서 요구되는 요구사항 관리 프로세스 영역은 요구사항에 대한 협의 확정(Commitment) 활동을 포항하고 있다. 요구사항 관리 프로세스 영역은 이전에 협의 확정된 요구사항이 필요한 경우 변경이 가능하도록 허용하고 있는데, CMMI와 같이 프로세스 중심적인 모델에서 이러한 변경 가능성은 협의 확정 사항의 무한정 확대(Escalation of Commitment)와 같은 문제점을 야기할 수 있다. 본 논문에서는 SPI학계에서 사용되는 협의 확정에 대한 정의를 살펴보고, 이 정의를 CMMI에 적용함으로써 요구사항 관리 프로세스 영역의 협의 확정을 수행하는 활동에서 발생할 수 있는 문제점을 해결하기 위한 방안을 제시한다. 협의 확정의 개념은 Brown에 의해서 정의된 속성(1)과 Meyer에 의해서 제안된 형태(2)를 적용하여 정성적이고 정량적인 관리가 가능할 수 있다. 이를 통하여, 요구사항의 협의 확정에 대한 체계적인 관리가 가능해질 수 있다.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2004.05a
• /
• pp.207-210
• /
• 2004

Waterfall 모델에서의 소프트웨어 개발 단계는 사용자로부터 요구 사항을 정의하고, 이것이 다음 단계의 input 이 되어 개발자에 의해 작업이 진행되는 개발 양식을 따른다. 시스템 요구 사항을 정의할 때에, 프로세스 관점에서 사용자 업무를 이해하고, 이 프로세스에서 사용되는 시스템과의 관계를 정의하여 요구 사항으로 함께 정의한다면, 단순한 시스템의 기능을 정의하여 개발하는 것 보다 시스템의 사용 목적을 이해하고 개발하게 됨으로써, 더 만족도 높은 시스템으로 개발할 수 있게 된다. 프로세스 관점에서 이해하고 정의하는 시스템의 요구 사항은 시스템 보수 작업(Maintenance)시에도 시스템의 상황이 현재 업무 프로세스와 어떻게 연계되어 있는지 파악하기 용이하고, 테스트 단계에서도 테스트 조건이나 테스트 시나리오로서도 활용이 가능하다. 새로운 업무를 담당하는 사람에게도 시스템 개발 요구 사항에서 정의된 업무 프로세스 맵(Map)이 관련 업무를 파악할 수 있는 기초 자료로 재 활용 될 수도 있다. 비즈니스 프로세스 리엔지니어링에서 사용하는 비즈니스 프로세스 맵핑(Mapping) 기술을 소프트웨어 개발 방법론에 적용하여, 요구 분석 단계에서 사용하는 분석 도구로서의 응용을 제안하고자 한다.

• Proceedings of the Korean Information Science Society Conference
• /
• 2012.06b
• /
• pp.172-174
• /
• 2012

요구사항은 소프트웨어 아키텍처 설계의 핵심 요소로서, 아키텍처의 구축과 생성의 근거를 제시해준다. 이러한 요구사항 분석을 위해 다양한 요구사항 분석 방법이 제안되고 있는데 그 중 대표적인 기법은 시나리오 기반의 분석, 목표 기반의 분석, 시나리오를 이용한 목표기반의 분석이다. 그러나 이러한 요구사항 분석 방법들은 정형화되어 있지 않아 요구사항을 분석하는 아키텍트에 의존할 수밖에 없다. 따라서 본 논문에서는 텍스트학을 기반으로 정형화된 기법인 거시구조를 이용한 요구사항 분석 방법을 기반으로 요구사항 분석 프로세스를 개선하여 제안하였다. 기존 연구에서 제안한 거시구조 요구사항 분석 방법을 재해석하여 요구사항을 분석하는 단계를 나누고 각 단계의 시스템 요소 설계와 구조를 정의하여 요구사항 분석 프로세스의 설계를 수행하였다.

• Proceedings of the Korea Society for Simulation Conference
• /
• 2005.05a
• /
• pp.134-138
• /
• 2005

기능적 제한이 있는 하나의 웹 서비스는 다른 기능의 여러 웹 서비스들과 다양한 형태로 조합되어 웹 프로세스(Web Process)를 만들게 된다. 이를 통해 개발에 소요되는 비용과 시간을 줄이고 사용자의 요구사항을 만족시키는 서비스의 유연한 조합이 가능하다. 웹 프로세스의 조합 및 통합 시에 중요한 것은 보다 효과적이고 높은 품질의 서비스를 제공할 수 있도록 하는 것이다. 웹 서비스의 조합과 QoS(Quality of Service) 평가 및 보장에 관한 기존 연구는 사용자가 자신의 QoS 요구사항을 만족하는 웹 서비스를 직접 찾아야 하고, 조합된 웹 프로세스가 원하는 QoS를 만족할 때까지 반복적인 수작업을 수행해야 하는 비효율적인 측면이 있었다. 본 논문에서는 사용자가 조합한 웹 프로세스의 QoS를 분석하고 사용자의 QoS 요구사항에 부합하는 웹 서비스를 지능적으로 찾아주는 QoS 기반 웹 서비스 조합 방법론 및 지원도구를 소개한다. 제안된 도구를 통해 Activity Diagram의 형태로 프로세스를 구성하고 구성된 프로세스의 QoS를 분석하여 QoS 요구사항을 만족하는 웹 프로세스를 효율적으로 구성할 수 있다.

• Journal of KIISE:Software and Applications
• /
• v.30 no.5_6
• /
• pp.503-514
• /
• 2003

In conventional development methodologies, requirements are considered to be not changing after analysis phase, and requirements specifications are used for the next step system design purpose. But in the real world, requirements can be changed and modified throughout the development life cycle according to end-user's more understanding about the target system, new IT technologies, changes of customer environment and market situation, and so on. So there needs a requirements change management process that can extend requirements management over the entire development life cycle and can support managing changes to the requirements after design phase. In this paper, a requirements change management process that can be integrated into conventional development methodologies is proposed to support the extension of requirements life cycle and managing changes to the requirements after design phase. This process was evaluated through an verification test with a widely used development methodology‘MaRMI’.

• Proceedings of the Korean Information Science Society Conference
• /
• 2008.06b
• /
• pp.13-18
• /
• 2008

소프트웨어 시스템 개발에 있어 요구사항 분석 단계는 개발 프로세스의 최 상위 단계로 프로젝트의 성공과 실패를 결정하는 중요한 단계이다. 특히, 반복 점증적 개발 프로세스를 적용하는 경우에 있어 고객 요구사항을 우선순위화하여 제한된 일정과 자원을 활용하여 제품을 개발하는 방법론이 필요하다. 기존 방법과 달리 본 논문에서는 SW QFD를 활용하여 고객관점 우선순위에 개발 관점을 추가하고 하위 수준 (Low Level) 요구사항까지 우선순위화 하는 Enhanced SW QFD 방법론을 제안한다. 고 품질의 소프트웨어 제품 개발을 위해 고객 요구사항을 명확하게 이해하고 고객과 개발자 양방향 관점 우선순위 프로세스를 제시한다.

• Proceedings of the Korean Information Science Society Conference
• /
• 2012.06b
• /
• pp.155-157
• /
• 2012

오늘날의 정보시스템을 개발하는데 파악해야하는 비즈니스 요구사항은 매우 복잡하고 방대하다. 기업의 비즈니스 서비스 대부분을 정보시스템이 제공하고 있기 때문에 이러한 시스템을 개발하는데 있어서 비즈니스 요구사항 분석은 매우 중요한 부분을 차지한다. 하지만 개발에 필요한 시간이 부족하여 정보시스템 개발에서 가장 중요한 비즈니스 요구사항을 충분히 분석하지 못하고 있다. 이러한 비즈니스 요구사항은 비즈니스 프로세스 모델에 잘 나타나 있으며, 이를 활용하면 효율적으로 요구사항을 분석할 수 있게 된다. 이미 비즈니스 프로세스 모델을 시스템 개발에 사용하기 위해 UML Use Case 다이어그램으로 변환하는 연구가 활발하게 진행되었지만 자동화, 관계식별 등의 해결해야 될 문제가 남아있다. 본 논문에서는 비즈니스 요구사항을 빠르고 효율적으로 분석하기 위해 비즈니스 프로세스 모델로부터 UML Use Case 다이어그램으로 추출하는 과정이 자동화가 가능한 방법을 제안한다.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2008.05a
• /
• pp.253-256
• /
• 2008

아직도 많은 프로젝트에서 지속적으로 변화하는 요구사항과 불가능한 납기일정 그리고 품질을 무조건 만족해야 하는 상황에 많은 개발자들이 괴로워하고 있다. 또한 최근 들어 프로젝트들이 그 개발의 방법으로 컴포넌트 기반 개발(CBD)를 많이 사용하고 있다. 이러한 상황에서 재사용성을 강조하는 품질 좋은 컴포넌트를 식별하고, 개발하기란 매우 어렵다. 또한 기존의 CBD 개발 방법의 프로세스가 요구사항을 초기에 고정하고, 그 기반 위에 여러 단계를 거치기 때문에, 납기기간이 짧거나, 요구사항이 고정되지 않았을 경우 많은 어려움에 직면하고 있다. 본 논문에서는 요구사항이 불명확하고, 납기일정이 짧은 프로젝트에서 유용하도록, 작은 단위의 반복과 그 피드백을 통해, 고객의 요구사항 변경에 빠르게 반응할 수 있고, 기존의 컴포넌트 개발 방법을 단순화한 기민한 컴포넌트 개발 프로세스를 제시한다. 이러한 제안된 기법의 실용성을 검증하기 위해 기존 식별 방법과의 비교, 평가를 제시한다.