[소프트웨어공학] 요구공학(요구공학 작성 / 요구사항 프로세스) 정리

More About SOFTWARE REQUIREMENT 5~6부 요약 정리

 

[ 요구사항 작성 ]

연결 문서

- SRS와 같은 문서들은 정보를 전달하는 가교 역할을 한다. 따라서 명확해야 한다. 

- 얼마만큼 디테일해야하는가? → 연결 문서는 작성자 관점보다 소비자의 시각에서 작성해야한다.

 

* SRS : Software Requirement Specification, 소프트웨어 요구 사양서

 

 

얼마나 상세하게 기술해야 하는가

1) 상세한 요구사항이 덜 적합한 경우

    - 고객들이 광범위하다.

    - 개발자들이 상당한 분야의 경험을 가진다.

    - 선례를 사용할 수 있다.

    - 패키지 솔루션이 사용될 수 있다.

 

2) 요구사항이 더 상세해야 하는 경우

    - 개발은 아웃소싱될 것이다.

    - 프로젝트 팀 멤버들이 지리적으로 흩어져 있다.

    - 요구사항이 테스트의 근거가 될 것이다.

    - 정확한 평가가 필요하다.

    - 요구사항 추적이 필요하다.

 

* 추적성

각 요구사항을 만족하기 위해 생성되는 개별 기능 요구사항들, 유스케이스, 제품 기능 또는 비즈니스 규칙 등 그리고 작업 산물 사이의 논리적인 연결을 생성하는 활동

- 요구명세에 대해 대단히 엄격할 때! 중요!

- 모든 요구사항은 설계 요소에 대해 전방향으로 추적한다.

- 각 설계 요소는 지정된 요구사항에 대해 역으로 추적 가능하다.

- 모든 요구사항은 코드로 구현된다.

- 모든 코드는 설계 요소에 대해 추적가능하고 요구사항도 추적한다.

- 테스트 케이스는 각 요구사항에 대해 추적한다.

 

 

요구사항 스타일의 요소

- 시스템 관점에서 기능 요구사항 작성 : “시스템은 ~”

- 사용자 관점에서 기능 요구사항 작성 : “ 사용자는 ~”

 

 

요구사항과 설계 사이의 퍼지라인

- 요구사항과 설계는 구분이

  → 명확 : 구조적 분석 (분석 : DFD / 설계 : 구조도(Flow Chart))

  → 모호 : 클래스다이어그램 (분석 : 클래스다이어그램 / 설계 : 클래스다이그램 => ?? 노테이션의 차이는 없어. 설계에 관계된 클래스들이 등장하면 설계단이라고 생각)

 

- 소프트웨어 명세와 개발에서 추상화 수준

  → 프로젝트를 착수한 이유 : 비즈니스 목표

  → 사용자가 제품으로 할 수 있는 것 : 유스케이스, 시나리오, 스토리

  → 개발자가 구축하는 것 : 특징, 기능요구사항, 제품 특성

  → 시스템 구성요소들과 이들을 함께 조합하는 방법 : 제품 아키텍쳐, 사용자 인터페이스 아키텍쳐,

  → 개별 요소들의 동작 : 상세 모듈, 클래스 설계, 데이터베이스 설계, 사용자인터페이스 설계

  → 각 구성 요소의 구현 : 알고리즘, 사용자 인터페이스

  * 비즈니스 목표단으로 올라갈수록 추상성이 증가하며 밑으로 내려갈수록 추상성은 감소하고 구체적임. 추상성이 클수록 사용자들이 요구하는 에센스들이 나타나고 구체적일수록 기계들이 요구하는 에센스들이 추가되는 형태

 

 

- 제약 사항을 만족하기 위해 여러 가지 대안 중에서 요구사항으로 하나의 솔루션을 채택한다.

- SRS와 설계물은 분리해서 생각해야하지만, 새로운 제품 개발이 아닌 기존 시스템을 고도화 시킬 때는 설계 제약을 설계 단계에서 생각하는 것이 아니라 SRS 초기 단계에 생각하는 것이 편할 때도 있다(물론, 설계 제약을 강제해서는 안됨).

 

 

[ 요구사항 프로세스 ] 

프로젝트 범위 정의

- 사용자, 액터가 어디까지 보는가, 개발자가 어디까지 개발해야하는가는 제품 범위와 관련이 있다. 

- 제품 범위는 현재 프로젝트가 다룰 궁극적인 제품 비전에 대한 부분, 프로젝트 입력과 출력 사이의 경계를 말한다. 

  * 제품 비전은 궁극적이 목적에 대한 장기 전략 개념과 새로운 형식의 시스템을 말함

- 범위는 컨텍스트 다이어그램, 유스케이스, 특징 수준에 의해 설정될 수 있다.

- 컨텍스트 다이어그램은 원의 원주인 시스템 경계 밖에는 외부엔티티인 터미널이 있다. 

- 프로젝트 이해 관계자들이 시스템 경계 외부에 놓여 있는 것에 대한 공통의 이해를 전달하는데 도움을 준다. 

- 유스케이스의 사각형 박스는 컨텍스트 다이어그램의 원과 비슷하게 시스템 경계를 나타낸다. 

- 박스 외부의 사람 모양은 액터를 나타내는데 어떤 목적을 가지고 시스템에 접근하는 사람, 시스템, 하드웨어 등이며 이들이 보는 서비스 단위가 유스케이스이다. 이 또한 시스템 바운더리로 사용되기에 적합하다.

- 사용자에게 능력을 제공하고 비즈니스 목표를 충족시키는 논리적으로 관련된 일련의 기능요구사항이다.

- 릴리즈 근거 요소 value-oriented

 

컨텍스트 다이어그램

1. 1970년대 구조적분석에서부터 시작됨

2. 원과 터미네이터를 통해 시스템의 경계를 나타냄

3. 외부 엔티티의 대상 : 사용자 클래스, 조직, 액터, 엔티티를 연결하는 다른 SW, HW

4. 고수준의 추상화로 범위를 나타낸다.

5. 어떤 특징과 기능이 범위 내에 있는지 명백히 식별하지 않는다.

6. 프로젝트 이해 관계자들이 시스템 경계에 놓인 것에 대한 공통 이해를 전달하는 데 도움을 준다.

 

유스케이스 다이어그램

1. UML을 구성하는 중요한 요소로 사용자 요구사항을 표현한다.

2. 사각형 박스는 컨텍스트 다이어그램의 원과 비슷하게 시스템의 경계를 표현한다.

3. 액터는 외부 엔티티로 시스템과 작용한다.

4. 컨텍스트 다이어그램과는 달리 유스케이스는 시스템의 가시성을 제공한다.

5. 화살표는 데이터 흐름을 표현하는 것이 아니다.

6. 유스케이스는 컨텍스트 다이어그램보다 더 많은 범위를 제공한다.

7. 그러나 매우 큰 소프트웨어 시스템인 경우 유스케이스와 액터사이에 많은 연결선을 가진 수십개의 유스케이스가 등장할 수 있다.

 

특징 수준

- 특징 : 사용자에게 기능을 제공하고 비즈니스 목표를 충족시키는 논리적으로 관련된 일련의 기능 요구사항

 - 특징은 사용자가 인식할 수 있는 제품의 능력이다.

- 릴리즈를 반복적으로 생산할 때 특징은 향상된다.

- 특징이 향상되는 것은 사용가치를 향상시키는 것이다.

- 분석가는 최우선 순위 특징에 대해 집중할 필요가 있다.

 

 

모래 위에 그은 선

요구는 계속해서 변경한다. 이로 인해 비용, 일정, 인원 등이 영향을 받는다. 이때 요구관리가 필요하다. 베이스라인은 공식적으로 검토하여 동의한 명세나 제품으로 그 후 향후 개발을 위한 기준으로서 다루어지고 공식 변경 통제 절차를 통해서만 변경될 수 있다. 공식 변경 통제를 시작한다. ? 프로젝트 관리자는 일정, 예산, 인원에 대해 책임을 가진다.

 

베이스라인 

- 공식적으로 검토하여 동의된 명세나 제품으로 그 후 향후 개발을 위한 기준이며 공식 변경 통제 절차를 통해서만 변경할 수 있다.

- 공식 변경 통제를 시작

- 프로젝트 관리자가 스태프와 예산을 결정한다.

- 프로젝트 관리자가 일정에 대한 책임을 갖는다.

- 요구사항을 일찍 정의하는 것은 통제 프로세스를 지나치게 압박할 수 있다.

- 베이스라인 구축이 너무 오래 거리는 것은 분석 불능상태라는 신호로 될 수 있따.

 

 

여섯 명의 장님과 요구사항

- 자연어는 

  1) 모호성이 강하다

  2) 명세가 길어진다 

  3) 추상성 수준이 낮다 

  4) 검증이 힘들다

 와 같은 문제를 갖는다.

 

- 그래픽 분석 모델

 → 시스템 외부 인터페이스 : 컨텍스트 다이어그램 / 유스케이스

 → 프로세스 흐름 단계 : DFD·Flow Chart / Activity·Sequence Diagram

 → 데이터나 개체의 상호관계 : ERD / Class·Instance Diagram

 → 시스템이나 개체 상태 : 상태전이 다이어그램 / State Diagram

 → 사용자 인터페이스 아키텍처 : 다이얼 로그 맵

  + petri net