소프트웨어요구사항 - 가정

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

1) 비즈니스 규칙이 분류체계, 비즈니스 규칙 문서화하기와 발견하기, 비즈니스 규칙 및 요구사항, 소프트웨어 요구사항 명세서, 소프트웨어 요구사항 명세서 템플릿에 대해 설명할 수 있다.

2) 좋은 요구사항의 특징, 요구사항 작성을 위한 지침, 요구사항 모델 만들기, 데이터 흐름과 스윔레인 다이어그램, 대화상자 맵, 의사결정 트리, 이벤트 반응표에 대해 설명할 수 있다.

☞ 동작 활성자 :  특정 조건이 참일 때 어떤 행위를 수행하게 하는 규칙을 동작 활성자(action enabler)라고 한다. 사람이 수동 프로세스로 작업을 수행할 수도 있다. 또는 시스템에서 촉발 이벤트를 감지했을 때 애플리케이션이 올바른 동작을 수행하도록 소프트웨어 기능을 지정하는 규칙이 생길 수도 있다.

☞ 가정 : 가정이란 증명이나 명확한 지식 없이 참이라 여겨지는 구문이나 표현을 말한다. 

☞ 데이터 흐름 다이어그램 : 데이터 흐름 다이어그램은 구조 분석을 위한 기본적인 도구다. DFD는 시스템의 변환 프로세스, 시스템이 다루는 데이터나 물리적인 자료 모음(저장소), 프로세스나 저장소, 외부 세상 간의 데이터나 자료의 흐름 등을 식별한다.

☞ 상태 전이 다이어그램 : 상태 전이 다이어그램(STD: State-transition Diagram)은 상태 간의 가능한 전이를 시각적으로 보여준다. 이와 관련된 기술로서 풍부한 표기법을 제공하며 객체가 생존하는 거치는 상태를 모델링할 수 있는 통합 모델링 언어(UML: Unified Modeling Language)에 포함된 상태 기계 다이어그램이 있다.

☞ 클래스 다이어그램 : 클래스 다이어그램은 객체지향 분석을 통해 식별된 클래스와 클래스 간의 관계를 묘사하기 위한 시각적인 방법이다.

☞ 비즈니스 규칙은 여러 애플리케이션이나 조직에 영향을 미칠 수 있기 때문에 전사적인 수준의 자산으로 관리해야 한다. 초기에는 단순한 비즈니스 규칙 카탈로그 정도면 충분하다. 만약 요구사항 관리 도구를 사용한다면 비즈니스 규칙을 요구사항 형식으로 저장하고 모든 소프트웨어 프로젝트에 제공할 수 있다. 대규모 조직이나 운영 및 정보 시스템이 비즈니스 규칙을 중심으로 운영되는 조직은 비즈니스 규칙 데이터베이스를 구축해야 한다. 규칙 카탈로그의 규모가 커져서 워드프로세서나 스프레드시트, 위키, 기타 협업 도구를 사용하기가 힘들다면 상용 규칙 관리 도구가 유용할 것이다. 

☞ 요구사항 개발의 결과는 개발해야 하는 프로젝트에 대한 이해관계자 간의 문사화된 합의다. 비전 점위 문서는 비즈니스 요구사항과 유스케이스나 사용자 스토리와 같은 형식으로 정리된 사용자 요구사항을 담고 있다. 제품의 기능적 요구사항과 비기능적 요구사항은 솔루션을 설계하거나 구현, 검증해야 하는 사람들에게 전달될 소프트웨어 요구사항 명세서  혹은 SRS에 저장되기도 한다. 요구사항을 주요 프로젝트 이해관계자가 쉽게 검토할 수 있는 조직적인 형태로 기록하면 이들이 어떤 부분에 동의하고 있는지 파악하는 데 도움이 된다. 

☞ 소프트웨어 요구사항은 다음과 같은 여러 가지 방법으로 표현할 수 있다. 

- 잘 구조화되고 신중하게 작성된 자연어

- 변환 프로세스, 시스템 상태와 각 상태 간의 변화, 데이터 관계, 로직 흐름, 기타 등등을 그린 시각적인 모델

- 아주 정밀한 명세 언어를 이용해 요구사항을 정의하는 정형 명세서

☞ 모든 요구사항은 유일하고 영구적인 식별자가 필요하다. 이를 통해 변경 요청이나 수정 이력, 상호 참조, 요구사항 추적 매트릭스에 대한 특정 요구사항을 참조할 수 있다. 또한 여러 프로젝트에서 요구사항을 재사용할 수 있다. 고유하게 식별되는 요구사항은 동료평가와 같은 팀 구성원 간 요구사항 논의에서 구성원 간의 협업을 촉진한다. 간단한 번호나 글머리 기호를 붙인 목록은 이러한 목적에 적절하지 않다. 

☞ 소프트웨어 요구사항을 명세화하기 위해 가장 적합한 형식을 선택하는 것은 각 프로젝트 팀에  달렸다. 요구사항 개발에 있어 가장 중요한 목표를 기억하라. 바로 허용 가능한 위험수준 내에서 다음 단계의 제품 개발을 진행할 수 있는 충분한 공통의 이해를 축적하는 것이다. 요구사항을 문서화하는 적절한 수준이 형식상 절차 및 구체화 정도는 다음과 같은 요인에 따라 달라진다. 

- 고객과 개발자 간의 시기 적절한 비공식적인 언어적 및 시각적 의사소통을 통해 각 사용자 요구사항을 올바르게 구현하는데 필요한 세부 사항을 공급할 수 있음

- 비공식적인 커뮤니케이션 방안을 통해 시간과 공간을 초월해 팀을 지속적으로 단일화할 수 있음

- 추후 개선 및 유지보수, 애플리케이션 리엔지니어링, 검증, 법률 및 감사 권한, 제품 인증, 계약된 만족도 등을 위한 요구사항 지식 유지에 가치 있거나 필요한 정도

- 예상 시스템의 기능이나 동작에 대한 설명을 효과적으로 대체할 수 있는 인수 테스트의 규모

- 서면 기록을 대체할 수 있는 인간의 기억력 수준

☞ 훌륭한 요구사항을 작성하기 위한 정형화된 방법은 없다. 요구사항을 제시하는 사람들의 경험과 피드백이 가장 좋은 스승이다. 예리한 시각을 가진 동료로부터 건설적인 피드백을 받음으로써 이들이 지적한 부분을 제대로 작성했는지 여부를 확인할 수 있기 때문에 큰 도움이 된다. 이는 요구사항 문서에 대한 동료평가가 매우 중요한 이유다. 

☞ 팀이 전체 시스템의 완벽한 분석 모델을 만들어야 하는 상황은 거의 없다. 시스템에서 사장 복잡하고 위험이 큰 부분과 모호함이나 불확실성에 대해 가장 많이 논의되고 있는 부분을 모델링하는 데 집중하자. 필수 안전, 필수 보안, 필수 시스템 요소는 결함으로 인한 영향이 너무 크기 때문에 모델링하기에 좋은 대상이다. 또한 모든 모델이 완전하다는 것을 보장하는 데 도움되는 모델을 선택하자. 

☞ 데이터 흐름 다이어그램은 구조 분석을 위한 기본적인 도구다. DFD는 시스템의 변환 프로세스, 시스템이 다루는 데이터나 물리적인 자료 모음, 프로세스나 저장소, 외부 세상 간의 데이터나 자료의 흐름 등을 식별한다. 데이터 흐름 모델링은 시스템 분석을 위해 복잡한 문제를 지속적으로 세부 수준으로 분해하는 기능 분해 접근법을 사용한다. 이는 트랜젝션 처리 시스템이나 기타 기능 위주의 애플리케이션에 적합하자. DFD기법은 제어 흐름 요소를 추가하면서 실시간 시스템의 모델링이 가능하도록 확장돼 왔다. 

☞ 소프트웨어 시스템에는 기능적인 동작, 데이터 조작, 상태 변화 조합 등이 수반된다. 실시간 시스템과 프로세스 제어 애플리케이션에는 특정 시간 동안 제한된 횟수의 상태가 존재 할수 있다. 상태 변화는 특정 조건하에서 어떤 입력 자극을 수신하는 등 잘 정의된 기준을 만족했을 때만 일어날 수 있다. 

문제1) 증명이나 명확한 지식 없이 참이라 여겨지는 구문이나 표현은 무엇입니까?  P226. 가정이란 증명이나 명확한 지식 없이 참이라 여겨지는 구문이나 표현을 말한다.

   스택

   연관

   링크

    가정

문제2) 비즈니스 프로세스나 여러 행위자와 시스템 간의 상호작용을 도식화하는 다이어그램은 무엇입니까? P265. 스윔레인 다이어그램은 비즈니스 프로세스나 여러 행위자와 시스템 간의 상호작용을 도식화한다. 순서도와 활동 다이어그램은 유스케이스 대화상자와 분기 흐름을 대안 흐름과 예외로 좀 더 시각적으로 묘사한다.

   프로세스형 다이어그램

   피라미드형 다이어그램

    스윔레인 다이어그램

   클래스 다이어그램