선택적 요구 사항에 대한 더 나은 단어? [닫은]

소프트웨어 엔지니어링의 선택적 요구 사항에 대한 더 나은 단어는 무엇입니까? 문구가 모순됩니다. 이전 프로젝트에서 "비 핵심 요구 사항"을 사용했습니다.

"범위 밖의 요구 사항"이라는 용어가 사용될 수 있습니다. 이는 요구 사항이 프로세스 내에서 캡처되어 추적 가능하다는 것을 의미하지만 예산, 스케줄, 시간, 또는 타당성.

그러나 "선택적 요구 사항"이라는 문구는 일반적으로 시스템에 반드시 필요한 것은 아니지만 범위 내에있는 것을 나타 내기 위해 사용됩니다. 요구 사항의 우선 순위를 측정 한 것입니다. 내 경험상 요구 사항은 종종 필수, 바람직 또는 선택 사항으로 우선 순위가 결정됩니다 (다른 계획도 있음). 프로젝트가 완전하고 완벽하게 기능하는 것으로 간주 되려면 모든 필수 요구 사항이 충족되어야합니다. 충분한 자원이 주어지면 바람직한 요구 사항이 다음에 구현됩니다. 마지막으로 선택적인 것으로 간주되는 것이 포함됩니다.

혼란은 "요구 사항"이라는 용어에서 비롯된 것이라고 생각합니다. 영어에서 요구 사항은 "필요한 것"또는 "필수, 강제 또는 필요한 조건"입니다. 그러나 소프트웨어 엔지니어링에서 요구 사항이라는 용어는 단순히 소프트웨어 시스템의 문서화 된 특성입니다. 선택적 및 필수 개념은 소프트웨어 시스템의 문서화 된 특성의 우선 순위를 설명합니다.

우리는 그것들을 요구 사항이 아니라 "좋은"기능이라고 부릅니다.

소프트웨어 요구 사항 문서의 경우 RFC 2119 요구 사항 수준 을 나타내는 핵심 단어 ( 즉, 선택적인 항목 을 나타냄)에 따라이 용어를 사용하는 한 선택적 요구 사항 문구 는 완벽하게 괜찮습니다 .

사양 텍스트에 형용사 대신 동사가 포함되어 있으면 "OPTIONAL"대신 "MAY"를 사용하십시오.

작고 읽기 쉽기 때문에 RFC 텍스트는 아래에 완전히 인용되어 있습니다.

    네트워크 실무 그룹 S. Bradner
    의견 요청 : 2119 Harvard University
    BCP : 1997 년 3 월 14 일
    카테고리 : 모범 사례


            요구 수준을 나타 내기 위해 RFC에 사용되는 키워드

    이 메모의 상태

       이 문서는 인터넷 모범 사례를 지정합니다.
       인터넷 커뮤니티, 토론 및 제안 요청
       개량. 이 메모의 배포는 무제한입니다.

    요약

       많은 표준 추적 문서에서 여러 단어를 나타내는 데 사용됩니다
       사양의 요구 사항. 이 단어들은 종종
       대문자. 이 문서는이 단어들을 원래대로 정의합니다.
       IETF 문서에서 해석됩니다. 이 지침을 따르는 저자
       문서의 시작 부분 근처 에이 문구를 통합해야합니다.

          핵심 단어 "MUST", "MUST NOT", "필수", "SHALL", "SHALL
          NOT ","SHOULD ","SHOULD NOT ","RECOMMENDED ","MAY "및
          이 문서의 "선택 사항"은 다음에 설명 된대로 해석됩니다.
          RFC 2119.

       이 단어의 힘은 요구 사항에 의해 수정됩니다.
       사용되는 문서의 수준.

    1. 반드시이 단어 또는 "필수"또는 "SHALL"이라는 용어는
       정의는 사양의 절대 요구 사항입니다.

    2. NOT NOT이 문구 또는 "SHALL NOT"문구는
       정의는 본 명세서의 절대적인 금지이다.

    3.이 단어 또는 형용사 "권장"은
       특정 상황에서 타당한 이유가있을 수 있습니다.
       특정 항목이지만 전체 의미를 이해하고
       다른 코스를 선택하기 전에 신중하게 무게를 측정하십시오.

    4.이 문구 또는 "권장하지 않음"이라는 문구는
       특정 상황에서 유효한 이유가있을 수 있습니다.
       특정 행동은 수용 가능하거나 유용하지만 전체
       시사점을 이해하고 사례를 신중하게 평가
       이 레이블로 설명 된 동작을 구현하기 전에

    5.이 단어 또는 형용사 "선택 사항"은 항목이
       정말 선택 사항입니다. 한 공급 업체가 품목을 포함하도록 선택할 수 있습니다.
       특정 마켓 플레이스에 필요하거나 공급 업체가
       다른 공급 업체가 동일한 항목을 생략 할 수있는 동안 제품을 향상시킵니다.
       특정 옵션을 포함하지 않는 구현은 반드시
       다른 구현과 상호 작용할 준비가되었습니다.
       기능이 축소 된 경우에도 옵션을 포함하십시오. 에서
       특정 옵션을 포함하는 구현과 동일한 맥락
       다른 구현과 상호 운용 할 수 있도록 준비해야합니다.
       옵션을 포함하지 않습니다 (물론 기능의 경우
       옵션을 제공합니다.)

    6.이 명령의 사용에 대한 지침

       이 메모에 정의 된 유형의 명령은주의해서 사용해야합니다.
       그리고 드물게. 특히, 그들은 그것이있는 곳에서만 사용해야합니다
       실제로 상호 운용이 필요하거나
       피해를 일으킬 가능성 (예 : 재전송 제한)
       예를 들어, 특정 방법을 강요하려고 시도해서는 안됩니다
       상호 운용성을 위해 메소드가 필요하지 않은 구현 자

    7. 보안 고려 사항

       이 용어는 보안 동작을 지정하는 데 자주 사용됩니다.
       시사점. MUST를 구현하지 않는 보안에 미치는 영향 또는
       SHOULD, 또는 스펙이 NOT NOT 또는 SHOULD라고 말하는 것을 수행해야합니다.
       수행하지 않으면 매우 미묘 할 수 있습니다. 문서 작성자는 시간이 걸립니다
       따르지 않는 보안 영향을 설명하기 위해
       대부분의 구현자가 가지지 않는 권장 사항 또는 요구 사항
       경험과 토론의 이점을
       사양.

    8. 감사의 말

       이 용어의 정의는 취해진 정의의 합병입니다.
       많은 RFC에서. 또한 제안은
       Robert Ullmann, Thomas를 포함한 많은 사람들이 통합
       Narten, Neal McBurnett 및 Robert Elz.

문서가 RFC를 정의의 소스로 언급해도 문제가되지 않습니다.

이 문서는 RFC 2119에 지정된 정의에 기반한 정의를 사용합니다 .

귀하의 질문에 대한 답변이 아니라는 점에 감사드립니다.하지만 세상에서, 당신이 어떤 이유로 든 그것을 성취하지 않더라도 여전히 요구 사항입니다.

나는 MoSCoW 접근 방식 (필수, 보유, 보유 가능, 현재 보유하지 않을 것)이 다른 요소와 함께 사용자와 요구 사항을 분류하는 것을 좋아한다. 인수는 선택 사항이지만 중요한 요구 사항을 충족시킵니다.)

선택적 요구 사항에 대한 더 나은 단어는 " 권장 "입니다.

선택적 기능 또는 선택적 작업으로 식별하는 것은 어떻습니까. 이는 프로젝트의 특정 시점에서 이러한 기능을 완료하는 데 시간과 돈이 있다고 판단 된 경우에만 수행됩니다.

외부 이벤트가 발생하면 트리거 될 수도 있습니다. 고객이 Windows 8로 전환하면 다음 작업을 수행해야합니다.

기능 설명에는 기능 수행 여부를 결정하기위한 마감 시한이 포함되어야합니다.

요구 사항은 소프트웨어 엔지니어링에서 4 가지 영역으로 분류됩니다.

1. 비즈니스 요구 사항 : 시스템의 전반적인 비즈니스 목표 및 목표에 중점을 둡니다.
2. 사용자 요구 사항 : 사용자 목표와 시스템을 사용하여 비즈니스 목표를 달성하기 위해 사용자가해야 할 일에 중점을 둡니다.
3. 기능 요구 사항 : 비즈니스 목표를 달성하기 위해 시스템이 수행해야하는 기능 및 작업
4. 비 기능 요구 사항 : 기능 요구 사항 외에 어떤 요구 사항이 있습니까? 여기에는 환경, 제약 조건, 인터페이스, 유지 관리 문제 등이 포함됩니다.

위의 4 가지 범주에 따라 요구 사항은 선택 사항 이거나 필수 일 수 있습니다 . 위에서 간략히 설명했습니다. 선택적 요구 사항은 고려중인 시스템의 범위 나 범위를 벗어날 수도 있습니다. 선택적 요구 사항은 Scope Creep 을 피하고 정확한 용어로 범위를 정의하는 좋은 수단 입니다.

선택적 요구 사항은 범위를 식별하는 데 도움이되고 범위 크리프를 피할 수있는 좋은 수단이므로 항상 소프트웨어 엔지니어링의 일부가됩니다. SDLC의 엔지니어링 관행과 모순된다고 말할 수는 없습니다. 그러나 요구 사항의 우선 순위를 정하고 잘 정의해야합니다.

에서 Volere 템플릿 용어 "대기실은"사용됩니다.

...이 템플릿은 요구 사항 사양의 기초로 사용하기위한 것입니다. 이 템플릿은 오늘날의 비즈니스, 과학 및 소프트웨어 시스템에 적합한 각 요구 사항 유형을 제공합니다. 요구 사항에 대한 점검 목록, 구조 및 추적 성을 제공합니다 ...이 템플릿은 툴과 독립적이며 Yonix, Requisite, DOORS, Caliber RM, IRqA 및 기타 널리 사용되는 툴과 함께 성공적으로 사용되었습니다 ...

Volere 기술은 Suzanne Robertson 및 James Robertson 의 요구 사항 프로세스 마스터 링 책에 설명되어 있습니다 .

나의 사업 (우주선)에서, 그들은 "목표"라고 불린다. 그것들은 그들이 문서화되었고 그것들을 충족시키기 위해 노력이 소비 될 것이지만, 그들이 충족되지 않으면 시스템은 여전히 ​​성공적인 것으로 간주 될 것이다; "욕망"(실제 단어는 아니지만 당신이 있습니다), 누군가가 목표를 원하고 목표의 상태를 달성하려고하지만 아직 받아 들여 지거나 문서화되지 않았다는 것을 나타냅니다. 또는 "크리프 요구 사항"은 자원을 차지하려고하지만 실제 요구 사항을 타협하거나 위협 할 수있는 "충분히 좋은"달성을 ​​시도하는 프로젝트에서 가치가없는 것을 나타내는 더 욕망의 욕망 버전입니다.

요구 사항의 우선 순위 가 높은 경우 우선 순위 가 낮은 요구 사항으로 간주 할 수 있습니다 .

나는 그것들이 "목표"라고 언급 된 사람이 아무도 없다는 것에 상당히 놀랐습니다. 내가 일한 모든 회사는 그것을 그렇게 불렀습니다. 그것들은 "할 것"대신에 "의지"또는 "해야한다"라는 단어를 사용하여 표시된다. 때로는 숫자에 대해 이야기 할 때 중괄호에 포함되기도합니다. 예 : 시스템은 100 {250} 시간 동안 운영자의주의가 필요없이 지속적으로 작동해야합니다. 충족해야하는 요구 사항은 100 시간이지만 목표는 250 시간입니다.

부수적으로, 인센티브가 포함되지 않는 한, 누군가가 객관적인 요구 사항을 충족시키기 위해 실제로 디자인하는 사람은 거의 없습니다.

"Desirement"라는 용어는 경우에 따라 선택적 요구 사항에 사용됩니다. 그러나 공식 문서에는 적합하지 않을 수 있습니다.

모든 응답이 프로젝트 개발의 추적 요구 사항과 관련되어 있다는 사실에 놀랐습니다. 개발자 임에도 불구하고 나는 그 맥락에서이 용어에 대해 너무 걱정하지 않았습니다. 질문을 처음 읽을 때 제품 개발이 아니라 사용자 제품 사양과 관련된 것으로 가정했습니다. 예를 들어 백과 사전은 컬러 프린터를 선택적인 요구 사항으로 표시 할 수 있습니다. 앱을 최대한 활용하려면 필요하지만 화면을 보려면 선택 사항입니다. 그러나 예를 들어 흑백 프린터가 있다면 어떨까요? 일부 사진이 잘 보이지 않을 수있는 명백한 제한으로 앱이 작동하는지 확인하는 방법은 무엇입니까? 아니면 다른 예로 인쇄하지 않습니까? 다기능 프린터에서 잉크가 요구 사항인지 또는 선택적 요구 사항인지 확인하려면 프린터 검토를 어떻게 확인해야합니까? 즉, 여전히 스캔 할 수 있습니까? 용어 및 검색 대상에 대한 힌트는 제품 개발자 / 판매자 및 소비자 모두에게 환영받을 것입니다.

나는 그것들을 선택적인 요구 사항이 아니라 "선택적인 기능"이라고 부를 것이다. 요구 사항은 당신이 뭔가 같은 소리 가 있어야 기능이 추가 기능은 원래 제품에 같은 소리하면서.