요구사항은 제품이 수행해야 할 기능을 정의하며, 프로젝트 실행 결과에 대해 문서화된 기대치를 의미한다. 이 문서는 프로그램, 그 기능, 그리고 프로젝트 전체에 대한 고객과 개발자 양측의 기대를 포착한다. 요구사항은 특성, 비용, 일정, 위험을 포괄한다. 따라서 요구사항이란 개발해야 할 대상에 대한 진술, 즉 프로젝트 실행 결과로 얻고자 하는 바에 대한 정확하고 정량적인 기술이라 할 수 있다. 부실한 요구사항 정의는 프로젝트 수행 중 발생하는 문제의 주된 원인이다.
요구사항은 무엇을 해야 하는지, 얼마나 잘해야 하는지, 어떤 제약조건 하에서 수행해야 하는지를 명시한다. 요구사항이 잘못되면 프로젝트와 제품 역시 결함을 갖게 된다. 요구사항, 제약조건, 그리고 가정은 문제를 여러 부분으로 나눈다. 이는 프로젝트의 전반적인 성공 여부를 좌우한다.
요구사항의 유형:
- 기능 요구사항은 특정 시스템 요소가 수행해야 할 기능을 정의한다.
- 성능 요구사항은 시스템이 수행하는 해당 기능들의 정량적 매개변수를 정의한다.
- 제약 요구사항은 운용 방식의 한계, 환경 조건, 안전성 고려사항, 또는 규제 준수에서 비롯된다.
- 검증 요구사항은 시스템이 실제 운용 환경에서 명시된 특성을 갖추고 있다는 확신을 제공한다.
- 인터페이스 요구사항은 모든 인터페이스의 기능, 특성, 허용오차, 제약조건을 정의한다.
- 운용 요구사항은 시스템의 운용 준비태세를 명시하며, 시스템 성능에 초점을 맞추는 동시에 시스템이 사용자와 상호작용하는 방식도 정의한다.
영어권 문헌에서는 좋은 요구사항의 특성을 기억하기 위해 SMART라는 약어를 사용한다.
- Specific(구체성) — 요구사항은 프로젝트의 한 가지 특징이나 시스템의 한 가지 특성만을 다루어야 한다. 무엇을 해야 하며 얼마나 잘해야 하는지의 관점에서 서술되어야 하며, 어떻게 해야 하는지와 같은 가능한 해결책의 관점에서 서술되어서는 안 된다.
- Measurable(측정가능성) — 측정 가능한 매개변수는 객관적이고 정량적으로 표현된다.
- Achievable(달성가능성) — 요구사항은 합리적인 비용으로 기술적으로 달성 가능해야 한다.
- Relevant(관련성) — 요구사항은 선택된 시스템 수준에 부합해야 한다.
- Traceable(추적가능성) — 하위 수준의 요구사항은 상위 수준의 요구사항으로부터 명시적으로 파생되고/또는 뒷받침되어야 한다. 상위 요구사항이 없는 요구사항은 《고아》 요구사항으로 간주되며, 그 이행 필요성을 평가받아야 한다.
필요성. 어떤 요구사항이 필요한지 의문이 든다면 다음과 같이 자문해보라: 《이 요구사항을 목록에 포함하지 않으면 시스템에 어떤 해가 발생하는가?》 답을 찾을 수 없다면 그 요구사항은 아마도 불필요한 것이다.
검증가능성. 요구사항이 정식화되는 즉시, 이를 어떻게 검증할 수 있는지 결정해야 한다. 이를 위해서는 적절한 준수 기준을 선정해야 한다.
달성가능성. 달성 가능하려면 요구사항은 주어진 일정과 예산 내에서, 추가적인 제약조건을 전제로 기술적으로 실현 가능해야 한다. 요구사항의 기술적 실현 가능성에 불확실성이 있다면 적절한 연구나 추가 조사를 수행해야 한다. 그 이후에도 불확실성이 남아있다면, 요구사항이 아니라 목표를 정식화해야 한다. 요구사항이 기술적으로 실현 가능하더라도 비용, 일정, 또는 중량과 같은 다른 제약조건 때문에 달성 불가능할 수 있다는 점은 분명하다. 달성이 불가능한 것에 대해 요구사항을 정식화하는 것은 무의미하며, 실용적인 태도를 취해야 한다.
명료성. 각 요구사항은 하나의 아이디어만을 표현해야 하며 간결하고 단순해야 한다. 요구사항이 명확하고 모호하지 않은 것이 중요하다. 좋은 요구사항은 대개 단순한 문장이면 충분하다.
요구사항은 긍정적인 방식으로 진술되어야 하며 결코 부정형으로 시작해서는 안 된다. 문법적으로 정확해야 하며 오탈자와 누락이 없어야 한다. 시스템의 모든 수준에서 일관된 용어를 사용해야 한다.