Qual é a maneira apropriada de lidar com requisitos implícitos?

Estou em P&D trabalhando em um novo produto de software.

É compreensível que a gerência se concentre nos principais recursos que obviamente oferecem uma vantagem ao cliente. Mas existem muitos requisitos que também podem ser considerados importantes (por exemplo , desempenho, extensibilidade futura, rastreabilidade de dados, segurança, interface do usuário suave ). Esses requisitos implícitos provavelmente são os maiores em número para qualquer produto e, se não cumpridos, podem levar a um cliente insatisfeito.

Receio que, de alguma forma, seja esperado que durante o desenvolvimento essas coisas sejam implementadas automaticamente. Para mim, porém, tudo é um aspecto atômico que requer atenção própria e esforço de desenvolvimento.

Sinto que a gerência pode estar muito ocupada para prestar muita atenção a esses aspectos. Pelo bem do meu orgulho de desenvolvedor, controle de qualidade e capacidade de explicar o esforço que gasto, quando e como devo documentar e comunicar requisitos implícitos?

(ou seja, recursos que existem em um produto, mas que não foram explicitamente discutidos com o cliente ou com a gerência)

Esclarecimento

Obrigado pelo interesse na pergunta, a principal essência das respostas até agora parece ser:

"Você precisa explicitar requisitos implícitos."

Ratos ... isso não me ocorreu.

Os requisitos que eu quero dizer podem ser dos seguintes tipos:

• O cliente não pode ouvir sobre esses requisitos, porque apresentarei uma longa lista de maneiras pelas quais o produto pode falhar, em vez de falar sobre como isso os fará felizes.
• A gerência ocupada sente que estou perdendo tempo, quando falo sobre recursos "óbvios".
• Só poderei descrever alguns desses requisitos durante a implementação. Durante o planejamento, posso ter a sensação de que um problema específico pode exigir um esforço concentrado durante o desenvolvimento.
• Não estou na altura necessária no totem da empresa para ditar minhas condições de trabalho.

Estou solicitando orientações sobre como semi-formalizar requisitos [implícitos], enquanto dedico menos esforço do que aos requisitos completos, mas mantendo-me preparado para o dia do julgamento, para não ser pego de mãos vazias.

Tornar explícitos os requisitos implícitos é a resposta correta.

Sobre suas restrições de acompanhamento:

O cliente não pode ouvir sobre esses requisitos, porque apresentarei uma longa lista de maneiras pelas quais o produto pode falhar, em vez de falar sobre como isso os fará felizes.

Imagine que você é um arquiteto, projeta edifícios para grandes empresas.

A Big Co. Inc. pede que você construa um arranha-céu para eles na praia. Tem que ter uma piscina no telhado e outra no 10º andar. Tem que ter um jardim de parede cobrindo a parede externa do 15º ao 17º andar.

Estes são os requisitos do cliente. Você hesitaria em adicionar à lista de requisitos os requisitos para que o edifício suporte seu próprio peso, mais duas piscinas cheias de água e um jardim de parede hughe?

Você hesitaria em acrescentar que ele precisa ter encanamento, fiação elétrica e um sistema para encher a piscina com água e mantê-la limpa?

Você é o arquiteto, sabe o que é necessário para um edifício, é para isso que eles estão pagando.

Você sabe que um prédio com mais de três andares precisará de um elevador, não é necessário que ninguém lhe diga isso.

A gerência ocupada sente que estou perdendo tempo, quando falo sobre recursos "óbvios".

Então o elevador é óbvio. Por mais óbvio que seja, ele ainda tem um impacto no custo geral, na força de trabalho geral necessária, na ETA do projeto e provavelmente em outros aspectos.

Só poderei descrever alguns desses requisitos durante a implementação. Durante o planejamento, posso ter a sensação de que um problema específico pode exigir um esforço concentrado durante o desenvolvimento.

É aqui que a analogia do arquiteto é interrompida, principalmente por causa da natureza fluida da TI. Meu único conselho aqui é que você pode se beneficiar de um processo iterativo que permita planejar o não planejado. Agile parece bastante popular.

Não estou na altura necessária no totem da empresa para ditar minhas condições de trabalho.

Sua empresa deve ter alguém responsável por garantir que a lista de requisitos esteja completa.

• Se não tiverem um grande problema, tente consertá-lo ou comece a polir seu currículo.
• Se o fizerem, mas essa pessoa não fez seu trabalho corretamente, ligue para ele e aumente conforme necessário.
• Se eles o fazem e essa pessoa é você, mas você não recebeu a autoridade para fazer seu trabalho, eles estão pedindo que você faça algo impossível, sua melhor jogada é não jogar (ou seja, tente fazê-los consertar ou comece a polir seu currículo).

Defina tudo. O único potencial negativo para isso é que você pode receber algo de volta reclamando que eles sentem que você está afirmando o óbvio.

Afirme o óbvio então.

Esta é a chave: tudo o que você não define pode ser jogado de volta na sua cara com "você nunca nos disse ..."

Qualquer coisa que não esteja definida pode explodir na sua cara. "Melhor prevenir do que remediar" são excelentes palavras para se viver.

O termo da indústria para os requisitos que você descreve é ​​chamado:

Requisitos não Funcionais

Sob todos os aspectos, eles devem ser identificados por recursos técnicos e adicionados ao plano do projeto como unidades atômicas de trabalho. Se você estiver executando um projeto Agile, eles serão gravados na forma de história do usuário e adicionados ao backlog a ser tratado. Como recurso técnico, você precisa defender o tempo para trabalhar neles e garantir que eles tenham prioridade apropriada durante o planejamento de sprint ou a sessão de planejamento de projetos com a empresa. Além disso, o controle de qualidade precisa elaborar um plano de teste apropriado para essas unidades de trabalho também.

Por acaso, alguns desses requisitos implícitos nos morderam porque eles não foram definidos e, portanto, o controle de qualidade não os testou e os bugs foram para produção e não foram encontrados por algum tempo, causando não apenas o incômodo de explicar aos clientes os problema e por que não foi encontrado anteriormente, mas é um problema legal real para nossa empresa. (Era um relatório que tratava de informações que precisavam ser relatadas ao governo.)

Se é importante o suficiente para fazer, ele precisa ser testado e, portanto, precisa fazer parte dos requisitos.

Os requisitos podem vir de qualquer fonte, desde que sejam rastreáveis ​​de onde vieram e não entrem em conflito um com o outro. Os clientes podem fornecer seus requisitos, mas os requisitos também vêm de leis e regulamentos, padrões do setor, necessidades de negócios e até mesmo experiências anteriores aprendidas com o fornecimento de produtos similares a outros clientes.

Cada um desses requisitos deve ser capturado em qualquer método usado para capturar requisitos, para que não seja esquecido. Isso também permitirá que eles sejam comparados para garantir que um requisito adicional não esteja em conflito com um requisito do cliente ou que um requisito do cliente não esteja em conflito com os regulamentos, por exemplo.

Você deve capturar esses requisitos e gerenciá-los desde o início do projeto e transmiti-los à equipe que está projetando, implementando e testando o software. Fazer isso garantirá que todos compreendam completamente o que o software entregue deve ser.

No entanto, ao adicionar um desses requisitos, verifique-o com as partes interessadas apropriadas. Você não pode simplesmente adicionar requisitos sem garantir que ainda possa entregar o software dentro do cronograma e orçamento pretendidos.

É aí que entra uma equipe diversificada, com pessoas especializadas em diferentes áreas. Também requer mais sr. pessoas da equipe para liderar o resto.

Por exemplo, desempenho, extensibilidade futura e rastreabilidade de dados devem realmente ser coisas pensadas desde o início. Eles não são uma caixa de seleção que você pode voltar e adicionar mais tarde, eles precisam estar na base do seu design.

Quanto à segurança, é quando alguém que está familiarizado com essa área está na sua equipe desde o início para ajudar no processo de design.

O design da interface do usuário tem a tendência de morder um produto se não for feito corretamente. Ter uma pessoa de experiência do usuário na equipe fazendo modelos e fluxos de tela para a equipe é onde isso entra em jogo. Mas, novamente, isso é algo que deve ser feito antecipadamente.

Seus requisitos podem ser um site que permita aos usuários pesquisar o inventário atual de uma loja local. Como você projeta esse sistema é onde esses requisitos implícitos entram em jogo.

Do ponto de vista do gerenciamento de projetos, isso significa que precisa haver tempo de design no orçamento, bem como tempo de teste adequado. Também deve haver check-ins com o cliente para mostrar o que foi feito para garantir que você esteja no caminho certo.

Quaisquer requisitos implícitos que acabem causando trabalho para a equipe devem ser explicitados.
Caso contrário, eles acabarão

1. mordendo você mais tarde quando as pessoas as criam de qualquer maneira, causando excesso no desenvolvimento
2. ignorado e posteriormente relatado como bugs
3. sendo implementado de qualquer maneira, apesar de não ter sido agendado, causando excedentes e relatórios de erros porque eles não foram implementados como o cliente pensava que deveria ter sido, mas nunca mencionado.

Portanto, ao tornar explícitos os requisitos implícitos, você economiza muitas dores de cabeça.