우리의 소프트웨어 제품 또는 프로젝트는 세 가지 수준과 세 가지 측면이 있다. 우선, 세 가지 수준의 요구 사항을 살펴 보겠습니다. 소프트웨어 요구 사항은 비즈니스 요구 사항, 사용자 요구 사항 및 기능 요구 사항의 세 가지 수준으로 구성됩니다. 비즈니스 요구 사항은 조직 또는 고객의 상위 수준 목표를 나타냅니다. 비즈니스 요구 사항은 일반적으로 프로젝트 투자자, 제품을 구입한 고객, 실제 사용자의 관리자, 마케팅 부서 또는 제품 기획 부서에서 비롯됩니다. 비즈니스 요구 사항은 조직이 시스템을 개발해야 하는 이유, 즉 조직이 달성하고자 하는 목표를 설명합니다. 비전 및 범위 문서를 사용하여 프로젝트 차트 또는 시장 수요 문서라고도 하는 업무 요구사항을 기록합니다. 사용자 요구 사항은 사용자의 목표 또는 사용자가 시스템에서 완료해야 하는 작업을 설명합니다. 사용 사례, 장면 설명 및 이벤트 응답 테이블은 모두 사용자의 요구를 표현하는 효과적인 방법입니다. 즉, 사용자 요구 사항은 사용자가 시스템으로 수행할 수 있는 작업을 설명합니다. 기능 요구 사항은 개발자가 제품에서 구현해야 하는 소프트웨어 기능을 규정하고 있으며, 사용자는 이러한 기능을 사용하여 작업을 수행하고 비즈니스 요구 사항을 충족시킬 수 있습니다. 기능 요구 사항은 일반적으로 "예" 로 설명되기 때문에 동작 요구 사항이라고도 합니다. "시스템에서 가입을 수락했음을 사용자에게 알리는 이메일을 보내야 합니다." 기능 요구 사항 설명은 개발자가 구현해야 하는 것입니다. 주: 사용자 요구사항이 항상 기능 요구사항으로 변환되는 것은 아닙니다. 제품 기능 (특성이라고 함) 은 비즈니스 목표를 충족하기 위해 사용자에게 특정 기능을 제공하는 논리적으로 관련된 기능 요구 사항 세트입니다. 상용 소프트웨어의 경우 기능은 고객이 인정하고 구매 여부를 결정하는 데 도움을 줄 수 있는 요구 사항, 즉 제품 설명서에 글머리 기호로 표시된 부분입니다. 고객이 원하는 제품 특성과 사용자의 작업 관련 요구 사항은 정확히 동일하지 않습니다. 특성에는 여러 사용 사례가 포함될 수 있으며, 각 사용 사례는 사용자가 작업을 수행할 수 있도록 여러 기능 요구 사항을 구현해야 합니다. 시스템 요구사항여러 하위 시스템을 포함하는 제품 (시스템) 의 최상위 요구사항을 설명하는 데 사용됩니다. 시스템에는 소프트웨어 시스템만 포함되거나 소프트웨어와 하드웨어 하위 시스템을 모두 포함할 수 있습니다. 사람도 시스템의 일부가 될 수 있기 때문에 일부 시스템 기능은 사람이 부담할 수 있다. 비즈니스 규칙에는 기업 정책, 정부 규정, 업계 표준, 회계 기준 및 계산 방법이 포함됩니다. 사업 계획 자체는 특정 소프트웨어 시스템의 범위에 속하지 않기 때문에 소프트웨어 요구 사항이 아닙니다. 그러나 비즈니스 규칙은 특정 사용 사례를 수행할 수 있는 사용자를 제한하거나 관련 규칙을 준수하기 위해 시스템에서 특정 기능을 구현해야 한다고 규정하는 경우가 많습니다. 경우에 따라 기능의 특정 물성 (기능에 의해 구현됨) 도 업무 규칙에서 비롯됩니다. 따라서 일부 기능 요구 사항으로 거슬러 올라가면 그 출처가 특정 비즈니스 규칙이라는 것을 알 수 있습니다. 기능 요구 사항은 SRS (software requirements specification) 에 기록됩니다. SRS 는 소프트웨어 시스템의 예상 특성을 완벽하게 설명합니다. SRS 우리는 보통 그것을 하나의 문서로 여긴다. 실제로 SRS 는 요구 사항 정보가 포함된 데이터베이스 또는 스프레드시트일 수도 있습니다. 또는 비즈니스 요구 사항 관리 도구에 저장된 정보; 작은 프로젝트의 경우 인덱스 카드 스택일 수도 있습니다. SRS 는 개발, 테스트, 품질 보증, 프로젝트 관리 및 기타 관련 프로젝트 기능에 사용됩니다. 또한 수요 수준에 대해서는 조직 차원의 수요->; 비즈니스 요구 사항->; 사용자 요구 사항-> 기능 요구 사항 (동작 요구 사항이라고도 함) 조직 수준 요구 사항: 일반적으로 조직의 비전과 목표를 나타냅니다. 대기업의 경우 일반적으로 선임 컨설턴트와 컨설팅 회사를 통해 얻을 수 있으며 컨설팅 보고서를 제공합니다. 예를 들어, ITSM 이나 기업 정보화에서 일반적인 조직 요구로는 비용 절감, 재고 비용 절감, 기업 IT 서비스 부서의 가치 향상, ISO20000 채택, IT 서비스 효율성 향상, 직원 만족도 향상 등이 있습니다. 비즈니스 요구 사항: 각 비즈니스 프로세스 및 비즈니스 단위는 사명을 완수하고 조직의 비전을 실현하기 위한 요구 사항입니다. 업무 수요는 조직 수요에 종속됩니다. 사용자 요구 사항: 사용자 수준 요구 사항은 비즈니스급 요구 사항에 따라 각 직책이 함께 업무를 완료하는 데 필요한 요구 사항입니다. 실제로 소프트웨어 요구 사항 설명서에 표현된 요구 사항은 주로 이러한 요구 사항입니다. 기능 요구 사항: 마찬가지로 제품 또는 소프트웨어에 필요한 기능을 나타냅니다. 일반적으로 관리자 또는 제품 마케팅 부서 직원은 회사의 운영 효율성 (정보 시스템의 경우) 또는 제품의 시장 경쟁력 (상용 소프트웨어의 경우) 을 높이기 위해 소프트웨어의 비즈니스 요구 사항을 정의합니다. 모든 사용자 요구 사항은 비즈니스 요구 사항을 충족해야합니다. 수요 분석가는 사용자의 수요에서 제품이 사용자에게 도움이 되어야 하는 기능을 도출합니다. 개발자는 기능 요구 사항 및 비기능 요구 사항에 따라 솔루션을 설계하여 제한된 한도 내에서 필요한 기능을 구현하여 규정된 품질 및 성능 지표를 달성합니다. 새로운 기능, 사용 사례 또는 기능 요구 사항이 제기되면 수요 분석가는 "범위 내에 있습니까?" 라는 질문을 고려해야 합니다. 。 대답이' 예' 인 경우 요구 사항은 요구 사항 사양서에 속하며, 그렇지 않은 경우 속하지 않습니다. 하지만 대답은' 아니, 하지만 그럴 거야' 일 수 있습니다. 이 경우 비즈니스 요구 사항을 담당하는 사람 또는 투자 관리자가 새로운 요구 사항에 맞게 프로젝트 범위를 확장할지 여부를 결정해야 합니다. 이것은 프로젝트의 진도와 예산에 영향을 줄 수 있는 상업적 결정이다. 둘째, 요구 사항의 세 가지 측면 SRS 는 기능 요구 사항 외에도 성능 지표 및 품질 특성에 대한 설명을 포함한 비기능 요구 사항을 포함합니다. 물성은 제품 기능 설명을 보완하며, 기능 설명은 여러 방면에서 제품의 다양한 특징을 설명합니다. 이러한 특성에는 가용성, 이식성, 무결성, 효율성 및 견고성이 포함되며 사용자나 개발자에게 중요합니다. 기타 비기능적 요구사항으로는 시스템과 외부 간의 외부 인터페이스, 설계 및 구현에 대한 구속조건이 있습니다. 또 다른 물성은 가용성이라고 하는데, 이는 업무 요구에서' 효율적' 이라는 단어의 의미를 정의합니다. 제약 조건은 시스템 설계 및 구축 시 개발자의 선택을 제한합니다. 제품의 아키텍처 설계에서 제약 조건은 가장 먼저 고려해야 할 문제입니다. 제품의 기능이 제품의 능력을 나타낸다면, 제품의 물성은 제품의 품질을 나타내고, 제품의 제약은 제품이 만족하거나 적응해야 하는 조건을 나타낸다! 고용주는 "사용자 경험" 이 제품의 영혼이라고 말하는데, 아마도 개인 소프트웨어에 사용하는 것이 더 적합할 것이다. 기업급, 심지어 산업급 제품의 경우 두 가지 영혼이 있다. 하나는 제품이 한 명의 사용자의 가치를 가지고 있고, 하나는 제품의 품질이다. 간단히 말하면 가치와 품질이다. 그러나 제품이 되기 위한 전제는 제약 조건을 충족해야 한다. 그렇지 않으면 디자인, 개발, 시장 진입, 쓰레기가 되어서는 안 된다. 사용자 요구 사항과 기능 요구 사항의 차이는 간단합니다. 사용자 요구 사항입니다. 사용자는 응용 프로그램 시스템에서 무엇을 구현해야합니까? 이를 위해서는 모든 상세한 업무 설명, 업무 프로세스, 양식 스타일 등이 필요합니다. 기능 요구 사항. 사용자 요구 사항 분류를 컴퓨터가 구현할 수 있는 하위 시스템 및 기능 모듈로 분할하고 설계 언어로 사용자 요구 사항을 설명하고 해석하여 안내 프로그램 설계 목적을 달성합니다.