수요 유형
소프트웨어 요구 사항은 비즈니스 요구 사항, 사용자 요구 사항 및 기능 요구 사항의 세 가지 수준으로 구성됩니다. 또한 각 시스템에는 다양한 비 기능 요구 사항이 있습니다.
BusinessRequirement 는 조직 또는 고객의 상위 수준 목표를 나타냅니다. 비즈니스 요구 사항은 일반적으로 프로젝트 투자자, 제품을 구입한 고객, 실제 사용자의 관리자, 마케팅 부서 또는 제품 기획 부서에서 비롯됩니다. 비즈니스 요구 사항은 조직이 시스템을 개발해야 하는 이유, 즉 조직이 달성하고자 하는 목표를 설명합니다. 비전 및 범위 문서를 사용하여 프로젝트 차트 또는 시장 수요 문서라고도 하는 업무 요구사항을 기록합니다. UserRequirement 는 사용자의 목표 또는 사용자가 시스템에서 완료해야 하는 작업에 대해 설명합니다. 사용 사례, 장면 설명, 이벤트 응답 테이블은 모두 사용자의 요구를 표현하는 효과적인 방법입니다. 즉, 사용자 요구 사항은 사용자가 시스템으로 수행할 수 있는 작업을 설명합니다.
기능 요구 사항은 개발자가 제품에서 구현해야 하는 소프트웨어 기능을 규정하고 있으며, 사용자는 이러한 기능을 사용하여 작업을 수행하고 비즈니스 요구 사항을 충족시킬 수 있습니다. 기능적 요구 사항은 습관적으로 "응당" 으로 설명되기 때문에 행동적 요구 사항이라고도 합니다. "시스템은 사용자에게 가입을 수락했음을 알리는 이메일을 보내야 합니다." 기능 요구 사항 설명은 개발자가 구현해야 하는 것입니다.
비기능 요구사항은 사용자의 비즈니스 요구를 충족하기 위해 소프트웨어 제품이 기능 요구 사항 외에 갖추어야 하는 특성을 정의합니다. 시스템 무결성 (온라인 도움말, 데이터 관리, 사용자 관리, 소프트웨어 출시 관리, 온라인 업그레이드 등) 을 포함합니다. ), 성능, 신뢰성, 서비스 용이성, 확장성, 기술 및 비즈니스에 대한 적응성 등
수요 분석 태스크
1 해결된 문제
1) 타겟 시스템의 모든 기능, 성능 및 한계를 완전하고 정확하게 파악합니다. 2) 모든 입력 및 출력 흐름을 찾으십시오. 3) 모든 처리 방법을 찾으십시오.
4) 완전한 계층형 DFD, 데이터 사전 및 처리 설명을 생성합니다. 5) 보충 의견.
2 종합적인 요구 사항
시스템의 종합적인 요구 사항, 시스템 기능 요구 사항, 시스템 성능 요구 사항, 운영 요구 사항 및 향후 가능한 요구 사항을 파악합니다.
3 임무
그림 1 은 수요 분석의 작업 다이어그램입니다. 요구 사항 분석 단계에서 완료해야 할 구체적인 최종 작업은 개발자와 사용자가 승인하거나 승인한 소프트웨어 요구 사항 분석 문서 (요구 사항 설명서, 개정된 프로젝트 개발 계획, 예비 사용 설명서, 테스트 계획 확인 및 데이터 요구 사항 설명서) 를 형성하는 것입니다. 이 문서는 시스템이 개발할 내용을 명확하고 정확하게 설명하고 모든 사용자 지향, 기계 지향 및 기타 소프트웨어 시스템 인터페이스를 포함한 상세한 기술 요구 사항을 규정합니다. 수요 문서는 개발 과정에서 줄곧 지도 역할을 하고 있다고 할 수 있다.
소프트웨어 개발 1 단계의 수요 분석 임무를 더 잘 완수하고 품질을 향상시키기 위해서는 수요 관리가 필수적이다.
수요 관리의 목적은 고객과 개발자 사이에 수요에 대한 공통된 이해를 구축하고, 수요와 기타 업무 결과의 일관성을 유지하고, 수요 변경을 통제하는 것입니다. 주로 수요 변경 관리를 추적하고 통제하는 데 반영됩니다. 수요 관리는 개발 작업의 효과적인 수행을 보장하는 것으로, 전체 개발 프로세스와 제품 자체를 포함하는 높은 수준의 시스템 동작입니다.
수요 분석 방법
수요 분석 방법은 소프트웨어 문제의 정보 필드와 기능 영역의 시스템 분석 프로세스와 표현으로 구성되며, 대부분의 수요 분석 방법은 정보 중심의 접근 방식입니다. 정보 도메인에는 정보 흐름, 정보 내용 및 정보 구조의 세 가지 속성이 있습니다.
일반적으로 사용되는 요구 사항 분석 방법에는 데이터 흐름을 위한 구조화 방법 (SA), 데이터 구조를 위한 Jackson 방법 (JSD), 데이터 구조를 위한 구조화 데이터 시스템 개발 방법 (DSSD), 객체 지향 분석 방법 (OOA) 등이 있습니다. 이 방법의 선택은 개발자가 사용할 수 있는 리소스를 기반으로 해야 하며, 맹목적으로 적용해서는 안 됩니다. 이 기사에서는 주로 데이터 흐름을위한 구조화 된 방법을 연구합니다.
데이터 흐름 지향 구조화 된 방법
데이터 흐름에 대한 구조화된 접근 방식은 데이터 흐름에 대한 수요 분석 방법으로, 수요 분석에서 가장 널리 사용되는 방법 중 하나입니다. SA 는 또한 모델링 활동입니다. 이 방법은 읽기 쉬운 기호를 사용하여 소프트웨어의 데이터 전송 및 변환 관계에 따라 위에서 아래로 분해하여 기능 요구 사항을 충족하는 소프트웨어 모델을 설명합니다. 데이터 처리 소프트웨어의 요구 사항 분석에 적합합니다. 이 방법은 간단하고 이해하기 쉬울 뿐만 아니라 설계 단계에서 구조화 설계 (SD) 와 연계하여 좋은 설계 결과를 얻을 수 있습니다.
하향식 층별 분해의 분석 전략
SA 방법의 기본 수단은' 분해' 와' 추상화' 이다. 이것은 시스템 개발 기술에서 복잡성을 제어하는 두 가지 방법이다. 시스템을 "추상적" 으로 모델링합니다. 즉, 입력 출력과 시스템 이름이 있는 상자입니다. 그런 다음 상자를 열고 이해할 수 있을 때까지 한 층씩 분해합니다. (존 F. 케네디, Northern Exposure (미국 TV 드라마), 컴퓨터명언) 그래서 분석의 전략은 위에서 아래로, 추상에서 구체적인 과정까지. 그림 2 와 같이.
구조화된 방법에서는 도구를 사용합니다.
SA 방법은 그래픽 등 반형식 설명 방법을 사용하여 요구 사항을 표현하고 간결하며 이해하기 쉬우며 이를 사용하여 요구 사항 사양 사양의 주요 부분을 형성합니다. 설명 도구는 다음과 같습니다
1) 데이터 흐름도: 시스템이 어떤 부분으로 구성되어 있는지, 각 부분 사이에 어떤 연관이 있는지 등을 설명합니다. 2) 데이터 사전: 데이터 흐름 그래프의 각 그래픽 요소를 정의합니다.
3) 프로세스 논리를 설명하는 구조화된 언어, 의사 결정 테이블 및 의사 결정 트리: 데이터 흐름 그래프에서 더 이상 분해할 수 없는 각 프로세스를 자세히 설명합니다.
분석은 주로 데이터 전송 및 데이터 변환을 기반으로 하는 데이터 흐름이기 때문에 구조화된 분석의 일반적인 방법은 데이터 흐름 차트 분석 방법을 사용하는 것입니다. 최종 결과는 데이터 흐름 차트 세트, 데이터 흐름 다이어그램의 구성 요소를 정의하는 데이터 사전 및 처리 논리에 대한 설명이 포함된 수요 사양 설명을 생성하는 것입니다.
구조적 분석 단계
체계적인 방법으로 시스템 요구 사항 분석을 수행하는 구체적인 단계는 1) 현재 시스템의 작업 흐름을 이해하고 현재 시스템의 물리적 모델을 얻는 것입니다. 현행 제도에 대한 상세한 조사를 통해 현행 제도의 업무 과정을 이해하고 자료, 기록, 자료, 보고 등을 수집할 수 있다. 우리가 보고, 듣고, 수집한 정보와 상황을 그래픽으로 표현합니다. 즉, 시스템 순서도를 그리는 것과 같이 현재 시스템에 대한 이해를 반영하는 모델을 사용하는 것입니다.
2) 현재 시스템의 논리 모델을 추상화합니다. 물리적 모델은 시스템 "어떻게" 의 구체적인 구현을 반영하고, 물리적 모델에서 비본질적인 요소를 제거하고, 본질적인 요소를 추출하고, 현재 시스템의 논리적 모델을 구축하고, 현재 시스템의 "무엇을 하는가" 기능을 반영합니다.
3) 대상 시스템의 논리 모델을 설정합니다. 대상 시스템과 현재 시스템의 논리적 차이를 분석하고, 대상 시스템이 무엇을 해야 하는지 명확히 한 다음, 현재 시스템의 논리 모델에서 대상 시스템의 논리 모델을 도출합니다.
4) 추가 보충 및 최적화. 대상 시스템을 완전히 설명하기 위해서는 결과 논리 모델을 보완해야 합니다.
대상 시스템의 인간-기계 인터페이스를 설명하십시오.
오류 처리, 시스템 시작 및 종료, 시스템 입/출력, 시스템 성능 요구 사항 등 지금까지 자세히 고려하지 않은 세부 사항을 설명합니다. ).
기타 (시스템별 및 충족되어야 하는 기타 성능 및 제한 사항) 도 적절한 형식으로 서면으로 기록해야 합니다. 분석 단계가 끝나면 시스템 분석가는 사용자와 함께 시스템 파일을 다시 한 번 자세히 검토하여 시스템 설계를 시작하기 전에 가능한 한 많은 시스템 오류를 찾아 적시에 수정해야 합니다. 시스템 파일 (소프트웨어 요구 사항 사양 등) 은 사용자가 모델이 요구 사항을 표현한 것을 확인한 후에만 사용할 수 있습니다. ) 는 결국 사용자와 소프트웨어 개발자 간의 "계약" 으로 확인되었습니다.
구조적 방법의 장단점
1) 이점: 구조화 된 접근 방식은 소프트웨어 요구 사항 분석에서 인정 받고 효과적이며 성숙하며 널리 사용되는 접근 방식이며 데이터 처리 소프트웨어 요구 사항 분석 개발에 더 적합합니다. 이 방법은 그래픽 등의 반형식화 도구를 사용하여 요구 사항을 표현하고 간결하고 읽기 쉽고 사용하기 쉬우며 후기 설계, 테스트 및 평가에 유리한 조건을 제공합니다. 2) 단점: ① 기존의 SA 방법은 주로 데이터 처리에 사용되며, 주요 도구인 DFD 는 시스템의 "무엇을 하는가" 기능을 구현하지만 처리 순서, 즉 제어 프로세스를 반영하지 않는 정적 모델입니다. 따라서 실시간 제어 시스템을 설명하는 데는 적합하지 않습니다. ②60 년대 후반에 나타난 데이터베이스 기술로 많은 대형 데이터 처리 시스템의 데이터가 데이터베이스 형식으로 조직되었다. SA 방법의 DFD 는 "데이터 요구 사항" 분석 및 설명에 제한적으로 적용되며, DFD 는 데이터베이스 기술의 엔티티 연락처 차트 (ER 차트) 와 결합되어야 합니다 (IDEF0 의 기능 모델이 IDE 1 의 정보 모델과 결합된 것처럼). ER 그래프는 데이터 저장소의 세부 사항, 데이터와 데이터의 관계, 데이터와 처리의 관계에 대한 이해를 높이고 DD 에 포함된 데이터 컨텐츠 표현 문제를 해결하여 시스템에 대한 사용자의 요구를 더욱 완벽하게 설명합니다. ③ 항공권 예약, 은행 관리 시스템 등과 같이 인간-컴퓨터 상호 작용이 잦은 소프트웨어 시스템의 경우 사용자가 가장 관심을 갖는 것은 사용 방법입니다. 입력 명령, 운영 모드, 시스템 응답 모드, 출력 형식은 모두 사용자 요구 사항의 중요한 측면입니다. DFD 는 인간-기계 인터페이스 시스템의 요구를 설명하는 데 적합하지 않습니다. SA 방법은 종종 자연어로 이 부분을 보완합니다. ④ 소프트웨어 요구 사항을 설명하는 정확성은 향상되어야 한다. 5 수요 변화
프로젝트를 개발하는 과정에서 사용자는 언제든지 개발자에게 해결을 요청하는 새로운 요구 사항을 제시할 것이다. 이러한 요구 사항은 개발 단계에서 제기될 수도 있고, 개발 단계 이후에 제기될 수도 있다. 수요 분석의 인접한 두 하위 단계 또는 반복 주기의 수요 분석에서 다음 단계 또는 주기의 수요 분석 결과가 이전 단계와 일치하지 않습니다. 이러한 불일치를 수요 변경이라고 합니다. 수요 변화의 주요 원인은 다음과 같습니다: 1) 수요 분석 단계에서 개발자와 사용자 간의 의사 소통이 부족합니다. 수요 분석 단계에서 개발자는 사용자와 잘 통신하지 않으므로 개발자는 사용자가 제공한 대략적인 정보를 기반으로 사용자의 요구를 도출합니다. 이러한 수요 분석을 통해 얻은 수요는 종종 사용자의 실제 수요와는 거리가 멀기 때문에 사용자가 변경을 하게 됩니다. 2) 프로젝트 구현 주기가 너무 깁니다. 시간이 지남에 따라 전체 시스템에 대한 사용자의 이해가 점점 더 깊어졌습니다. 모듈의 인터페이스, 기능, 성능에 대해 더 높고 더 많은 요구 사항을 제시합니다. 3) 기술 업데이트가 너무 빠릅니다. 기술의 빠른 업데이트로 인해 기업들은 대상 시스템과 직접적인 관계를 가질 수 있는 새로운 장치를 도입할 수 있습니다. 이러한 변화는 사용자의 기존 문제가 해결되기 전이나 해결 과정에서 발생할 수 있기 때문에 개발자는 이러한 새로운 요구에 동참해야 합니다. [3]
수요 변경을 최소화하고 수요 분석의 높은 안정성을 보장하기 위해 다음과 같은 방법을 사용할 수 있습니다. 1) 분업이 명확하고 시스템 분석가와 프로그래머의 책임이 다릅니다. 시스템 분석가는 사용자와 프로그래머 사이에 있으며 사용자와 개발자의 지식과 의견을 전달합니다. 시스템 분석가는 사용자가 개발된 소프트웨어에 대한 수요를 제시할 수 있도록 돕고, 프로그래머와 충분히 교류하여 합리성과 실현 가능성을 탐구해야 합니다. 그림 3 에서 볼 수 있듯이 시스템 분석가는 수요 분석 단계에서 중요한 역할을 합니다.
2) 개발자는 사용자와 협력하여 교환합니다. 시스템 분석가는 사용자의 요구를 주의 깊게 경청하고 사용자가 요구 사항을 변경할 때 정리하고 분석해야 합니다. 수요 변화의 원인을 분석하고 실행 가능한 대안을 제시하다. 또한 이러한 수요 변경이 전체 프로젝트의 발전에 악영향을 미칠 수 있음을 사용자에게 설명합니다. 3) 계약 제약. 수요 변경은 전체 프로젝트에 영향을 줄 수 있으므로 개발자와 사용자는 프로젝트 계약을 체결할 때 수요 변경에 관련 계약 조건을 추가할 수 있습니다. 4) 요구사항 문서를 작성하고 버전을 관리합니다. 수요 분석의 최종 결과는 고객과 개발자가 개발한 제품에 대해 이미 * * * 를 이해하고 있는 시스템 문서입니다. 이 문서를 사용하면 개발자의 역할이 변경되더라도 수요 분석의 선행 작업에 영향을 주지 않습니다. 각 요구 사항 변경에는 새 버전이 있습니다. 5) 수요 검토 및 수요 기준 수립. 개발자가 사용자의 요구 사항을 자세히 이해할 수 있도록 다양한 사람들이 다양한 관점에서 요구 사항을 검증하도록 하기 위해 요구 사항 제출자 (사용자) 로서 요구 사항 검토 과정에서 많은 가치 있는 의견을 제시할 수 있는 경우가 많습니다. 또한 요구 사항을 최종적으로 확인할 수 있는 기회이기도 합니다. 수요 변경 발생을 효과적으로 줄일 수 있습니다. 요구 사항이 공식적인 검토 및 승인을 통과한 후에는 요구 사항 베이스라인을 결정하고 프로젝트 정의 변경 프로세스에 따라 추가 요구 사항을 변경해야 합니다. 수요 기준선을 설정하면 변경으로 인한 번거로움을 최소화할 수 있습니다.
소프트웨어 아키텍처 (소프트웨어
Architecture) 는 대규모 소프트웨어 시스템의 모든 측면을 안내하는 일련의 관련 추상 패턴입니다. 소프트웨어 아키텍처는 시스템의 스케치입니다. 소프트웨어 아키텍처가 설명하는 객체는 직접 조합 시스템입니다.
시스템의 추상 구성 요소. 구성 요소 간의 연결은 구성 요소 간의 통신을 명확하고 자세하게 설명합니다. 구현 단계에서 이러한 추상 구성 요소는 특정 클래스나 객체와 같은 실제 구성 요소로 세분화됩니다. 얼굴
객체 영역에서 구성 요소 간의 연결은 일반적으로 인터페이스 _ (컴퓨터 과학) 를 통해 이루어집니다.
소프트웨어 아키텍처는 컴퓨터 소프트웨어 실습을 구축하는 기초입니다. 건축가가 건축 프로젝트의 설계 원칙과 목표를 제도사 그림의 기초로 설정하는 것처럼, 소프트웨어 설계자 또는 시스템 설계자는 소프트웨어 아키텍처를 실제 시스템 설계 시나리오의 기초로 제시하여 다양한 고객의 요구를 충족합니다.
소프트웨어 아키텍처는 이해하기 쉬운 개념으로, 대부분의 엔지니어 (특히 경험이 적은 엔지니어) 는 직관적으로 알 수 있지만 정확한 정의를 내리기는 어렵다. 특히 디자인과 아키텍처는 명확하게 구분하기 어렵습니다. 아키텍처는 설계의 한 측면에 속하며 특정 특성에 중점을 둡니다.
"소프트웨어 아키텍처 소개" 에서 데이비드 갈런드 (David Shaw) 와 메리 쇼 (Mary Shaw)
소프트웨어 아키텍처는 다음과 같은 문제와 관련된 설계 측면으로 간주됩니다. "계산 알고리즘과 데이터 구조 외에도 시스템의 전체 구조를 설계하고 식별하는 것이 새로운 문제가 되었습니다. 구조적 문제에는 전체 조직 구조와 글로벌 통제 허브가 포함됩니다.
구조; 통신, 동기화 및 데이터 액세스 프로토콜 디자인 요소의 기능 할당; 물류; 디자인 요소의 구성; 교정 및 성능 대체 설계 선택.
하지만 건축은 단순한 구조가 아닙니다. IEEE 워크그룹
On Architecture 는 이를 "시스템 환경에서 가장 높은 개념" 으로 정의합니다. 이 프레임워크에는 시스템 무결성, 경제적 제약, 미적 요구 사항 및 스타일도 포함되어 있습니다. 그것은 단지 알아차리는 것이 아닙니다.
내부 고려를 강조하면서 사용자 환경과 개발 환경 모두에서 시스템을 전반적으로 고려해야 합니다. 즉, 외부 고려에도 중점을 두어야 합니다.
Rational 통합 과정에서 소프트웨어 시스템의 아키텍처 (지정된 지점에서) 는 인터페이스를 통해 감소 구성 요소 및 인터페이스로 구성된 구성 요소와 상호 작용하는 시스템의 중요한 구성 요소의 구성 또는 구조를 나타냅니다.
목적, 주제, 자료 및 구조와 관련하여 소프트웨어 아키텍처는 건물의 아키텍처와 비교할 수 있습니다. 소프트웨어 설계자는 소프트웨어 이론에 대한 광범위한 이해와 사실과 통제에 대한 경험이 필요합니다.
소프트웨어 제품의 고급 디자인. 소프트웨어 설계자는 소프트웨어의 모듈화, 모듈 간 상호 작용, 사용자 인터페이스 스타일, 외부 인터페이스 방법, 혁신적인 설계 특성, 상위 수준의 객체에 대한 객체 조작 및 논리를 정의하고 설계합니다.
및 프로세스.
일반적으로 소프트웨어 시스템의 아키텍처에는 두 가지 요소가 있습니다.
소프트웨어 시스템이 전체적으로 부분까지 가장 높은 계층입니다.
시스템은 일반적으로 구성 요소로 구성되며, 이러한 구성 요소가 형성되는 방법과 상호 작용하는 방법은 시스템 자체의 구조에 대한 중요한 정보입니다.
특히 아키텍처 구성 요소, 커넥터 및 작업 흐름이 포함됩니다.
아키텍처 요소란 시스템을 구성하는 핵심' 벽돌' 이며 커넥터는 이러한 요소 간의 통신 경로, 통신 메커니즘 및 예상 결과를 설명하고 작업 흐름은 시스템이 이러한 요소를 사용하는 방법을 설명합니다.
커넥터가 요구 사항을 충족합니다.
시스템 구축을 위한 최고 수준의, 변경하기 어려운 비즈니스 및 기술 결정.
시스템을 구축하기 전에 미리 결정해야 할 중요한 결정이 많이 있는데, 일단 시스템이 설계나 세부 구축을 시작하면 이러한 결정은 바뀌기 어렵고 심지어 변할 수도 없습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 시스템명언) 이러한 결정은 반드시 시스템 설계의 성패와 관련된 가장 중요한 결정이며, 반드시 매우 세심하게 연구하고 조사해야 한다.
프레임워크는 더 큰 일반 응용 프로그램에 사용해야 하므로 많은 시간을 절약할 수 있습니다. 소프트웨어를 쉽게 개발할 수 있습니다.
(소프트웨어 개발은 일반적으로 아키텍처 설계보다는 디자인 패턴에 초점을 맞추고 있습니다.)