Podstawy inżynierii wymagań i analizy ( piwa | 14 hours )

훈련 목표

교육 참가자는 요구 엔지니어링, 비즈니스 분석 및 시스템 분석 분야에서 조직적, 기술적 측면 모두에서 실제로 즉시 적용하는 데 유용한 기본 기술을 습득하게 됩니다.

대상 그룹

지식과 기술을 체계화하고 새로운 지식과 기술을 습득하려는 분석가(비즈니스 분석가 및 시스템 분석가) 및 요구 사항 엔지니어, 사용자 및 비즈니스 요구 사항의 변화를 효과적으로 획득, 분석 및 관리하는 기술이 필요한 모든 사람: 프로그래머, 프로젝트 관리자, 테스터, 참가자 스크럼 팀, 그리고 자신의 요구 사항을 IT 부서나 외부 공급업체에 능숙하게 전달해야 하는 소프트웨어를 주문하는 사람들입니다.

블록 1: 요구사항 엔지니어링이 없는 요구사항 - 좋은 사례와 나쁜 사례

• 워크샵 1 – 요구 사항은 실제로 어디에서 오는가?
• 요구사항 엔지니어링 또는 비즈니스 분석?
• 프로젝트 관리에 숨겨진 요구사항 엔지니어링
• Agile, 즉 정말 뛰어난 요구 사항 엔지니어링(비록 이국적인 용어로 숨겨져 있음)
• 요구사항 엔지니어링은 프로그래밍 팀의 책임입니다.
• 품질은 요구사항 엔지니어링 부족으로 인해 발생하는 비용입니다.

블록 2: 요구 사항은 얼마나 정확해야 합니까?

• 워크숍 2 – 요리책의 정확성을 결정하는 것은 무엇입니까?
• 실패 결과에 따른 요구 사항 완전성
• 제품 크기 및 복잡성에 따른 요구 사항 정확도
• 조직 특성에 따른 요구 사항 완전성

블록 3: 좋은 요구사항과 나쁜 요구사항

• 좋은 요구사항의 특징(속성)
• 유용한 요구사항 매개변수 및 가능한 값
• Agile의 제품 백로그 요소로서 좋은 요구 사항

블록 4: 요구사항 획득 방법

• 워크숍 3 – 요구사항 검색
• IT 시스템에 대한 비즈니스 비전 및 요구사항
• 이해관계자: 우리, 그들, 그리고 다른 사람들
• 시스템 경계, 시스템 컨텍스트 및 나머지 세계
• 요구사항 도출 프로세스
• 요구사항 도출 기술
• 요구사항 검증 및 협상

블록 5: 요구사항 설명

• 탐색적 요구사항 정의
• 자연어로 요구 사항 설명 – 이점과 위협, 보조 방법
• 요구사항 모델링
  •  불완전한 모델링을 가볍게 사용
  •  사용자 스토리
  •  제어 흐름도
  •  수영 레인 다이어그램
  •  데이터 흐름 다이어그램(컨텍스트)
  •  엔터티 관계 다이어그램
  •  UML: 사용 사례 다이어그램
  •  UML: 활동 다이어그램
  •  UML: 상태 전이 다이어그램
  •  UML: 상호작용 다이어그램
  •  UML: 구조도
• 요구 사항 설명: 형식, 템플릿, 문서 또는 도구(ReQtest, DOORS, 기타 도구)

블록 6: 요구 사항과 다음은 무엇입니까?

• 요구 사항을 기반으로 워크로드 예측
• 요구사항을 시스템 비전, 서로, 시스템 아키텍처, 구성 요소 및 테스트에 연결
• 요구사항 변경에 대처하는 방법