(설계과목이니 planning을 주로 다루는 chapter 2는 건너뛰겠다고 하심)
SDLC 중 Analysis 단계에 해당한다.
용어
as-is system == current system
to-be system == new system
Requirement Determination
Requirement : system이 해야하거나 가져야하는 특성을 문장으로 기술한 것으로, 나중엔 어떻게 구현될지 technical description으로 자세하게 바뀌어야한다.
Requirement는 use-case를 파악하는 것은 물론, 이후 다양한 분석 과정에서 기반이 되는 자료이다. 아래 설명하는 다양한 방식으로 Requirements를 최대한 많이 자세하게 수집하고, 나머지 analysis 과정은 모두 이 requirements를 기반으로 이루어진다고해도 과언이 아니다.
물론 Requirements는 statement이므로 모호한 표현이 있을 수도 있고, Requirements에는 없던 정보가 분석 중에 나올 수도 있다. 그럼에도 우선 분석의 첫 단계는 requirements를 파악하는게 맞다.
전체 개발 과정에서 Requirement Determination(요구사항 찾기)은 가장 중요한 부분이다.
50% 이상의 system이 requirements로 문제를 겪는다.
이를 찾아내서 high level business requirement를 detailed requirement로 변경하는 것이 목표이다.
OOSAD 방식을 반복적으로 적용하는 것이 효과적이다. 매번 system이 진화하므로, 요구사항을 반영하기 좋기때문이다.
Requirment를 파악하는데 어려움이 있는 이유는 다음과 같다.
1. Analyst가 올바른 user에게 접근하지 못할 수 있다. 무슨 말이냐면, 전문 계산기 프로그램을 만드는데 전문성을 갖춘 사용자가 아닌 일반인에게 feed-back을 받는다면 제대로된 타겟 집단의 요구사항을 파악하기 어려울 것이다. 그런데 그런 올바른 user에게 접근하기가 쉽진 않다. 특정 집단을 선택해도 사람마다 특성이 다르기 때문이다.
2. Requirements specifications이 적절하지 않을 수 있다. 대게 프로그래머가 아닌 사람들은 매우 추상적인 요구사항을 말하기 쉽다. (ex.로그인이 잘 안돼요.)
3. 몇몇 requirements는 초반에 알 수 없는 경우가 있다.
4. requirements를 검증하는 것이 어려울 수 있다.
(그래서 requirement engineering이라는 분야도 따로 있을 정도라고 한다..)
Requirements Analysis Strategies (요구사항 분석 전략)
1. Problem Analysis
가장 많이 사용된다.
그냥 user에게 질문하는 것이다. as-is system에서의 문제가 무엇이며, to-be system에서 어떻게 해결할지를 질문한다.
(user들은 좋은 아이디어를 가지고 있는 경우가 많다.)
2. Root Cause Analysis
근본 원인을 찾는 방법, solution을 찾는 것이 아님.
특정 문제가 발생하면, 그 문제의 원인을 타고타고가며 근본적인 problem을 찾는다.
Requirements Gathering Techniques (요구사항 수집 기술)
목표 : 모든 requirements를 찾아내는 것 (뒤늦게 발견한걸 반영하기는 골치아프다..)
크게 아래 다섯가지 기술이 있다.
- Interviews
- Joint Application Development(JAD)
- Questionnaires
- Document analysis
- Observation
1. Interviews
가장 흔하게 사용되는 요구사항 수집 기술이다.
질문에는 세가지 종류가 있다.
Closed-ended questions: 단답으로 대답할 수 있는 질문
Open-ended questions
Probing questions: "예시를 주시겠습니까?" 같은 탐구적인 질문
질문은 구체적인 것부터 물어나가는 Bottom-up 방식과 일반적인 것부터 물어나가는 Top-down 방식이 있다.
물론 상황에 맞게 적절하게 구체적 질문과 일반적 질문을 섞어가며 해도 된다.
인터뷰 대상자를 고르고 -> 인터뷰 질문을 선정하고 -> 인터뷰를 준비하고 -> 진행하고 -> Post-interview를 진행한다.
인터뷰 진행 후 48시간 이내로 인터뷰 내용을 종합해 보고서를 작성해야한다. 이후 인터뷰 대상자에게 종합본을 발송해서 확인을 옳게 정리됐는지 확인을 받으면 된다.(추가 궁금증 등도 해결)
잘못된 점이 있다면 수정하거나 사후 인터뷰를 추가 진행한다.
2. Joint Application Development (JAD)
그냥 한꺼번에 여러명을 모아서 requirements 수집을 진행하는 것이다.
user를 대상으로 requirements를 수집하는데, 서로 말이 맞지 않을 수 있기 때문이다.
온라인상에서 익명으로 진행할 수도 있다.
준비를 철저히 해야한다. user들이 document나 manual을 가져오도록 해야할 수도 있다.
3. Questionnaires (설문지)
미리 작성된 질문지를 통해 정보를 수집하는 방법이다.
대상자가 많거나, 조직 밖의 고객 등이 대상일때 사용한다. 정보와 의견이 모두 필요할때 사용해도 좋다.
종이로해도되고 전자설문을 활용해도 된다. 보통 종이설문 응답률은 50%미만이고, 전자설문은 30%미만이다.
4. Document Analysis
해당 system을 개발하며 작성하는 document를 분석해 as-is system을 이해한다.
추가로 reports라던가 user가 작성한 다양한 서류 자료 또한 분석한다.
이를 통해 requirements를 찾는 것이다.
5. Observation (관찰)
users나 managers도 모든걸 다 기억하지 못할 수 있다. 그래서 우리가 직접 관찰하여 requirements를 수집할 수 있다.
하지만 사람이란게 관찰당하면 행동이 바뀔 수 있어서, 최대한 방해하지 않고 영향이 없도록 해야한다.
주기적 활동을 놓치지 않도록 조심해야한다.
Text Analysis
위와 같이 requirements를 수집하고나서 이를 분석하는 한 기술이다.
requirements는 문장으로 표현되기 때문에, 여기서 중요한 명사/동사 등을 추려내는 과정이다.
OO 관점에서 보자면 이렇게 분석했을때 무엇을 class로 만들어야할지 대충 보이고, class간의 관계도 보인다.
이렇게 추려낸 class들은 Taxonomic analysis를 이용해 관계를 표현할 수 있다.
"a kind of", "a part of", "a cause of", ... 등등 각 class와 class들 간의 관계를 표현하여 설계를 돕는다.
주목해야하는 관계들은 ppt ch3 p.19에 universal semantic relationships로 정리돼있다.
Requirements Definition (요구사항 정의)
Functional Requirements와 Non-functional Requirements로 나눠서 작성하는 것이다.
각 requirements는 우선순위대로 작성해야하며, 이후 작업을 위한 추가 정보도 담고 있어야한다.
또한 scope도 기술해야하는데, 작업의 범위를 말하는 것이다. 모든 요구사항을 구현하기에 어려움이 있을때 우선순위에 맞게 어디까지 하겠다고 기술하는 것이다.
Non-functional Requirements란, user가 요구하는 기능 외의 요구사항을 말한다.
이런건 굳이 말하지 않더라도 설계자가 알아서 질문하거나 찾아서 작성해야한다.
예를들어 어떤 OS에서 실행될 프로그램인지, back up이 필요한 프로그램인지, performance는 어느정도 기대하는지, 보안수준은 어떻게 해야되는지, 문화/정치적으로 문제될게 있는지 등등..
해당 system 본연의 기능 외 다른 기능들을 말한다. (자세한 예시는 ppt ch3 p.22)
Functional Requirements란, user에게 답을 들을 수 있는 system이 갖춰야하는 요구사항을 말한다.
정리하자면, requirements-gathering techniques 등으로 세부사항을 수집하여, 기능적/비기능적 요구사항으로 분리해 작성한다.
우선순위가 있어야하며, 이 프로세스를 통해 계속해서 analysis를 해나간다.
scope를 조심해야한다. 꼭 scope 내에 있을 필요가 없는 기능은 나중에 추가되도록 작성해둔다.
User storeis
주로 Agile에서 사용하는 requirements 분석 기법이다.
user에게 특정 format을 작성하도록해 거기서 requirements를 뽑아내는 것이다.
참고로 agile에선 requirements를 물을 수 있는 사용자가 항상 곁에 있다고 생각하고 진행한다.(빠른 진행)
(예시는 ppt ch3 p.25)
The System Proposal
planning & analysis의 모든 요소들을 합친 document(?)이다.
바쁜 경영진들에게 제출할때 주로 사용되는 정리본이다.
The system request
The workplan
The feasibility analysis
The requirements definition
Current models of the system (완성본이 아님)
- Functional model (ch4)
- Structural model (ch5)
- Behavioral model (ch6)
위 사항들이 모두 들어간다.
(배운건 아직 requiremnets definiton밖에 없음.. 왜냐면 그 위에 놈들은 planning 단계인데 그건 건너뛰었으니 없고, 뒷부분은 앞으로 배울 내용들. 어쨌든 저놈들을 모두 종합한 것이 system proposal이란 것만 일단 알고가자.)
'수업 > Software Design' 카테고리의 다른 글
| [Software Design] Behavioral Modeling (0) | 2022.10.19 |
|---|---|
| [Software Design] Structural Modeling (0) | 2022.09.27 |
| [Software Design] Business Process and Functional Modeling (1) | 2022.09.15 |
| [Software Design] System Development Life Cycle(SDLC) (0) | 2022.09.07 |
| Object-Oriented Systems의 기본 특징 (3) | 2022.09.07 |