2010-08-10 5 views
7

사용자 스토리가 있으며 비즈니스 규칙 (주로 요구 사항을 준수하는 법을 준수하는 법칙)이 있습니다. 애자일 SDLC에서 나는 이러한 "규칙"이 내 사용자 스토리에 첨부되어 있는지 잘 모르겠습니다.사용자 스토리에 대한 비즈니스 규칙 통합

예를 들어, 같은 사용자 스토리 : 나는 새로운 환자 파일을 생성하기 위해 환자 정보를 추가 할 의사로

.

과 같은 규칙 :

다음 정보는 각 환자의 기록에 입력해야합니다 의 (a) 환자 : (I) 이름과 지정된 이름; (ii) 주소; (iii) 생년월일; 및 (iv) 성별;

이 두 가지가 명확하게 결합되었지만 어떻게 링크 할 수 있습니까? 내 사용자 스토리의 테스트 수락 정의로? 다른 사용자 이야기?

답변

4

나는이 처리 본 적이 몇 가지 방법이 있습니다 :

  1. 아티팩트는 비즈니스 규칙을 저장하기 위해 만든되며, 따라서이가 전반에 걸쳐 알려진 모든 규칙의 일부 중앙 저장소에 저장됩니다

    개발 팀과 지식의 창고가 유지됩니다. 응용 프로그램을 구축하는 데 불과 몇 년 내에 수백 가지 규칙이있을 수 있으므로 추한 결과를 가져올 수 있습니다.

  2. 사용자 스토리 내에서 별도의 카드에 규칙을 적용 할 수 있습니다. 따라서 사용자 스토리는 한 줄이지만 6 ~ 8 개의 카드가있어 해당 스토리의 모든 작업을 완료 할 수 있습니다. 예를 들어, 새로운 환자 양식, 양식에 대한 유효성 검증 등이 있어야합니다. 따라서 이러한 요구 사항을 추적 할 수있는 방법으로 카드에이 줄이 보이지는 않습니다. 이것은 카드가 "양식의 일부 필드가 필수라는 것을 확실히 할 수 있기 때문에 특정 목록이 100 % 기록 될 곳이 아니지만 내 생각에는 가장 자연 스럽습니다."

  3. 명시 적 링크가 아니라 오히려 QA 또는 BA가 양식이이 규칙을 시행하는지 확인하도록 사용자를 유의하는 규칙입니다. 이는 하나와 유사하지만 문제는 이것에 대한 개발자의 책임입니다. 이 경우 QA는 개발자가 아닌 추적하는 것이 좋습니다.

사용자 스토리는 포괄적 인 요구 사항 목록이 아닌 토론을 시작하기위한 것입니다. 이 규칙은 개발자가 내 환자의 파일을 작성하기 위해 사용자와 논의 할 때 발생해야하는 것입니다.


나는 이야기가 완료 된 후 몇 스프린트 카드에 매달려의 아이디어를 좋아하지만, 나는 카드가 궁극적으로 파괴됩니다 점을 참조 할. 동시에 적절한 영역에 규칙을 구현하는 코드가 있어야합니다. 게시 한 예제를 사용하려면 필드를 표시해야하는 UI 레이어와 오류 메시지가 있기 때문에 필요한 필드 목록이 몇 군데에 표시되지만 비즈니스 로직 레이어가 있어야합니다. 새로운 환자 파일을 만들려고 시도하기 전에 일부 필드가 구체적으로 완료되었는지 확인하는 논리가 있습니다. 건설중인 시스템은 규칙을 어떤 형태로든 보관할 것입니다.

+0

좋아, 토론 중에 내가 몇 가지 규칙에 동의하면 나는 (2) 제안을 따를 수 있습니다. 나는 그것이 좋을 것이라고 생각한다. 유일한 문제는 사용자 스토리가 일반적으로 '자체 파괴적'인 점입니다. 즉 이야기가 끝난 후 삭제하게됩니다. 그래서 규칙도 잃어 버렸을까요, 아니면 내가 틀렸습니까? –

+0

그게 나를 위해 할 일, 귀하의 상세한 답변을 주셔서 감사합니다! –

0

허용 기준. 결국 이들은 테스트로 실행될 수있는 규칙입니다. 확실히 새로운 이야기는 아니며, 이는 전달 목표가 없기 때문에 잘못 될 것입니다.