기능적 또는 비 기능적 요구 사항?

기능적 또는 비 기능적 요구 사항이 궁금합니다. 해당 용어에 대해 여러 가지 다른 정의를 찾았으며 요구 사항 중 일부를 적절한 범주에 할당 할 수 없습니다.

일부 작업과 관련이 없거나 추가 조건이있는 요구 사항이 궁금합니다. 예를 들면 다음과 같습니다.

1. 선택한 장치 목록에서 장치를 반복 할 수 있습니다.
2. 데이터베이스는 100 개 이상의 항목을 포함해야합니다
3. 일부 가치의 통화는 USD 달러 여야합니다.
4. 장치의 이름과 전력 소비량은 와트 단위 여야합니다.

이러한 요구 사항은 기능적 또는 비 기능적입니까?

기능적 요구 사항 은 시스템 또는 응용 프로그램이 수행 할 작업을 정의 합니다 . 특히 외부 상호 작용 (사용자 또는 다른 시스템과의 컨텍스트)에서 발생합니다.

새로 주문할 때 시스템은 총 비용을 표시하고 사용자의 확인이 필요합니다. 기능적인 요구 사항입니다. 시스템 의 기능 을 설명 합니다.

자세한 내용은 Wikipedia : Functional Requirement 를 참조하십시오.

비 기능적 요구 사항은 시스템의 입 / 출력 동작을 설명 하지 않는 요구 사항입니다 . 우리는 여전히 구현 세부 사항 이 아닌 요구 사항 에 대해 이야기하고 있으므로 "비 기능적"이라는 문구를 사용한다고해서 해당 섹션에 아무 것도 공평한 게임 이라는 의미는 아닙니다 .

가장 일반적인 유형의 비 기능적 요구 사항은 시스템 운영 (가용성, 연속성, DR), 성능 (처리량, 대기 시간, 스토리지 용량) 및 보안 (인증, 권한 부여, 감사, 개인 정보 보호)과 관련이 있습니다.

이것들은 모든 "기능"에 영향을 미치지 만 실제로는 그 자체로 기능하지는 않습니다. 그것들은 기능 메타 데이터와 비슷 하기 때문에 시스템이 원하는 기능을 수행하는지 여부 뿐만 아니라 성능을 설명 합니다. 그래도 그 비유를 너무 많이 들지 마십시오. 단지 비유 일뿐입니다.

비 기능적 요구 사항은 일부 사람들이 제안한 것과는 달리 주관적이거나 수동적 이지 않습니다 . 사실, 그들은 해야 실제로 (더 이상 100 이상 밀리 즉 응답 시간) 그들에 부착 된 하드 메트릭 있습니다. NF 요구 사항은 구현 세부 정보 또는 "ORM 프레임 워크 업그레이드"와 같은 작업이 아닙니다 . 누구나 그 아이디어를 얻을 수있는 단서가 없습니다.

Wikipedia : Non-Functional Requirement에 대한 자세한 내용 .

문제의 예를 구체적으로 설명하려면 다음을 수행하십시오.

1. 선택한 장치 목록에서 장치를 반복 할 수 있습니다.

   • 분명히 기능적 요구 사항. 시스템의 출력 모습을 설명합니다.

2. 데이터베이스는 100 개 이상의 항목을 포함해야합니다

   • 비즈니스 규칙처럼 들리므로 기능적 요구 사항도 있습니다. 그러나 불완전한 것 같습니다. 이 규칙의 이유는 무엇입니까? 데이터베이스에 100 개 미만의 항목이 포함되어 있으면 어떻게됩니까?

3. 일부 가치의 통화는 USD 달러 여야합니다.

   • 기능적 요구 사항이지만 실제로 올바르게 요구되지는 않습니다. 보다 유용한 문구는 다음과 같습니다 . 시스템은 하나의 통화 (USD)를 지원해야합니다. 분명히 둘 이상의 통화를 지원해야하는 경우 수정 될 수 있으며 요구 사항에 통화 변환 등에 대한 정보가 포함되어야합니다.

4. 장치의 이름과 전력 소비량은 와트 단위 여야합니다.

   • 실제로 어떤 종류의 요구 사항이 아니라 기술 사양과 비슷합니다. 전력 정격이 와트로 가정 될 때 기능적 요구 사항이 명시됩니다 . 통화와 마찬가지로 UOM이 두 개 이상인 경우 기능 요구 사항에는 단위 변환, 구성 위치 / 방법 등 (해당되는 경우)에 대한 섹션이 있어야합니다.

Aaronaught는 이미 훌륭한 답변을했지만 기능적 요구 사항이 무엇인지에 대해 완전히 잘못된 다른 답변이 있었기 때문에 비 기능적 요구 사항입니다.

비 기능적 요구 사항은 "제품이 가지고 있어야하는 품질 또는 재산"입니다 ¹. 제임스 테일러는 비 기능적 요구 사항은 "[...]는 요구 사항이며, 고객에게도 중요하며 때로는 기능적 요구 사항보다 훨씬 중요하다"고 말합니다 . 그런 다음 제품 로고와 장비의 정확성 및 신뢰성이라는 두 가지 예를 제시합니다. 이 두 가지 예는 다음과 같이 잘 나타납니다.

• 비 기능적 요구 사항은 "현재 인터넷은 중요하며 웹 사이트를 갖고 싶어합니다"와 같은 마케팅 요술쟁이가 아닙니다.
• 비 기능적 요구 사항은 고객의 생산성과 제품 사용 능력에 큰 영향을 줄 수 있으므로 고객과 관련이 있습니다.
• 비 기능적 요구 사항은 전적으로 객관적입니다.

마지막 요점은 필수적입니다. 요구 사항이 주관적인 경우 요구 사항 목록에서 수행 할 작업이 없습니다. 주관적인 것으로부터 검증 테스트를 구축하는 것은 불가능하다 . 요구 사항 목록의 유일한 목적은 고객의 분명한 기대치를 열거하는 것입니다. "이 정사각형이 빨간색이되기를 원합니다"는 요구 사항입니다. "이 정사각형의 색상이 좋으면 좋겠다"는 설명이 필요한 소원입니다.

요구 사항 목록은 계약과 같습니다 (대부분의 경우 계약의 일부 임). 고객과 개발 회사가 서명 한 것으로 소송의 경우 귀하의 업무가 올바르게 수행되었는지 판단하기 위해 법적으로 사용됩니다. 나를 위해, 당신이 실제로 수행 한 것은 아니기 때문에, 어떻게 내가 당신에게 소프트웨어 제품을 주문하는 경우, 즉 "제품이 큰해야한다"지정하고 제품이 완료되면 지불을 거부 할 좋은 제품?

몇 가지 예를 보도록하겠습니다.

  1. 소프트웨어 제품이 최종 사용자에게 반응합니다.

이것은 요구 사항이 아닙니다. 기능적이지 않습니다. 작동하지 않습니다. 그것은 단지 요구 사항이 아닙니다. 조금도. 값이 0입니다. 유효성 검사 테스트 중에 소프트웨어 시스템이이 요구 사항을 충족하는지 확인할 수 없습니다. QA 부서 나 고객 모두 귀하가 아닙니다.

  2. 사용자 통계 재로드는 100ms 미만의 시간의 90 %를 수행합니다. 부록 G 파트 2에 지정된 성능과 CPU의로드 10 % 미만, 메모리의 경우 50 % 미만, 활성 R / W 디스크 작동이없는 머신에서 테스트 할 때.

요구 사항입니다. 부록 G 파트 2가 충분히 정확하다면, 비슷한 하드웨어를 가진 머신을 가지고 QA 부서에서 검증 테스트를 수행 할 수 있으며, 항상 이진 결과를 얻을 것입니다 : 합격 또는 불합격.

기능적 요구 사항입니까? 번호는 지정하지 않는 어떤 시스템이 수행해야합니다. 소프트웨어 응용 프로그램이 사용자 통계를 다시로드 할 수 있어야한다고 지정하기 전에 기능 요구 사항이 있었을 것입니다.

기능이 필요하지 않습니까? 그것은. 백분율 임계 값이 지정된 경우 제품에 있어야하는 속성, 즉 최대 / 평균 응답 시간을 지정합니다.

  3. 응용 프로그램이 C #으로 작성되었습니다.

이것이 필수 요건입니까? 문맥이 없으면 우리는 정말로 모른다. 나중에 사용 언어에 대해 동료들과 논의하는 것을 피하기 위해이 요구 사항을 삽입하여 원하는 수석 개발자의 소원 일 수 있습니다. 하드웨어 / 소프트웨어, 레거시 또는 호환성 요소를 기반으로하는 요구 사항 일 수도 있습니다. 우리는 모른다.

  4. 제품의 C # 코드베이스는 Microsoft 최소 권장 규칙 및 Microsoft 세계화 규칙을 따릅니다.

이것은 이상한 일입니다. 개인적으로 나는 그것을 요구 사항이라고 부르지 않고 표준과 모범 사례를 지정하는 별도의 문서에 넣습니다.

  5. 응용 프로그램의 기본 창에는 파란색 (# 00f) 10px 테두리가 있고 분홍색 (#fcc)으로 채워진 원이 있습니다.이 원은 테두리의 내부 가장자리에 있고 직경이 3px이며 서로 20px로 구분됩니다.

요구 사항이며 작동하지 않는 요구 사항입니다. 그것은 우리가 검증 테스트 기간 동안 테스트 할 수 뭔가를 지정하고, 그렇지 제품의 속성을 지정 어떤 제품이 수행하도록 구성된다.

  6. 차량 추적 시스템은 ± 0.016mph의 정밀도로 속도를 측정합니다.

또한 비 기능적 요구 사항. 시스템 정밀도의 측정 가능한 임계 값을 제공합니다. 그것은 시스템이 무엇을해야하는지 말하지는 않지만 시스템이 얼마나 정확한지 알려줍니다. 하지만 기다려? 차량 추적 시스템 이 속도를 측정 한다고 알려줍니다 . 기능적인 요구 사항입니까? 글쎄, 우리는 측정의 정확성이 아니라 측정의 정확성에 악센트를두기 때문에.

  7. 차량 추적 시스템은 차량의 속도를 측정합니다.

이제는 기능 요구 사항입니다. 시스템 작동 방식이 아니라 시스템 작동 방식을 알려줍니다. 기능 요구 사항을 통해 차량 추적 시스템이 속도, 배터리 전력, 압력을 측정한다는 사실을 알 수 있습니다. 전등이 켜져 있는지 여부를 알 수 없습니다.

  8. 웹 사이트의 페이지는 850ms가 걸립니다. 로드합니다.

이것은 요구 사항이 아닙니다. 하나가 되려고하지만 완전히 유효하지 않습니다. 이것을 어떻게 자산화 하시겠습니까? 어떤 페이지? 모든? 쿼드 코어 클라이언트 시스템의 로컬 1Gbps 네트워크와 SSD가 2 % 사용 된 8 코어 서버 또는 구식 노트북과 크 래피 랩톱의 모뎀을 통해 테스트되었으며 웹 사이트가 99 %로 사용되는 작은 서버에서 호스팅되고 있음 ? "로드"란 무엇입니까? 페이지를 다운로드한다는 의미입니까? 다운로드하여 표시 하시겠습니까? 큰 데이터와 함께 POST 요청을 보낸 다음 응답을로드하고 표시합니까?

결론적으로, 비 기능 요구 사항은 요구 사항이 대신 말하는 완전히 객관적이고 자동 또는 수동 검증 테스트를 통해 확인 할 수 있습니다 뭔가 설명하는 수단 항상 어떤 시스템이하고있다가, 그것을 설명 하는 방법을 시스템 뭔가하고있다 거나 하는 방법을 시스템이 자체이다 .

^{¹ 정보 기술 프로젝트 관리 : 소프트웨어, 하드웨어 및 통합 이니셔티브에 프로젝트 관리 전략 적용, James Taylor, ISBN : 0814408117.}

기능 요구 사항은 시스템과 상호 작용의 결과를 설명합니다 (어떤 시스템 주어진 상황에서 수행) 동안, 비 기능 요구 사항은 일반적으로 등 성능, 용량, 응답 시간의 세부 ... 기능을 나타내지 않는 것을하는을 말한다 시스템의 프로세스 또는 상호 작용의 결과.

말하지만, 설명하고있는 비 기능적 요구 사항은 실제로 기술 사양의 기능적 요구 사항입니다 (실제로 나쁜 요구 사항이 됨). 귀하의 사건에 대한 비 기능적 요구 사항의 예는 다음과 같습니다.

-주사위 애니메이션이 실행되는 동안 UI를 잠그면 안됩니다.

사용자 요구 사항 은 일반적으로 특정 UI 요구 사항으로, 상황에 따라 기능적 또는 비 기능적이며 시스템 요구 사항 (예 : 동시 사용자 용량)은 대부분 비 기능적입니다.

비 기능적 요구 사항을 때때로 "불량"이라고하는 기존의 좋은 대답에 추가하기 위해 시스템이 일반 기능 외에 추가로 보유해야하는 특성입니다. "유일성"에는 가용성, 유용성, 보안, 유연성 및 더욱 주관적인 미학이 포함됩니다.

이들 중 일부는 지정하고 평가하기 가 매우 어렵습니다. 그럼에도 불구하고 그들은 중요합니다. 계약에 서명 한 경우 "시스템이 안전해야합니다"와 같이 의미없는 수동 버전을 피해야합니다. 이러한 요구 사항을 해결하려고 할 때의 문제는 사람들이 중요한 것보다는 쉽게 측정 할 수있는 것들에 끌리는 경향이 있다는 것입니다. ). 최종 결과는 일반적으로 안전하고 사용 가능하지 않거나 유연하지 않은 시스템으로 끝납니다 (이용 가능성은 지정하기가 어렵지 않지만 여전히 많은 두통을 유발 함).

문화적 차이보다 일반적인 분석 거래 계약과 형식적인 물건과 사람을 다루는 사람들 사이에 여기있다, 아키텍처, 연구 등 모호한 손으로 물결 모양의 요구 사항이 여전히 요구 가 표현하기 때문에 지금까지 후자가 걱정이다 계약 직원들과 완전히 동정하더라도 고객에게 중요한 것들은 세부적으로 탐구되고 철저히 정리되기 전까지 는 유용한 계약 요건 이 아니라는 것입니다.

하나의 마지막 요점- "아직도"의 객관적인 척도를 제시 할 수 없다고해서 고객이 필요하지 않다는 의미는 아닙니다. 막연하다! = 불필요하다. 그러나 이는 그러한 것들을 측정하고 비 기능적 요구 사항을 점진적으로 도출 및 개선하거나 모든 것에 대한 선행적인 객관적인 조치없이 작동 할 수있는 방식 (Agile 등)으로 계약하는 더 나은 방법을 개발해야 함을 의미 할 수 있습니다.

이 의견은 모두 훌륭하지만 과도하게 조리되었으며 명확한 템플릿을 제공하지 않습니다. 다음과 같이 지정하는 것이 명확하지 않습니까?

제 생각에는 기능적 요구 사항은 응용 프로그램을 사용할 때 사용자가 경험하는 것입니다. 개발자가 처음부터이를 구현, 개선 또는 수정하려고 할 때 충족되어야합니다. 예를 들어, 사용자가 로그인해야합니다. 명령 프롬프트를 통해 응용 프로그램을 실행하는 새로운 방법을 추가 한 경우에도 사용자가 여전히 로그인해야한다고 가정 해 봅시다.

기능하지 않는 요구 사항은 보닛에서 발생합니다. 사용자는 인식하지 못하지만 구현되어 있어야합니다. 예를 들어, 응용 프로그램은 C #으로 개발해야합니다. 다른 언어로 개발 된 경우 사용자는 알지 못합니다. 그러나 기존 코드를 기반으로하기 때문에 요구 사항이 될 수 있습니다. 다른 예는 특정 서버에 설치해야한다는 것입니다. 사용자는 서버 이동을 알 수 없습니다.

기능적 또는 비 기능적? 나는 둘 다 말하지 않을 것이다. 대부분의 경우, 나열된 모든 예가 비즈니스 규칙처럼 보입니다 (시스템 프로세스가 따라야하는 프로세스 관련 제약 조건 및 의사 결정 규칙 지정).

비즈니스 규칙은 일반적으로 비즈니스 분석의 일부로 수집되며 종종 외부 참조가 아닌 기능 요구 사항 사양에 포함되기 때문에 많은 엔지니어가 잊거나 알지 못하는 것입니다.

기능적 요구 사항은 일반적으로 시스템이 수행 할 수 있거나 수행 할 수있는 작업입니다. 조치 결과 (음수 결과)로 표시 될 수 있습니다. 비 기능적 요구 사항은 고객 / 최종 사용자가 신경 쓰지 않고 결과에 영향을 미치지 않는
것입니다. 예를 들어 , Windows에는 분홍색 점이있는 파란색 테두리가 있습니다. -프로그램은 Java로 작성됩니다
.-코딩 표준, 방법 및 프로세스와 관련된 모든 것.

비 기능적 요구 사항은 고객에 의해 기능적 요구 사항으로 전환 될 수 있음에주의하십시오. 고객이 잡지 기사를 읽고 Erlang으로 작성하기를 원하기 때문에 프로그램이 Erlang으로 작성됩니다. -프로그램은 DB 2를 사용해야합니다. 고객이 기존 DB 2 시스템에서이를 실행하고 수년간의 경험과 해당 플랫폼에 익숙한 IT 팀을 보유하고 있기 때문입니다.
-소스 코드는 모든 MISRA 권장 사항을 통과해야합니다.

요약하면-고객이 관심을 기울이면 기능 요구 사항입니다. 그렇지 않으면 기능 요구 사항이 아니거나 요구 사항이 아닙니다.

기능 요구 사항은 시스템과 그 동작을 설명하는 데 필요한 것으로 생각하지만 비 기능적 요구 사항은 시스템에 필요하지 않으며 시스템 설계 협상 중에 수집되지 않는 것은 속도 범위 품질과 같은 시스템에서 나옵니다. 건축 된 체계에서, 안전, 유지 관리 등.