tempo de leitura: 9 minutos

os requisitos claramente definidos são sinais essenciais na estrada que conduzem a um projecto bem sucedido. Eles estabelecem um acordo formal entre um cliente e um provedor que ambos estão trabalhando para alcançar o mesmo objetivo. Requisitos detalhados e de alta qualidade também ajudam a reduzir os riscos financeiros e manter o projeto em um cronograma., De acordo com o órgão de Análise de negócios da definição de Conhecimento, os requisitos são uma representação utilizável de uma necessidade.

criar requisitos é uma tarefa complexa, pois inclui um conjunto de processos como elicitação, análise, especificação, validação e gestão. Neste artigo, vamos discutir os principais tipos de requisitos para produtos de software e fornecer uma série de recomendações para o seu uso.

Classificação dos Requisitos

Antes de discutir como os requisitos são criados, vamos diferenciar seus tipos.,

high-level requirements cascade down to specific details

Business requirements. Estas incluem declarações de alto nível de metas, objetivos e necessidades.requisitos das partes interessadas. As necessidades de grupos discretos de partes interessadas também são especificadas para definir o que eles esperam de uma determinada solução.requisitos para a solução. Os requisitos de solução descrevem as características que um produto deve ter para atender às necessidades dos stakeholders e do próprio negócio.,os requisitos não funcionais descrevem as características gerais de um sistema. Eles também são conhecidos como atributos de qualidade.os requisitos funcionais descrevem como um produto deve comportar-se, quais as suas características e funções.requisitos de transição. Um grupo adicional de requisitos define o que é necessário de uma organização para passar com sucesso de seu estado atual para seu estado desejado com o novo produto.

vamos explorar os requisitos funcionais e não funcionais em maior detalhe.,os requisitos funcionais

e as suas especificações

requisitos funcionais são características do produto ou funções que os programadores devem implementar para permitir que os Utilizadores cumpram as suas tarefas. Então, é importante deixá-los claros tanto para a equipe de desenvolvimento como para as partes interessadas. Geralmente, os requisitos funcionais descrevem o comportamento do sistema em condições específicas. Por exemplo:

uma característica de pesquisa permite que um usuário caça entre várias faturas se quiser creditar uma fatura emitida.

Aqui está outro exemplo simples: como convidado, eu quero um sofá em que eu possa dormir durante a noite.,os requisitos de

são geralmente escritos em texto, especialmente para projetos ágeis. No entanto, também podem ser visuais. Aqui estão os formatos mais comuns e documentos:

• documento de especificação de requisitos de Software
• casos de Uso
• histórias de Usuário
• Estrutura de divisão de Trabalho (WBS) funcional (decomposição)
• Protótipos
• Modelos e diagramas

de Software, especificação de requisitos documento

requisitos funcional e não Funcional pode ser formalizado na especificação de requisitos (SRS) do documento., (Para saber mais sobre documentação de software, Leia nosso artigo sobre esse tópico.) O SRS contém descrições de funções e capacidades que o produto deve fornecer. O documento também define restrições e pressupostos. A SRS pode ser um único documento comunicando requisitos funcionais ou pode acompanhar outra documentação de software, como histórias de usuário e casos de uso.

não recomendamos a composição de SRS para toda a solução antes do início do desenvolvimento, mas você deve documentar os requisitos para cada característica antes de realmente construí-la., Uma vez que você recebe o feedback inicial do usuário, você pode atualizar o documento.

SRS deve incluir as seguintes secções:

propósito. Definições, visão geral do sistema e antecedentes.descrição geral. Pressupostos, restrições, Regras de negócio e visão de produto.requisitos específicos. Atributos do sistema, requisitos funcionais, requisitos de base de dados.é essencial tornar as RSE legíveis para todas as partes interessadas. Você também deve usar modelos com ênfase visual para estruturar a informação e ajudar a compreendê-la., Se você tem requisitos armazenados em alguns outros formatos de documentos, link para eles para permitir que os leitores para encontrar a informação necessária.exemplo: se você gostaria de ver um documento real, Baixe este exemplo SRS criado na Universidade Estadual de Michigan, que inclui todos os pontos mencionados acima, além de apresentar casos de uso para ilustrar partes do produto.casos de uso

casos de uso

casos de uso descrevem a interação entre o sistema e usuários externos que leva a alcançar objetivos particulares.cada caso de Utilização inclui três elementos principais: actores., Estes são os usuários fora do sistema que interagem com o sistema.

Sistema. O sistema é descrito por requisitos funcionais que definem um comportamento pretendido do produto.objectivos. Os objectivos da interacção entre os utilizadores e o sistema são delineados como objectivos.

Existem dois formatos para representar casos de uso:

• especificação de caso de Uso estruturada em formato textual
• Diagrama de caso de Uso

uma especificação de caso de uso representa a sequência de Eventos, juntamente com outras informações relacionadas com este caso de uso., Um típico caso de uso especificação de modelo inclui as seguintes informações:

• Descrição
• Pré – e Pós – condição de interação
• Basic interação caminho
• caminho Alternativo
• o caminho da Exceção

Exemplo:

caso de Uso especificação de modelo

Um caso de uso diagrama de não conter uma grande quantidade de detalhes. Ele mostra uma visão geral de alto nível das relações entre atores, diferentes casos de uso e o sistema.

O diagrama de caso de Utilização inclui os seguintes elementos principais:

casos de Utilização., Geralmente desenhado com ovais, os casos de Uso representam diferentes cenários de uso que os atores podem ter com o sistema (login, fazer uma compra, Ver itens, etc.)

limites do sistema. Os limites são delineados pela caixa que agrupa vários casos de uso em um sistema.actores. Estas são as figuras que retratam usuários externos (pessoas ou sistemas) que interagem com o sistema.associações. As associações são traçadas com linhas que mostram diferentes tipos de relações entre actores e casos de Utilização.,

exemplo:

Use case diagram example

User stories

a user story is a documented description of a software feature seen from the end-user perspective. A história do usuário descreve exatamente o que o usuário quer que o sistema faça. Em projetos ágeis, histórias de usuário são organizadas em um backlog, que é uma lista ordenada de funções de produto. Atualmente, histórias de usuários são considerados o melhor formato para itens backlog.,

Uma típica história de usuário é escrito desta forma:

Como <tipo de usuário> Eu quero <algum objetivo> para que <alguma razão>.

exemplo:

como administrador, eu quero adicionar descrições aos produtos para que os usuários possam mais tarde ver essas descrições e comparar os produtos.as histórias de Utilizador devem ser acompanhadas de critérios de aceitação., Estas são as condições que o produto deve satisfazer para ser aceito por um usuário, partes interessadas, ou um proprietário do produto. Cada história de usuário deve ter pelo menos um critério de aceitação. Os critérios de aceitação eficazes devem ser testáveis, concisos e completamente compreendidos por todos os membros da equipa e partes interessadas. Eles podem ser escritos como listas de verificação, texto simples, ou usando dado/quando/então formato.

exemplo:

Aqui está um exemplo da lista de critérios de aceitação para uma história de usuário descrevendo uma característica de pesquisa:

• um campo de pesquisa está disponível na barra superior.,
• inicia-se uma pesquisa quando o utilizador clica no envio.
• a substituição por omissão é um tipo de texto cinzento do nome.
• a substituição desaparece quando o utilizador começa a escrever.
• a língua de pesquisa é o inglês.
• o Usuário não pode digitar mais de 200 símbolos.não suporta símbolos especiais. Se o utilizador digitou um símbolo especial na entrada de pesquisa, ele mostra a massagem de aviso: a entrada de pesquisa não pode conter símbolos especiais.,

Finalmente, todas as histórias de usuário deve caber a INVESTIR modelo de qualidade:

• I – Independente
• N – Negociável
• V – Valiosa
• E – Estimável
• S – Small
• T – Testável

Independente. Isto significa que você pode agendar e implementar cada história de usuário separadamente. Isso é muito útil se você implementar processos de integração contínua.

negociáveis. Isto significa que todas as partes concordam em priorizar as negociações sobre a especificação. Isso também significa que os detalhes serão criados constantemente durante o desenvolvimento.valioso., Uma história deve ser valiosa para o cliente. Você deve perguntar a si mesmo do ponto de vista do cliente “por que” você precisa implementar um dado recurso.

estimável. Uma história de usuário de qualidade pode ser estimada. Isso ajudará a uma agenda de equipe e priorizará a implementação. Quanto maior é a história, mais difícil é estimá-la.

pequeno. Boas histórias de usuários tendem a ser pequenas o suficiente para planejar lançamentos de produção curta. Pequenas histórias permitem estimativas mais específicas.

testável. Se uma história pode ser testada, é suficientemente clara e boa., Histórias testadas significam que os requisitos são feitos e prontos para uso.

estruturas de decomposição funcional ou de degradação do trabalho (WBS)

uma decomposição funcional ou WBS é um documento visual que ilustra como processos complexos se decompõem em seus componentes mais simples. WBS é uma abordagem eficaz para permitir uma análise independente de cada parte. A WBS também ajuda a capturar a imagem completa do projeto.

sugerimos a seguinte lógica de decomposição funcional:

1. Encontra a função mais geral.
2. Encontre a sub função mais próxima.,
3. Encontre o próximo nível da sub-função.verifique o seu diagrama.

Ou o processo de decomposição pode ser como esta:

Alto Nível de Função>Sub-função> Processo> Atividade

Os recursos devem ser decompostos até o ponto em que o nível mais baixo de peças não podem ser desfeitos mais.,

Exemplo:

um exemplo de uma decomposição funcional

Software de protótipos

Software protótipo é um termo guarda-chuva para diferentes formas de fase precoce produtos de trabalho que são criados para mostrar como requisitos devem ser implementados. Os protótipos ajudam a colmatar as lacunas de visão e permitem que as partes interessadas e equipas clarifiquem áreas complicadas de produtos em desenvolvimento. Tradicionalmente, os protótipos representam como a solução irá funcionar e dão exemplos de como os usuários irão interagir com ele para realizar suas tarefas.,protótipos podem ser representações visuais rápidas e baratas de requisitos (protótipos descartáveis) ou mais complexos (protótipos evolucionários). Este último pode mesmo tornar-se as primeiras versões do produto que já tem algumas partes do Código final. Efetivamente, protótipos evolucionários podem até se transformar em MVPs que descrevemos em um artigo separado.

documentos de Projecto e protótipos

os requisitos de projecto são geralmente recolhidos e documentados utilizando três formatos principais que se dividem entre si:

Wireframes., Wireframes são estruturas gráficas de baixa fidelidade de um site ou aplicativo. Eles ajudam a mapear diferentes páginas de produtos com seções e elementos interativos.Mockups. Uma vez que wireframes estão prontos, eles são transformados em mockups, designs visuais que transmitem a aparência e sensação do produto final. Eventualmente, mockups podem se tornar o design final do produto.protótipos de Projecto. Estes documentos contêm visuais e permitem algumas interações de interface, como deslizar, clicar em links, ou preencher formulários., Protótipos de Design podem ser construídos a partir do zero usando HTML e CSS, mas a maioria das equipes UX usam serviços de prototipagem como o InVision.

exemplo:

para saber mais sobre como os processos de design da UX são tratados, verifique o nosso estudo de caso sobre a construção de uma solução de gestão de viagens para a Cornerstone, um provedor de SaaS corporativo, no qual usamos todos os três tipos de requisitos de design.os requisitos não funcionais

os requisitos não funcionais

os requisitos não funcionais descrevem como um sistema deve comportar-se e estabelecer restrições à sua funcionalidade. Este tipo de requisitos é também conhecido como atributos de qualidade do sistema.,

vamos dar uma olhada em requisitos não-funcionais típicos.

usabilidade

usabilidade define como será difícil para um usuário aprender e operar o sistema. A usabilidade pode ser avaliada a partir de diferentes pontos de vista:

eficiência de uso: o tempo médio que leva para realizar os objetivos de um usuário, quantas tarefas um usuário pode completar sem qualquer ajuda, o número de transações concluídas sem erros, etc.

Intuitiveness: como é simples compreender a interface, botões, cabeçalhos, etc.,

baixa carga de trabalho percebida: quantas tentativas são necessárias pelos usuários para realizar uma tarefa particular.exemplo: os requisitos de usabilidade podem considerar barreiras linguísticas e tarefas de localização: pessoas sem compreensão do francês devem ser capazes de usar o produto. Ou você pode definir os requisitos de acessibilidade: os usuários de Teclado que navegar por um site usando <tab>, deve ser capaz de atingir o “Add to cart” botão da página de um produto, no prazo de 15 <tab> cliques.,os requisitos de segurança garantem que o software é protegido contra o acesso não autorizado ao sistema e aos seus dados armazenados. Ele considera diferentes níveis de autorização e autenticação em diferentes papéis de usuários. Por exemplo, privacidade de dados é uma característica de segurança que descreve quem pode criar, ver, copiar, alterar ou excluir informações. A segurança também inclui proteção contra vírus e ataques de malware.

exemplo: as permissões de Acesso para a informação específica do sistema só podem ser alteradas pelo administrador de dados do sistema.,

fiabilidade

fiabilidade define a probabilidade de o software funcionar sem falhas durante um determinado período de tempo. A confiabilidade diminui por causa de bugs no código, falhas de hardware ou problemas com outros componentes do sistema. Para medir a confiabilidade do software, você pode contar a porcentagem de operações que são concluídas corretamente ou acompanhar o período médio de tempo que o sistema corre antes de falhar.exemplo: o processo de atualização da base de dados deve retroceder todas as atualizações relacionadas quando qualquer atualização falha.,

Performance

Performance é um atributo de qualidade que descreve a capacidade de resposta do sistema a várias interações do utilizador com ele. O mau desempenho leva a experiência negativa do Usuário. Também põe em risco a segurança do sistema quando está sobrecarregado.

exemplo: o tempo de carga da primeira página não deve ser mais de 2 segundos para os usuários que acessam o site usando uma conexão móvel LTE.

disponibilidade

disponibilidade é aferida pelo período de tempo que a funcionalidade e serviços do sistema estão disponíveis para uso em todas as operações., Assim, os períodos de manutenção programados influenciam diretamente este parâmetro. E é importante definir como o impacto da manutenção pode ser minimizado. Ao escrever os requisitos de disponibilidade, a equipe tem que definir os componentes mais críticos do sistema que devem estar disponíveis a todo momento. Você também deve preparar notificações do usuário no caso de o sistema ou uma de suas partes ficar indisponível.exemplo: a implantação de novos módulos não deve impactar a primeira página, páginas de produtos e verificar a disponibilidade das páginas e não deve demorar mais de uma hora., O resto das páginas que podem ter problemas devem exibir uma notificação com um temporizador mostrando quando o sistema vai estar em cima novamente. os requisitos de escalabilidade descrevem como o sistema deve crescer sem influência negativa no seu desempenho. Isso significa servir mais usuários, processar mais dados e fazer mais transações. A escalabilidade tem implicações de hardware e software. Por exemplo, você pode aumentar a escalabilidade adicionando memória, servidores ou espaço em disco. Por outro lado, você pode comprimir dados, usar algoritmos otimizados, etc.,

exemplo: o limite de frequência do site deve ser escalável o suficiente para suportar 200.000 usuários de cada vez.

palavras finais

todos os projetos de software incluem os limites de informação que descrevem o produto e os objetivos do projeto. Estes limites são definidos nos requisitos e especificações do projecto. O valor de criar uma especificação de requisitos de software está na otimização do processo de desenvolvimento. Especificações de requisitos de Software respondem a todas as perguntas do desenvolvedor sobre o produto que são necessários para iniciar o trabalho., A especificação funcional é aprovada pelo cliente e garante que os desenvolvedores estão construindo o que o cliente quer.