소프트웨어 공학 - OOLC (Object-Oriendted Software Life Cycle) 요구사항 모델링
요구사항 모델링
1. 요구사항
OOLC 뿐 아니라 SDLC의 첫 시작도 요구사항이 뭔지 찾는 것이다.
그리고 실제 개발할때도 이 요구사항에 대해서 확실하게 하고 가는 것은 매우 중요하다.
그렇다면 요구사항이란 뭘까?
몇몇 곳에서 정의한 요구사항에 대한 정의를 가져왔다.
Webster’s Ninth New Collegiate Dictionary : “Something required; something wanted or needed”
IEEE Standard 729 : “a condition or capability need by a user to solve a problem or achieve an objective.”
우리말 샘 : “명확하거나 시험이 가능하거나 측정이 가능한, 제품 또는 프로세스의 운영과 기능, 설계상의 특징이나 제약에 관련된 항목들을 이르는 말. 제품이나 프로세스의 수용 가능성을 위하여 필요한 것이다.”
위의 말들은 다 어느정도 맞다고 생각한다. 하지만 한마디로 줄이자면 역시 필요한 것에 가깝다고 생각한다.
이러한 요구사항에 대해서 제대로 정의해두지 않는다면 많은 문제가 생기는데 프로젝트의 실패원인 대부분이 요구사항과 관련있기 때문이다. 아래의 표는 프로젝트가 실패하는 원인에 대해 %로 정리해 둔 것이다.
| Causes for Failed Projects | Percentage |
| 사용자 입력의 부족 | 12.8% |
| 불완전한 요구사항 | 12.3% |
| 요구사항 변경 | 11.8% |
특히 초반 부에 이 요구사항에 대한 정의를 제대로 하지 않는다면 테스트까지 갔을 때 수정 비용은 더욱 증가한다.
아래의 표는 각 단계별에서 오류 수정시 드는 상대적인 비용에 대해 서술해둔 표이다.
| Project Stage | Relative Repair Cost |
| Requirements | 1-2 |
| Design | 5 |
| Coding | 10 |
| Unit Test | 20 |
| System Test | 50 |
| Maintenance |
2. Use-Case diagram
요구 사항에 대해 정의를 했다면 Use-case diagram을 그려보는 것이다.
이 다이어그램을 그리려면 먼저 Actor를 식별 하고, Use case를 확인한 다음에 시스템 경계를 설정하고 Actor와 Use case, Use case와 Use case 간의 관계를 정의한다. 일단 Actor와 Use case가 시스템 경계는 어떻게 설정하는지 관계 정의는 어떻게 하는지 순서대로 알아보자.
1) Actor
시스템 밖에서 시스템과 상호작용하는 누군가 혹은 무언가를 말한다 (Someone/something outside the system that interacts with the system)
다이어그램에서는 아래와 같이 철사인간으로 그린다.
2) Use Case
액터가 시스템을 사용하여 하려는 작업을 말한다.
(What an actor wants to use the system to do)
다이어그램에서는 아래와 같이 타원형으로 그리고 중앙에 기능을 기재하며 일반적으로 동사 + 명사(또는 명사구)형태로 작성한다.
3) 시스템 경계
시스템의 내부 기능과 외부 요소를 구분하는 선이다. 일반적으로 사각형으로 그리며 Use case가 배치되는 곳이다.
만약 다수의 모듈로 이루어진 시스템이라면 각 모듈이 시스템 경계가 될 수 있다.
4) 관계 정의
Actor와 Use case의 관계는 아래와 같은 타입으로 표현한다.
| 관계유형 | 설명 | UML 표기 |
| 연관 (Association) | 액터와 유스케이스 간의 기본적인 상호작용 관계 | 직선 |
| 포함 (Include) | 한 유스케이스가 항상 다른 유스케이스를 호출해야 할 때 사용 | 점선 + <<include>> |
| 확장 (Extend) | 특정 조건이 있을 때만 선택적으로 다른 유스케이스가 수행되는 경우 | 점선 + <<extend>> |
| 일반화 (Generalization) | 액터나 유스케이스가 상속 관계에 있을 때 사용 | 직선에 삼각형 화살표 |
※ Use case diagram 예시
간단한 TO-DO 프로그램을 만든다고 생각해보자.
기능은 최대한 간단하게 로그인과 todo 생성, 변경, 확인, 삭제만 있다. 이 시스템에 대한 Use case를 만들어보겠다.
3. Use-Case description
위의 Diagram 만으로는 요구사항에 대해서 전체 파악이 힘드므로 설명을 포함한 형태이다.
대략적인 구조는 아래와 같다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Use Case Name : (Use case에 따른 기능 이름)
Summary : (Use case에 따른 기능에 대한 간략한 설명)
Actor : (해당 Use case와 상호작용하는 Actor의 이름)
Dependency : (해당 Use case에 연결된 다른 Use case)
Precondition : (해당 Use case의 기능이 동작하기 위한 선행 조건)
Description :
(문제 없이 실행되었을때의 순서 1,2,3 ... 과 같이 번호를 단다.)
Alternatives :
(예외나 별도의 분기가 발생했을때의 순서, 발생한 번호에 세부 번호를 달아서 표기한다.)
Postcondition :
(성공 했을 때와 실패했을 때 이후 상태에 대해서 기재한다)
※ 예시
위 TO-DO 프로그램의 Create To-do 기능을 예시로 써보자면 아래와 같다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Use Case Name : Create To-do
Summary : To-do를 만든다.
Actor : 프로그램 사용자
Dependency : <<include>> Authenticate User
Precondition : 프로그램이 켜져있어야 한다.
Description :
1. 시스템이 로그인 화면을 띄운다.
2. 프로그램 사용자가 로그인을 한다.
3. 시스템은 <<Authenticate User>>를 수행하여 프로그램 사용자를 인증한다.
4. 시스템은 Todo 리스트를 출력한다.
5. 프로그램 사용자는 create to-do 버튼을 클릭한다.
6. 시스템은 create to-do가 가능한지 여부를 체크한다.
7. 시스템은 create to-do 모달 화면을 표시한다.
8. 프로그램 사용자가 생성할 to-do 내용을 기재하고 추가 버튼을 누른다.
9. 시스템은 to-do 내용을 저장한다.
10. 시스템은 Todo 리스트를 출력하는 형태로 복귀시킨다.
Alternatives :
3a. 사용자 인증에 실패한다.
3a1. 시스템은 인증 실패 사실을 프로그램 사용자에게 알린다.
3a2. 흐름은 1단계로 돌아간다.
8a. 프로그램 사용자가 todo 생성 취소를 요청한다.
8a1. 시스템은 Todo 리스트를 출력하고 프름은 4로 돌아간다.
8b. todo의 입력 가능 범위를 넘어섰다.
8b1. todo를 생성할 수 없음을 프로그램 사용자에게 알린다.
8b2. 흐름은 7로 돌아간다.
Postcondition :
성공 시, 시스템은 todo 내용을 저장하고 todo 리스트에 반영한다.
실패 또는 취소 시, 시스템은 todo 내용을 저장하지 않으며 todo 리스트의 상태도 변경하지 않는다.
※ 추가 업데이트 및 검증 예정이다.
참고 자료
- H. Gomaa, “Chapter 6 - Designing Concurrent, Distributed, and Real-Time Applications with UML”, Addison Wesley Object Technology Series, July, 2000
- 시스템 분석 및 설계 - 2-2. 유스케이스 표기법
원문 참고 자료
- J. Rumbaugh et al, “Object-Oriented Modeling and Design”, Prentice Hall, 1991
- I Jacobson et al, “Object-Oriented Software Engineering”, Addison Wesley, Reading MA, 1992.