코드 외부에서 복잡한 비즈니스 규칙을 어떻게 추적합니까?

다른 사람들이 어떻게 하는지를보고 싶습니다. 특히 여러 다른 클라이언트가 약간 다른 비즈니스 규칙을 가진 동일한 소프트웨어 기반을 사용하는 상황에서. 모든 것이 어떻게 작동하는지 또는 비즈니스 규칙을 문서화하기 위해 어떤 종류의 관행을 사용합니까?

기본적으로 새로운 개발자가 팀에 합류하면 버그가없는 것을 만드는 것과 제대로 작동하는 것에는 분명히 차이가 있기 때문에 일이 어떻게 작동해야하는지 쉽게 확인할 수 있습니다.

무언가를 어떻게 처리해야하는지에 대한 질문이 생길 때마다 건축 가나 BSA를 대화에 참여시키는 대신 자원을 활용하는 것이 정말 좋을 것입니다.

이는 Cucumber와 같은 BDD 프레임 워크의 사용 사례 중 하나로서 코드에서 비즈니스 요구 사항을 캡처하고 해당 요구 사항을 자주 테스트 할 수 있습니다. 내가 사용한 다른 접근 방식은 길고 복잡한 사양 문서, 벽에 고정 된 큰 용지, 슬라이드 데크 및 테이블 끝의 모든 사람을 아는 Joe가 있습니다.

나는 최소한 이것들이 요구 사항 문서에 문서화되고 유지 될 것이라고 생각한다.

대부분의 장소에는 서면 요구 사항이 없거나 유지 관리되지 않았지만 다른 문제라는 것을 알고 있습니다. :-)

BPMN을 사용하여 비즈니스 워크 플로우를 문서화하고 모델링했습니다.

우리는 또한 사용자가 모델링에 참여할 수 있도록 프로젝트에서 워크 플로 엔진을 사용하려고 시도했지만 모델링이 워크 플로 전문가와 함께 수행 되었더라도 문제를 해결하기가 너무 두려웠 기 때문에 약간의 저항을 받았습니다. IT 부서.