유용한 팁

비즈니스 요구 사항 : 개발 및 디자인 예

Pin
Send
Share
Send
Send


소프트웨어 엔지니어링 용어의 IEEE 표준 용어는 요구 사항을 다음과 같이 정의합니다.

  1. 사용자가 문제를 해결하거나 목표를 달성하기 위해 필요한 조건 또는 기회
  2. 계약을 이행하거나 표준, 사양 또는 기타 공식 문서를 충족시키기 위해 시스템 또는 시스템 구성 요소가 가져야하는 조건 또는 기능
  3. 조항 1 및 2에 대한 조건 또는 기회에 대한 문서화 된 프레젠테이션

비즈니스 요구 사항

비즈니스 요구 사항(비즈니스 요구 사항)에는 시스템의 조직 또는 고객의 높은 수준의 목표가 포함됩니다. 일반적으로 프로젝트, 시스템 구매자, 실제 사용자 관리자, 마케팅 부서에 자금을 제공하는 사람들이 표현합니다. 이 문서는 조직에 이러한 시스템이 필요한 이유, 즉 조직의 도움으로 달성하려는 목표를 설명합니다. 프로젝트의 이미지와 경계에 대한 문서 형태로 비즈니스 요구 사항을 작성하는 것을 좋아합니다. 프로젝트 헌장 (프로젝트 헌장) 또는 시장 요구 사항 문서 (시장 요구 사항 문서)라고도합니다. 프로젝트의 경계를 정의하는 것은 워크로드 증가의 일반적인 문제를 관리하는 첫 번째 단계입니다.

사용자 요구 사항

사용자 요구 사항 (사용자 요구 사항)은 사용자가 시스템에 제공 할 목표와 목표를 설명합니다. 이러한 유형의 요구 사항을 제시하는 좋은 방법은 사용 사례, 스크립트 및 이벤트-응답 테이블을 포함합니다. 따라서이 문서는 고객이 시스템을 사용하여 수행 할 수있는 작업을 나타냅니다.

기능 요구 사항

기능 요구 사항 (기능 요구 사항)은 사용자가 비즈니스 요구 사항 프레임 워크 내에서 작업을 완료 할 수 있도록 개발자가 빌드해야하는 소프트웨어의 기능을 결정합니다. 행동 요구 사항이라고도하며, 기존의 "필수"또는 "수행해야 할"조항이 포함되어 있습니다. "시스템은 사용자에게 이메일로 주문 확인서를 보내야합니다."
기능 요구 사항은 SRS (소프트웨어 요구 사항 사양)에 문서화되어 있으며 필요한 시스템 동작을 완벽하게 설명합니다.

정의

용어의 혼동은 세 가지 주요 이유로 발생합니다.

  1. 목표 또는 예상 혜택을 비즈니스 요구 사항으로 지정하는 것이 일반적입니다.
  2. 일반적으로 사람들은이 용어를 사용하여 제품, 시스템 및 소프트웨어를 만들 계획입니다.
  3. 광범위한 모델은이 두 가지 유형의 응용 프로그램이 비즈니스 요구 사항이 높은 수준이고 종종 모호하고 세부적인 구성 요소 요청으로 분해되는 세부 수준 또는 추상화 수준 만 다르다고 주장합니다.

이러한 개념이 목표가 아니라는 점을 인식하고 만족하는 경우 그에 대한 답변 (즉, 가치를 제공)을 인식하면 이러한 오해를 피할 수 있습니다. 비즈니스 요구 사항은 제품, 시스템 및 소프트웨어로 분해되지 않습니다. 오히려 모든 것이 다른 방향으로 발생합니다. 제품 및 해당 응용 프로그램은 비즈니스 요구 사항에 대한 응답을 나타냅니다. 이 개념은 프로덕션 환경에 존재하며 발견되어야하며 제품에 대한 수요는 사람에 의해 결정됩니다. 사업 계획에 대한 요구 사항은 존재 수준으로 제한되지 않지만 세부 사항으로 축소해야합니다. 세부 사항에 관계없이 입찰은 만족할 때 항상 가치를 제공합니다.

제품 업데이트

시스템 또는 소프트웨어 개발 프로젝트에서 소기업의 요구 사항에는 일반적으로 이해 당사자의 권한이 필요합니다. 제품을 작성하거나 업데이트합니다. 시스템 및 소프트웨어 비즈니스 요구 사항은 일반적으로 기능 및 비 기능 응용 프로그램으로 구성됩니다. 물론 일반적으로 제품 기능의 첫 번째 옵션과 함께 정의됩니다. 두 번째는 종종 비즈니스 요구 사항의 디자인을 반영하는 경우가 많으며 때로는 제한으로 간주됩니다. 여기에는 생산 수준에서 적용 가능한 필수 성능 또는 안전 측면이 포함될 수 있습니다.

프로세스 악센트

응용 프로그램은 종종 백서에 나열되어 있습니다. 그들은이를 달성하는 방법보다는 비즈니스 요구 사항을 정확하게 계획하고 개발하는 프로세스 또는 활동에 중점을 둡니다. 이 매개 변수는 일반적으로 스펙 또는 시스템 요청 문서 또는 기타 변형에 위임됩니다. 모든 차이점을 고려하지 않으면 이들 사이에 혼동이있을 수 있습니다. 따라서 많은 백서에서 실제로 제품, 시스템 또는 소프트웨어의 요구 사항에 대해 설명합니다.

소프트웨어 개발 또는 수명주기와 관련된 비즈니스 요구 사항은 사용자를 식별하고 문서화하는 개념입니다. 예를 들어, 시스템 생성주기의 초기 단계에서 고객, 직원 및 공급 업체와 같은 미래의 설계를 안내합니다. 응용 프로그램은 종종 분석가에 의해 기록됩니다. 비즈니스 프로세스의 요구 사항을 분석하고 목표 "미래"를 결정하기 위해 "있는 그대로"연구하는 경우가 종종 있습니다.

응용 프로그램의 구성

비즈니스 프로세스 요구 사항에는 종종 다음이 포함됩니다.

  1. 변경 사유를 포함한 상황, 영역 및 배경.
  2. 요구 사항이있는 주요 이해 관계자.
  3. 미래 또는 목표 조건에 대한 성공 요인.
  4. 비즈니스 또는 다른 시스템에 의해 부과 된 제약.
  5. 플로우 차트를 사용하여 모든 것을 "있는 그대로"나타내는 프로세스 모델 및 분석
  6. 논리 데이터 모델 및 사전 링크.
  7. 비즈니스 용어 및 지역 전문 용어집.
  8. 알고리즘이 비즈니스 운영 흐름을 나타내는 플로차트와 달리 정보 시스템을 통과하는 방법을 설명하는 데이터 흐름도.

비즈니스 요구 사항을 기록하는 데 가장 널리 사용되는 형식은 문서입니다. 그들의 목표는 시스템에서 어떤 결과가 필요할지 결정하는 것이지만 궁극적으로 추가 조건없이 개발 될 수 있습니다. 결과적으로 기술, 성능, 유지 관리 성, 적응성, 신뢰성, 가용성, 보안 및 확장 성 등 서비스 품질과 관련된 모든 전문 요구 사항을 포함하여 기술의 성능 및 인프라의 기대 사항을 자세히 설명하는 참조 자료로 문서가 보완됩니다.

테스트 초기 단계에서 프로토 타입을 작성하면 식별 된 비즈니스 요구 사항의 완전성과 정확성을 평가할 수 있습니다. 이해 관계자는 먼저 프로세스를 거쳐 구조를 결정합니다. 결과는 시스템을 구축하는 프로젝트의 비즈니스 요구 사항 개발자 팀에게 전송됩니다. 다른 이해 관계자는 최종 배포 계획을 테스트하고 평가합니다. 명확성에는 적절한 템플릿을 결정하는 공식 프로세스를 사용하여 응용 프로그램 및 해당 솔루션을 추적해야합니다.

비즈니스 요구 사항의 범위는 시스템으로 구축해야 할 사항을 결정하는 단계로 제한되지 않습니다. 이는 기존 전략을 관리하고 유지하는 방법을 제공하는 것 이상입니다. 그리고 비즈니스 목표를 지속적으로 준수하도록하십시오. 요구 사항 문서는 통제 된 방식으로 지속적으로 검토되어야합니다. 특정 비즈니스 기능 및 도메인을 위해 설계된 표준화 된 형식 또는 템플릿을 사용하면 해당 영역의 초점을 유지하는 것 외에도 요청의 완전성을 보장 할 수 있습니다.

일반적으로 요구 사항을 평가하는 수단으로 간주되지만 프로토 타이핑은 일반적으로 생성중인 제품이나 시스템에 대한 관심을 이동시킵니다. 프로토 타입은 작동하는 소프트웨어이므로 비즈니스 요구 사항과는 별도로 3 단계 (응용 프로그램, 엔지니어링 또는 기술 설계 및 구현)로 구성됩니다. 또한 이들은 개발자가 구현하려는 예비 버전입니다.

프로토 타입은 매우 구체적이기 때문에 프로토 타입을 시험해 보는 이해 관계자는 개발자가 생성 한 내용의 일부 측면에 대해보다 의미있는 피드백을 제공 할 수 있습니다. 이는 만족도의 해석입니다. 또한 그래픽 사용자 인터페이스에는 밑줄이 표시되고 내부는 바로 가기입니다. 그것들은 대부분의 소프트웨어 로직을 형성하며, 대부분의 비즈니스 요구 사항이 충족되는 곳입니다. 다시 말해, 프로토 타입이 감지하는 문제는 쿼리와 관련이 없을 것입니다.

개발

응용 프로그램의 변경 사항을 인식하고 문서화하고 업데이트하는 것이 중요합니다. 그러나 비즈니스 요청은 일반적으로 인식만큼 변경되지 않습니다. 비즈니스 요구 사항이 존재하지만 이해 당사자, 분석가 및 프로젝트 팀에 의해 인식되거나 이해되지 않을 수 있습니다.

변경 사항은 일반적으로 부적절한 재료를 만족시키기 위해 제안 된 방법을 반영합니다. 실제로 비즈니스 요구 사항 충족과 관련된 대부분의 어려움은 실제로 제품, 시스템 또는 소프트웨어의 높은 수준의 디자인을 구성하는 거의 모든 노력을 목표로하는 일반적인 관행을 반영합니다. 이는 가치를 제공하기 위해 먼저 비즈니스 요구 사항을 적절하게 정의 할 수 없기 때문입니다.

개발 실무자들은 일반적으로 필요한 것을 충족시키는 것, 즉 생산 요구를 충족시키는 것처럼 보이는 솔루션으로“다시 돌아올”때까지 제품을 계속 수정합니다. 비즈니스 요구 사항을 정의하기위한 간접 시행 착오 방법은 "모범 사례"로 선전되는 인기있는 방법을 포함하여 많은 반복 개발의 기초입니다.

디자인 예

템플릿을 사용하면 검색어와 관련이있을 수있는 특정 주제를 빠르게 요청할 수 있습니다. 비즈니스 요구 사항과 관련된 표준화 된 문서를 작성하여 이해를 용이하게 할 수 있습니다. 템플릿은 요청의 정확성 또는 완전성을 보장하지 않습니다. 잘못 사용 된 예는 의미있는 분석없이 표면 성과 기계적 결정을 촉진하는 경향이 있으므로 연구에 부정적인 영향을 미칩니다.

이해 상충의 가능성이있는 결정에 관련된 많은 이해 관계자 기반으로 인해 비즈니스 요구 사항이 조기에 강화되는 경우가 종종 있습니다. 거버넌스와 합의 구축 과정은 본질적으로 정교하고 정치적 일 수 있습니다. 덜 어려운 일이지만 일반적인 작업은 다른 지리적 위치에있는 이해 관계자와 함께 분산 된 그룹입니다. 당연히 영업 사원은 고객에게 더 가깝고 생산 직원은 각 장치에 더 가깝습니다. 고위 경영진을 포함한 재무 및 직원 관리는 등록 본사에 더 가깝습니다.

예를 들어 영업 및 생산에 관련된 사용자가 참여하는 시스템에는 비즈니스 요구 사항이 필요합니다. 목표가 충돌 할 수 있습니다. 한 쪽은 최대 기능 수를 제공하는 데 관심이 있고 다른 쪽은 최저 생산 비용에 중점을 둘 것입니다. 그러한 상황은 종종 합리적이고 유리한 가격과 분배에 대한 최대 기회와 합의로 끝납니다.

이러한 문제를 해결하기 위해 초기 단계에서 이해 관계자 참여는 프로토 타입을 시연하고 협력하여 이루어집니다. 간단한 토론뿐만 아니라 조직 된 세션 형태의 실무 세미나는 특히 민감한 비즈니스 요구 사항과 잠재적 인 이해 상충이있는 부분에 대한 합의에 도달하는 데 도움이됩니다. 프로세스의 복잡성은 중요한 요소입니다. 법적 또는 규제 요구 사항, 브랜딩 또는 기업의 사회적 책임 의무와 같은 내부 지침을 이해하려면 전문 지식이 필요할 수 있습니다. 분석은 비즈니스 프로세스에서 "무엇"을 포착 할뿐만 아니라 컨텍스트를 제시하는 "어떻게"로 구성됩니다.

시스템 요구 사항

시스템 요구 사항 (시스템 요구 사항)은 많은 서브 시스템을 포함하는 고급 제품 요구 사항입니다. 시스템에 대해 말하면 소프트웨어 또는 하드웨어의 소프트웨어 또는 하위 시스템을 의미합니다. 사람은 시스템의 일부이므로 시스템의 특정 기능은 사람에게 확장 될 수 있습니다.

비즈니스 규칙

비즈니스 규칙 (비즈니스 규칙)에는 회사 정책, 정부 규정, 산업 표준 및 계산 알고리즘이 포함됩니다. 비즈니스 규칙은 소프트웨어 시스템의 경계를 벗어나므로 소프트웨어 요구 사항이 아닙니다. 그러나 이들은 종종 특정 VI를 수행 할 수있는 사람을 결정하거나 관련 규칙을 준수하는 시스템이 어떤 기능을 수행해야하는지에 대한 제한을 부과합니다. 때때로 비즈니스 규칙은 기능으로 구현되는 품질 속성의 소스가됩니다. 따라서 특정 기능 요구 사항의 출처를 해당 비즈니스 규칙으로 추적 할 수 있습니다.

비 기능적 요구 사항

비 기능적 요구 사항 품질의 목표와 속성을 설명하십시오. 품질 속성은 제품 기능에 대한 추가 설명이며 사용자 또는 개발자에게 중요한 특성에 대한 설명을 통해 표현됩니다. 이러한 특성에는 다음이 포함됩니다.
* 사용 편의성
* 운동의 용이성
* 무결성
* 효율 및 내결함성
* 시스템과 외부 세계 간의 외부 상호 작용
* 설계 및 구현 제한 사항. 제약 조건 (제약)은 제품의 모양과 구조를 개발할 수있는 선택과 관련이 있습니다.

제품 특징

제품 특징 (기능)은 사용자 기능을 제공하고 비즈니스 목표를 충족시키는 논리적으로 관련된 기능 요구 사항 집합입니다. 상용 소프트웨어 분야에서 특성은 구매 결정을 내릴 때 중요한 모든 이해 당사자가 인식하는 요구 사항 그룹입니다 (제품 설명의 글 머리 기호 목록 요소).

좋은 요구 사항에는 어떤 특성이 있어야합니까?

우수한 요구 사항의 품질 특징 :

- 완전성. 각 요구 사항에는 제품에서 구현해야하는 기능이 자세히 설명되어 있어야합니다. 즉, 개발자가이 기능을 작성하는 데 필요한 모든 정보를 포함해야합니다. 특정 종류의 데이터가 충분하지 않다는 것을 이해하는 경우 다음과 같이 필드에 "TBD"표시 (결정)를 사용하십시오.
그런 장소를 강조하기 위해 다트 깃발. 이 기능의 구성을 진행하기 전에 요구 사항의 각 조각에있는 모든 간격을 채우십시오.

- 정확성. 각 요구 사항은 원하는 기능을 정확하게 설명해야합니다. 정확성을 유지하려면 요구 사항 소스 (예 : 사용자 또는 고급 시스템 요구 사항)와 통신해야합니다. 부모 요구 사항과 충돌하는 소프트웨어 요구 사항은 올바른 것으로 간주 할 수 없습니다. 그러나 여기서의 주요 평가는 사용자 담당자를위한 것이므로 해당 담당자 나 직속 대리인이보기 요구 사항을 제공해야합니다.

- 타당성.시스템 및 운영 환경의 특정 조건 및 제한에서 각 요구 사항을 구현할 수 있어야합니다. 달성 할 수없는 규정을 따르지 않으려면 개발자가 요구 사항 추출 전체 기간 동안 요구 사항의 마케팅 담당자 및 분석가와 상호 작용하도록하십시오. 개발자는 기술적으로 수행 할 수있는 작업과 수행 할 수없는 작업 또는 수행 할 수있는 작업, 그러나 추가 자금을 통해 실제로 감사하게 생각합니다. 개념을 확인하는 증분 개발 및 프로토 타입을 통해 요구 사항의 실현 가능성을 확인할 수 있습니다.

- 필요. 각 요구 사항에는 사용자가 실제로 필요하거나 외부 시스템 요구 사항 또는 표준을 충족시키는 데 필요한 기능이 반영되어야합니다. 또한 직책을 기록 할 권한이있는 사람이 제공해야합니다. 사용 사례가 식별되면 사용자 의견 수집 단계까지 각 요구 사항을 추적합니다.
비즈니스 규칙 또는 기타 출처.

- 우선 순위. 각 기능 요구 사항, 기능 또는 유스 케이스의 우선 순위를 지정하여 각 버전의 제품에 필요한 것을 판별하십시오. 모든 규정이 똑같이 중요하다면 프로젝트 관리자가 예산 삭감, 마감 기한 위반, 직원 상실 또는 개발 과정에서 새로운 요구 사항 추가에 대처하기가 어려울 것입니다.
추가 정보 14 장에서는 우선 순위에 대해 자세히 설명합니다.

- 모호함. 모든 요구 사항 독자는 동일한 방식으로 해석해야하지만 자연 언어에는 종종 다 항성이 있습니다. 사용자가 이해할 수있는 어휘를 사용하여 간단하고 간결하고 정확하게 문서를 작성하십시오. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.

- Проверяемость. 여러 테스트를 개발하거나 다른 방법 (예 : 검사 또는 데모)을 적용하여 각 요구 사항이 실제로 제품에 구현되어 있는지 확인하십시오. 요구 사항이 검증되지 않으면, 올바른 구현의 문제는 분석의 목표가 아니라 결론의 주제가된다. 불완전하거나 일관성이 없거나 실행 불가능하거나 모호한 요구 사항도 확인되지 않습니다.

요구 사항 사양에는 어떤 특성이 있어야합니까?

사양을 구성하는 요구 사항은 다음의 특성을 충족해야합니다.

- 완전성. 요구 사항이나 필요한 데이터는 생략하면 안됩니다.

- 일관성. 합의 된 요구 사항은 동일한 유형의 다른 요구 사항이나 고급 사용자, 시스템 또는 비즈니스 요구 사항과 충돌하지 않습니다. 개발 프로세스가 시작되기 전에 문서 불일치를 해결해야합니다. 연구를 완료 할 때까지 어떤 위치가 틀린지 (일부 틀린 경우) 항상 알 수있는 것은 아닙니다. 갈등이 여전히 발견되면 누가이를 표명했는지 확인하기 위해 각 클레임의 저자를 기록하는 것이 좋습니다.

- 수정하는 능력. 필요한 경우 요구 사항을 재 작업 할 수 있도록 보장하고 각 규정에 대한 변경 기록을 유지해야합니다. 이렇게하려면 모든 항목을 고유하게 표시 할 수 있도록 고유하게 표시하고 레이블을 지정해야합니다. 각 요구 사항은 사양에 한 번만 기록해야합니다. 그렇지 않으면 같은 위치에서 두 위치 중 하나의 위치 만 변경하면 쉽게 불일치가 발생합니다. 중복 절 대신 초기 명령문에 대한 링크를 사용하십시오. 문서의 내용과 색인을 컴파일하면 사양을 훨씬 쉽게 수정할 수 있습니다. 상용 요구 사항 관리 도구의 데이터베이스에 사양을 저장하면 재사용 할 수 있습니다.

- 추적 성. 추적 성 또는 분석 기능은 소스와 포워드 방향,이를 구현하는 디자인 요소 및 소스 코드, 정확성, 구현을 확인할 수있는 사용 사례에 모두 구현할 수 있습니다. 추적 가능한 요구 사항에는 해당 식별자가 표시되어 있습니다. 그것들은 긴 서사 형식의 단락들과 대조적으로 구조적이고 상세한 형식으로 작성됩니다. 여러 요구 사항을 하나의 덩어리로 묶지 마십시오. 개별 요구 사항은 다양한 디자인 및 코드 요소로 추적 될 수 있습니다.

Pin
Send
Share
Send
Send