시스템 아키텍처 설계 전문 기술 · 소프트웨어 엔지니어링 요구 엔지니어링

시리즈 기사 목차

시스템 아키텍처 설계 고급 기술 · 소프트웨어 아키텍처 개념, 아키텍처 스타일, ABSD, 아키텍처 재사용, DSSA (1) [시스템 아키텍트] 시스템 아키텍처 설계 고급 기술 · 시스템 품질 속성 및 아키텍처 평가 (
2) [시스템 아키텍트]
고급 기술 시스템 아키텍처 설계 · 소프트웨어 신뢰성 분석 및 설계(3) [시스템 아키텍처 디자이너]

1. 요구공학 개요

소프트웨어 요구사항은 기능, 동작, 성능, 설계 제약 등 의 측면에서 시스템에 대한 사용자 의 기대를 나타냅니다.

요구 공학(RE)은 적절한 도구와 표기법을 통해 개발할 시스템, 동작 특성 및 관련 제약 조건을 체계적으로 설명하기 위해 입증되고 효과적인 원리와 방법을 적용하는 것을 의미합니다.

요구사항 엔지니어링은 그림과 같이 수요 확보, 수요 분석, 수요 사양 형성(또는 수요 문서화), 수요 확인 및 검증, 수요 관리의 5단계로 구성됩니다.

소프트웨어 요구사항 사양(SRS)
SRS에는 기능적 . 제약조건에는 설계 제약조건과 프로세스 제약조건이 포함됩니다. 승인된 SRS는 요구사항 개발과 요구사항 관리 사이의 가교 역할을합니다

요구사항 관리
요구사항 관리는 변경 제어, 버전 제어, 요구사항 추적 및 기타 활동을 포함하여 시스템 요구사항을 변경, 이해 및 제어하는 ​​프로세스입니다.

2. 수요개발(본선, 목표)

2.1 요구사항 분류

• 요구사항 분류

(1) 비즈니스 요구 사항 : 비즈니스 요구 사항은 시스템에 대한 기업 또는 고객의 높은 수준의 목표 요구 사항을 반영하며 일반적으로 프로젝트 투자자, 제품을 구매하는 고객, 고객 단위 관리자, 마케팅 부서 또는 제품 기획 부서 등에서 발생합니다. 비즈니스 요구 사항에 따라 프로젝트 보기와 범위가 결정됩니다.

(2) 사용자 요구사항 : 사용자 요구사항은 사용자의 특정 목표 또는 사용자가 시스템을 완료하기 위해 요구하는 작업을 설명합니다. 즉, 사용자 요구사항은 사용자가 시스템으로 무엇을 할 수 있는지를 설명합니다. 사용자 인터뷰와 설문지는 일반적으로 사용자 사용 시나리오(시나리오)를 구성하여 사용자 요구 사항을 설정하는 데 사용됩니다.

(3) 시스템 요구사항 : 시스템 요구사항은 기능적 요구사항, 비기능적 요구사항, 설계 제약사항 등 시스템 관점에서 소프트웨어 요구사항을 기술한다.

• 품질기능전개 QFD

소프트웨어 엔지니어링 과정에서 사용자 만족도를 극대화할 목적으로 사용자 요구사항을 소프트웨어 요구사항으로 변환하는 기술입니다. 이러한 목표를 달성하기 위해 QFD는 소프트웨어 요구사항을 일반 요구사항, 예상 요구사항, 예상치 못한 요구사항의 세 가지 범주로 나눕니다.

(1) 기본 요구사항 : 일반 요구라고도 하며, 사용자가 시스템이 달성해야 한다고 생각하는 기능이나 성능으로, 더 많은 기능이나 성능을 구현할수록 사용자의 만족도는 높아집니다.

(2) 기대 요구사항 : 사용자는 시스템이 갖춰야 할 기능이나 성능을 당연하게 여기지만, 자신이 원하는 기능이나 성능 요구사항을 정확하게 기술할 수는 없습니다. 기대가 충족되지 않으면 사용자는 불만을 느끼게 됩니다.

(3) 예상치 못한 요구 사항 : 흥미로운 요구 사항이라고도 알려진 예상치 못한 요구 사항은 사용자 요구 사항 범위를 벗어난 기능이나 성능입니다(그러나 일반적으로 소프트웨어 개발자가 시스템에 기꺼이 제공하는 기술적 기능). 이러한 요구 사항이 충족되면 사용자는 더 행복해질 것입니다. 실현되었으나 실현되지 않았으며, 구매 결정에도 영향을 미치지 않습니다.

2.2 요구사항 획득

방법	특징
정보를 수집하다	시스템 개발에 유용한 시스템 관련 정보를 수집합니다.
역사 문서 읽기	데이터 기반 정보를 수집하는 데 유용합니다.
사용자 인터뷰	1 ~ 1-3, 대표 사용자, 주관적인 생각 이해, 좋은 상호 작용. 비용이 높으며 도메인 지식 지원이 필요합니다.
설문지	사용자가 많고 , 한 번의 인터뷰가 불가능하며, 비용도 저렴합니다 .
현장 관찰	보다 복잡한 프로세스 및 운영에 적합합니다.
비즈니스 실무에 참여	문제의 본질을 효과적으로 발견하고 해결책을 찾습니다.
JRP(공동 요구 사항 계획)	모든 당사자가 참여하고, 아이디어를 이해하고, 차이점을 제거하고, 좋은 상호 작용을 하고, 높은 비용을 포함하는 고도로 조직화된 그룹 회의입니다.
스토리보드( 프로토타이핑 방법)	이야기가 전달되는 일련의 사진입니다.
샘플 조사/샘플링	수학적 통계를 바탕으로 비용을 절감하고 빠르게 확보하세요. 표본 크기 = a*(신뢰도 계수/허용 오차)2 참고: a는 일반적으로 0.25입니다.

• 사용자 인터뷰
  사용자 인터뷰는 요구사항을 획득하는 가장 기본적인 수단이며, 그 형식에는 구조화된 인터뷰와 비구조화된 인터뷰가 포함됩니다 . 구조화란 사전에 일련의 질문을 준비하고 이를 목표 방식으로 수행하는 것을 의미하며, 구조화되지 않음은 대략적인 아이디어만 나열하고 인터뷰의 특정 상황에 따라 전개하는 것을 의미합니다 . 가장 효과적인 면접은 이 두 가지 방법을 결합하여 진행되는데, 결국 모든 것을 명확하게 계획하는 것은 불가능하며 좋은 유연성이 유지되어야 합니다.
  사용자 인터뷰는 유연성이 뛰어나고 적용 범위가 넓습니다 . 하지만 사용자가 바빠서 시간 조율이 어려운 경우가 많고, 인터뷰 시 정보량이 많아 녹음이 어려운 경우 , 의사소통을 위해서는 많은 기술이 필요하고, 시스템 분석가는 충분한 도메인 지식이 있어야 하는등또한, 인터뷰 중에 회사의 기밀이고 민감한 주제에 직면할 수도 있습니다. 따라서 간단해 보이는 이 기술에도 시스템 분석가에게는 풍부한 경험과 강력한 의사소통 능력이 필요합니다.

• 설문
  조사는 사용자 인터뷰에 비해 많은 수의 응답으로부터 단시간 에 저렴한 비용으로 데이터를 수집할 수 있으며, 설문조사는 응답자가 익명으로 작성할 수 있어 대부분의 사용자가 실제 정보를 제공할 수 있으며 , 설문조사 결과가 더 쉽습니다. 정리하고 계산합니다 . 그러나 설문조사의 가장 큰 단점은 유연성이 부족하다는 점이며, 그 외의 단점으로는
  ① 양측이 만나지 못했다는 점, 시스템 분석가가 사용자의 표현이나 기타 행위로부터 좀 더 암시적인 정보를 얻을 수 없고, 사용자에게 기회가 없다는 점 등을 들 수 있다. 질문에 대한 자신의 의견을 즉시 명확히 하기 위해 모호하거나 잘못된 답변.
  ② 사용자는 작은 형태에도 심리적으로 주의를 기울이지 않고 심각하게 받아들이지 않아 피드백 정보가 불완전할 수 있습니다.
  ③ 설문지 내용이 질문에 대한 답변에 도움이 되지 않으며, 일부 내용을 이해할 수 없습니다.
  ④ 응답자 수가 예상보다 적은 경우가 많으며, 사용자가 질문에 답변하거나 모든 질문에 대해 추가 설명을 한다는 보장이 없습니다.

• 표본조사/표본추출 표본 조사/표본이란 모집단 중에서 대표 표본 집합을
  체계적으로 선택하는 과정을 말하며, 선택된 표본 집합에 대한 면밀한 연구를 통해 모집단 전체에 대한 유용한 정보를 밝힐 수 있습니다. 정보 시스템 개발을 위해 기존 시스템의 문서(파일)는 샘플링 모집단입니다. 시스템에 대한 요구사항 분석을 시작할 때 기존 시스템의 문서를 검토하는 것이 시스템을 사전에 이해하는 가장 좋은 방법입니다. 그러나 시스템 분석가는 어떤 유형의 문서를 살펴봐야 할까요?문서의 데이터가 너무 커서 하나씩 연구할 수 없는 경우 샘플링 기술을 사용하여 대표 데이터를 선택 해야 합니다 . 샘플링 기술은 데이터를 수집하는 데 사용될 수 있을 뿐만 아니라 사용자와의 인터뷰를 수집하거나 사용자를 수집하고 관찰하는 데에도 사용될 수 있습니다. 위에서 설명한 것과 동일한 샘플링 기술이 사람들을 샘플링할 때도 적용됩니다. 샘플링 기술을 통해 전체 인구가 아닌 부분을 선택하면 데이터 수집 속도가 빨라질 뿐만 아니라 효율성이 높아져 개발 비용이 절감됩니다. 또한 샘플링 기술은 수학적 통계의 원리를 사용하여 데이터 수집의 편향을 줄입니다. 그러나 표본추출 기술은 통계적 원리에 기초를 두고 있기 때문에 표본크기의 결정은 기대되는 신뢰성과 기존의 사전지식에 따라 달라지며, 시스템 분석가의 주관적 요인, 개인적 경험, 시스템 분석가의 경험에 크게 좌우된다. 의존도가 높으며 시스템 분석가에게 높은 수준의 풍부한 경험이 필요합니다.
  

• JRP(공동 요구 사항 계획)
  JRP는요구 사항을 얻는 데 상대적으로 비용이 많이 드는 방법이지만 매우 효과적인 방법이기도 합니다. 주요 사용자 대표, 시스템 분석가 및 개발 팀 대표를 한자리에 모아 조직화된 요구 사항을 논의합니다일반적으로 이 회의의 참가자 수는 6~18명이며, 소요 시간은 1~5시간입니다 .
  JRP의 주요 목적은 요구사항을 분석하고 검증하는 것이 아니라 요구사항을 수집하는 것입니다 . JRP를 시행함에 있어서는 다음과 같은 주요원칙을 파악해야 한다.
  ① JRP를 시행하기에 앞서 구체적인 안건을 수립하고 이를 엄격히 준수해야 한다.
  ② 정해진 시간표에 따라 진행한다.
  ③ 회의 내용을 최대한 완벽하게 녹음하도록 노력하세요.
  ④ 토론 중에 전문적인 용어는 사용하지 마십시오.
  ⑤ 갈등해결 능력을 최대한 활용한다.
  ⑥ 회의 중에는 충분한 휴식 시간을 설정해야 합니다.
  7팀이 합의에 도달하도록 격려한다.
  ⑧ JRP에 참여하는 모든 인원은 사전에 합의된 규정을 준수할 수 있도록 한다.

2.3 요구사항 분석

요구사항 분석 : 좋은 요구사항은 명확성, 완전성, 일관성, 테스트 가능성, 확실성, 추적성, 정확성 및 필요성과 같은 특성을 가져야 합니다. 따라서 분석가는 지저분한 사용자 요구 사항과 기대치를 사용자 요구로 변환하는 것이 요구 사항 분석의 작업 입니다 .

요구사항 분석 작업 :
(1) 시스템 컨텍스트 범위 다이어그램 그리기
(2) 사용자 인터페이스 프로토타입 생성
(3) 요구사항 타당성 분석
( 4) 요구사항 우선순위 결정
(5) 요구사항 모델 설정
(6) 데이터 생성 사전
(7) QFD(Quality Function 배포) 활용

2.3.1 구조적 분석 방법-SA

구조적 분석 방법인 SA 의 핵심은 데이터 사전 이다 . 이 코어를 둘러싼 모델 에는 데이터 모델, 기능 모델, 행동 모델(상태 모델) 이라는 세 가지 수준의 모델이 있습니다 .

구조화된 분석의 단계는 다음과 같습니다.
(1) 비즈니스 상황을 분석하고 현재의 물리적 모델을 반영한 데이터 흐름도(Data Flow DiagramDFD)를 만듭니다.
(2) 등가물류모델의 DFD를 도출한다.
(3) 새로운 논리 시스템을 설계하고 데이터 사전 및 기본 설명을 생성합니다.
(3) 인간-기계 인터페이스를 구축하고 대상 시스템의 물리적 모델에 대한 대체 DFD를 제안합니다.
(5) 다양한 옵션의 비용과 위험 수준을 결정하고 그에 따라 다양한 옵션을 분석합니다.
(6) 플랜을 선택하세요.
(7) 완전한 요구사항 사양을 설정합니다.

구조화된 분석 방법인 SA는 데이터 흐름(Data Flow)과 제어 흐름(Control Flow)이 있으며, 주로 사용되는 방법으로는 데이터 흐름도(DFD)와 데이터 사전(Data Dictionary)이 있습니다.

2.3.1.1 SA - 데이터 사전 DD

데이터 사전은 요구사항 분석 모델의 핵심입니다. 데이터 흐름도에서 데이터 흐름이나 파일을 구성하는 각 데이터 흐름, 파일, 프로세스, 데이터 항목에 대한 설명입니다.

데이터 사전에는 데이터 흐름, 데이터 항목, 데이터 저장 및 기본 처리라는 네 가지 범주의 항목이 있습니다. 데이터 요소, 데이터 구조, 데이터 흐름, 처리 논리 및 외부 엔터티가 포함됩니다. 아래 그림과 같이:

2.3.1.2 SA - 데이터 흐름도 DFD

데이터 흐름도(DFD)는 데이터 흐름도를 사용하여 기능 모델을 표현합니다. DFD는 시스템이 완성하는 기능을 설명합니다. 데이터 전송 및 처리 관점에서 시스템의 각 구성 요소의 기능을 설명하기 위해 그래픽 기호를 사용합니다. 계층별 세분화를 통해 그들 사이의 데이터 전송 상황은 시스템에 의해 완료되는 기능을 설명합니다. 아래 그림과 같이:

그 중 DFD에는 '최상위 DFD 맵'과 '0 레이어 DFD 맵'도 있습니다.

위 그림에 표시된 것처럼 다음과 같은 "그림 요소" 설명이 있습니다.

다음과 같이 잘못된 DFD 다이어그램이 첨부되어 있습니다.

위에 표시된 오류:

처리 3.1.2에는 입력이 있지만 출력이 없는 경우를 "블랙홀"이라고 합니다.
처리 3.1.3에는 출력이 있지만 입력이 없습니다. 그것을 "기적"이라고 부르세요.
3.1.1 처리에서는 입력이 출력을 생성하기에 충분하지 않은데, 이를 "회색 구멍"이라고 합니다.

2.3.1.3 SA - 상태 전이 다이어그램 STD

상태 전이 다이어그램은 행동 모델을 표현하는 데 사용되며, STD는 시스템의 상태와 시스템 상태 전이를 유발하는 이벤트를 설명하여 시스템의 동작을 나타내며, 특정 이벤트의 결과로 어떤 작업이 수행되는지 나타냅니다. 아래 그림과 같이:

2.3.1.4 SA - ER 다이어그램/엔티티 관계 다이어그램

ER 다이어그램은 주로 엔터티 속성과 엔터티 간의 관계를 설명합니다. 또한 ER 모델은 구조화 시대의 모델이자 산물이며 객체지향이나 UML에는 존재하지 않습니다. 아래 그림과 같이:

약한 실체란 무엇인가?
예: 인사 관리 시스템에서 직원의 자녀에 대한 정보는 직원의 존재를 기반으로 하며 자녀 엔터티는 약한 엔터티이며 자녀와 직원 간의 관계는 종속 관계입니다. 따라서 직원은 실체이며 강력한 실체가 될 수도 있습니다.
강한 엔터티와 약한 엔터티 간의 관계는 1:1 또는 1:N만 가능합니다.

2.3.2 객체지향 분석방법 - OOA

여러 관련 개념

물체	속성[데이터] + 메소드[작업] + 객체 ID/식별 ID
수업 [자세한 내용은 아래 참조]	엔터티 클래스/컨트롤 클래스/경계 클래스 엔터티 클래스: 데이터 유형이든 데이터베이스와 대응 관계를 갖는 경우가 많다. 컨트롤 클래스: 엔터티 클래스와 경계 클래스를 연결하는 클래스 경계 클래스: 외부와 통신하는 클래스 시스템의 경계 세 가지 유사한 MVC 모델 간의 관계, 그들의 아이디어는 동일합니다.
상속과 일반화	재사용 메커니즘은 일종의 긴밀한 결합입니다. 상위 클래스가 변경되면 하위 클래스도 변경되어야 하기 때문입니다. 상속은 기존 인스턴스를 기반으로 합니다.
캡슐화	객체의 속성과 구현 세부정보를 숨기고 인터페이스만 외부에 노출합니다.
다형성	서로 다른 개체는 동일한 정보를 받고 서로 다른 결과를 생성합니다.
상호 작용	메소드 정의만 있고 메소드 구현은 없는 특수 클래스
초과 적재	클래스에는 이름이 같고 매개변수 유형이 다른 여러 메서드가 있을 수 있습니다. 이름은 같지만 매개변수가 다른 함수의 특징은
소식화 소식통신	메시지는 비동기적으로 전달됩니다.
덮어쓰기 및 다시 쓰기	하위 클래스와 이름이 같은 메서드가 상위 클래스와 이름이 같은 메서드를 재정의합니다.
조합 및 집계	집합관계 : 자동차 부품과 자동차 전체의 관계(전체와 부품의 수명주기가 다름) 결합관계 : 부서와 기업의 관계 회사가 부도나면 부서도 망하게 된다. (전체 생애주기는 부품 생애주기와 동일하다)

OOA는 대략 다음 5가지 기본 단계를 따릅니다.

(1) 객체 및 클래스 결정 : 여기서 언급하는 객체는 데이터와 그 처리 방법을 추상화한 것으로, 현실 세계의 특정 사물에 대한 정보를 저장하고 처리하는 시스템의 능력을 반영합니다. 클래스는 여러 개체에 대한 공통 속성 및 메서드 모음에 대한 설명이며, 클래스에서 새 개체를 만드는 방법에 대한 설명을 포함합니다.
(2) 구조 결정 : 구조는 문제 영역의 복잡성과 연결 관계를 의미합니다. 클래스 멤버 구조는 일반화-전문화 관계를 반영하고, 전체-부분 구조는 전체와 부분의 관계를 반영한다.
(3) 주제를 정한다 : 주제란 사물의 총체적 개관과 종합적 분석모형을 말한다.
(4) 속성 결정 : 속성은 객체의 인스턴스나 분류 구조를 설명하는 데 사용할 수 있는 데이터 요소로, 다이어그램에 제공되고 객체 저장소에 지정될 수 있습니다.
(5) 방법 결정 : 방법은 메시지를 받은 후 수행해야 하는 일부 처리 방법입니다. 방법은 다이어그램에 정의되고 개체 저장소에 지정되어야 합니다. 모든 개체 및 구조에 대해 추가, 수정, 삭제 및 선택 방법은 그 자체로 암시적이며(비록 개체의 저장소에 정의되어 있고 다이어그램에 표시되지 않음) 일부가 표시됩니다.

2.3.2.1 OOA - UML

OOA 요구 사항 분석을 위한 UML(Unified Modeling Language, 플랫폼 및 언어 독립적)은 기본 빌딩 블록, 규칙 및 공통 메커니즘으로 구성됩니다.

UML 기본 빌딩 블록 [중요 구성 요소]

사무	설명하다
구조적인 것	클래스, 인터페이스, 협업 사용 사례, 활동 클래스, 구성 요소 및 노드를 포함한 가장 정적인 부분
행동적인 것들	메시지, 동작 순서, 연결을 포함하여 시간과 공간의 동작을 나타냅니다.
그룹 물건	패키지, 구성요소 등 하나의 상자로 생각하세요.
사물에 주석을 달다	UML 모델의 해석 부분입니다. 모델 요소 설명, 예시 및 주석 달기

UML의 기본 빌딩 블록 간의 관계 [사물을 서로 밀접하게 연결]

관계	설명하다
종속성	하나가 변경되면 다른 것에 영향을 미치며, 포함 관계와 확장 관계는 모두 종속 관계입니다.
일반화 관계	특수 일반 관계, 특수 요소의 객체는 일반 요소의 객체를 대체할 수 있습니다.
연결 관계	객체 간의 연결인 체인을 설명합니다.
관계를 깨닫다	接口与类之间的关系，一个类指定了由另一个类保证执行的契约

UML基本构造块之图【多个相互关联的事物的集合】

图	描述
静态图	结构图
类图	描述一组类，接口协作和它们之间的关系。
对象图	描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。
构件图	也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。
部署图	表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。
制品图	描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。
包图	将某些类放入“包”中，通过包图来组织业务概念图。
组合结构图	展示该部分内容“内部”参与者的配置情况。这个图不常用。
动态图	行为图
用例图	系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。
顺序图	强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。
通信图	也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。
定时图	消息跨越不同对象或角色的实际时间。交互图的一种。
交互概览图	活动图与顺序图的结合。这个图不常用。
活动图	类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。
状态图	从某个物品的状态是如何变化的角度来展示流程。

UML规则

是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML公共机制

是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。

UML中的概念

• 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
• 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
• 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
• 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
• 用例：是描述一系列的动作，产生有价值的结果。
• 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
• 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。

2.3.2.2 OOA - UML 4+1视图

现有的UML，再有的UML视图

UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。

“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。

“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。

2.3.2.3 OOA - 用例模型与分析模型

在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。

2.3.2.4 需求分析工具

2.3.2.4.1 使用用例建模系统需求

用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。

用例建模促进并鼓励了用户参与，具有如下优点：

• 提供了捕捉功能需求的工具。
• 有助于将系统分解为更易于管理的小块。
• 提供了与用户以及其他关心系统的关联人员进行交流的工具。
• 辅助估计项目范围、投入和进度。
• 提供了需求跟踪的工具。
• 提供了确定数据对象或实体的起点。
• 提供了设计用户和系统接口的功能规格说明。

为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。

1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：

• 对架构设计的重要影响。
• 容易实现但包含重要功能。
• 包含有风险、时间紧迫或复杂的功能。
• 需要大量的研究或者新的、有风险的技术。
• 包含主要的业务功能。
• 将增加或者减少费用。

2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：

• 系统事件及其状态的图形化表述有利于对系统功能的理解。
• 有助于确定遗漏的用例。
• 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。

2.3.2.4.2 数据建模与分析

数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。

数据建模的系统概念：

• 实体
• 属性（数据类型、域、默认值）（键）
• 关系

如何构造数据模型？

• 获取实体。
• 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
• 基于键的数据模型：确定每个实体的键。
• 泛化层次体系：父实体、子实体。
• 具有完整属性的数据模型。
• 分析数据模型：规范化（第一范式、第二范式、第三范式）。
• 将数据需求映射到地点：数据–地点–CRUD矩阵。

2.3.2.4.3 过程建模

过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。

过程建模的系统概念：

• 外部代理：常见的同义词包括外部实体。
• 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
• 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
• 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。

如何构造过程模型：

• 构造上下文数据流图：0号数据流图。
• 构造系统功能分解图。
• 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
• 事件分解图：把事件处理过程增加到分解图中。
• 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
• 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
• 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。

2.3.2.4.4 面向对象分析与建模

面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。

2.4 需求定义（形成需求规格）

需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。

原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。

2.5 需求确认与验证

需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求验证包括了需求评审和需求测试。

需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。

需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

三、 需求管理（支持，保障）

在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

3.1 定义需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。

3.2 需求的状态

在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

3.3 需求变更管理

CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。

3.4 需求变更管理过程

（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：

(1) 모든 요구사항 변경은 변경 관리 프로세스를 따라야 합니다.
(2) 승인되지 않은 변경 사항에 대해서는 설계 및 구현 작업을 수행해서는 안 됩니다.
(3) 변경 사항은 프로젝트 변경 통제 위원회에서 어떤 변경 사항을 구현해야 하는지 결정해야 합니다.
(4) 프로젝트 위험 보유자는 변경 내용을 이해할 수 있어야 합니다.
(5) 변경 요청의 원본 문서를 프로젝트 구성 라이브러리에서 삭제하거나 수정해서는 안 됩니다.
(6) 각 통합 요구사항 변경은 수평 추적성을 유지하기 위해 승인된 변경 요청까지 추적 가능해야 합니다.

3.5 수요위험

위험한 관행에는 다음이 포함됩니다. ① 참여할 사용자가 충분하지 않습니다. ②사용자 분류는 무시됩니다. ③사용자 요구가 계속 증가하고 있습니다. ④ 모호한 요구. ⑤불필요한 기능. ⑥지나치게 간소화된 SRS. 7부정확한 추정.

변경사유 : ① 외부환경의 변화. ②요구사항과 디자인이 충분하지 않습니다. ③ 신기술의 등장. ④ 회사의 조직개편은 업무프로세스의 변화를 가져온다.

3.6 요구사항 추적

SRS의 각 소프트웨어 구성 항목의 요구 사항은 관련된 시스템(또는 하위 시스템)의 요구 사항을 양방향으로 추적할 수 있어야 합니다. 소위 양방향 추적에는 순방향 추적과 역방향 추적이 포함됩니다. 순방향 추적은 SRS의 각 요구 사항이 후속 작업 결과에서 해당 지점을 찾을 수 있는지 확인하는 것을 의미합니다. 역방향 추적은 역방향 추적이라고도 하며 설계를 확인하는 것을 의미합니다. .문서, 코드, 테스트 케이스, 기타 작업 결과를 모두 SRS에서 찾을 수 있는지 여부.