소프트웨어 요구사항 - 다양한 기능 제공

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

1) 기존 시스템에 적용할 수 있는 요구사항 기법, 비즈니스 목표에 따라 우선순위 할당하기, 패키지 솔루션 선택을 위한 요구사항, 패키지 솔루션을 구현하기 위한 요구사항에 대해 설명할 수 있다. 

2) 요구사항의 적절한 명세화 수준, 변경 관리, 인수 기준, 비즈니스 프로세스 모델 만들기, 비즈니스 성과 지표 모델 만들기에 대해 설명할 수 있다.

☞ 갭 분석 : 갭 분석(gap analysis)은 기존 시스템의 기능과 신규 시스템에서 원하는 기능을 비교하는 것이다. 갭 분석은 유스케이스, 사용자 스토리, 기능 등 다양한 방식으로 표현될 수 있다.

☞ 해외 업무 위탁 : 해외 업무 위탁은 납품업체 국가가 가깝거나 인수업체 국가의 언어나 문화를 공유하는 경우 ""인접 국가 외주(nearshoring)""라 하기도 한다.

☞ 현행 프로세스 : 현재의 비즈니스 동작 방법을 설명하는 프로세스는 as-is(현행) 프로세스라고 한다. 아직 구체화되지 않은 비즈니스가 작동하는 방법에 대한 미래의 상태를 설명하는 것을 to-be(목표) 프로세스라고 한다.

☞ 점진적인 개발 : 점진적인 개발은 납품업체의 개발자에게 잘못된 방향으로 잘못 전달했을 때 방향을 바로잡을 수 있게 해주는 또 한 가지 관리 기법이다. 

☞ 비즈니스 프로세스 모델 및 표기법(BPMN) : 비즈니스 프로세스 모델 및 표기법(BPMN)은 비즈니스 프로세스 모델링을 위한 그래픽 표기법이다. BPMN은 비즈니스 프로세스 모델링의 어떠한 방법에도 적용될 수 있다.

☞ 교체 시스템 프로젝트에서는 새로운 개발 프로젝트와 마찬가지로 필요한 모든 기능을 이해할 필요가 있다. 새로운 시스템의 후보 기능을 식별하기 위해 기존 시스템으로부터 사용자 인터페이스를 연구하자. 사용자가 현재 시스템을 사용하는 방법을 이해하자. 아무도 사용자 인터페이스에 숨겨진 기능이나 비즈니스 규칙을 이해하지 못한다면 무슨 일이 일어나고 있는지 찾기 위해 누군가가 코드나 데이터베이스를 뒤져봐야 할 것이다. 요구사항을 식별하기 위해 설계 문서, 도움말 화면, 사용 설명서, 교육용 자료를 비롯해 존재하는 모든 문서를 분석하자. 

☞ 기존 시스템을 변경하거나 교체할 때 저항에 부딪힐 수도 있다. 사람들은 자연스럽게 변경을 꺼려한다. 사용자의 작업을 용이하게 하는 새로운 기능을 도입하는 것은 좋은 일이다. 그러나 사용자가 현재의 시스템을 다루는 데 익숙해져 있고 이를 변경하려 한다면 사용자의 관점에서 꼭 좋은 것만은 아니다. 시스템을 교체하는 것은 단순히 기능을 변경하는 것과는 차원이 다르기 때문에 더 큰 문제다. 만약 여러분이 비즈니스 분석가나 프로젝트 관리자, 프로젝트 스폰서라면 저항을 예상하고 이를 극복하기 위한 방법을 계획해야 한다. 그래야 사용자가 새로운 기능이나 시스템을 받아들일 것이다. 

☞ 각기 다른 패키지 솔루션이 서로 다른 방법으로 동작하더라도 사용자는 패키지와 상관 없이 작업 목표를 달성할 수 있어야 한다. COTS 도입을 위한 대다수의 요구사항 관련 노력은 사용자 요구사항 수준에 집중해야 한다. 유스케이스와 사용자 스토리는 이 같은 목적에 적합하다. 또한 프로세스 모델이 사용될 수 있으며, 조직에 이미 존재할 수도 있다. 공급업체가 이미 다 준비해 놓았을 수도 있기 때문에 구체적인 기능적 요구사항을 명세화하거나 사용자 인터페이스를 설계하는 것은 무의미하다. 

☞ 패키지 솔루션은 독립 모드에서 사용하지 않는 한 애플리케이션 환경에 통합해야 한다. 이러한 통합은 패키지가 상호작용해야 하는 기타 다른 애플리케이션의 외부 인터페이스에 대한 이해를 필요로 한다. 모든 부분이 잘 들어맞도록 코드 일부를 수정해야 할 수도 있을 것이다. 코드는 다음과 같은 형태가 될 수 있다. 

- 인터페이스를 수정하거나 누락된 기능을 추가하는 어댑터

- 전사 시스템에서 COTS 소프트웨어와 나머지를 분리하는 방화벽

- 패키지의 압출력을 가로채어 인터페리스 반대편에서 사용될 수 있는 형태로 데이터를 수정하는 래퍼

☞ 다음은 패키지 솔루션을 선택하고 개발할 떄 발생할 수 있는 일반적인 문제다. 

- 너무 많은 후보

- 너무 많은 평가 기준

- 공급 업체에 의한 패키지 기능의 왜곡

- 솔루션에 대한 잘못된 기대

- 사용자가 솔루션을 거부

☞ 소프트웨어 개발 작업은 외주의 가장 일반적인 유형이지만 테스트 또한 외주가 가능하다. 외주 테스트는 외주 개발과 같은 문제를 가진다. 두 유형 모두 성공을 위해서는 확실한 요구사항이라는 견고한 기반을 필요로 한다. 

☞ 자체 개발과 마찬가지로 시각적 요구사항 모델은 외주 팀에게 기능 및 비기능적 요구사항을 보완한다. 요구사항에 대한 다양한 설명을 만들어내는 것은 소통의 범위를 증가시켜 사내 팀이 소프트웨어를 개발했을 때보다 좀 더 많은 모델이 만들어지는 데 도움이 된다는 사실을 알 수도 있다. 문화와 모국어를 넘어서서 일을 한다면 글로 쓴 명세서를 보완하기 위해 시각적 모델과 같은 표현은 해석에 앞서 무언가를 개발자에게 줄 수 있기 때문에 훨씬 더 가치가 있다. 

☞ 제대로만 된다면 개발 작업 외주는 소프트웨어 시스템을 구축하는 데 효과적인 전략이 될 수 있다. 거리, 언어, 문화적 차이, 그리고 잠재적인 경쟁 이익 때문에 외주 개발 업체와 협력 관계를 만드는 것은 쉽지 않은 일이다. 납품업체는 출시 후보 전달에 따른 문제를 해결하기 위해 더 많은 비용을 지불해야 하는 상황에서 발견된 요구사항 오류 또는 모호성을 해결하려 하지 않을 수도 있다. 성공적인 외주 개발에 필요한 출발점은 고품질의 완전하고 명확한 요구사항의 집합이다. 

문제1) 프로젝트 개선 및 교체를 위한 요구사항 기법 중에서 생태계 맵 만들기의 적절한 이유는 무엇입니까?  P452. 생태계 맵 만들기의 적절한 이유는 다음과 같다.

- 영향을 받는 다른 시스템 찾기

- 시스템 간의 신규, 수정, 불필요한 인터페이스 찾기

   외부 개체 식별하고 문서화하기 

   추적 체인에서 단절된 링크 식별하기 

   기존 시스템에 없는 새 보고서 정의하기 

    영향을 받는 다른 시스템 찾기 

문제2) 변경에 영향을 받는 사람을 산정하고, 신규 사용자 클래스가 누구의 요구사항을 충족해야 하는지 파악하는 기법은 무엇입니까?   P452. 사용자 클래스 식별하기의 적절한 이유는 다음과 같다.

- 변경에 영향을 받는 사람 산정하기

- 신규 사용자 클래스가 누구의 요구사항을 충족해야 하는지 파악하기

    사용자 클래스 식별하기 

   요구사항 명세서 검사하기 

   품질 속성 구체화하기 

   데이터 모델 만들기 

문제3) 패키지 솔루션을 선택하고 개발할 때 발생할 수 있는 일반적인 문제가 아닌 것은 무엇입니까?  P473. 다음은 패키지 솔루션을 선택하고 개발할 때 발생할 수 있는 일반적인 문제다.

- 너무 많은 후보

- 너무 많은 평가 기준

- 공급 업체에 의한 패키지 기능의 왜곡

- 솔루션에 대한 잘못된 기대

- 사용자가 솔루션을 거부

   너무 많은 후보 

   공급 업체에 의한 패키지 기능의 왜곡 

    다양한 기능 제공 

   사용자가 솔루션을 거부