시스템을 모델링하고 있는데 다음과 같은 사례가 있습니다. {선생님 (adimin) 지정, 성적 (교사) 지정, 학생 관리 (admin), 출석 기록 (teacher) , cocurricular (admin)} 유스 케이스 단계와 유스 케이스 시나리오를 생각해 내는데 몇 가지 문제가 있습니다. 나는 이미 개념적 클래스 다이어그램을 그려 놨다. 아무도 그것에 대해 어떻게 생각하니? 당신은 같은 this 유용한 기사를 찾을 수 있습니다 사전유스 케이스 단계 및 유스 케이스 시나리오
에
감사합니다.
나의 사고 방식. 유스 케이스에 대한 일반적인 설명이 있으므로 구축중인 시스템이 무엇을해야하는지 알 수 있습니다. 그러나 이러한 사용 사례에는 의심의 여지없이 많은 주름과 특별한 경우가 있습니다. [ "학생 관리"를 전달하는 과정에서 "학생 등록", "학생 일시 중지", "대학원생"등이 필요한 "교사 지정"장애와는 약간 다른 입도로 보인다.
다음 단계는 다음 단계입니다. 유스 케이스에 대한 자세한 내용을 제공함으로써 시스템의 요구 사항을 더 많이 확보 할 수 있습니다. 당신은 사람과 시스템의 행동 측면에서이를 표현합니다. 시스템 컨텍스트 다이어그램이 있습니까? 그러면 시스템이 상호 작용하는 모든 것이 표시됩니다. 그런 다음 시나리오를 배우, 시스템 및 기타 시스템에 의한 일련의 작업으로 표현합니다.
The Teacher logs on
TheSystem presents a menu
The Teacher selects "record grade"
The System presents a list of classes taught by the teacher
The Teacher selects class
etc.
발생할 수있는 변형을 고려하면 주름이 생깁니다. 실패한 성적을위한 특별 조치? 특정 유형의 학생에 대한 채점 제한? 따라서 "흥미로운"사례에 대한 시나리오를 추가로 만들 수 있습니다.
이 단계에서 스펙픽 클래스와 클래스 다이어그램은 필요하지 않습니다. 나중에 "시스템이 선생님이 가르쳐 준 수업 목록을 제시합니다"와 같은 단계를 고려하고 시스템이 수업 도표를 사용하여 수업을 구현하는 방법을 고려하십시오.
목표를 기억하십시오 : 만족해야 할 요구 사항의 전체 그림을 얻으십시오.
또한 클래스에서이 작업을 수행 할 필요는 없지만 요구 사항 수집에 유용한 또 다른 단계는 오용 사례를 확인하는 것입니다. 즉, 시스템에서 발생할 수있는 나쁜 점을 파악하고 싶습니다. 예를 들어, 오용 사례는 시스템에 해킹당하는 사람이 될 수 있습니다. 그런 다음 오용 사례를 수정하기 위해 취할 단계를 작성할 수 있습니다. 생각할 무언가.