[소프트웨어 공학] 6. Requirement Analysis & Specification

※ Feasibility Study

Evaluation in Feasibility Study
Benefits	New or improved capabilities, Efficiency of operations,   Accuracy, Timeliness of decisions, Cost savings
Cost	Hardware, Software, Operational costs (maintenance),   Client's personnel (During development), Changeover to new system
Alternatives	benefit/cost analysis on each, Tradeoffs explicit, Alternatives versus benefit/cost

Kinds of Feasibility
Economic	Does the benefit/cost analysis justify the project?  - 이익과 비용의 측면
Technical	Are there limits of theory or technologgy applicable to the project?   - 기술적으로 한계가 있는지?
Schedule	Can the project be completed on time with available staff and resources?  - 주어진 인력과 자원으로 가능한지?
Operational	Is the client staff technically able to operate the project?   - 주어진 인적 자원으로 기술적으로 수행가능한지?
Motivational	Is the client staff motivated to perform the necessary steps correctly and promptly?   - 실무자 관점에서도 쓸모가 있는지?
Legal & Ethical	Do any infringements or liability arise from this project?   - 정책적인 측면

※ Information (Requirements) Gathering

- Interviewing

- Documents

- Joint Application development

- Questionnaires

- Observation

Interview Process

Before interview	인터뷰 계획수립 - 토픽을 정함, 질문 정리, 팀원 구성, 고객 비즈니스 이해, 고객 조직 이해
During interview	최대한 고객의 의견을 끌어낼 수 있도록 질문은 짧게 진행한다.
After interview	노트 기록 및 요약

※ Requirements Description

Requirements

- a statement of what the system must do or what characteristic it must have. - 시스템이 정확히 무엇을 하는지 명시

- can be changed over time as moves from analysis to design

- can be either functional requirements or nonfuncitional requirements

- Incorrect specification is major reason for project's failure. - 요구사항 명세가 정확하도록 해야 한다.

- Late discovery of problems is costly. - 나중에 발견되는 문제일수록 큰 비용이 발생한다.

Functional requirements	directly related to a process the system has to perform.  Functionality : What the system should do? 시스템이 수행해야할 기능  Data : input and/or output data, their formats - 데이터 포맷  Users : persons who use or manage the system - 사용자가 누구인지?
Nonfunctional requirements	behavioral properties that the system must have, such as performance  Operational requirements   Resource requirements - 자원  Performance requirements - 성능  Security requirements - 보안  Culture and political requirements - 정책  Quality requirements - 품질
Interface requirements	User Interface  Other existing system - 다른 시스템과 연동

※ Specification Qualities

Correct	모든 요구사항이 포함되었는지, 그리고 정확해야 한다.
Unambiguous	모든 요구사항은 모든 사람이 한가지 의미로 해석될 수 있도록 명확해야 한다.
Complete	시스템의 모든 상황에 대한 응답이 정의되어야 한다.  모든 페이지가 넘버링 되어야 하며 모든 사진 및 테이블이 넘버링, 이름이 있어야한다  "To Be Determined" (TBD)가 없어야 한다.
Consistent	요구사항이 복잡하지 않고 명확하게 이해할 수 있어야 한다.  일관성있는 단어를 사용해야 한다. (같은 단어는 같은 의미로 사용되어야 한다)
Understandable by customer	Requrements Specification은 고객도 이해할 수 있어야 한다.
Modifiable	Section이 잘 나뉘어져 있어 수정하기도 쉬워야 한다.
Traceable	individual requirement가 추적가능 해야 한다. (Traceability Matrix 작성해야 한다)

요구사항 명세서가 중요한 이유.

요구사항 또는 명세서 자체가 잘못된 경우 다음 단계에 진행되는 과정에서 문제가 발생하고, 그 문제만큼 비용이 크게 증가한다.

따라서 정확히 파악한 요구사항이 정확하게 명세서로 작성될 경우 프로젝트의 변경이 적고 시간소모도 적다.

※ Methods for Requirements Analysis & Specification

Structured Analysis	Popular in the late 1970s and 1980s  Focused on the data and the functional processes - 데이터와 기능 관점  Representative methodologies  - SA / SD : Structured Analysis and Structured Design  - CODART : Concurrent Design Approach for Real-Time system.
Object-Oriented Analysis	Popular in the early 1990s  Focused on the classes which contain the attributes and operation - 객체 관점  Representative methodologies  - OMT : Object Modeling Method  - COMET : Concurrent Object Modeling Method  - OCTOPUS  - ESUML : Embedded Software modeling with UML 2.0
Information Engineering	Popular in the late 1980s  Focused on the data and transactional process - 데이터와 트랜잭션 관점  Representative methodologies  - Information Engineering
Formal Methods	Focused on the events, the system states and states transitions - 이벤트 관점  Representative techniques  - Petri Net modeling approach  - Z notation  - SDL : Specfication and Description Language (Activity Diagram와 비슷)  - Statechart

Structured Analysis

여러가지 분석법 중 구조적 분석방법을 정리합니다.

※ Structured Analysis : Overview

Structured Analysis	From the general idea of the system under construction, structured analysis build models to describe what the system should do.
Objective	Decompose the system into less complex pieces that are easier to design  - 시스템들을 분할하여 복잡하지 않은 형태로 설계를 진행한다.
Notions	Modularity  기능을 분해할 경우 설계에서 좋은 모듈화단계를 얻을 수 있다.  Stepwise refinement  높은 단계의 추상화를 점진적으로 분해하기 시작하면서 단계별로 낮은 단계의 추상화로 표현하여 시스템의 상세한 부분을 기술할 수 있다.

※ Structured Analysis : Overall Process

1. Brain storming on the problem and establish the problem statement that describes the key requirements.

2. Identify the events accepted or generated by the system. (And record the results on the Event Table)

3. Draw a System Context Diagram

4. Decompose diagrams to capture the details as required to describe what the system should do.

 (And record the results on the corresponding Data Flow Diagram)

5. Describe the internal behavior of each bubble at the Process Specification.

6. Define input/output specification of each bubble at the Data Dictionary.

System Context Diagram	시스템을 한 눈에 볼 수 있도록 Data Flow를 그림으로 표현한다.
Event Table	다음 내용을 테이블 형식으로 작성한다.  Intent  Contents  Cycle : Periodic or aperiodic  Required response time
Data Flow Diagram	System Context Diagram를 분해하여 정해진 Symbols 과 Terminator 등을 이용하여  Data Flow와 Control Flow를 그림으로 표현한다.  이때 Naming, Numbering (레벨과 분해되기전 어떤 function인지),  Input/Output Preservation rule (입출력 일관성) 등을 주의한다.
Data Dictionary	Contains the definitions of all data mentioned.  DFD 나 PSPEC 등에서 표현된 모든 데이터에 대하여 정의해야 한다.
Process Specification	Bubbles at lowest level need to be specified.  1. Mini-Spec: 최하위 DFD의 기능을 슈도코드로 작성한다.  2. Decision Table : Condition and Action Table 작성.

이 외에 좀더 복잡한 로직을 갖고 있다면 State Transition Diagram(STD)를 추가적으로 작성한다.

Contents of SRS
1. Introduction

 - Purpose of this document

 - Project overview

 - Related documents, terms, abbreviations

2. Requirements

 - Data flow diagram

 - Data dictionary

 - Process spec (Mini-spec)

 - Other functional Characteristics

3. Other Requirements or Constraints

 - Performance requirements

 - Hardware requirements

 - Exception handling

 - User interface constraints

 - Other constraints

4. Acceptance Criteria

 - Functionality test criteria

 - Performance test criteria

5. Others 

 - Considerable issues

6. Traceability Analysis

 - Traceability matrix

7. References and Appendix

소프트웨어 개발에 있어서 객체지향 분석 또는 구조적 분석 등 methodology를 선택하는 기준은 무엇인가?

회사의 방침 또는 프로그래머의 스킬, 구현 언어, 개발 분야 등에 따라서 적합한 방법론을 선택한다.