시스템 요구사항
시스템이 제공해야 하는 서비스들과 그 서비스들이 동작에 관한 제약을 기술한 것
요구공학(RE)
서비스와 제약사항들을 찾고, 분석하고, 문서화하며 점검하는 프로세스
요구사항
- 사용자 요구사항
시스템이 사용자에게 제공해야 할 서비스와 동작하면서 준수해야 할 제약사항들에 대해
자연어와 다이어그램으로 기록한 문장 - 시스템 요구사항
소프트웨어 시스템의 기능, 서비스와 동작 중 제약사항에 대한 보다 상세한 설명
Fuctional and Non-Functional Requirements
- 기능적 요구사항
시스템이 제공해야 하는 서비스와 특정 입력에 대해 시스템이 반응하는 방식,
그리고 특정 상황에 시스템이 동작해야 하는 방식을 기술한 것
기능적 요구사항은 시스템이 무엇을 해야 하는지를 설명
기능적 요구사항은 시스템 개발자를 위해 사용자 요구사항을 확장해서 작성
Mentcare 시스템에 대한 기능적 요구사항
1. 사용자는 모든 클리닉에 대한 예약 리스트를 검색할 수 있어야 한다.(사용자 요구사항)
2. 시스템은 매일 각각의 클리닉에 대해 당일 예약에 맞추어 참여할 것으로 예상되는 환자의
리스트를 보여줄 수 있어야 한다.(시스템 요구사항)
3. 시스템을 사용하는 각 스탭 멤버는 8자리 숫자의 직원번호로 유일하게 구분할 수 있어야 한다.(시스템 요구사항) - 비기능적 요구사항
시스템이 제공하는 서비스나 기능에 대한 제약사항
시스템이 사용자에게 제공하는 특정 서비스나 직접적으로 관련되지 않은 요구사항
신뢰성, 응답시간과 메모리 사용과 같은 시스템 속성과 관련되는 경우가 많음
비기능적 요구사항의 종류
- 제품 요구사항(사용성, 효율, 확실성, 보안 요구사항)
- 조직 요구사항(환경, 운영, 개발 요구사항)
- 외부 요구사항(규제, 윤리적, 법률적 요구사항)
시스템에서 가능한 비기능적 요구사항
1. 제품 요구사항
Mentcare 시스템은 정규업무시간(월~금,08:30~17:30) 동안 모든 클리닉에서 사용할 수 있어야 한다.
정규업무시간중 고장시간은 어떠한 날이든 5초를 넘어서는 안 된다.
2. 조직 요구사항
Mentcare 시스템의 사용자는 보건 신분 카드로 사용자의 신분을 확인할 수 있어야 한다.
3. 외부 요구사항
시스템은 Hstan-03-2006-priv 에서 설정한 환자 사생활 보호 체계를 구현해야 한다.
요구공학 프로세스(Requirements Engineering Processes)
요구사항을 분석한 뒤 명세화하고 , Feasibility study - 타당성 확인
명세화한 후 문서화를 한다.
요구사항 가지고 프로토타입을 만든다.
요구사항 도출(Requirements Elicitation)
- 인터뷰
사람들이 무엇을 하는지에 대해 이야기를 나눈다. - 관찰 또는 문화기술적 연구(ethnography)
일을 하는 사람들의 모습을 지켜보고 사람들이 무엇을 사용하는지, 어떻게 사용하는지 등을 살핀다. - 문화기술적 연구
동작 프로세스를 이해하고, 이 프로세스를 지원하는 소프트웨어에 대한
요구사항을 얻기 위해 사용하는 관찰 기법 - 사용자 스토리(Stories)
애자일 기법에서 사용하는 사용자 스토리는 실제로는 요구사항을 도출하는 데 도움을 주는
일반적 스토리보다는 대화식 시나리오에 가깝다. - 시나리오(Scenarios)
시나리오 도출 과정 동안 상세한 내용들을 추가함으로써 보다 완전한 형태의 상호작용을 작성한다.
요구사항 명세화(Requirements Specification)
시스템 요구사항을 작성하기 위한 표기법(Notation)
- 자연어 문장 : 요구사항을 작성할 때 번호를 붙인 자연어 문장으로 작성한다.
각 문장은 하나의 요구사항을 나타내야 한다.
- 구조적 자연어 : 표준 양식이나 탬플릿에 따라 자연어로 요구사항을 작성한다.
각각의 필드는 요구사항의 한 양상에 대한 정보를 제공한다.
- 그래픽 표현 : 문자 표기법으로 보충한 그래픽 모델로 시스템의 기능적 요구사항을 정의한다.
UML(Unified Modeling Language) 유스케이스 다이어그램과 시퀀스 다이어그램을 사용한다.
- 수학적 명세 : 이 표기법은 유한-상태 머신이나 집합 같은 수학적 개념에 기반하고 있다.
비록 이러한 분명한 명세는 요구사항 문서의 모호성을 줄여줄 수 있지만, 고객들은 대부분
정형적 명세를 이해하지 못한다. 고객들은 그 정형적 명세가 원하는 바를 표현하고 있는지
확인하지 못하기 때문에 그 내용을 시스템 계약으로 채택하는 데 주저하게 된다.
유스케이스(Use cases)
그래픽 모델과 구조적인 글을 이용하여 사용자와 시스템 사이의 상호작용을 설명하기 위한 방법
Objectory기법에서 처음 사용
유스케이스 다이어그램을 이용하여 문서화
actor는 사람, 기계, 시스템 중 하나가 될 수 있다.
actor가 사용하는 기능만 연결한다.
소프트웨어요구사항명세서(SRS : Software Requirements Specification)
요구사항 검증(Requirements Validation)
요구사항이 고객이 원하는 시스템을 제대로 정의하고 있는지를 점검하는 과정
시스템 변경을 통해 요구사항 문제를 수정하는 비용은 대부분 설계나 코드 오류의 경우보다 훨씬 높다.
- 요구사항을 변경하게 되면 시스템 설계와 구현도 변경되어야 한다.
- 시스템을 다시 테스트해야 한다.
요구사항 점검(Requirements checking)
1. 유효성 점검
- 요구사항이 시스템 사용자의 실제 요구를 반영하는지를 점검
2. 일관성 점검
- 명세서상의 요구사항은 서로 상충되지 않아야 함
3. 완전성 점검
- 요구사항명세서는 시스템 사용자가 의도한 모든 기능과 제약을 정의하는 요구사항을 포함해야 함
4. 실현성 점검
- 기존 기술의 지식을 사용해서 시스템에 대한 주어진 예산으로 실제로 구현이 가능한지를 점검
5. 검증가능성
- 고객과 계약자 사이의 분쟁 가능성을 줄이기 위해, 시스템 요구사항은 문서로 작성해서 검증 가능해야 함
요구사항 변경(Requirements Change)
대규모 소프트웨어 시스템에 대한 요구사항은 항상 바뀜
시스템을 설치하고 주기적으로 사용하기 시작하면, 새로운 요구사항이 나타날 수 밖에 없음
시스템 요구사항에 대한 대부분의 변경은 시스템에 대한 비즈니스 환경 변화 때문에 발생
요구사항 관리 계획
1. 요구사항 식별
2. 변경 관리 프로세스 - 변경에 대한 영향과 비용을 평가하는 활동
3. 추적가능성 정책 - 각각의 요구사항 사이 또는 요구사항과 시스템 설계 사이의 관계를 정의
4. 도구 지원
'Software Engineering' 카테고리의 다른 글
| Architectural Design (0) | 2019.04.20 |
|---|---|
| System Modeling (0) | 2019.04.20 |
| 애자일 개발 기법 (0) | 2019.04.17 |
| Agile software development (0) | 2019.04.17 |
| Software process (0) | 2019.04.17 |
