Melhor palavra para Requisitos Opcionais? [fechadas]

Qual é a palavra melhor para um requisito opcional em engenharia de software? A frase é contraditória. Eu usei "Requisitos não essenciais" em projetos anteriores.

O termo "requisito fora do escopo" pode ser usado. Isso significa que o requisito foi capturado dentro do seu processo e é rastreável, mas foi determinado que o requisito é algo que está além do escopo atual do sistema, devido a vários motivos, como orçamento, cronograma, tempo, ou viabilidade.

No entanto, a frase "requisito opcional" é comumente usada para denotar algo que está no escopo, mas não necessariamente exigido pelo sistema. É uma medida da prioridade do requisito. Nas minhas experiências, os requisitos geralmente são priorizados como obrigatórios, desejáveis ​​ou opcionais (embora também existam outros esquemas). Para que um projeto seja considerado completo e totalmente funcional, todos os requisitos obrigatórios devem ser atendidos. Dados os recursos suficientes, os requisitos desejáveis ​​seriam implementados a seguir. Finalmente, qualquer coisa considerada opcional seria incluída.

Eu acredito que a confusão vem do termo "requisito". No idioma inglês, um requisito é "uma coisa necessária" ou "uma condição obrigatória, obrigatória ou necessária". No entanto, na engenharia de software, o termo requisito é simplesmente uma característica documentada de um sistema de software. O conceito de opcional e obrigatório descreve a prioridade da característica documentada do sistema de software.

Nós os chamamos de recursos "legais de ter", em oposição aos requisitos.

Para a documentação dos requisitos de software, a redação Requisitos Opcionais é perfeitamente aceitável, desde que você use este termo em conformidade com a RFC 2119 Palavras-chave para indicar níveis de exigência - ou seja, para indicar itens que são realmente opcionais.

Quando o texto da sua especificação implica verbo em vez de adjetivo, use "MAIO" em vez de "OPCIONAL".

Como é pequeno e fácil de ler, o texto RFC é totalmente citado abaixo:

    Grupo de Trabalho em Rede S. Bradner
    Pedido de Comentários: 2119 Harvard University
    BCP: 14 de março de 1997
    Categoria: Melhores práticas atuais


            Palavras-chave para uso em RFCs para indicar níveis de exigência

    Status deste memorando

       Este documento especifica as melhores práticas atuais da Internet para o
       Comunidade da Internet e solicita discussão e sugestões para
       melhorias. A distribuição deste memorando é ilimitado.

    Abstrato

       Em muitos padrões, rastrear documentos são usadas várias palavras para significar
       os requisitos na especificação. Essas palavras são frequentemente
       capitalizado. Este documento define essas palavras como elas devem ser
       interpretado em documentos IETF. Autores que seguem estas diretrizes
       devem incorporar esta frase perto do início de seu documento:

          As palavras-chave "DEVE", "NÃO DEVE", "NECESSÁRIO", "DEVERÁ", "DEVERÁ
          NÃO "," DEVE "," NÃO DEVE "," RECOMENDADO "," PODE "e
          "OPCIONAL" neste documento deve ser interpretado conforme descrito em
          RFC 2119.

       Observe que a força dessas palavras é modificada pelo requisito
       nível do documento em que são usados.

    1. DEVE Esta palavra, ou os termos "NECESSÁRIO" ou "DEVERÁ", significar que o
       definição é um requisito absoluto da especificação.

    2. NÃO DEVE Esta frase, ou a frase "NÃO DEVERÁ", significa que o
       definição é uma proibição absoluta da especificação.

    3. Esta palavra, ou o adjetivo "RECOMENDADO", significa que existem
       podem existir razões válidas em circunstâncias particulares para ignorar uma
       item específico, mas todas as implicações devem ser entendidas e
       cuidadosamente pesado antes de escolher um curso diferente.

    4. NÃO DEVE Esta frase ou a frase "NÃO RECOMENDADO" significa que
       pode haver razões válidas em circunstâncias particulares quando o
       comportamento particular é aceitável ou até útil, mas a
       implicações devem ser entendidas e o caso cuidadosamente ponderado
       antes de implementar qualquer comportamento descrito com este rótulo.

    5. PODE Esta palavra, ou o adjetivo "OPCIONAL", significa que um item é
       verdadeiramente opcional. Um fornecedor pode optar por incluir o item porque uma
       mercado específico exige isso ou porque o fornecedor sente que
       aprimora o produto enquanto outro fornecedor pode omitir o mesmo item.
       Uma implementação que não inclua uma opção específica DEVE ser
       preparado para interoperar com outra implementação que não
       inclua a opção, embora talvez com funcionalidade reduzida. No
       mesma linha, uma implementação que inclui uma opção específica
       DEVE estar preparado para interoperar com outra implementação que
       não inclui a opção (exceto, é claro, pelo recurso que o
       opção fornece.)

    6. Orientação no uso desses imperativos

       Os imperativos do tipo definido neste memorando devem ser usados ​​com cuidado
       e com moderação. Em particular, eles DEVEM ser utilizados somente onde
       realmente necessário para interoperação ou para limitar comportamentos que tenham
       potencial de causar danos (por exemplo, limitar retransmissões)
       Por exemplo, eles não devem ser usados ​​para tentar impor um método específico
       em implementadores onde o método não é necessário para interoperabilidade.

    7. Considerações de segurança

       Estes termos são freqüentemente usados ​​para especificar comportamento com segurança
       implicações. Os efeitos na segurança da não implementação de um MUST ou
       DEVE, ou fazer algo que a especificação diz NÃO DEVE ou DEVE
       NÃO ser feito pode ser muito sutil. Os autores do documento devem levar algum tempo
       elaborar as implicações de segurança de não seguir
       recomendações ou requisitos, pois a maioria dos implementadores não terá
       teve o benefício da experiência e discussão que produziu o
       especificação.

    8. Agradecimentos

       As definições desses termos são um amálgama de definições tomadas
       de vários RFCs. Além disso, sugestões foram
       incorporada por várias pessoas, incluindo Robert Ullmann, Thomas
       Narten, Neal McBurnett e Robert Elz.

Não faria mal se sua documentação se referir ao RFC como a fonte das definições:

Este documento usa definições baseadas nas especificadas na RFC 2119 .

Agradeço que não seja uma resposta para sua pergunta, mas, no meu mundo, ainda é um requisito, mesmo que por qualquer motivo você não o cumpra.

Gosto da abordagem do MoSCoW (deve ter, deveria ter, poderia ter, não terá esse tempo) para categorizar requisitos com os usuários, além de outros fatores (no meu mundo regulamentado, os requisitos podem ser críticos ou não críticos, e muitos argumento explode sobre requisitos opcionais, mas críticos.)

Uma palavra melhor para um requisito opcional é " Recomendação "

Que tal identificá-lo como um recurso opcional ou tarefas opcionais. Isso só será feito se, em um determinado momento do projeto, tiver sido determinado que há tempo e dinheiro disponíveis para concluir esses recursos.

Eles também podem ser acionados se ocorrer um evento externo. Se os clientes mudarem para o Windows 8, será necessário executar as seguintes tarefas ...

A descrição do recurso deve incluir um prazo para determinar se eles serão concluídos.

Os requisitos são classificados em 4 áreas na Engenharia de Software:

1. Requisitos comerciais : concentra-se nas metas e objetivos gerais de negócios do sistema
2. Requisitos do usuário : Concentra-se nos objetivos do usuário e no que os usuários precisam fazer para usar o sistema para alcançar os objetivos de negócios
3. Requisitos funcionais : que funcionalidade e tarefas o sistema deve executar para alcançar os objetivos de negócios
4. Requisitos não funcionais : quais requisitos existem além dos funcionais. Isso inclui ambiente, restrições, interface, problemas de manutenção, etc.

Agora, os requisitos podem ser Opcionais ou Obrigatórios , dependendo das 4 categorias acima, que descrevi acima. Os requisitos opcionais também podem se enquadrar no escopo do sistema em consideração ou fora dele. Os requisitos opcionais são bons meios para evitar o escopo do escopo e definir seu escopo em termos precisos.

Os requisitos opcionais sempre farão parte da engenharia de software, pois nos ajudam a identificar o escopo e são um bom meio de evitar o escorregamento do escopo. Você nunca pode dizer que eles contradizem as práticas de engenharia do SDLC. No entanto, os requisitos devem ser priorizados e bem definidos.

No modelo Volere, o termo "Sala de espera" é usado.

... Este modelo deve ser usado como base para suas especificações de requisitos. O modelo fornece cada um dos tipos de requisitos apropriados para os sistemas comerciais, científicos e de software atuais. Ele fornece uma lista de verificação, estrutura e rastreabilidade para seus requisitos ... O modelo é independente de ferramenta e foi usado com sucesso com Yonix, Requisite, DOORS, Calibre RM, IRqA e outras ferramentas populares ...

As técnicas Volere são descritas no livro Mastering the Requirements Process de Suzanne Robertson e James Robertson ...

Na minha empresa (espaçonave), eles são chamados de "objetivos", indicando que estão documentados e que serão gastos esforços para alcançá-los, mas o sistema ainda será considerado bem-sucedido se não for atingido; "desejos" (não é uma palavra real, mas você está aqui), indicando que alguém os deseja e que eles estão tentando atingir o status dos objetivos, mas ainda não foram aceitos ou documentados; ou "requisitos rastejantes", que são uma versão mais depreciativa dos desejos, indicando coisas que estão tentando consumir recursos, mas que não valem a pena em um projeto que tenta alcançar o "bom o suficiente", onde comprometem ou ameaçam alcançar os requisitos reais.

Se seus requisitos forem priorizados , você poderá considerá-los requisitos de baixa prioridade .

Estou bastante surpreso que ninguém tenha mencionado que esses são chamados de "objetivos". Toda empresa em que trabalhei os chamou assim. Eles são indicados pelo uso das palavras "vontade" ou "deve" em vez de "deve". Às vezes, eles são incluídos no aparelho ao falar sobre números. Por exemplo, o sistema deve operar continuamente sem a necessidade de atenção do operador por 100 {250} horas. Significando que o requisito que deve ser atendido é de 100 horas, mas o objetivo é de 250 horas.

Como observação lateral, muito raramente alguém realmente projeta para atender ao requisito objetivo, a menos que haja algum tipo de incentivo envolvido.

O termo "Desejo" às vezes é usado para requisitos opcionais. No entanto, pode não ser apropriado para um documento formal.

Estou surpreso que todas as respostas estejam relacionadas aos requisitos de rastreamento no desenvolvimento do projeto. Apesar de ser um desenvolvedor, nunca me preocupei demais com essa terminologia nesse contexto. Quando li pela primeira vez a questão, presumi que ela estava relacionada à especificação do produto do usuário, não ao desenvolvimento do produto. Por exemplo, uma enciclopédia pode listar uma impressora colorida como um requisito opcional. É necessário se você deseja obter todos os benefícios do aplicativo, mas opcional se você deseja visualizar a tela. Mas e se você tivesse, por exemplo, uma impressora monocromática? Como deixar claro se seu aplicativo funciona com a restrição óbvia de que algumas fotos podem não parecer tão boas? Ou não imprimirá? Como outro exemplo, como devo verificar uma revisão da impressora para verificar se a tinta é um requisito ou um requisito opcional em uma impressora multifuncional? Em outras palavras, ainda posso digitalizar? Algumas dicas sobre terminologia e o que procurar seriam bem-vindas tanto como desenvolvedor / vendedor de produto quanto como consumidor.

Eu os chamaria de "recursos opcionais", não de requisitos opcionais. Os requisitos parecem algo que você precisa ter , enquanto os recursos parecem um complemento para o produto original.