질문 2: 사용자 요구 사항 1 을 체계적으로 분석하는 방법 개념
요구사항의 정의에는 사용자의 관점 (시스템의 외부 동작) 과 개발자의 관점 (일부 내부 특성) 에서 수요를 해석하는 것이 포함됩니다.
중요한 문제는 요구사항 문서를 작성하는 것입니다. 나는 모든 개발자가 한 프로젝트에서 교체되는 것을 목격했고, 고객은 새로운 수요 분석가와 함께 앉아야 했다. 시스템 분석가는 말했다: 우리는 당신과 당신의 요구에 대해 이야기하고 싶다. 고객의 첫 번째 반응은: 나는 이미 나의 요구를 모두 너의 전임자에게 알렸는데, 지금은 단지 나에게 시스템을 만들어 주고 싶다는 것이다.
자칭 전지전능한 사람
사실 UGGs, 수요는 문서화되지 않았기 때문에 새로운 분석가는 처음부터 시작해야 한다. 따라서 메일, 회의록, 단편적인 대화만 있다면, 사용자의 요구를 이미 알고 있다는 것을 확신하는 것은 완전히 자신을 속이는 것이다. (알버트 아인슈타인, 자기관리명언)
수요의 또 다른 정의는 수요가 사용자에게 필요하며 프로그램 또는 시스템 개발을 트리거할 수 있다는 것입니다. 일부 수요 분석가는 시스템 외부에서 사용자 만족을 위한 기능, 기능 및 속성을 찾을 수 있도록 개념을 확장했습니다. 이러한 정의는 제품이 어떻게 설계되고 구성되었는지 강조하는 것이 아니라 제품이 어떤 것인지 강조한다. 다음 정의는 사용자 요구사항에서 시스템 특성으로 더 이전됩니다.
수요는 반드시 달성해야 할 것을 나타내는 규범이다. 시스템의 동작, 특성 또는 속성을 설명하며 개발 중 시스템에 대한 제약입니다.
이러한 다양한 정의에서 명확하고 모호한 수요 용어가 없다는 것을 쉽게 알 수 있습니다. 진정한 요구는 사실 사람들의 머리 속에 존재한다. 이 사람은 주로 고객을 가리킨다. 그러나 일반적으로 사용자는 자신의 요구를 설명할 수 없습니다. 그들은 단지 시스템 분석가가 자신의 언어 설명에 따라 관련 요구 사항을 정리하고 고객과 확인하기를 원할 뿐이다. 시스템 분석가와 고객은 모든 프로젝트 관련자들이 요구 사항을 설명하는 용어를 이해해야 합니다.
문서화된 모든 요구 사항 (예: 아래에 설명된 요구 사항 사양) 은 모델과 설명일 뿐입니다.
2. 수요 분석 작업
소프트웨어 시스템 개발의 가장 어려운 부분은 무엇을 개발해야 하는지 정확하게 설명하는 것이다. 가장 어려운 개념적 작업은 사용자, 기계 및 기타 소프트웨어 시스템의 모든 인터페이스를 포함한 상세한 기술 요구 사항을 작성하는 것입니다. 동시에, 이는 일단 잘못을 저지르면 결국 시스템에 큰 피해를 입힐 수 있는 부분이며, 후기 수정은 매우 어렵다.
현재 국내 제품이 많기 때문에 한 기업이 여러 시스템을 병행할 수 있다. 이들 사이의 인터페이스는 시스템 개발자가 가장 골치 아픈 것이다.
커머셜 엔드 유저 어플리케이션의 경우 엔터프라이즈 정보 시스템과 소프트웨어는 분명히 큰 시스템의 일부인 제품입니다. 그러나 Dell 개발자에게는 고객이 승인한 요구 사항 문서를 작성하지 않았습니다. 프로젝트가 언제 끝나는지 어떻게 알 수 있습니까? 만약 우리가 고객에게 무엇이 중요한지 모른다면, 우리는 어떻게 그들을 만족시킬 수 있습니까?
그러나 비상업적 용도의 소프트웨어 수요도 필요하다. 예를 들어 라이브러리, 어셈블리 및 도구는 개발 팀 내에서 사용됩니다. 물론, 문서가 없을 경우 때때로 다른 사람의 의견에 동의할 수 있지만, 재작업을 반복하는 것은 불가피한 결과이며, 코드를 다시 프로그래밍하는 데 드는 비용은 수요 문서를 다시 작성하는 데 드는 비용보다 훨씬 더 큽니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 이러한 피투성이의 교훈은 국내 소프트웨어 개발자에게 일어나고 있다.
최근에 코드 편집기가 포함된 내부용 컴퓨터 지원 소프트웨어 세트를 개발한 개발 팀을 만났습니다. 유감스럽게도, 그들이 이 도구를 개발한 후, 이 도구가 소스 코드 파일을 인쇄할 수 없다는 것을 알게 되자, 사용자는 당연히 이 기능을 원했다. 그 결과 팀은 코드 검사를 위해 소스 코드 문서를 수동으로 복사해야 했습니다. 즉, 요구 사항이 명확하고 정확하더라도 문서를 작성하지 않으면 소프트웨어는 자신이 원하는 목표를 달성하지 못했다고 탓할 수 있습니다.
대신 간단한 인터페이스가 오류 추적 시스템에 통합되어 요구 사항 설명 페이지를 작성하는 것을 보았습니다. 그러나 운영 체제 관리자는 스크립트를 처리할 때 간단한 요구 사항 목록이 매우 유용하다는 것을 알게 되었습니다. 요구 사항에 따라 시스템을 테스트할 때 시스템은 필요한 모든 기능을 명확하게 구현했을 뿐 아니라 오류도 발견하지 못했습니다.
사실, 수요 문서는 개발 과정에서 줄곧 지도적 역할을 해 왔다.
수요 분석 프로세스
전체 소프트웨어 요구 사항을 엔지니어링할 수 있습니다 ... >>
질문 3: 수요 분석에서 해결되는 문제는 시스템이 반드시 해야 하는 것이다. 안녕하세요.
해결해야 할 문제는 어떻게 해야 하는가.
내 대답이 마음에 들지 않으면 계속 질문하십시오.
질문에 대답하기가 쉽지 않아요, 서로 이해해요 ~
질문 4: 수요 분석의 역할과 진행 방법 해당 문제 및 환경에 대한 이해와 분석을 통해 문제와 관련된 정보, 기능 및 시스템 동작을 모델링하고 사용자의 요구 사항을 정확하고 완벽하게 설명함으로써 요구 사항 사양을 형성합니다. 이러한 일련의 활동은 소프트웨어 개발 라이프 사이클의 요구 사항 분석 단계를 구성합니다.
수요 분석은 시스템 분석과 소프트웨어 설계 사이의 다리입니다. 수요 분석은 시스템 사양과 프로젝트 계획을 분석 활동의 기본 출발점으로 삼아 소프트웨어의 관점에서 검토하고 조정합니다. 한편, 요구 사항 사양은 소프트웨어 설계, 구현, 테스트 및 유지 관리의 주요 토대입니다. 좋은 분석 활동은 가능한 한 빨리 초기 오류를 피하거나 제거하여 소프트웨어 생산성을 높이고 개발 비용을 절감하며 소프트웨어 품질을 향상시키는 데 도움이 됩니다.
수요 공학은 컴퓨터의 발전에 따라 발전한다. 컴퓨터 개발 초기에는 소프트웨어 규모가 크지 않았고, 소프트웨어 개발은 코드 작성에 중점을 두었으며, 수요 분석에 거의 관심을 기울이지 않았다. 그 후 수명 주기의 개념이 소프트웨어 개발에 도입되어 수요 분석이 첫 번째 단계가 되었습니다. 소프트웨어 시스템 규모가 커짐에 따라 소프트웨어 개발 및 유지 보수 프로세스 전반에 걸쳐 수요 분석 및 정의가 점점 더 중요해지고 있으며, 이는 소프트웨어의 성패와 직접적인 관련이 있습니다. 수요 분석 활동이 더 이상 소프트웨어 개발의 초기 단계에 국한되지 않고 시스템 개발의 전체 수명 주기에 걸쳐 있다는 사실을 점차 인식하고 있습니다. 80 년대 중반에는 소프트웨어 공학의 하위 영역인 수요 공학 (re) 이 형성되었다. 1990 년대 이래로 수요 공학은 연구 핫스팟 중 하나가 되었다. 1993 부터 수요공학국제세미나 (ISRE) 는 2 년마다 열리고 1994 부터 수요공학국제회의 (ICRE) 는 2 년마다 열린다. 1996 년, Springer-Verlag 는 새로운 간행물인 수요공학을 출판했다. 유럽의 Renoir (International Cooperations Research 팀의 수요 엔지니어링 네트워크) 와 같은 수요 엔지니어링에 관한 실무 그룹도 설립되어 작업을 시작했습니다. 수요 공학이란 성숙한 기술과 방법을 적용하여 수요를 분석하고, 고객의 요구를 식별하고, 분석가가 문제를 이해하고, 목표 시스템의 모든 외부 특성을 정의하는 분야를 말합니다. 적절한 도구와 기호를 통해 개발할 시스템과 해당 동작 특성 및 관련 제약 조건을 체계적으로 설명하여 변화하는 사용자의 수요 진화를 지원하는 수요 문서를 형성합니다. RE 는 시스템 요구 사항 엔지니어링 (하드웨어 및 소프트웨어로 구성된 전체 시스템) 과 소프트웨어 요구 사항 엔지니어링 (소프트웨어로만 구성된 경우) 으로 나눌 수 있습니다. 소프트웨어 요구 사항 엔지니어링은 소프트웨어 요구 사항을 분석하고 기록하는 분야입니다. 시스템 요구 사항을 주요 하위 시스템과 작업으로 분할하고, 이러한 하위 시스템이나 작업을 소프트웨어에 할당하고, 일련의 반복 분석, 설계, 비교 연구 및 프로토타입 개발 프로세스를 통해 이러한 시스템 요구 사항을 소프트웨어 요구 사항 설명 및 일부 성능 매개변수로 변환합니다.
수요 설계는 수요를 반복적으로 정의, 기록 및 개발하고 궁극적으로 검증을 기준으로 수요를 동결하는 프로세스입니다. 1980 년대에 HerbKrasner 는 수요 정의 및 분석, 수요 결정, 수요 사양 설명 형성, 수요 실현 및 검증, 수요 진화 관리 등 수요 엔지니어링의 5 단계 수명 주기를 정의했습니다. 최근 MatthiasJarke 와 KlausPohl 은 취득, 표상, 검증이라는 3 단계 순환 이론을 제시했다.
몇 가지 관점을 종합하면 수요 엔지니어링 활동은 다음 다섯 단계로 나눌 수 있습니다.
(1) 요구 사항 획득: 사용자와 소통하고, 기존 시스템을 관찰하고, 작업을 분석하여 사용자 요구 사항을 개발, 캡처 및 수정합니다.
(2) 수요 모델링: 최종 사용자가 보는 시스템에 대한 개념 모델을 만들어 수요에 대한 추상적 설명으로 가능한 실제 의미를 캡처합니다.
(3) 수요 사양 설명 형성: 사용자와 개발자 간의 계약으로 수요 모델 구성 요소에 대한 정확한 공식 설명을 생성합니다.
(4) 수요 검증: 수요 사양 설명을 입력으로 기호 실행, 시뮬레이션 또는 빠른 프로토타입을 통해 수요 사양 설명의 정확성과 실현 가능성을 분석합니다.
(5) 수요 관리: 수요 변경 및 추적 가능성과 같은 시스템의 수요 진화를 지원합니다. ...>& gt
질문 5: 소프트웨어 요구 사항은 무엇이며 기능 요구 사항은 무엇입니까? 우리의 소프트웨어 제품 또는 프로젝트는 세 가지 수준과 세 가지 측면이 있다. 우선, 세 가지 수준의 요구 사항을 살펴 보겠습니다. 소프트웨어 요구 사항에는 세 가지 수준의 비즈니스 요구 사항, 사용자 요구 사항 및 기능 요구 사항이 포함됩니다. 비즈니스 요구 사항은 조직 또는 고객의 상위 수준 목표를 나타냅니다. 비즈니스 요구 사항은 일반적으로 프로젝트 투자자, 제품을 구입한 고객, 실제 사용자의 관리자, 마케팅 부서 또는 제품 기획 부서에서 비롯됩니다. 비즈니스 요구 사항은 조직이 시스템을 개발해야 하는 이유, 즉 조직이 달성하고자 하는 목표를 설명합니다. 비전 및 범위 문서를 사용하여 프로젝트 차트 또는 시장 수요 문서라고도 하는 업무 요구사항을 기록합니다. 사용자 요구 사항은 사용자의 목표 또는 사용자가 시스템에서 완료해야 하는 작업을 설명합니다. 사용 사례, 장면 설명, 이벤트 DD 응답 테이블은 모두 사용자의 요구를 표현하는 효과적인 방법입니다. 즉, 사용자 요구 사항은 사용자가 시스템으로 수행할 수 있는 작업을 설명합니다. 기능 요구 사항은 개발자가 제품에서 구현해야 하는 소프트웨어 기능을 규정하고 있으며, 사용자는 이러한 기능을 사용하여 작업을 수행하고 비즈니스 요구 사항을 충족시킬 수 있습니다. 기능 요구 사항은 일반적으로 "예" 로 설명되기 때문에 동작 요구 사항이라고도 합니다. "시스템에서 가입을 수락했음을 사용자에게 알리는 이메일을 보내야 합니다." 기능 요구 사항 설명은 개발자가 구현해야 하는 것입니다. 주: 사용자 요구사항이 항상 기능 요구사항으로 변환되는 것은 아닙니다. 제품 기능 (특성이라고 함) 은 비즈니스 목표를 충족하기 위해 사용자에게 특정 기능을 제공하는 논리적으로 관련된 기능 요구 사항 세트입니다. 상용 소프트웨어의 경우 기능은 고객이 인정하고 구매 여부를 결정하는 데 도움을 줄 수 있는 요구 사항, 즉 제품 설명서에 글머리 기호로 표시된 부분입니다. 고객이 원하는 제품 특성과 사용자의 작업 관련 요구 사항은 정확히 동일하지 않습니다. 특성에는 여러 사용 사례가 포함될 수 있으며, 각 사용 사례는 사용자가 작업을 수행할 수 있도록 여러 기능 요구 사항을 구현해야 합니다. 시스템 요구사항여러 하위 시스템을 포함하는 제품 (시스템) 의 최상위 요구사항을 설명하는 데 사용됩니다. 시스템에는 소프트웨어 시스템만 포함되거나 소프트웨어와 하드웨어 하위 시스템을 모두 포함할 수 있습니다. 사람도 시스템의 일부가 될 수 있기 때문에 일부 시스템 기능은 사람이 부담할 수 있다. 업무 규칙에는 기업 정책, 규정, 업계 표준, 회계 기준 및 계산 방법이 포함됩니다. 사업 계획 자체는 특정 소프트웨어 시스템의 범위에 속하지 않기 때문에 소프트웨어 요구 사항이 아닙니다. 그러나 비즈니스 규칙은 특정 사용 사례를 수행할 수 있는 사용자를 제한하거나 관련 규칙을 준수하기 위해 시스템에서 특정 기능을 구현해야 한다고 규정하는 경우가 많습니다. 경우에 따라 기능의 특정 물성 (기능에 의해 구현됨) 도 업무 규칙에서 비롯됩니다. 따라서 일부 기능 요구 사항으로 거슬러 올라가면 그 출처가 특정 비즈니스 규칙이라는 것을 알 수 있습니다. 기능 요구 사항은 SRS (software requirements specification) 에 기록됩니다. SRS 는 소프트웨어 시스템의 예상 특성을 완벽하게 설명합니다. SRS 우리는 보통 그것을 하나의 문서로 여긴다. 실제로 SRS 는 요구 사항 정보가 포함된 데이터베이스 또는 스프레드시트일 수도 있습니다. 또는 비즈니스 요구 사항 관리 도구에 저장된 정보; 작은 프로젝트의 경우 인덱스 카드 스택일 수도 있습니다. SRS 는 개발, 테스트, 품질 보증, 프로젝트 관리 및 기타 관련 프로젝트 기능에 사용됩니다. 또한 수요 수준에 대해서는 조직 차원의 수요->; 비즈니스 요구 사항->; 사용자 요구 사항-> 기능 요구 사항 (동작 요구 사항이라고도 함) 조직 수준 요구 사항: 일반적으로 조직의 비전과 목표를 나타냅니다. 대기업의 경우 일반적으로 선임 컨설턴트와 컨설팅 회사를 통해 얻을 수 있으며 컨설팅 보고서를 제공합니다. 예를 들어, ITSM 이나 기업 정보화에서 일반적인 조직 요구로는 비용 절감, 재고 비용 절감, 기업 IT 서비스 부서의 가치 향상, ISO20000 채택, IT 서비스 효율성 향상, 직원 만족도 향상 등이 있습니다. 비즈니스 요구 사항: 각 비즈니스 프로세스 및 비즈니스 단위는 사명을 완수하고 조직의 비전을 실현하기 위한 요구 사항입니다. 업무 수요는 조직 수요에 종속됩니다. 사용자 요구사항: 사용자 레벨 요구사항이란 업무 레벨 요구사항, 각 직책에 대한 요구사항 ... >> 를 의미합니다
질문 6: 시스템 요구 사항 분석을 작성하는 방법? 시스템 요구 사항 분석 1 의 첫 번째 부분. 시스템 기능 모듈은 기본적으로 시스템 관리 시스템: 학생 선택 시스템의 시스템 유지 관리: 학생 선택 운영 교사 조회 시스템: 학생 선택 조회 2 로 나뉩니다. 시스템 유지 관리 2 1 2. 1. 학생 기본 정보 유지 관리 목표: 2. 1.2. 학생 기본 데이터 유지 관리 개요: 전제 조건: 관리자는 학생 기본 데이터를 추가, 삭제, 업데이트 또는 쿼리합니다. 역할: 각 수준의 시스템 관리자 입력: 학생의 기본 속성 (학번, 이름, 학과, 클래스, 암호, 선택 과목 총 학점). 기본 프로세스: 로그인 관리자 시스템 → 현재 사용자 권한 확인 → "학생 기본 데이터 유지 관리" 선택 → 관리자 추가, 삭제 또는 수정 → 입력 또는 수정된 데이터 확인 → 검증 통과: 데이터베이스 업데이트 인증 실패: 사용자에게 다시 입력하도록 요청하는 프롬프트를 표시합니다. 출력: 학생 기본 정보 보고서. 2 2 2.2. 1. 교사 기본 정보 유지 관리 목표: 교사 기본 정보 추가, 삭제, 업데이트, 조회. 2.2.2. 교사 기본 정보 유지 관리 개요: 전제 조건: 관리자는 교사 기본 정보를 추가, 제거, 업데이트 또는 조회해야 합니다. 역할: 모든 수준의 시스템 관리자 입력: 교사 기본 정보 (직장 번호, 이름, 부서, 암호 및 관련 정보). 기본 프로세스: 로그인 관리자 시스템 → 현재 사용자 권한 확인 → "교사 기본 정보 유지 관리" 선택 → 관리자 추가, 삭제 또는 수정 → 입력 또는 수정된 데이터 확인 → 검증 통과: 데이터베이스 업데이트, 검증 실패: 사용자에게 다시 입력하도록 요청하는 힌트 정보를 제공합니다. 결과: 교사 기본 정보 보고서. 2 3 2.3. 1. 과정 기본 데이터 유지 관리 목표: 과정의 기본 데이터 추가, 삭제, 업데이트 및 조회. 2.3.2. 과정 기본 데이터 유지 관리 개요: 전제 조건: 관리자는 과정 기본 데이터를 추가, 삭제, 업데이트 또는 조회할 수 있어야 합니다. 역할: 보조 시스템 관리자 입력: 과정 기본 정보 (과정 번호, 과정 이름, 과정 소개, 클래스 시간, 클래스 위치, 세션, 학점, 온라인 인원 수, 현재 인원 수, 교사 수) 기본 프로세스: 로그인 관리자 시스템 → 현재 사용자 권한 확인 → 과정 기본 정보 유지 관리를 선택합니다 출력: 강좌 세부 정보. 242.4. 1. 부서 데이터 유지 관리 목표: 부서 데이터 추가, 삭제, 업데이트 및 조회. 2.4.2. 부서 유지 관리 개요: 전제 조건: 관리자는 부서 데이터를 추가, 삭제, 갱신 또는 조회해야 합니다. 역할: 1 차 시스템 관리자 입력: 부서 데이터 (부서 번호, 부서 이름) 기본 프로세스: 로그인 관리자 시스템 → 현재 사용자 권한 검증 → 부서 데이터 유지 관리 선택 → 관리자 추가, 삭제 또는 수정 업데이트 → 입력 또는 수정된 데이터 검증 → 검증 통과: 데이터베이스 업데이트, 검증 실패:; 출력: 없음 2 5 2.5. 1. 관리자 유지 관리 대상: 레벨 2.5.2 관리자 권한을 설정합니다. 관리자 유지 관리 개요: 전제 조건: 역할: 기본 관리자 입력: 관리자 권한 기본 프로세스: 시스템 로그인 → 권한 확인 → 관리자 권한 설정 → 설정 확인 → 성공적인 업데이트 또는 실패 결과 반환: 2 6 2.6.65438+. 표준: 관리자 2.6.2 의 로그인 비밀번호를 올바르게 수정합니다. 비밀번호 수정 개요: 전제 조건: 이전 비밀번호를 사용하여 역할에 올바르게 로그인: 레벨 관리자 입력: 이전 비밀번호, 새 비밀번호, 비밀번호 검증. 기본 프로세스: 로그인 선택 시스템 → 권한 확인 → 이전 비밀번호, 새 비밀번호 입력, 비밀번호 확인 제출 → 이전 비밀번호가 정확한지 확인 새 비밀번호와 비밀번호가 같은지 확인 → 성공 또는 실패 (하루 3 회 이하) 출력: 성공 또는 실패 정보 2 7 2.7. 1. 시스템 설정 대상: 시스템 설정 2.7.2 를 통해 시스템 환경 변수를 수정합니다. 시스템 설정 ... >; & gt
질문 7: 시스템 설계와 수요 분석의 관계는 무엇입니까? 절박한 수요 2012-4-2712:19 만족스러운 답변 네트워크 계획 및 수요 분석 문자 그대로 수요 분석은 수요와 수요의 관계를 찾아내 현재 업무에서 가장 중요한 측면을 찾아내는 것이다 고객의 요구에 따라 이미 형성된 방안을 수정하다. 이 장에서는 2. 1 유형 수요 분석 2.2 수요 2.3 실현가능성 논증 2.4 프로젝트 입찰 2.2. 1 응용 배경 분석, 현재 네트워크 응용 프로그램의 기술적 배경 요약, 산업 응용 프로그램의 방향 및 기술 동향 등을 중점적으로 설명합니다. 이 기업 네트워크 정보화의 필연성을 설명하다. 응용 배경 요구 사항 분석은 네트워크 통합을 구현해야 하는 이유에 대한 질문에 답해야 합니다. (1) 외국 동업 정보화 정도, 어떤 성적을 거두었는가. (2) 국내 동종업계 정보화 추세는 어떻습니까? (3) 이 기업 정보화의 목적은 무엇인가? (4) 기업이 채택해야 할 정보화 단계를 어떻게 분석합니까? P332.2. 1 애플리케이션 배경 분석 애플리케이션 배경 요구 사항 분석을 입력하여 네트워크 통합을 구현해야 하는 이유에 대한 질문에 답해야 합니다. (1) 외국 동업 정보화 정도, 어떤 성적을 거두었는가. (2) 국내 동종업계 정보화 추세는 어떻습니까? (3) 이 기업 정보화의 목적은 무엇인가? (4) 기업이 채택해야 할 정보화 단계를 어떻게 분석합니까? P332.2.2 비즈니스 요구 사항 유형 비즈니스 요구 사항 분석의 목표는 기업의 비즈니스 유형, 애플리케이션 시스템 소프트웨어 유형 및 대역폭, 서비스 품질 QoS 와 같은 네트워크 기능 지표에 대한 요구 사항을 명확히 하는 것입니다. 비즈니스 요구 사항은 엔터프라이즈 네트워크 구축의 주요 부분입니다. 네트워크 계획 및 설계의 기본 토대입니다. 수요 분석 유형 P332.2.2 비즈니스 요구 사항 비즈니스 요구 사항 분석을 통해 (1) 달성하거나 개선해야 할 엔터프라이즈 네트워크 기능은 무엇입니까? (2) 통합해야 할 엔터프라이즈 애플리케이션은 무엇입니까? (3) 이메일 서비스가 필요하십니까? (4) 웹 서비스가 필요하십니까? (5) 인터넷 접속이 필요한가요? 대역폭은 얼마입니까? (6). 비디오 서비스가 필요하십니까? (7) 어떤 종류의 데이터 * * * 패턴이 필요합니까? (8) 필요한 대역폭은 무엇입니까? (9) 계획 투자 규모는 얼마입니까? 수요 분석 유형 P332.2.3 관리 수요 네트워크 관리는 엔터프라이즈 네트워크 구축에 없어서는 안 될 측면입니다. 네트워크가 설계 목표에 따라 안정적인 서비스를 제공하는지 여부는 주로 효과적인 네트워크 관리에 달려 있습니다. 효율적인 관리 전략은 네트워크의 운영 효율성을 향상시킬 수 있습니다. 우리는 네트워크 건설 초기부터 이러한 전략에 주의를 기울여야 한다. 수요 분석 유형 P342.2.3 관리 수요 네트워크 관리에 대한 수요 분석다음과 같은 유사한 질문에 답해야 합니다. 네트워크를 원격으로 관리할 필요가 있습니까? 원격 관리를 통해 네트워크 관리자는 원격 제어 소프트웨어를 사용하여 네트워크 디바이스를 관리하여 네트워크 관리를 보다 편리하고 효율적으로 수행할 수 있습니다. 누가 네트워크 관리를 담당합니까? 필요한 관리 기능 (예: 유료 여부, 네트워크에 대한 도메인 설정 여부, 도메인 모드 선택 등) 입니다. 수요 분석 유형 P342.2.3 관리 요구 사항 어느 공급업체의 네트워크 관리 소프트웨어를 선택하는지, 상세한 평가가 있는지 여부 어떤 공급 업체의 네트워크 장비를 선택하고 관리 용이성을 선택하십시오. 네트워크 운영 정보를 추적, 분석 및 처리해야 하는지 여부 네트워크 관리 콘솔 구성은 어디에 있습니까? 장비와 배선을 쉽게 관리할 수 있습니까? P342.2.4 보안 요구 사항은 기업의 보안 요구 사항을 분석할 때 다음과 같은 사항을 명확히 해야 합니다. 기업의 민감한 데이터의 보안 수준 및 배포 네트워크 사용자 및 해당 권리의 보안 수준; 가능한 보안 취약점 및 이러한 취약점이 시스템에 미치는 영향 네트워크 장비 보안 기능 요구 사항; 수요 분석 유형 P342.2.4 네트워크 시스템 소프트웨어 보안 요구 사항에 대한 보안 평가 응용 시스템 보안 요구 사항 어떤 바이러스 백신 소프트웨어를 사용하고 있습니까? 어떤 방화벽 기술 프로그램을 사용합니까? 보안 소프트웨어 시스템 평가 네트워크가 따르는 보안 사양 및 달성된 보안 수준입니다. 수요 분석 유형 P342.2.5 트래픽 수요 트래픽 수요는 네트워크 애플리케이션을 기반으로 현재 기술 조건 하에서 제공할 수 있는 네트워크 대역폭을 평가합니다.
질문 8: 솔루션과 요구 사항 분석 및 시스템 설계의 차이점은 무엇입니까? 해결책은 전체적인 해석이다.
수요는 시스템이 해야 할 일이다.
시스템 설계는 어떻게 해야 하는지를 의미한다.
질문 9: 소프트웨어 수요 분석에 대한 수요 유형 다음 정의는 수요 엔지니어링 분야에서 일반적으로 사용되는 용어의 정의입니다. 소프트웨어 요구 사항은 비즈니스 요구 사항, 사용자 요구 사항 및 기능 요구 사항 (비기능 요구 사항 포함) 의 세 가지 수준으로 구성됩니다. 1. 비즈니스 요구 사항은 프로젝트 뷰 및 범위 문서에 설명된 시스템 및 제품에 대한 조직 또는 고객의 상위 수준 목표 요구 사항을 반영합니다. 2. 사용자 요구사항 문서는 사용자가 제품을 사용할 때 완료해야 하는 태스크를 설명하며 사용 사례 문서 또는 시나리오 스크립트 설명에 설명되어 있습니다. 3. 기능 요구사항은 사용자가 업무 요구를 충족하기 위해 태스크를 완료할 수 있도록 개발자가 구현해야 하는 소프트웨어 기능을 정의합니다. SRS (software requirements specification) 에 설명된 기능 요구 사항은 소프트웨어 시스템이 가져야 하는 외부 동작을 충분히 설명합니다. 소프트웨어 요구 사항 사양은 개발, 테스트, 품질 보증, 프로젝트 관리 및 관련 프로젝트 기능에서 중요한 역할을 합니다. 대규모 시스템의 경우 소프트웨어 기능 요구 사항은 하위 시스템 (또는 소프트웨어 구성 요소) 에 속할 수 있으므로 시스템 요구 사항의 하위 집합일 수 있습니다. 기능 요구 사항을 보완하기 위해 소프트웨어 요구 사항 설명서에는 비 기능 요구 사항도 포함되어야 합니다. 비 기능 요구 사항은 시스템이 사용자에게 제공하는 동작 및 작동을 설명합니다. 여기에는 제품이 준수해야 하는 표준, 사양 및 계약이 포함됩니다. 외부 인터페이스의 구체적인 세부 사항 성능 요구 사항 설계 또는 구현된 구속 및 물성. 제약이란 개발자가 소프트웨어 제품을 설계하고 구축하는 것에 대한 제한을 말한다. 물성은 모든 각도에서 제품의 특성을 설명하여 제품의 기능을 반영하는 것이다. 사용자와 개발자에게 다중 각도 설명 제품은 매우 중요합니다. 하위 프로세스를 예로 들어 다양한 유형의 요구 사항을 설명하겠습니다. 비즈니스 요구 사항은 "사용자가 문서의 맞춤법 오류를 효과적으로 수정할 수 있습니다." 라고 할 수 있으며, 제품 상자의 표지에는 비즈니스 요구 사항에 맞는 맞춤법 검사기임을 알 수 있습니다. 해당 사용자 요구 사항은 "문서에서 맞춤법 오류를 찾아 제공된 대체 목록을 통해 맞춤법 오류가 있는 단어를 선택합니다." 일 수 있습니다. 또한 맞춤법 검사기에는 잘못된 단어를 찾고 강조하는 작업과 같은 많은 기능 요구 사항이 있습니다. 문서 전체를 바꿀 수 있는 대체 단어를 제공하는 대화 상자를 표시합니다. 위의 정의에서 알 수 있듯이 요구 사항에는 설계 세부 정보, 구현 세부 정보, 프로젝트 계획 정보 또는 테스트 정보가 포함되지 않습니다. 수요는 이것들과 무관하며, 당신이 정말로 개발하고 싶은 것을 충분히 설명하는 것에 관심이 있다. 프로젝트에는 개발 환경이나 제품 출시 및 지원 환경으로 이식하는 요구와 같은 다른 요구 사항이 있습니다. 이러한 요구 사항은 프로젝트의 성공에도 중요하지만 이 책에서는 다루지 않습니다.