[Object Oriented S/E] Chapter 4 - Software Requirements Elicitation

# 범위

80page ~ 103page

 

# 내용

## 4.1 WHAT IS REQUIREMENTS ELICITATION?

• 실제 세계의 프로젝트에서는 예산이나 시간의 제한이 존재한다.
• 그렇기 때문에 요구사항의 subset만이 충족되어 진다.
• 소프트웨어 요구사항은 시스템이 제공해야 하는 기능이다.
• 성공적인 소프트웨어 프로젝트는 예산을 넘기지 않고 계획된대로 시스템을 완성시키는 것이다.
• 이해관계자들의 성향(경영가, 개발자, 기술자 ...)에 따라서 우선순위로 두는 것이 달라지기 때문에 요구사항의 우선순위를 두는것이 어렵다.
• 제약조건은 소프트웨어 솔루션 공간에 대한 제약이다.
• 제약은 설계와 구현대안들을 감소시킨다.
• 극단적인 예로, 제약조건이 없다면 선택범위가 매우 광범위 하지만 제약족건이 존재하면 솔루션 공간이 매우 감소한다. -> 이게 좋다는건가 아니다는건가..?
• 실현 가능성을 조사하는 것은 안정성을 증대시킨다.

## 4.2 IMPORTANCE OF REQUIREMENTS ELICITATION

• 지은이는 열심히 2년동안 개발했는데, 고객사가 자기네들이 기대했던거와 다른 시스템이라고 해서 한푼도 받지 못했다고 함.
• 그렇기 때문에 개발자가 고객만큼이나 진짜 요구사항을 이해하는 것은 매우매우 중요하다.

 

## 4.3 CHALLENGES OF REQUIREMENTS ELICITATION

• 요구사항을 명확히 하는것은 어렵다 왜냐하면 요구사항 도출과정동안의 매우 어려운것들을 극보해야 하기 때문이다.
• 소프트웨어 시스템은 일반적으로 wicked problem이다.

1. 개발팀들은 어플리케이션과 어플리케이션의 도메인에 대해서 충분히 알지 못한다. 어플리케이션 도메인에 대한 이해는 몇년의 걸친 경험으로부터 얻어지기 때문에 이해하는 것이 어렵고, 그래서 애자일방법에서는 고객과 협력을 강조하는 것이다.
2. 고객들과 유저들은 소프트웨어가 무엇을 할 수있는지 모르고 어떻게 그들의 니즈를 해결하는지에 대해서 모른다. 소프트웨어 개발자들은 고객과 사용자들로부터 적절한 의견을 얻지 못한채 그러한 결정들을 내린다. 그래서 개발팀은 고객과 긴밀히 협력해야 하는 것이다 그들이 무엇을 원하는지에 대해서 알기 위해, 또 뭐를 원하지 않는지
3. 공통 배경이 부족해 고객과 소통 장벽이 발생한다. "security"라는 단어가 흔히 여겨지는 뜻과 경제 도메인에서의 해석이 다르다. 이러한 것들이 맥락 파악을 힘들게 한다.
4. 소프트웨어 요구사항은 명확하게 특정 될 수 없다.  wicked problem이기 때문에
5. 요구사항 도출의 중요성과 어려움은 종종 경영진, 고객 매니저, 유저, 개발자에 의해 과소평가됩니다.
6. 기능적이지 않은 요구사항은 이해될 수 없다. 
7. 요구사항들은 소프트웨어 생명주기 전반에 걸쳐서 변경되고 심지어 운영단계에서도 변경이 일어난다.

 

## 4.4 TYPES OF REQUIREMENT

• 요구사항은 기능적인것과 비기능적인 요소로 나뉜다.
• 기능적인 요구사항은 소프트웨어 시스템이 반드시 가져야 하는 정보이다. 
• 이러한 기능적인 요구사항은 must shall will과 같은 문장으로 명확히 표현이 가능하다.
• 요구사항은 유저의 관점에서도 쓰여질 수 있다.

 

• 비기능적인 요구사항은 아래와 같이 몇가지 항목으로 나뉜다.

1. 성능 요구사항
2. 퀄리티 요구사항
3. 안정성 요구사항
4. 보안 요구사항
5. 인터페이스 요구사항

 

## 4.5 STEPS FOR REQUIREMENTS ELICTATION

1. 어플리케이션에 관한 정보 수집
2. 원하는 분석모델에 대한 구조화
3. 요구사항 및 제약사항 도출
4. 실현가능성 조사 수행
5. 요구사항 명세 리뷰

 

## 4.6 APPLYING AGILE PRINCIPLES

• 애자일 방법은 변화는 당연하다는 사실을 받아들인다. 그리고 변화에 더욱 빠르게 반응한다 짭른 주기 덕분에
• water-fall 방식은 요구사항 도출 단계에 많은 시간을 소모했다면 애자일 방법은 요구사항 도출에 아주 적은 시간과 작은 노력을 들인다.
• 애자일에서 목적은 높은 우선순위의 요구사항 리스트를 작성해내는 것이다.

1. 고객협력과 유저와 동적이게 속하는 것은 필수적이다. 주에 적어도 두번에서 세번의 미팅을 가져야한다
2. 요구 사항을 높은 수준으로 파악하고 세부 사항은 후속 반복 작업에 맡긴다.
3. 충분하면 됐다. 소프트웨어 요구 사항 목록을 신속하게 작성하고 다음 단계로 이동합니다
4. 모델이 요구사항 도출에 도움이 되도록 구성된 경우, 최소 모델을 신속하게 구성할 수 있습니다. 목적을 달성할 수 있을 뿐만 아니라 그 이상은 필요하지 않다.

## 4.7 REQUIREMENTS MANAGEMENT AND TOOLS

변경사항이 비용에 이익인지 여부를 판단하기 위해 변경사항 영향, 변경사항 구현 비용 및 영향을 해결하기 위한 비용을 평가해야 한다.