Requirements engineering processes
- Requirements elicitation / Requirements analysis / Requirements validation / Requirements management의 순으로 이루어지며 Requirment engineering의 공통적 작업이다.
- 각 단계는 밀결합되어 있으며 spiral하게 process가 진행된다.
Requirement elicitation(discovery)
- 소프트웨어 엔지니어는 다양한 분야의 이해 당사자들과 협업하면 서비스가 제공해야하는 것, 필요한 기능, 하드웨어 제한 사항 등을 알아내야 한다.
- 요구 사항 발견
- 요구 사항 분류 및 조직화(다양한 stakeholder에서 요구 사항이 발생하기 떄문)
- 요구 사항 우선 순위 부여(일정 및 충돌 발생 대비) 및 협상(요구 사항 조정)
- 요구 사항 명세화(문서화, 한번에 끝낼수 없다면 spiral하게 여러 번 반복)
요구 사항 도출에서의 문제점
- 수많은 이해 당사자들이 본인이 정확이 무엇을 원하는지 모른다
- 본인들이 원하는 것을 자신들의 용어로 표현한다.
- 서로 다른 이해당사자들의 요구 사항이 충돌한다.
- 집단이나 정치적인 요소가 시스템의 요구사항에 영향을 줄 수 있다.
- 요구 사항이 분석 과정 중에 바뀌거나 새로운 이해 당사자의 등장이 비즈니스 환경에 영향을 줄 수 있다. 미래 발전에 대학 예측 후 조율하는 과정 또한 필요하다
문제점을 줄이면서 요구 사항을 효과적으로 도출할 수 있는 방법
Interviewing
- 이해 당사자들과 공식적이거나 비공식적인 인터뷰를 통해 도출
- closed interview : 미리 정해진 질문을 통해 인터뷰(구체적인 사항 추출)
- open interview : 미리 주제를 정하지 않고 다양하게 인터뷰(큰 틀에서의 파악)
- 잘 듣고자 하는 의지가 중요하며 편향적인 생각이 아닌 열린 마음이 필요하다
- spring board를 사용하거나 지난 회의에서의 이해를 바탕으로 요구사항을 제안해보거나 프로토타입을 같이 시행해본다
- 이해 당사자들이 어떤 방식으로 어떻게 상호작용하는지에 대해 이해하는 것이 중요하다
인터뷰의 문제점
- 전문가들의 용어를 이해하기 어렵다 -> 관련된 영역의 사전적인 공부가 필요하다
- 해당 분야의 기본적인 지식은 의논되지 않거나 명확하게 특정되기 어렵기 때문에 개발자에게 이해의 어려움을 줄 수 있다. -> 해당 영역의 기초 지식을 공부하며 기본적인 것은 찾아서 반영해야한다.
Ethnography(민족지/관찰)
- 어떤 식으로 시스템을 사용하고 업무를 하는 지를 관찰하여, 복잡한 상호작용 및 작업 과정(이유)을 이해할 수 있다. 객관적이고, 실제 관찰을 통해 이해관계자들 관계를 이해할 수 있다. 하지만, 지금 있는 시스템을 관찰하기 때문에, 새로운 개선점과 변화에 대해서는 이해가 부족할 수 있다.
- 프로토타입 기법을 사용해서 개선점 여지를 찾을 수도 있다. 관찰한 내용을 분석하고, 대상자에게 알려주고 피드백을 받을 수 있다. 또한 프로토타입을 만들어 개선할 수 있다.
Stories and scenarios
- 시스템을 어떻게 사용해야 하는지에 대해 실생활 예시를 들어 설명한다.
- 구체적인 사례에 집중하여 설명함으로써 그에 관련된 이해 당사자들이 더 많은 이야기를 할 수 있다.
- 사용자가 겪을 수 있는 상황을 구체적인 형태를 갖추고 이야기한다.
- 작업의 시작 상황 / 일반 상황에서의 이벤트의 순서와 작업 / 주의사항 / 동시적으로 이뤄지는 활동들 / 끝나고 난 뒤의 바뀐 상황
Requirements specification
- 요구사항을 기술한 내용은 요구사항 문서를 도출한다.
- User requirements에서는 가능한 기술적인 부분은 배제되어야 한다.
- System requirements는 기술적인 정보를 포함해 상세하게 기술되어야 한다.
System requirements 기술하는 방법
자연어
- 요구 사항은 넘버링이 되어야 하며 한 문장은 반드시 하나의 요구사항만 기재한다.
- 다이어그램이나 테이블을 사용하기도 한다(Tabular specification)
- 가장 직관적이고 보편적인 방법이며 고객을 이해시키기 가장 좋은 방법이다.
- 표준화된 규격을 만드는 것이 좋으면 용어는 일관적인 방식으로 사용해야한다.
- 컴퓨터와 관련된 용어의 사용은 피하는 것이 좋다.
- 추가설명이 필요하면 기술하는 것이 좋다
단점
- 형용사 및 부사의 사용으로 정확도가 떨어지고 이해도가 떨어질 수 있다.
- 요구사항이 한 데에 섞여 혼동을 일으킬 수 있다.
구조화된 자연어
- 특정 구조를 자연어를 사용하여 표현(표나 템플릿)
- 요구사항을 기재하는 사람에게 제약을 줌으로써 특정 방식을 기술되게 한다.
- 임베디드 시스템 등과는 잘 맞지만 엄격한 구조는 agile방식과는 잘 맞지 않는다.
- 이름과 기능, 입력과 출력, 동작, 추가 필요정보, 동작의 구체적인 설명, 전처리 및 후처리, 영향을 받는 다른 기능들에 대한 내용을 필수적으로 포함해야한다.
Description languages
- 의사코드와 같이 프로그래밍 언어를 쓰지 않지만, 프로그래밍 언어처럼 표현
graphics notation
- UML USE CASE, SEQUENCE DIAGRAM과 같은 그림으로 표현
- 시스템과 관련이 있는 actor들이 등장한다.
수학적 명세
- 상태천이도와 같은 수학적 기호, 조건을 사용하여 기술하는 방법
- 수학적 명세가 많이 사용되면 이해가 어려울 수 있다.
요구사항과 디자인은 분리되어 설명할 수 없다.
- NON-functional한 요구사항을 만족시켜야하는 소프트웨어 구조는 디자인에 설명을 반드시 포함해야한다.
- 규제나 제한 사항에 관련될 수 있기 때문에 디자인에 대해 고려해야한다.
- 다른 시스템과 상호작용이 가능해야하기 때문에 디자인과 일부 구현의 내용도 포함해야한다.
- 회사에 사용하는 양식이 있거나 시스템 및 IEEE 표준도 존재한다.
Requirements Validation
- 고객이 원하는 것이 기술되었는지 검증한다.
- 요구 사항이 잘못되었을 때의 비용은 상당히 크다
평가기준
- Validity(필요한 기능이 명시되어 있는지)
- Consistency(충돌여부)
- Completeness(Comprehensibility)
- Realism(예산과 사용 가능한 기술 안에서 구현가능한지의 여부)
- Verifiability(구현의 판단 여부를 검사할 수 있는 지)
- Traceability(수정 사항 발생 시, 추적 가능 여부, 넘버링의 사용 이유)
- Adaptability(변화를 받아드릴 수 있는 지)
validation에 사용되는 기술
- 요구사항을 Review(많은 인원, 다양한 영역의 사람들이 참여)
- 요구사항을 통해 프로토타입을 만들어 볼 수 있다.
- Test-case를 돌려보며 요구 사항을 검증할 수 있다.
Requirement Change
새로운 하드웨어의 등장, 법규와 규정의 변화, 비즈니스 환경의 변화가 소프트웨어 변화를 야기할 수 있다. 이런 변화에 단계적으로 요구사항부터 재정의가 필요하다.
Requirements management
요구사항의 변화를 관리한다. 즉, 각각의 요구사항들이 관리되며, 각 요구사항의 관계들도 관리된다. 따라서 새로운 요구사항이 들어오면, 정해진 절차에 따라 기존의 요구사항의 미치는 영향들을 고려해야 한다.
- Requirement identification(요구 사항 식별)
- Traceability policies(추적이 가능해야한다)
- Tool support(요구 사항 관리를 위한 도구를 사용하는 것이 좋다)
- A change management process (바뀐 요구사항을 수용할지에 대해 관리할 프로세스가 있어야한다)
- 문제를 분석하고 명세서를 수정한다.
- 분석과 예산, 비용을 수정하고 수정된 것을 구현한다.
Requirements management Planning
- 각각의 요구사항들은 식별가능해야 하며, 넘버링을 통해 추적이 가능하여 넘버링이 바뀌면 서브넘버링도 수정하는 상하 관계와 상호 관계를 관리해야한다.
- 또한 이를 쉽게 관리해주는 도구(spread sheets 등)을 이용할 수 있다.
KHU, SWCON