그중에서 가장 먼저 지향해야 할 것은 장기적인 발전에 부합하는 소프트 인문 관리 이념을 세우는 것이다. 둘째, 보다 유연한 공간과 경영 이념에 부합하는 장기적 메커니즘과 장기적 피드백 메커니즘이 있습니다. 이진 환경에서 숫자 및 연산을 촉진하는 효율적인 커뮤니케이션 모드입니다. 집행력을 높이고, 경제 원가 흐름 조직 모델을 최적화하고, 내부 및 외부 거래 비용을 절감하고, 시효성과 실용성을 중시하는 SOP 입니다. 제품 및 팀의 경쟁력을 효과적으로 향상시킵니다. 또한 장기적 메커니즘에 따라 합리적인 조정 메커니즘을 개발하여 자원 할당량을 신속하게 조정할 수 있습니다. 이를 통해 인력, 시간 및 유효 자원의 최적화된 비율로 더 큰 이윤 공간과 더 많은 부가 가치 확장을 창출할 수 있습니다.
엔터프라이즈 정보 시스템은 조직 구조, 프로세스, 데이터, 비즈니스 규칙 및 기능 (성능) 의 다섯 가지 기본 요소로 구성됩니다. 그 중에서도 사용자의 관점에서 볼 때, 우리의 주된 관심사는 프로세스이며, 이것이 핵심이다. 프로세스를 통해 다른 요소들이 관통되고 수요 분석가도 이러한 관점에서 사용자와 소통해야 합니다. 개발자의 관점에서 볼 때, 시스템 구현을 용이하게 하기 위해 기업의 데이터, 비즈니스 규칙 및 기능에 초점을 맞추고 있습니다. 구현자의 관점에서, 주로 기업의 조직 구조와 기능에 초점을 맞추어 제도의 발표와 시행을 용이하게 한다.
1) 기업의 조직 모델
부서 설정, 직무 설정, 직무 책임 등을 포함한 기업의 조직 구조다. 트리 조직도는 엔터프라이즈 조직 모델을 설명하는 일반적인 방법입니다. 부서 간 리더십 관계, 각 부서 내 인력 배치 상황, 책임 분담 등을 명확히 하는 데 사용할 수 있다. 시스템 범위를 분할하고 시스템 네트워크를 계획하는 기초입니다. 조직도에서 사용자의 조직 구조를 계층별로 상세히 설명하고 각 부서의 역할을 간략하게 설명해야 합니다. 조직 구조는 사용자 기업의 업무 프로세스와 정보의 전달체이며 분석가가 기업의 업무를 이해하고 시스템의 범위를 결정하는 데 도움이 됩니다. 사용자의 조직도를 가져오는 것은 수요 획득 단계의 기본 작업 중 하나입니다.
사용자 환경에서 기업 직책이나 역할은 조직과 마찬가지로 분석가가 기업 업무를 이해하고 대상을 추출하는 기초이기도 합니다.
사용자의 역할 인식은 컴퓨터 시스템의 시스템 관리자를 놓치는 경우가 많으며, 역할 식별이 철저하지 않아 향후 기능 인식에 사각 지대를 초래할 수 있습니다.
(2) 비즈니스 프로세스 모델
기업의 업무 프로세스로서 어떤 프로세스, 프로세스 간의 관계, 각 프로세스에 포함되는 활동, 각 활동에 관련된 직책을 포함한다. 기업의 워크플로우에는 먼저 전체 업무 흐름도가 있어야 하며, 기업 내 각 업무 간의 관계를 설명한 다음 각 업무를 상세히 설명해야 업무 프로세스와 부서의 역할을 결합할 수 있다. (윌리엄 셰익스피어, 업무, 업무, 업무, 업무, 업무, 업무, 업무, 업무, 업무, 업무) 자세한 비즈니스 흐름도는 직선 비즈니스 흐름도 형식일 수 있습니다. 기업의 경우 비즈니스 순서도의 설명 기준을 정의해야 합니다. 모두 같은 범례로 설명하여 관리가 용이합니다.
비즈니스 프로세스 다이어그램의 이점:
■ 도면을 그리는 과정은 실제로 워크플로우를 구성하는 과정입니다.
■ 직관적이고, 사용자와 소통하기 쉽고, 프로젝트 팀 내에서 의사 소통이 용이합니다.
연구 성과는 사용자의 승인을 받아야 하며, 이를 위해서는 사용자와 연구 성과와 문헌을 교류해야 한다.
문서는 통속적이고 이해하기 쉬워야지 전문 용어를 사용해서는 안 된다.
■ 구현자 및 기술 서비스 인력을 교육하는 문서로 사용할 수 있습니다.
비즈니스 프로세스 다이어그램의 단점:
■ 고위 경영진의 실제 수요에 대한 조사가 불분명하다.
한편으로는 사용자가 컴퓨터를 접한 적이 없기 때문에, 컴퓨터를 채택한 후의 관리는 어떤 모습일까? 지금의 수동 조작, 컴퓨터는 무엇을 할 수 있습니까? 어떤 일을 할 수 있고, 어떤 일을 지금 손으로 할 수 없고, 명확한 개념이 없기 때문에 사용자는 이러한 문제를 반영할 수 없다. 반면 분석가들은 경험이 없고, 원본 자료를 깊이 파고들지 않고, 사용자가 제공한 자료에서 사용자의 실제 요구를 추출할 수 없고, 현재 관리의 문제점을 발견할 수 없다는 설명이다.
■ 비즈니스 간의 전반적인 관계를 표현하지 않았습니다.
직선 업무 흐름도는 기업의 각 업무 처리 프로세스를 명확하게 표현할 수 있지만 업무 간의 관계는 표현하지 않습니다. 비즈니스 흐름도는 분명하지만 통합 할 수는 없습니다. 수요 분석 문서로서 표현이 완전하지 않습니다.
■ 공구를 사용하지 않고 화법이 번거롭다.
그래픽은 프로세스를 명확하게 설명할 수 있지만, 업무 발생 빈도, 사고 처리, 러시아워의 업무 발생 빈도 등과 같은 일부 문자가 필요합니다. 순서도는 설명할 수 없으며 문자로 자세히 설명해야 합니다.
(3) 엔터프라이즈 데이터 모델
기업의 정보 전달체에는 어떤 것이 있습니까? 기업의 다양한 문서, 장부, 보고서에 대한 설명을 포함하여 이러한 정보 전달체에 대한 자세한 설명을 제공합니다. 요구사항 보고서에서 문서에 대한 설명은 형식을 지정해야 하며 설명할 내용은 다음과 같습니다.
문서의 용도, 즉 파일이 어디에 사용됩니까?
파일 형식: 명확한 그림을 그려야 하며, 실제 사례에는 데이터가 있으며, 문제를 구체적이고 직관적으로 설명할 수 있습니다.
문서의 데이터 항목에 대한 구체적인 설명: 길이, 유형, 계산 및 생성 방법, 제약조건 등.
컴퓨터에서 채울 수 있는 데이터 항목을 포함하여 문서의 데이터 항목을 채우는 다양한 역할 유형은 무엇입니까?
문서의 어떤 데이터가 필수이고 어떤 데이터는 필요하지 않습니다.
문서 트래픽: 하루 평균 생성되는 레코드 수, 피크 수
문서 분류: 업무 유형 (구매/판매/생산), 생성 방법 (수동 입력/자동 생성), 포맷별 변경 빈도 (변동/안정), 표시 형식 (목록/카드 유형) 등 여러 각도에서 문서를 분류할 수 있습니다
문서 간 관계: 참조 관계 등
마찬가지로 필요한 보고서와 책도 위 항목을 참조하여 자세히 설명할 수 있습니다.
(4) 기업의 비즈니스 규칙 모델
기업의 비즈니스 규칙은 무엇입니까? 이 규칙들은 어디에 쓰입니까? 업무 규칙은 영향 범위에서 두 가지 범주로 나눌 수 있습니다. 하나는 음수 재고 허용과 같은 로컬 규칙이고, 다른 하나는 모든 품목을 로트로 관리하는 것과 같은 전체 규칙입니다. 비즈니스 규칙은 일반적으로 기능 모델 또는 프로세스 모델에 숨겨져 있으며 별도의 설명이 필요하지 않지만, 기업의 다양한 문서 회계에 대한 비즈니스 로직, 5) 기업의 기능 모델과 같은 복잡한 비즈니스 규칙은 별도의 설명을 추출해야 합니다.
기능 요구 사항은 사용자의 가장 중요한 요구 사항입니다. 사용자 기능 요구 사항에 대한 설명은 문자 또는 용어와 그래픽으로 설명할 수 있습니다. 단, 사용자의 요구 사항을 완전하고 정확하며 쉽게 설명할 수 있는 한 말입니다. 기능 요구 사항이 복잡한 시스템 (예: 10 개 이상의 기능 항목) 의 경우 먼저 요약을 설명할 수 있습니다. 간단한 시스템은 직접 자세히 설명할 수 있습니다. 사용자의 기능 요구 사항을 분류하려면 분류 방법을 통해 사용자가 쉽게 이해할 수 있도록 해야 합니다. 예를 들어, 사용자의 부서 설정에 따라 각 부서의 요구 사항을 설명하여 사용자 검토를 쉽게 구성할 수 있습니다. 다음은 분류 방법의 예입니다.
부서별 분류: 구매부, 영업부, 계획부, 생산현장, 재무부, 통계부, 총지배인 등.
기능 유형별로 분류: 문서 입력, 문서 감사, 문서 조회, 회계, 장부 조회, 통계 보고서, 시스템 관리 등.
기능 요구 사항 분류는 수준마다 다른 방법을 사용할 수 있습니다.
각 기능에는 기능 사양의 장에 해당하는 기능 번호가 있어야 합니다. 각 기능에 대한 설명은 사용자의 입력, 프로세스 방법, 시스템 출력 및 해당 기능에 대한 기타 요구 사항을 나타내야 합니다. 기능 요구사항은 이 기능을 사용하는 position 도 식별해야 합니다. 시스템 관리자가 요구하는 특수 기능은 여기에 명시할 수 있으며, 비특수한 요구 사항은 요구 사항 분석 설명서에 자세히 설명되어 있습니다. 사용자 권한이 등급을 매길 수 있는 경우 작업 로그 등이 있어야 합니다.
기능 요구 사항과 성능 요구 사항은 불가분의 관계입니다. 일반적인 성능 요구 사항은 의미가 없으며 분석가가 시스템을 분석할 때 쉽게 간과할 수 있는 특정 기능 요구 사항을 대상으로 해야 합니다.
위의 다섯 가지 기본 요소는 5 개 튜플 "조직, 프로세스, 기능, 데이터, 비즈니스 논리" 로 설명할 수 있습니다. 사용자의 경우 조직 차원에서 시스템을 보는 데 익숙합니다. 즉, 부서의 작업, 각 작업이 참여하는 활동 (기능), 기능에서 작동하는 데이터 및 해당 데이터에 대한 논리적 처리 개발자는 기능 차원에서 시스템을 보는 데 익숙합니다. 즉, 기능이 작동하는 데이터, 해당 데이터의 논리적 처리, 이 기능이 속한 프로세스, 사용할 수 있는 위치 등을 말합니다. 디자이너는 데이터 차원에서 시스템을 보는 데 익숙해질 수 있습니다. 즉, 시스템에 있는 데이터, 해당 데이터에 대해 수행할 수 있는 작업, 즉 OO 의 생각에 따라 데이터 객체에 대한 작업입니다.
위의 다섯 가지 기본 요소를 설명하는 것은 실제로 시스템 모델링 과정입니다. 모델의 조작성을 보장하기 위해 위의 다섯 가지 기본 요소 외에 중점적으로 설명해야 할 내용은 다음과 같습니다.
(1) 새로운 시스템의 애플리케이션 패턴 변화
조직 구조, 워크플로우, 파일 형식, 서적 및 보고서, 비즈니스 규칙 등의 변경 사항을 포함합니다.
(2) 새로운 시스템의 인터페이스 모델
개발 도구를 사용하여 사용자 인터페이스를 빠르게 그려 사용자 마음속에 수를 세도록 합니다. 시간이 허락한다면 인터페이스 프로토타입을 데이터베이스 테이블 및 필드에 연결하여 시스템의 프로토타입인 빠른 프로토타입을 만들 수 있습니다.