요구사항 엔지니어링 프로세스
도출 및 분석 – 이해관계자와의 상호작용을 통한 요구사항 식별
사양 – 요구 사항을 의미 있는 형식으로 가져오기
확인 – 요구 사항이 실제로 고객이 원하는 시스템을 정의하는지 확인합니다.
관련 활동은 나선형 반복 프로세스로 구성됩니다.
- 각 활동에 필요한 시간과 노력은 다음 특성에 따라 다릅니다.
- 전체 프로세스의 단계, 개발할 시스템 유형, 사용 가능한 예산 등
요구사항 엔지니어링 프로세스의 특성
1. 공정 단계에 따라 다른 초점
- 이니셜: 높은 수준의 비즈니스, 비기능 요구 사항, 사용자 요구 사항
- 후반부: 비기능적 요구 사항, 더 자세한 시스템 요구 사항
2. 환경에 따라 반복 횟수나 진행 상황이 다를 수 있습니다.
- 일부/전체 사용자 요구사항 도출 후 종료
- 요구사항서와 시스템 개발을 동시에 진행할 수 있음(프로토타이핑 → 애자일 개발)
3. 다음과 같은 이유로 모든 시스템에 대한 요구 사항이 변경되었습니다.
- 이해 관계자는 소프트웨어가 수행해야 하는 작업을 더 잘 이해합니다.
- 조직 구매 시스템의 변화
- 시스템의 하드웨어, 소프트웨어 및 조직 환경이 변경됩니다.
요구사항 도출
- 이해관계자가 무엇을 하고 있으며 작업을 지원하기 위해 새로운 시스템을 어떻게 사용하고 있는지 이해합니다.
- 소프트웨어 엔지니어는 이해 관계자와 협력하여 다음을 알아냅니다.
- 애플리케이션 도메인, 비즈니스 활동, 서비스, 이해 관계자가 원하는 시스템 기능, 요구되는 시스템 성능, 하드웨어 제약 조건 등
- 시스템 참가자의 요구 사항 수집 및 이해 어려움
요구사항 도출이 어려운 이유
1. 모호하고 비현실적인 이해관계자 요구사항
- 일반적으로 말하자면 – 대부분의 경우 컴퓨터 시스템에서 원하는 것이 무엇인지 모릅니다 – 시스템이 수행해야 하는 작업을 명확하게 말하기는 어렵습니다.
- 무언가가 유효한지 확실하지 않음
2. 도메인 경험에 따른 요구 사항
- 시스템 참가자는 다른 사람들이 자신의 업무에 대한 지식을 가지고 있는 경우 기술 전문 용어로 요구 사항을 표현합니다.
- 도메인에 대한 경험이 없는 요구 사항 엔지니어가 이해하기 어려울 수 있음
3. 서로 다른 이해관계자의 서로 다른 요구
- 서로 다른 이해 관계자는 서로 다른 방식으로 요구 사항을 표현할 수 있습니다.
- 요구 사항 엔지니어는 요구 사항의 모든 잠재적 소스를 검색하고 유사점과 충돌을 찾아야 합니다.
4. 정치적 요인이 시스템 요구 사항에 영향을 미칠 수 있음
- 관리자는 조직에서 영향력이 커지기 때문에 특정 시스템 요구 사항을 요청할 수 있습니다.
5. 역동적인 경제와 비즈니스 환경
- 상황은 분석 과정에서 변할 수밖에 없습니다.
- 특정 요구 사항의 중요성도 변경될 수 있습니다.
- 새로운 이해 관계자는 새로운 요구 사항을 요구할 수 있습니다.
요구사항 도출 및 분석 프로세스
1. 요구사항 발견 및 이해
- 요구 사항을 결정하기 위해 상호 작용하는 시스템 이해 관계자의 프로세스
- 도메인 요구 사항 및 문서 가져오기
2. 요구사항의 분류 및 구성
- 요구 사항을 수집하고 일관성 있는 그룹으로 구성
3. 요구 사항의 우선 순위 지정 및 협상
- 귀하의 필요를 우선시하십시오
- 상충되는 요구사항을 찾아 협상을 통해 해결
4. 요구 사항 문서화
- 다음 단계에서는 과제에 대한 요구 사항을 문서화합니다.
요구 사항 도출 시 중요 사항
1. 이해관계자 정보 구성 및 그룹화
- 이해관계자 관점에서 요구사항 통합
- 요구 사항 분석 프로세스 간소화
2. 이해관계자 정기 간담회
- 이해관계자에게 우려 사항을 표명하고 타협 제안에 동의할 수 있는 기회를 제공합니다.
3. 문서화 단계에서 일반 텍스트 및 다이어그램 사용
- 이해 관계자가 요구 사항을 이해하고 의견을 제시하려면 정보 공유를 용이하게 하는 공통 문서 또는 위키를 사용하는 것이 가장 좋습니다.
요구사항 도출 기법
- 다양한 유형의 이해 관계자와의 회의를 통해 요구 사항 도출
- 기존 시스템에 대한 정보 및 사용 방법, 변경 필요성 이해
- 요구 사항 도출에 대한 두 가지 접근 방식
- 인터뷰 – 사람들이 자신이 하는 일에 대해 말하는 방식
- 관찰 또는 민족지학 – 사람들이 어떤 일을 하고 무엇을 사용하는지, 어떻게 사용하는지 등을 관찰하는 방법.
회견
- 인터뷰 중 이해 관계자는 현재 사용 중인 시스템과 개발해야 할 시스템에 대한 질문을 받았습니다.
- 다음 두 가지 유형으로 나뉩니다.
- 비공개 인터뷰 – 이해관계자가 미리 정의된 질문에 답변합니다.
- 개방형 인터뷰 – 미리 정의된 내용 없음, 요구 사항을 더 잘 이해하기 위해 시스템 이해 관계자와 함께 다양한 문제 탐색
- 실제로 두 가지 유형은 서로 바꿔서 사용할 수 있습니다.
일반적으로 인터뷰를 시작하기 위해 질문을 한 다음 인터뷰에 집중합니다.
면접의 어려움
도메인 지식 추출이 어려움
- 모든 애플리케이션 전문가는 자신의 업무와 관련된 전문 용어를 사용합니다.
- 기술적 관점에서 용어 없이 도메인 요구 사항을 논의하는 것은 불가능합니다.
- 용어가 가혹하고 미묘한 방식으로 사용될 때 오해를 받을 수 있음
- 일부 도메인 지식은 이해관계자에게 너무 익숙하거나 명백합니다.
- 설명하기 어려울 수 있으며 때로는 생략됨
조직의 요구 사항 및 제약 사항에 대한 지식을 도출하기가 어렵습니다.
- 이론적 구조를 넘어 실제 정보를 외부에 제공하는 것을 꺼림
- 대부분의 사람들은 요구 사항에 영향을 미칠 수 있는 정치적 및 조직적 문제에 대해 이야기하고 싶어하지 않습니다.
효과적인 면접을 위해 해야 할 두 가지
피해자의 말을 들어야 합니다
- 열려 있고 요구 사항을 너무 많이 사용하지 마십시오.
- 갑작스러운 요구가 있을 때 시스템에 대한 생각을 기꺼이 바꿔야 합니다.
인터뷰 대상자가 대화를 시작하도록 격려해야 합니다.
- 소개 질문, 제안된 요구 사항, 프로토타이핑 시스템 사용 등
- 응답자는 일반적인 용어보다 정의된 맥락에서 말하는 것이 훨씬 쉽다는 것을 알았습니다.
- “원하는 것을 말해봐”라고 물어보는 것으로 유용한 정보를 얻기는 어렵습니다.
문화 및 기술 연구
시스템 사용에 영향을 미치는 사회적 및 조직적 문제를 이해하려고 노력하는 것은 요구사항 엔지니어링 프로세스에서 매우 중요합니다.
- SW 시스템은 단독으로 존재하는 것이 아니라 사회적이고 조직적인 환경에서 사용된다.
- 소프트웨어 시스템 요구 사항은 환경에 의해 생성되거나 영향을 받습니다.
행동 프로세스를 이해하고 이러한 프로세스를 지원하는 소프트웨어에 대한 요구 사항을 얻는 데 사용되는 관찰 기술
- 공식 프로세스보다 명확하지 않은 시스템 요구 사항을 발견하도록 지원
사람들은 자신의 세부 작업을 명확하게 설명하는 데 어려움을 겪습니다.
- 자신이 잘 알고 있는 업무 및 다른 업무와의 관계를 이해하고 설명하는 데 어려움이 있음
민족지학적 연구를 통해 효과적으로 찾을 수 있는 요구사항 유형
실제 작업 관행에서 발생할 수 있는 요구사항
- 사람들은 공식적인 절차를 따르지 않습니다.
타인의 활동에 대한 협력과 인식에서 비롯되는 욕구
- 직원은 다른 직원의 정보를 보거나 협업할 수 있습니다.
민족지 연구의 특징
프로토타이핑과 결합 가능
- 프로토타입 개선 주기 단축에 도움이 될 수 있습니다.
- 프로토타이핑은 문화적으로 기술적인 연구에도 초점을 맞출 수 있습니다.
- 이 방법을 사용하여 논의할 수 있는 문제와 질문을 식별하고 나중에 답을 찾으십시오.
항상 혁신과 일치하는 것은 아닙니다.
- 혁신은 신제품 개발을 의미합니다.
- 민족지학 연구는 기존 시스템을 이해하는 데 도움이 됩니다.
- 노키아 대 애플(아이폰)
- 노키아는 새로운 휴대전화를 개발하기 위해 민족지학적 연구를 사용합니다.
최종 사용자에 집중
- 다른 요구 사항 추출 기술에서 놓치는 주요 프로세스의 세부 정보를 찾을 수 있습니다.
- 일반적인 조직 또는 영역별 요구 사항 또는 혁신 제안을 식별하는 데 효과적이지 않음
스토리와 시나리오
특정 작업에 시스템을 사용하는 방법에 대한 설명
- 사람들이 수행할 작업, 사용 및 생성할 정보, 작업 프로세스를 진행하면서 사용할 시스템에 대한 설명입니다.
- 시스템에 대해 논의하거나 보다 구체적인 시스템 요구 사항을 작성할 때 사용할 수 있습니다.
설명이 구조화된 방식과 프레젠테이션을 위한 세부 수준에 따라 분류됨
- 스토리: 스토리를 전달하는 방식으로 시스템이 사용되는 방식에 대한 높은 수준의 설명입니다.
- 시나리오: 입력 및 출력과 같은 수집된 특정 정보로 구성됨
- 스토리의 일부를 더 다듬어 시나리오로 제시할 수 있습니다.
이야기
누구나 쉽게 이야기에 참여할 수 있습니다.
- 인터뷰할 수 있는 것보다 더 큰 그룹에서 정보를 수집할 때 유용합니다.
- iLearn 시스템의 예 – 위키에 스토리를 작성하고 교사와 학생을 초대하여 위치에 관계없이 스토리에 댓글을 달 수 있습니다.
- 높은 수준의 스토리는 시스템에 대한 자세한 정보를 제공할 수 없습니다.
- 향상된 기능으로 보다 구체적인 시나리오 가능
대본
사용자 상호 작용이 발생하는 특정 간격의 예에 대한 설명
- 대화식 문장보다는 구조화된 방식으로 자신을 표현하는 것이 가장 좋습니다.
- 애자일 기술에 사용되는 사용자 스토리는 대화형 시나리오와 유사합니다.
- 요구 사항을 충족시키는 데 도움이 되는 일반적인 이야기와 다릅니다.
시나리오에는 다음이 포함됩니다.
- 시나리오가 시작될 때 시스템과 사용자가 기대하는 것에 대한 설명
- 시나리오의 정상적인 이벤트 흐름에 대한 설명
- 무엇이 잘못되었는지, 어떻게 대처해야 하는지에 대한 설명
- 동시에 수행할 수 있는 다른 활동에 대한 정보
- 시나리오 종료 시 시스템 상태에 대한 설명