Por que criar um documento de requisito técnico?
Rachel S. Smith, author of Writing a Requirements Document, explains that a technical requirement document, “Presents why a product is needed, puts the product in context, and describes what the finished product will be like.” For software projects, a technical requirements document generally refers to how the software will be built including the operating system it is being programmed for and other standards.
Se você não criar um documento de requisito técnico, problemas reais podem se desenvolver, de acordo com Smith. Esses problemas podem incluir:
- Construir um produto que não preencha uma necessidade real.
- Desenvolvendo "creep de recurso".
- Ter um grupo na equipe que acha que está construindo uma formiga, enquanto outro grupo acha que está construindo um elefante.
Renee Fellman, a Portland, Oregon-based business expert who specializes in turning around businesses on the brink of failure, has found that failure to adequately document technical requirements can cause serious problems for a company that impact their bottom line.
Problems that arise from not having technical requirements documentation can range from simple to complex. “In one company I consulted for,” Fellman said, “Vital FDA compliance issues weren’t being addressed because human resources had failed to do something as simple as assign the duty of taking care of regulatory affairs.”
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
O valor dos documentos de requisitos técnicos
Um documento de requisito técnico permite que sua equipe entenda mutuamente o que é necessário, tecnicamente, para fazer do seu projeto ou produto um sucesso. Das 5 fases de gerenciamento de projetos, documentos de requisitos técnicos devem ser criados durante a Fase 2 do ciclo de vida do seu projeto. Durante esta fase, o escopo do seu projeto é definido e as metas são definidas. Documentos de requisitos técnicos também fornecerão informações que o ajudarão a:
- Determinar seu orçamento.
- Criar seu cronograma de divisão de trabalho.
- Desenvolver o gráfico de Gantt do projeto.
- Iniciar um plano de comunicação.
- Definir aspectos de gerenciamento de riscos.
Expectativas dos preparadores de documentos de requisitos técnicos
Qualquer pessoa que prepare um documento de requisito técnico deve entender o que compreende um requisito de sistema "bom" e como comunicar essas informações de forma clara.
- Lembre-se dos seguintes pontos:
- Seja criativo sobre as fontes que você escolhe explorar à medida que analisa seus requisitos técnicos e sempre use sua necessidade de negócios como um ponto de referência básico
- Ajude os outros a entender seus resultados usando uma linguagem fácil de entender
- Use protótipos para descobrir o que você está perdendo
- Certifique-se de entender as interrelações, prioridades, custo, implementação e consequências ambientais quando decidir o que incluir
- Defina limites do sistema
Outros tipos de documentos de requisitos comumente encontrados nos negócios
Ao determinar sua lista inicial de requisitos técnicos, esteja ciente de que existem outros documentos que também estão sendo preparados por outras equipes dentro de sua empresa. Esses documentos são quase o mesmo projeto, mas para públicos diferentes. É altamente possível que alguns desses documentos possam conter informações redundantes. Você pode sentir que alguns itens pertencem ao seu documento de requisito técnico e não ao documento de exigência de negócios ou mercado, mas não se preocupe, você pode tê-los em ambos. Cabe a você criar um documento de requisito técnico que funcione melhor para seus propósitos. Certifique-se de coletar as informações que são mais úteis para você.
Michael Shrivathsan, vice-presidente de gerenciamento de produtos da Accompa, é um especialista em tipos de documentos de requisitos e suas funções.
“There can be some overlap between business, market, and technical requirement documents,” said Shrivathsan. “Depending on the organization, they may or may not use all these document types. At large companies (1,000 employees plus), they typically do use all three of these docs. Most mid-sized companies (200 employees or more) use at least two of them.”
Pode haver informações importantes nesses outros relatórios que podem informar, influenciar ou criar contingências com seu documento de requisito técnico. Aqui estão alguns outros documentos que podem ser criados por outros departamentos para apoiar seu projeto:
Documentos de requisitos comerciais (BRD)
Escrito por: gerentes de produto, gerentes de marketing de produtos
Público-alvo: gerentes de engócios
Revisados e aprovados por: executivos de nível C
Um documento de requisito comercial define o caso comercial de alto nível do projeto e geralmente é preparado primeiro.
Um documento de requisito comercial define o objetivo do projeto do ponto de vista da empresa. A documentação desta fase delineia as metas de negócios em alto nível. Os membros desta equipe devem ter se reunido com gerentes de negócios apropriados em sua empresa ou empresa do cliente para coletar as informações comerciais necessárias que se concentram na necessidade de sua empresa e do cliente.
A partir do documento de requisito comercial, você pode obter as seguintes informações que podem ajudá-lo com seu documento de requisito técnico:
- A natureza das necessidades de seus clientes.
- Como atender a essas necessidades se alinha à missão de sua empresa.
- Como seu produto, sistema ou software resolverá as necessidades do cliente em um nível alto.
- Um retrato da relação entre todas as partes interessadas no projeto, por meio de fluxo apropriado, gráficos organizacionais ou diagramas, é recomendado para garantir clareza.
Documento de requisitos de mercado (MRD)
Escrito por: gerentes de produto, gerentes de marketing de produtos
Público-alvo: gerentes de negócios
Revisados e aprovados por: nível de direção
Documento de requisitos de mercado adiciona mais informações ao BRD, em termos do que o mercado precisa, e identifica o cenário atual do mercado para produtos ou programas como o que você está desenvolvendo. Saber algo sobre o que já está por aí, como ele é comercializado e para quem, pode ajudá-lo a determinar lacunas em outros recursos do produto.
A partir do documento de requisito comercial, você pode obter as seguintes informações que podem ajudá-lo com seu documento de requisito técnico:
- O tipo de produto que está sendo planejado;
- Os clientes que são o foco;
- As personas que definem:
- Características do cliente;
- Os desafios que enfrentam;
- Como seu produto proposto ajudará a resolver esses desafios;
- Produtos concorrentes e suas vantagens e desvantagens;
- Maneiras pelas quais seu produto será melhor.
Se ninguém em sua empresa está preparando os relatórios acima, você pode ter que fazer algum trabalho extra para ter a visão completa do universo em que seu produto existirá.
Requisitos técnicos devem se concentrar nos resultados desejados
Os requisitos técnicos de desenvolvimento de software incluem componentes como planejamento de desenvolvimento, arquitetura técnica, testes de software e implementação. Fellman aconselha que a documentação dos bons requisitos técnicos comece focando nos resultados que você deseja e não focando excessivamente no processo. Por quê? Porque para onde você quer ir determina tudo sobre como você vai chegar lá. Por exemplo, você não pegaria um camelo para chegar ao pico do Monte Everest, mas você poderia montar um se seu objetivo final fosse chegar até uma antiga tumba no deserto egípcio.
Fellman adverte: "Não fazer as perguntas certas antes de começar a preparar o documento de requisitos técnicos pode levar a um documento que realmente não resolve o problema que você está procurando resolver."
As perguntas, é claro, variam de acordo com seus clientes, sua empresa e o serviço ou produto pretendidos, mas para documentos de requisitos técnicos, explore o que você deseja que o novo sistema ou software realize, especialmente do ponto de vista do usuário. Você pode querer consultar os desenvolvedores e perguntar, do ponto de vista deles, o que é factível e o que não é.
Modelos de lista de verificação de requisitos técnicos são ferramentas organizacionais valiosas
Usar uma lista de verificação modelo, como a Lista de verificação de coleta de requisitos da Smartsheet, pode ajudá-lo a se manter focado nos tipos de informações que deve coletar como parte de sua análise de requisitos técnicos.
Certifique-se de incluir:
- Requisitos funcionais e as tarefas que ele executará;
- Datas de condução em termos de marcos;
- Requisitos físicos para um produto tangível como tamanho, peso, cor, forma, textura e robustez;
- Detalhes do ambiente técnico;
- Requisitos de dados;
- Interfaces externas;
- Compatibilidade/portabilidade;
- Manutenção.
Reúna informações de diversos grupos
Smith sugere que informações para esses tipos de documentos podem vir de várias fontes, incluindo usuários finais, clientes, desenvolvedores e outras partes interessadas. As informações podem ser coletadas por meio de entrevistas, enquetes, questionários, pesquisas ou até mesmo discussões de mesa redonda entre e dentro das equipes.
Empregue análise de uso
Identifique os tipos de usuários que usarão seu produto e descubra seus padrões de uso. Isso ajudará quando se trata de determinar todos os requisitos necessários para o nível de desempenho que você deseja alcançar.
Desenvolva casos de uso
Modelos para interações por usuários típicos devem ser incluídos em um documento de requisito técnico ou no documento de requisito comercial, usando diagramas e relatórios de casos.
Explore necessidades e resultados desejados
Considere a coleta dos seguintes tipos de informações para o documento de requisitos técnicos:
1. Defina as expectativas e necessidades do usuário final e como o produto será usado no mundo real. Faça perguntas (aqui estão algumas amostras):
- Que problema central o produto ou software resolverá para o público-alvo?
- O que você quer que as pessoas realizem ao usar o produto ou software?
- Como as vidas serão mais fáceis e produtivas?
2. Defina a estrutura e as contingências da equipe.
- Quais membros da equipe são responsáveis por aspectos do trabalho? (Lembre-se do exemplo de Fellman acima e certifique-se de que todas as responsabilidades importantes do trabalho sejam atribuídas.)
3. Defina o produto,
- Use mock-ups, narrativas ou listas.
- Defina claramente os requisitos de interface.
- Esclareça os requisitos do cliente, especialmente se o produto ou software está sendo construído de acordo com a especificação de um cliente.
- Defina estágios de desenvolvimento.
- Inclua etapas específicas até a conclusão e crie um cronograma inicial que pode ser refinado à medida que mais detalhes forem descobertos e decididos.
- Identifique contingências explorando quais partes do processo dependem umas das outras e por quê.
4. Crie um protótipo para ajudar a esclarecer os resultados que os usuários antecipam do novo produto ou sistema quando concluídos.
5. Defina todo o ciclo de vida do desenvolvimento de produtos, incluindo pessoas, processo, software e desenvolvimento de tecnologia, gerenciamento de mudanças.
6. Certifique-se de que cada requisito do sistema descreva:
- A função relevante que desempenha.
- Qualquer tipo de limite, em termos de design, restrições ou riscos jurídicos ou regulatórios.
- Requisitos de design ambiental para localização operacional, uso ou armazenamento.
Considere as qualidades do sistema
Considere as seguintes qualidades do sistema ao descrever a qualidade do serviço necessário para atender aos requisitos de seus negócios e usuários.
- Disponibilidade - Quanto "tempo de atividade" você pode esperar que o sistema tenha com base nos recursos, serviços e acessibilidade do sistema aos usuários finais.
- Capacidade latente - Como o sistema lidará com picos inesperados de uso independente de mais recursos.
- Desempenho - Dadas as condições específicas de carga de uma série de usos, qual será o tempo de resposta e a capacidade latente.
- Escalabilidade - A rapidez com que a capacidade e o número de usuários podem ser aumentados ou reduzidos, sem alterações na arquitetura original.
- Prestação de serviços - O quanto é fácil monitorar, reparar e atualizar os componentes do hardware e do sistema de software? Os fatores a serem considerados incluem planejamento para o tempo de inatividade, oportunidades de manutenção com base em padrões de uso, tempos críticos para disponibilidade de serviços, cronogramas para diagnóstico e monitoramento.
- Segurança - Quão seguro é o sistema, incluindo autorização e autenticação de usuários e informações durante a transferência?
Valide e refine seus requisitos técnicos
Depois de definir seus requisitos técnicos, aproveite o tempo para validá-los e refiná-los. Smith disse: "Analisamos fatores como: quantas partes interessadas solicitaram um determinado requisito, quantos outros requisitos dependiam dele, se tornaria o sistema mais fácil de usar ou executar uma função que os usuários não poderiam fazer de outra maneira, bem como outras medidas qualitativas."
Para Smith, a validação dos requisitos significou colocar o máximo de supervisão possível sobre eles, ouvir feedback e discutir as implicações de manter ou rejeitar um determinado requisito. "Não há, realmente, um atalho. Trata-se de envolver as principais partes interessadas e trabalhar com elas para entender e resolver quaisquer diferenças de opinião."
Smith prevê que você nunca saberá se capturou todos os requisitos necessários. "Você provavelmente vai reunir mais do que você precisa. Mas depois de tê-los, priorize-os e trabalhe nos requisitos de prioridade máxima que se encaixam em seu tempo e orçamento. Às vezes, não são os maiores requisitos que são os mais importantes."
Mantenha as partes interessadas informadas
Hoje, existem ferramentas que dão às partes interessadas uma visão direta do processo de desenvolvimento, onde elas podem ver o progresso monitorado visualmente, revisar (mas não editar) os requisitos à medida que estão sendo implementados e testar protótipos iniciais. "O desenvolvimento de software é uma coisa tão complicada", disse Smith. "As pessoas ficam animadas com os recursos antes de serem desenvolvidos e podem ficar realmente decepcionadas se suas expectativas não forem atendidas." Portanto, manter as pessoas informadas e oferecer acesso antecipado e atualizações regulares de qualquer maneira que funcione para elas é fundamental para a satisfação do usuário final uma vez que o produto é lançado.
O Agile Modeling é para você?
Agile Modeling (AM) é outra maneira de criar e documentar um modelo que pode ser implementado no desenvolvimento de sistemas e produtos baseados em software. Seu escopo vai além da documentação dos requisitos técnicos para incluir todo o processo e combina as práticas recomendadas com base nos valores e princípios mais eficazes para criar o melhor software possível, dado o tempo e o orçamento.
Para saber mais sobre Agile Modeling, aqui estão alguns livros recomendados:
- Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterprise de Scott W. Ambler e Mark Lines, IBM Press, ISBN: 013281013
- The Object Primer 3rd Edition: Agile Model Driven Development with UML 2. Cambridge University Press, 2004 ISBN#: 0-521-54018-6
- Introduction to Disciplined Agile Delivery: A Small Team's Journey from Scrum to Continuous Delivery de Mark Lines e Scott W. Ambler, Disciplined Agile Consortium, ISBN: 978 149 754 4383
Modelos de requisitos técnicos VS. Software
Os modelos são fáceis de usar e o custo é justo, mas também há alternativas. A empresa de Shrivathsan, Accompa, faz um software de documentos que gerencia problemas que podem surgir com base em informações redundantes ou mal interpretadas.
Este software:
- Acompanha as dependências entre esses três tipos de documentos. Se algo no documento de exigência comercial mudar, isso pode ter um efeito cascata nos documentos de requisitos técnicos e de mercado.
- Ele fornece um repositório para manter todas as informações para que possam ser facilmente consumidas (Shrivathsan mencionou que, na maioria das grandes empresas, essas informações podem ser fraturadas em múltiplos silos, tornando muito difícil de encontrar e usar).
"Para qualquer coisa, menos para os menores projetos, é quase impossível rastrear essas dependências manualmente", disse Shrivathsan, "portanto, uma ferramenta de software acessível é necessária."
Conselhos para escrever o documento de requisito técnico
Escrever requisitos técnicos é um pouco diferente de outros documentos comerciais padrão. Há uma arte em escrevê-los para que possam ser compreendidos pelas pessoas que os usarão para concluir um projeto ou construir um novo tipo de software. Aqui estão algumas dicas que podem ajudá-lo a escrever requisitos técnicos úteis:
- Use uma linguagem simples e direta para que todos compreendam o que você quer dizer.
- Seja conciso. Comece com um parágrafo introdutório, seguido por marcadores para aumentar a facilidade de leitura.
- Mantenha sua estrutura de frases simples para transmitir apenas uma ideia principal de cada vez.
- Às vezes, uma imagem vale mil palavras, especialmente se simplifica um conceito ou mostra a relação de um conceito com outro.
Documentos de requisitos técnicos para instituições e empresas educacionais;
Algumas instituições educacionais e empresas têm páginas web em seus sites dedicadas aos requisitos técnicos básicos para hardware, software e navegadores de computador. Se esses requisitos técnicos básicos não forem cumpridos, alunos, professores ou funcionários não poderão acessar a intranet. No caso dos alunos, isso significa que eles não podem ter aulas on-line. No caso das empresas, isso significa que os funcionários podem não ser capazes de fazer seu trabalho.
As informações geralmente incluem:
- Configurações mínimas para as plataformas Windows e Mac, como velocidade mínima de processador ou CPU, memória mínima e tipo de sistema operacional;
- Velocidade de conexão de rede para acesso à internet;
- Lista atual de navegadores suportados, além de links para baixá-los;
- Lista atual de plug-ins de navegadores, além de links para baixá-los;
- Informações de acesso à internet;
- Como se cadastrar em uma conta de e-mail da escola ou da empresa;
- Software necessário;
Modelos Smartsheet transformam seus requisitos técnicos em uma lista de verificação de trabalho para gerenciar qualquer projeto
Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.