• Journal of KIISE:Software and Applications
• /
• v.33 no.1
• /
• pp.58-68
• /
• 2006

Requirements are very important to model software architecture. Requirements are divided into functional and quality requirements. Functional requirements are pinpointed subsystems and components. Quality requirements affect the structure of architecture. Thus requirements are essential to understand clearly in order to design software architecture. This paper focuses on a quantitative approach to requirements analysis for modeling architectures. In our proposal, functional requirements are quantified through calculating each priority of components. Quality requirements are quantified through calculating the correlation degree between components and quality attributes. The proposed method is implemented by DRAMA (Domain Requirements Analysis for Modeling Architectures), which fully supports our approach and are developed in Java environments. Our proposal is validated to apply some industrial examples.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2008.11a
• /
• pp.570-573
• /
• 2008

최근 시스템을 구축하는데 있어서 점점 더 많은 상용 컴포넌트가 쓰이고 있다. 컴포넌트에서 핵심 요소로 작용하는 요구사항은 기능 요구사항과 비기능 요구사항으로 나뉘며, 실질적인 컴포넌트의 재사용에 있어서 비기능적이 요소가 결정적인 기준으로 작용하고 있다. 비기능 요구사항은 해당 시스템이 지원해야 할 기능 요구사항의 제약사항 또는 품질 속성을 말하며, 소프트웨어의 품질 요구 사항으로 반영된다. 결국 시스템의 품질을 보장하기 위해서는 시스템을 구성하는 컴포넌트가 가진 품질을 고려해야 한다. 따라서 본 논문에서는 시스템의 품질에 관여하는 비기능 요구사항을 분석 및 반영 하기 위해 품질 속성이나 제약사항과 같은 컴포넌트가 가져야 할 비기능 요구사항을 고려한 컴포넌트의 추출 기법을 제안한다. 비기능 요구사항의 분석은 UML의 유스케이스에서 이루어지며 기능-비기능 요구사항의 영향관계를 고려하여 컴포넌트를 추출한다. 추출된 컴포넌트는 문서화를 통해 잘 기술된 제약사항 및 품질 요구사항에 대한 정보를 가지고 있기 때문에 보다 효과적인 컴포넌트를 이용한 개발을 가능케 한다.

• 시스템엔지니어링워크숍
• /
• s.1
• /
• pp.127-133
• /
• 2003

시나리오 형태의 요구사항 분류는 ATAM, SAAM, Software Quality Metric 과 같은 품질 요구사항 분석 및 평가 방법 등 많은 분야에 응용된다. 이들 기법들은 소프트웨어 시스템의 품질 요구사항을 분석, 평가하기에 앞서 초기 수집된 요구사항들을 분류하게 된다. 그러나 요구사항을 분류하는 일은 수작업을 통해 이루어지게 되고, 따라서 미 분류, 중복분류, 등의 결함을 가질 수 있다. 결함의 가능성을 요구사항의 수가 많은 대형 프로젝트 일수록 높아지게 된다. 따라서 본 논문에서는 요구사항 분류언어를 통한 품질 요구사항 자동 분류 기법을 제안한다. 제안된 기법은 분류언어와 유사도를 이용한 2 단계 분류기법을 이용하였다. 분류언어는 각 도메인별로 개발되어 비슷한 도메인일 경우 재사용될 수 있다. 이를 검증하기 위해, 본 논문에서는 15 여개의 프로젝트로부터 수집된 요구사항을 이용해 실험을 수행하고 그 결과를 분석, 평가 하였다.

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

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

• Journal of KIISE:Software and Applications
• /
• v.33 no.7
• /
• pp.615-623
• /
• 2006

A non-functional requirement is a property or quality that the proposed systems have to support the functional requirements. A non-functional requirement is reflected by quality attribute These non-functional requirements playa crucial role during system development, serving as selection criteria for choosing among decisions. It should be continuously considered through the software development process. In spite of the importance of the non-functional requirements, it received little attention because of ambiguousness and invisibility of non-functional requirements. Therefore non-functional model which is a process to analyze the non-functional requirement is proposed for improving the management efficiency of non-functional requirements. Also, this paper presents the trace among the UML diagrams to the conceptual model. According to the non-functional requirement development process, this paper achieved performance-based case study. After then, non-functional requirement should be traced using the UML diagrams.

• Proceedings of the Korean Information Science Society Conference
• /
• 2004.04b
• /
• pp.412-414
• /
• 2004

요구사항 추출 단계에서 고객의 요구의 일부가 반영되지 않거나 명확히 기술하지 않은 요구사항은 개발단계에서 많은 수정 작업이 요구되고, 심지어 그 프로젝트가 실패하게 되는 요인이 된다. 이와 같은 요구사항의 문제로 인한 추가적인 비용은 전체 개발비용의 30~50%나 소요된다(Boehm 과 Papaccio 1988). 하지만 요구사항 추출 단계에서 고객이 원하는 요구를 가능한 많이 추출하고 검증함으로써 추가적인 변경으로 인한 개발비용의 비용을 줄일 수 있다. 고객의 요구를 정확히 반영하기 위해서는 요구사항 추출 과정에서 고객의 참여가 매우 중요한데 본 논문에서는 성공적인 요구사항 추출 및 검증과 명세를 위해 사용자의 참여를 높이기 위한 웹 기반 요구사항 추출 도구를 소개하고 명확한 요구사항을 표현할 수 있기 위해 다이어그램을 통합한 요구사랑 관리도구를 제시한다.

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

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

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

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

• The Journal of the Korea Contents Association
• /
• v.8 no.5
• /
• pp.61-71
• /
• 2008

It is often claimed that the descriptive way of documentation is insufficient to define software requirements as being unambiguous. This is caused by not only the difference of knowledge and understanding of the stakeholder as to system but also the difference in the way of documentation like method of representation as well as depth of description. The study explains the process and results of applying a diagraming tool like UML to improve the requirements of GLORY(GLObal Resource management sYstem) initially defined in descriptive way. Especially, the result shows that the requirements are more accurately improved with the good hierarchies and well-leveled functionalities, with the help of diagraming tool, expecting easy maintenance of requirements and prevention of omission of requirements.

• The KIPS Transactions:PartD
• /
• v.14D no.6
• /
• pp.641-648
• /
• 2007

To develop a dynamic system project in which the requirement changes frequently, it's impossible to finish the development within a fixed-cost due to additional budget occurring in need of requirement creep. To manage the successive project within a fixed-cost, it's better to manage the ratio of necessarily changed size of project and necessary optional requirement. According to Bhagwat, it is occurred in the construction phase. Also, he stated that the software development cost, construction phase cost and requirement cost are equal and it was wrong explanation in the ratio of requirement creep and optional requirement. This paper assumes the requirement creep to be happening in the phase of elaboration and construction. In addition, some differences were supposed to happen between software development cost, construction phase cost, and requirement creep cost. As a result, the reality was preferred rather than the ratio of optional requirement and the ratio of requirement creep.