[Software Engineering] Software Requirements

What are requirements?

- 시스템에 의해 제공되는 서비스와 운영 제약 사항을 기술한 것

- Requirements engineering이란 그런 서비스와 제약사항을 찾아내고, 분석하고, 문서화하는 것이다.

 

Classifications of Requirements

- Functional Requirements: 시스템이 제공해야 하는 서비스와 특정 입력에 대해 시스템이 반응하는 방식, 그리고 특정 상황에 시스템이 동작해야 하는 방식을 기술한 것.

 

- Non-functional Requirements: 시스템이 제공하는 서비스나 기능에 대한 제약사항. 비기능적 요구사항은 시간적 제약, 개발 프로세스에 대한 제약과 표준에 의해 지켜야 하는 제약 등을 포함. 개별적인 시스템 특징이나 서비스보다는 전체 시스템에 적용되는 경우가 많다.

1. Product requirements: 소프트웨어 런타임 동작에 대한 명세나 제약을 작성한 것.

2. Organisational requirements: 고객과 개발자 조직의 정책이나 절차로부터 얻은 넓은 범위의 시스템 요구사항.

3. External requirements: 시스템과 개발을 위한 프로세스의 외부 요소로부터 얻는 모든 요구사항을 광범위하게 포함.

Non-functional Requirement는 검증, 테스트하기 애매하고, 수치적, 정량적 판단이 어렵다.

 

- User requirements: 시스템이 사용자에게 제공해야 할 서비스와 동작하면서 준수해야 할 제약사항들에 대해 자연어와 다이어그램으로 기록한 문장.

- System requirements: 소프트웨어 시스템의 기능, 서비스와 동작 중 제약사항에 대한 보다 상세한 설명. 시스템 요구사항 문서(기능 명세)는 무엇을 구현해야 할지에 대해 정확하게 정의해야함.

 

Requirements Specification Language

- Natural language-based specification: 표현력이 풍부하고, 직관적이고 보편적인 반면, 애매하고 모호하며 읽는 사람의 배경에 따라서 다르게 해석될 여지가 있다.

- Form-based specification: 아래와 같이 표준 양식을 사용하여 요구사항을 명세하는 것인데, 깔끔하긴 하지만 유연성이 떨어진다.

 

- Tabular specification

 

- Graphical specification: 시스템 전체가 한 눈에 잘 들어온다.

 

- Formal specification: 자연어에서 나타나는 모호성이 줄어들고, Requirement에서 모순의 유무를 확인할 수 있으며, 코드로 생성할 수 있다. 그러나 작성하기 어려운 단점이 있다.

 

Guidelines for Requirements Specification

Natural Language의 단점: 명료하지 못함. 요구사항이 애매모호함. 비슷한 것들이 중복되어 있음.

- Unambiguity: 부정확하고 모호한 요구사항은 소프트웨어 공학 문제의 원인이 된다.

- Complete: 빠진 것도 없고 겹치는 것도 없어야 한다.

- Consistent: 모순, 모호성이 없도록 일관성이 있어야한다.

- Testability: 검증/검사 가능해야한다.

- Documentation: 요구사항은 문서화 가능해야하고, 이는 사용자 요구사항과 시스템 요구사항의 명세/정의를 반드시 포함해야한다. 이는 디자인 설계 문세는 아니므로 어떻게 시스템이 어떻게 작동하느냐보다는 무엇을 해야하는가에 초점이 맞추어져 있어야 한다.