새소식

대학생활/소프트웨어공학

소프트웨어 공학 이론 정리 -6장- <요구사항 분석>

  • -

Establishing the Groundwork

작업을 수행하기 전 확립해야 할 사전 작업에 대한 논의

-      Stakeholder를 확인한다. [유저, 스폰서, 개발자]

-      Stakeholder가 다양한 관점을 갖는다는 것을 인지할 수 있어야 한다.

-      Stakeholder간 협업을 할 수 있어야 한다.

-      첫 번째 질의

  • 프로젝트의 요구사항을 제시하는 사람과 그 뒤에서 영향을 주고 있는 사람은 누구인가?
  • 솔루션의 사용자는 누군가?
  • 성공적으로 솔루션을 만들었을 때, 어떤 금전적인 이익이 생기는가?
    [
    stakeholder 별로 원하는 이익이 다를 수 있다.]
  • 솔루션[소프트웨어]를 만들 때, 필요한 도메인 기술이나 추가적인 역량이 필요하진 않은가?

 

Collaborative Requirements Gathering

-      미팅을 진행할 때 Stakeholder간 의사소통을 진행하고, 요구사항을 제시한 후, 이 요구사항의 구체적인 내용을 파악해야 한다.

-      회의에 대한 룰을 지정해야 한다. 예를 들어 주 마다 언제 할지, 요구사항에 대한 회의 방법론에 대한 토의

-      의제를 발의할 때는, 모든 포인트를 커버하며 동시에 형식성을 띄어야 한다.
하지만 아이디어의 흐름을 가로막지 않는 선에서 어느정도 비형식적일 필요도 있다.

-      미팅이 잘 진행될 수 있도록 조력자, 협력자[facilitator]를 정해야 한다.

-      목표는 문제를 확인하고, 솔루션의 요소를 제안하고, 다양한 접근에 대한 협의를 해야 한다.

 

 

Elicitation Work Products
[
요구사항을 분석할 때 어떤 결과물을 도출해야 하느냐(추상적인 부분을 피하는 방법을 논한다.)]

-      소프트웨어가 어디에 필요하기에 제작해야 하는가? [고객 니즈 파악]
Statement of need and feasibility[
필요한 것]

-      시스템을 구성할 때 범위를 설정해야 한다.
[
시스템을 구성하는 요소들이 담당하는 범위를 설정하고 어떤 요소들이 상호간 통신이 필요한지, 협력이 필요한지를 정해야 한다.]

-      요구사항을 생산하는데 관여하는 customer, user, stakeholder의 리스트를 갖고 있어야 한다.

-      시스템의 기술적인 환경을 설명할 수 있어야 한다.

-      요구사항을 나열(구체적인 기능별로)해야 하며, 도메인마다 있는 제약사항 나열이 필요하다.

-      Stakeholder가 사용하게 되는 시나리오 셋을 구성해야 한다. 이것은 시스템이나 product를 사용하는 insight를 제공한다.

 

Use Case Definition

유저 입장에선 데이터를 주고받으며 소프트웨어를 사용하게 되기에 Data Flow를 사용하고,
내부 장비나 시스템은 하나의 일에 대한 협동상황을 명시한다.

-      첫 번째, 두번째 Actor가 누구냐?

-      Actor의 목적이 무엇이냐?

-      시나리오의 스토리가 진행되기 전, 어떤 전재조건이 있느냐?

-      Actor가 수행하는 기능이나 일은 무엇이냐?

-      스토리를 구성하는데, usage case에서 확장되어 나가야하는 기능이나 usage case가 무엇이 있느냐?

-      Actor와의 소통[interaction]에 어떤 변형[variations]이 존재할 수 있느냐?

-      Actor가 어떤 시스템 정보를 얻거나, 변화시킬 수 있는가?

-      Actor가 외부환경의 변화에 대해 시스템에 꼭 알려 줘야하는 사항이 있는가?

 

 

Analysis Model Elements

[요구사항 분석 모델]

-      소프트웨어를 제작하는 요구사항에 대해서, 정보적인 측면, 기능적인 측면, 행동적인 측면에서 제공되는 모델이다. [하나의 Analysis Model이 다양한 측면에서 제공된다.]

-      Scenario-based elementsUML use case diagrams으로 표현될 수 있다.
[
요것이 customers own words]

-      Class-based elementsUML class diagrams으로 표현된다. (information domain)

-      Behavioral elementsUML state diagrams [오브젝트가 모듈안에서 어떤식으로 행동하는가가 Behavioral Elements며 이를 표현하는게 UML state diagrams.]Input에 따른 State의 변화를 표현하다.

Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.