소프트웨어 요구사항 - NAH

소프트웨어 요구사항 3 국내도서 저자 : 칼 위거스,조이 비티(Joy Beatty) / 최상호,임성국역 출판 : 위키북스 2017.04.27 상세보기

1) 검증과 확인, 요구사항 검토하기와 프로토타이핑하기, 요구사항 테스트하기와 검증하기, 요구사항 재사용의 관점, 재사용을 위한 요구사항 정보의 종류, 요구사항 패턴, 재사용에 유용한 도구에 대해 설명할 수 있다.

2) 요구사항 노력 산정하기, 요구사항을 기반으로 프로젝트 계획하기, 요구사항을 기반으로 설계 및 구현하기, 애자일 개발 방법론, 요구사항에 대한 애자일 접근 방식의 필수 요소에 대해 설명할 수 있다.

☞ 재사용성 : 재사용성이란 동일 프로젝트나 선행 프로젝트에서 이미 완료된 작업을 이용하는 것을 의미한다.

☞ 참조 방식의 복사는 실제로 요구사항 정보를 저장하기 위한 것이 아니라 단순히 프로젝트 문서상의 위치를 알려주는 것이다. 

☞ NIH 증후군과 NAH 증후군 : 재사용에 대한 두 가지 장벽은 NIH 증후군과 NAH 증후군이다. NIH는 ""여기서 발명되지 않음(Not Invented Here)""이란 의미다. NAH, 즉 ""여기에 적용할 수 없음(Not Applicable Here)"" 증후군은 실무자가 새로운 프로세스나 접근법을 본인의 프로젝트나 조직에 적용할 수 없다고 이의를 제기하는 것을 말한다. 

☞ 애자일 개발 : 애자일 개발은 이해관계자 사이의 지속적인 협업을 돕고 작은 단위의 유용한 기능을 신속하고 빈번하게 전달하기 위한 소프트웨어 개발 방법의 모음을 의미한다.

☞ 백로그의 우선순위 할당 : 백로그의 우선순위 할당은 백로그에서 버릴 항목과 돌아오는 반복주기에 해야 할 작업을 선택하기 위한 지속적인 활동이다.

☞ 비정형평가는 사람들에게 제품에 대해 교육할 때나 비정형적인 피드백을 수집할 때 유용하다. 그러나 이 방법은 체계적이지 않거나 빈틈이 있거나, 혹은 일관된 방식으로 수행되지 않는다. 비정형 검토 방법은 다음과 같다. 

- 동료 탁상 평가

- 패스어라운드

- 검토회

☞ 기능적 요구사항이나 사용자 요구사항에서 파생된 것을 기반으로 하는 테스트를 프로젝트 참가자로 하여금 예상하는 시스템 동작으로 가시화할 수 있게 돕는다. 테스트를 설계하는 단순한 행위는 동작하는 소프트웨어에서 테스트를 실행하기 훨씬 이전에 많은 문제를 드러낸다. 기능 테스트를 작성함으로써 특정 조건하에서 시스템이 동작하는 방법에 대한 비전을 확고히 한다. BA나 개발자, 고객이 함께 테스트하면 제품이 동작하는 방법에 대한 공통의 비전을 달성하고 요구사항의 정확성에 대한 신뢰가 향상될 것이다. 테스트는 요구사항을 검증하고 확인하기 위한 강력한 도구다.

☞ 소프트웨어 개발자들은 그들이 완벽한 제품을 만들었을 것이라 믿고 싶겠지만 이에 대한 결정은 고객이 할 것이다. 고객은 시스템이 사전에 정의한 인수 기준을 만족하는지 평가해야 한다. 인수 기준과 이에 대한 인수 테스트는 제품이 요구사항 문서를 충족 하는지와 의도한 운영 환경에서 사용하는데 적합한지 평가해야 한다. 직접 인수 테스트를 고안하는 사용자는 효과적인 요구사항 개발에 중요한 기여자다. 인수 테스트 작성이 빠를수록 팀은 더 빨리 요구사항에서 결함을 걸러낼 수 있다. 

☞ 효과적인 요구사항 재사용의 장점은 빠른 전달과 낮은 개발 비용, 애플리케이션 내부 혹은 기타 다른 애플리케이션 간의 일관성, 높은 팀 생산성, 더 적은 결함, 재작업 감소 등이 있다. 신뢰할 수 있는 요구사항을 재사용함으로써 검토 시간을 절약할 수 있으며, 승인 주기를 가속화하고, 테스트와 같은 프로젝트 활동을 빨리 마칠 수 있다. 기존 프로젝트의 동일한 요구사항을 구현하는 것과 동일한 데이터를 이용할 수 있다면 재사용은 개발 노력 산정 능력을 향상시킬 수 있다. 

☞ 요구사항 패턴에는 다음과 같은 여러 절을 포함하고 있다. 

- 지침 : 관련 패턴, 접근 가능하거나 가능하지 않은 상황, 해당 유형의 요구사항을 작성하기 위한 방법에 대한 논의 등을 포함하는 패턴에 대한 기초적인 세부사항

- 콘텐츠 : 각 항목별 전달해야 하는 요구사항 콘텐츠의 구체적인 설명

- 템플릿 : 변경할 수 있는 정보 조각이 있을만한 곳을 자리 표시자로 표시한 요구사항의 정의

- 예시 : 해당 유형의 실례가 되는 하나 이상의 요구사항

- 추가 요구사항 : 주제에 대한 특정 측면을 정의할 수 있는 부가적인 요구사항이나 원래의 고수준 요구사항을 충족시키기 위해 반드시 완료해야 하는 것과 같이 일련의 구체적인 요구사항을 작성하는 법에 대한 설명

- 개발 및 테스트를 위한 고려사항 : 패턴에 명시된 유형의 요구사항을 개발할 때 개발자가 염두에 둬야 하는 요소 및 테스터가 이러한 요구사항을 테스트할 때 염두에 둬야 하는 요소

☞ 요구사항은 프로젝트 예정 작업을 위한 기초이기 때문에 이러한 요구사항에 대한 산정, 프로젝트 계획, 스케줄을 기반으로 해야 한다. 가장 중요한 프로젝트 결과는 원래의 프로젝트 계획에 따라 모든 초기 요구사항을 개발하는 게 아니라 비즈니스 목표에 부합하는 시스템이라는 것을 기억하자. 요구사항과 계획은 그 결과를 달성하는 데 소요되는 특정 시간에 대한 팀의 평가를 나타낸다. 그러나 프로젝트의 범위가 목표를 벗어났다거나 초기 계획이 비현실적이거나 목표에 잘 부합하지 않을 수 있다. 비즈니스 니즈나 규칙, 프로젝트 제약조건 모두 달라질 수 있다. 진화하는 목표와 현실에 따라 계획을 갱신하지 않는다면 프로젝트의 비즈니스적인 성공에 문제가 발생할 것이다. 

☞ 소프트웨어 프로젝트는 자주 목표 달성에 실패하는데, 보통은 소프트웨어 엔지니어가 형편없다기보다는 개발자 및 기타 프로젝트 참가자들의 낙관적인 평가와 허술한 기획 때문이다. 일반적인 작업의 노력이나 시간의 과소평가, 프로젝트 위험 산정 실패, 재작업 예측 실패 등을 일반적인 기획 실수의 사례로 볼 수 있다. 효과적인 프로젝트 일정 산정에는 다음과 같은 요소가 필요하다. 

- 제품 규모 예측

- 과거 성과를 기반으로 한 개발팀의 생산성 파악

- 기능이나 유스케이스 구현 및 검증을 완료하는 데 필요한 작업 목록

- 최소한 다음 개발 반복주기를 위한 합리적이고 안정적인 요구사항

- 프로젝트 관리자가 무형의 요소와 각 프로젝트의 고유 측면을 조정하는 데 도음이 되는 경험 

문제1) 완전성 결함 체크리스트에 해당하는 것은 무엇입니까? P389. 구성 및 추적성 - 요구사항이 논리적이고 접근 가능한 방식으로 구성됐는가?

완전성 - 요구사항이 고객이나 시스템의 알려진 모든 니즈를 충족하는가?

구성 및 추적성 - 각 요구사항이 고유하고 명확하게 명명돼 있는가?

품질 속성 - 모든 사용성, 성능, 보안, 안전성 목표가 적절히 명시됐는가?

 

   요구사항이 논리적이고 접근 가능한 방식으로 구성됐는가? 

    요구사항이 고객이나 시스템의 알려진 모든 니즈를 충족하는가? 

   각 요구사항이 고유하고 명확하게 명명돼 있는가? 

   모든 사용성, 성능, 보안, 안전성 목표가 적절히 명시됐는가?

문제2) 실무자가 새로운 프로세스나 접근법을 본인의 프로젝트나 조직에 적용할 수 없다고 이의를 제기하는 것을 말하는 증후군은 무엇입니까?  P416. NAH, 즉 "여기에 적용할 수 없음(Not Applicable Here)" 증후군은 실무자가 새로운 프로세스나 접근법을 본인의 프로젝트나 조직에 적용할 수 없다고 이의를 제기하는 것을 말한다. 

 

    NAH 

   NBH 

   NCH 

   NDH