비즈니스 규칙을 문서화하는 방법


12

비즈니스 규칙을 문서화하는 공식적이고 가장 일반적으로 사용되는 방법이 무엇인지 궁금합니다. 또한 개발 아티팩트의 UI 사양을 문서화하는 방법 (예 : 문서화 양식 필드 및 단추가 양식, 정보 텍스트 등에서 작동하는 방식)


"공식"은 "가장 좋은 방법"이 아닙니다. 제목이 혼란 스럽습니다 :
-P

나는 그것을 변경했다, 나는 그것이 덜 혼란되기를 바란다 :)
Maro

기술 문서 또는 기능 문서? 누가이 문서를 읽을 것입니까?
Laiv

답변:


1

비즈니스 규칙의 경우 @Joppe가 우리 모두가 생각하고있는 UML을 지적했다고 생각합니다.

유스 케이스 다이어그램은 액터 / 역할이 시스템과 상호 작용하는 방식과 시스템이 수행하는 작업에 대한 탁월한 개요를 제공합니다. complexe 사용 사례를 들어, 추가 정보가 많은 도움이됩니다 텍스트로 설명 ( 전제 조건 , 사후 조건 , 이전 UC의 실행에 대한 종속성 , )

여러 수준에서 비즈니스에 대한 훌륭한 개요를 제공하는 다이어그램이 있습니다.

  • 문서화 할 상태가있는 경우 상태 머신 다이어그램 .
  • 활동 다이어그램 . 복잡한 유스 케이스의 경우 세부 사항에 대해 자세히 알아야 할 수도 있습니다. 세부 사항의 수준은 사용자에게 달려 있으며 설명서를 읽을 사람에 따라 다릅니다. 이 문서는 업무상 문서처럼 보이지는 않지만 적절한 수준의 세부 사항이 있으면 그렇게 될 수 있습니다.

조언만으로, 각 사용 사례에 코드를 할당하십시오 (예 : UC-1 , UC-n ). 이것들은 나중에 UI 문서화 중에 유용합니다.

UI 문서의 경우 일반적인 요령 (현재)은 와이어 프레임 을 수행하는 것 입니다. 깨끗하고 단순 해 보이기 때문에 스크린 샷보다 훨씬 좋습니다. 예를 들어 WireframeSketcher를 살펴보십시오.

와이어 프레임에 대한 문서가 충분하지 않을 수 있으므로 각 화면에 대해 간략하게 소개하고 모든 버튼을 설명하십시오. 또한 화면에 포함 된 UC에 대한 참조를 수행 하십시오 ( UC 코드가 유용한 이유 참조 ). 이것은 문서를 일관성있게 만듭니다.

Wireframesketcher와 같은 도구의 요점은 대화 형 모형을 수행한다는 것입니다. 디자인하거나 개발하는 동안 고객에게 대화 형 무언가를 제공하기에 완벽합니다.

탐색 계획 을 문서화하는 것을 잊지 마십시오 . 탐색 Plan에는 UML 다이어그램이 없지만 State Machine Diagram 을 대신 사용할 수 있습니다. 그것이 만들어진 것이 아니라 여전히 그렇습니다.

마지막으로 누구에게 연락하고 있는지 명심하십시오.

  • 기술자 : 세부 사항을 자세히 살펴보고 기술을 사용할 수 있습니다.

  • 기술자 아님 : 기술을 피하십시오 (languaje 및 코드와 관련이 없음). 명확하고 단순하며 고객이 사용하는 것과 동일한 용어 / 단어를 사용하십시오. 프로그래밍에 대해 전혀 모른다고 생각하십시오.


5

문서는 종종 사용 사례 및 기타 산문 양식으로 수행됩니다. 또한 UML 다이어그램 및 기타 그래픽 양식을 사용하여 더 높은 수준의 개요를 제공하고 페이지와 페이지를 읽는 것보다 짧은 시간에 이해하기 쉽습니다.

마지막으로 가장 좋은 문서는 비즈니스 규칙을 실행하는 테스트 사례입니다. 그렇게하면 코드를 변경하고 비즈니스 규칙을 위반하고 있음을 알 수 있습니다. 그렇지 않으면 문서가 항상 오래되고 구식이 될 위험이 있습니다.


4

아마도 가장 일반적인 형태는 유스 케이스 입니다. 화면 모형 및 설명으로 보충 할 수 있습니다.

내가 추천하는 책은 Alistair Cockburn의 "유효 활용 사례 작성"입니다. 다양한 수준의 사용 사례를 작성하는 방법, '템플릿'중심 접근 방식에 빠지지 않도록하는 방법 및 필요한 관련 비트를 문서화하는 방법 만 설명합니다.


2

어떤 방법을 사용하든 적극적으로 관리 할 수 ​​있어야합니다. 그들은 살아있는 문서 여야합니다. 버전 관리 시스템 또는 Sharepoint와 같은 일종의 문서 관리 시스템에 문서를 보관하면 문서를 유지 관리하는 데 많은 도움이됩니다. 이메일에 첨부 된 단어 문서를 통해 비즈니스 규칙을 추적하는 것은 여러 버전이 떠 다니기 때문에 문제를 처리하는 끔찍한 방법입니다.


0

유스 케이스 및 UI 디자인에서 비즈니스 규칙 만 참조하여 비즈니스 규칙과 시스템 스펙을 엄격하게 분리하는 것이 좋습니다. 내가 가장 좋아하는 기술은 다음과 같습니다.-스프레드 시트에 식별 된 비즈니스 규칙 목록이 있습니다. -시스템 설계, 유스 케이스 스펙, 사용자 스토리 또는 무엇이든 "사용자는 비즈니스 규칙 BR012에 지정된대로 정보를 입력합니다", "시스템은 비즈니스 규칙 BR510에 지정된대로 총량을 계산합니다"를 지정하십시오. 이 기사를 추천합니다 http://www.allaboutrequirements.com/business-rules/


-1

Visual Studio 코드 및 Plant UML 플러그인을 사용하여 UML 다이어그램 생성

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.