- O que é engenharia de requisitos?
Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferecem e as restrições a seu funcionamento. Esses requisitos refletem as necessidades dos clientes para um sistema que serve a uma finalidade determinada, como controlar um dispositivo, colocar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado engenharia de requisitos (RE, do inglês requirements engineering).
- O que é Requisito Funcional?
Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles dependem do tipo de software a ser desenvolvido, de quem são seus possíveis usuários e da abordagem geral adotada pela organização ao escrever requisitos. Quando expressos como requisitos de usuário, os requisitos funcionais são normalmente descritos de forma abstrata, para serem compreendidos pelos usuários do sistema. No entanto, requisitos de sistema funcionais mais específicos descrevem em detalhes as funções do sistema, suas entradas e saídas, exceções etc.
- O que é Requisitos Não Funcional?
São restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo. Os requisitos não funcionais, são requisitos que não estão diretamente relacionados com os serviços específicos oferecidos pelo sistema a seus usuários.
- Reporte sobre o Documento de Requisitos.
O documento de requisitos de software, às vezes chamado de Especificação de Software (SRS – do inglês Software Requiriments Specification), é uma declaração oficial de o que os desenvolvedores do sistema devem implementar. Deve incluir tanto os requisitos de usuário para um sistema quanto uma especificação detalhada dos requisitos de sistema. Em alguns casos, os requisitos de usuário e de sistema são integrados em uma única descrição. Em outros, os requisitos de usuário são definidos em uma introdução especificação de requisitos de sistema. Se houver um grande número de requisitos, os requisitos detalhados de sistema podem ser apresentados em um documento separado.
- Qual a estrutura do Documento de Requisitos?
Prefácio – Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo umas justificativas para a criação de uma nova versão e um resumo das mudanças feitas em cada versão.
Introdução – Deve escrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e explicar como ele vai funcionar com outros sistemas. Também deve descrever como o sistema atende aos objetivos globais de negócio ou estratégicos da organização que encomendou o software.
Glossário – Deve definir os termos técnicos usados no documento. Você não deve fazer suposições sobre a experiência ou o conhecimento do leitor.
Definição de requisitos de usuário – Deve descrever os serviços fornecidos ao usuário. Os requisitos não funcionais de sistema também devem ser descritos nessa seção. Essa descrição pode usar a linguagem natural, diagramas ou outras notações compreensíveis para os clientes. Normas de produto e processos que devem ser seguidos devem ser especificados.
Arquitetura do sistema – Deve apresentar uma visão geral em alto nível da arquitetura do sistema previsto, mostrando a distribuição de funções entre os módulos do sistema. Componentes de arquitetura que são reusados devem ser destacados.
Especificação de requisitos do sistema – Deve descrever em detalhes os requisitos funcionais e não funcionais. Se necessário, também podem ser adicionados mais detalhes aos requisitos não funcionais. Interfaces com outros sistemas podem ser definidas.
Modelos do sistema – Pode incluir modelos gráficos do sistema que mostram os relacionamentos entre outros componentes do sistema, o sistema e seu ambiente. Exemplos de possíveis modelos são modelos de objetos, modelos de fluxo de dados ou modelos semânticos de dados.
Evolução do sistema – Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como quaisquer mudanças previstas, em decorrência da evolução de hardware, de mudanças nas necessidades do usuário etc. Essa seção é útil para projetistas de sistema, pois pode ajuda-los a evitar decisões capazes de restringir possíveis mudanças futuras no sistema.
Apêndices – Deve fornecer informações detalhadas e específicas relacionadas à aplicação em desenvolvimento, além de descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações mínimas ideais para o sistema. Requisitos de banco de dados definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre esses dados.
Índice – Vários índice podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um índice de diagramas, de funções, entre outros pertinentes.
- O que é especificar Requisitos?
A especificação de requisitos é o processo de descrever os requisitos de usuário e de um sistema em um documento de requisitos. Idealmente, os requisitos de usuário e de um sistema devem ser claros, inequívocos, de fácil compreensão, completos e consistentes. Na prática, isso é difícil de conseguir, pois os stakeholders interpretam os requisitos de maneiras diferentes, e, muitas vezes, notam-se conflitos e inconsistência inerentes aos requisitos.
- Quais são os usuários do Documento de Requisitos e o que fazem?
Clientes do sistema – Especificam e leem os requisitos para verificar se estes satisfazem suas necessidades. Os clientes especificam as alterações nos requisitos.
Gerentes – Usam o documento de requisitos para planejar uma proposta para o sistema e para planejar o processo de desenvolvimento do sistema.
Engenheiros de sistema – Usam os requisitos para entender o sistema que será desenvolvido.
Engenheiros de teste – Usam os requisitos para desenvolver testes de validação do sistema.
Engenheiros de manutenção de sistema – Usam os requisitos para entender o sistema e os relacionamentos entre suas partes.
8. De acordo com Sommerville, quais as diretrizes orientadas para uma linguagem natural?
- Invente um formato-padrão e garanta que todas as definições de requisitos aderem a esse formato. A padronização do formato torna menos prováveis as omissões e mais fácil a verificação dos requisitos. O formato que eu uso expressa o requisito em uma única frase. Eu associo uma declaração com a justificativa para cada requisito de usuário para explicar por que o requisito foi proposto. A justificativa também pode incluir informações sobre quem propôs o requisito (a fonte do requisito), para saber quem consultar caso o requisito tenha de ser mudado.
- Use uma linguagem consistente para distinguir entre os requisitos obrigatórios e os desejáveis. Os obrigatórios são requisitos aos quais o sistema tem de dar suporte e geralmente são escritos usando-se ‘deve’. Requisitos desejáveis não são essenciais e são escritos usando-se ‘pode’.
- Use uma forma de destacar as partes fundamentais do requisito (negrito, itálico ou cores).
- Não assuma que compreendem a linguagem técnica da engenharia de software. Frequentemente, palavras como ‘arquitetura’ e ‘módulo’ são mal interpretadas. Você deve, portanto, evitar o uso de jargões, siglas e acrônimos.
- Sempre que possível, tente associar uma lógica a cada um dos requisitos de usuário. Essa justificativa deve explicar por que o requisito foi incluído, e é particularmente útil quando os requisitos são alterados, uma vez que pode ajudar a decidir sobre quais mudanças seriam indesejáveis.
Referências
Sommerville, Ian
Engenharia de Software / Ian Sommerville ; tradução Ivan Bosnic e Kalinka G. de O. Gonçalves ; revisão técnica Kechi Hirana – 9.ed – São Paulo : Pearson Prentice Hall, 2011.
Titulo original: Software engineering.
ISBN 978-85-7936-108-1