Engenharia de requisitos – Introdução (Parte 1)
Discutimos anteriormente as 4 principais actividades da engenharia de requisitos.
A engenharia de requisitos é um processo de recolha e definição do que os serviços devem ser prestados pelo sistema.
Foca na avaliação da utilidade do sistema para o negócio (estudo de viabilidade), descoberta de requisitos (elicitação e análise), conversão desses requisitos em algum formato padrão (especificação), e verificação de que os requisitos definem o sistema que o cliente deseja (validação).
Na prática, a engenharia de requisitos não é um processo sequencial, é um processo iterativo no qual as atividades são intercaladas.
Por exemplo, itera primeiro os requisitos do usuário; elicitação, especificação e validação, e repetir as mesmas etapas para os requisitos do sistema.
>
No processo, a maior parte do esforço será gasto na compreensão dos requisitos de alto nível do negócio e do usuário. Mais tarde no processo, mais esforços serão gastos na elicitação e compreensão dos requisitos detalhados do sistema.
Algumas pessoas consideram a engenharia de requisitos como o processo de aplicação do método de análise estruturada, tal como a análise orientada a objetos. Isso envolve analisar o sistema e desenvolver um conjunto de modelos gráficos de sistema, como modelos de caso de uso, que então servem como uma especificação de sistema.
Embora os métodos estruturados tenham um papel a desempenhar no processo de engenharia de requisitos, há muito mais na engenharia de requisitos do que o que é coberto por esses métodos.
Análise e projeto orientado a objetos serão discutidos em outra série de tutoriais.
Requisitos do usuário e do sistema
Tipicamente, os requisitos são apresentados em dois níveis de detalhe; requisitos do usuário e do sistema, onde o usuário precisa de uma declaração de alto nível dos requisitos, enquanto os desenvolvedores do sistema precisam de uma especificação mais detalhada do sistema. Assim, os requisitos do usuário e do sistema são apenas referentes a diferentes níveis de detalhe.
Discrever diferentes níveis de detalhe é útil porque comunica informações sobre o sistema que está sendo desenvolvido para diferentes tipos de leitores.
Então, os usuários finais não estarão preocupados com os detalhes, eles precisam de um requisito escrito genérico e abstraído.
Embora as pessoas que estão envolvidas no desenvolvimento, elas precisam exatamente o que o sistema deve fazer.
Você provavelmente acabará com muitos problemas e mal-entendidos se você não tiver uma separação clara entre os diferentes níveis de detalhe.
Requisitos do usuário
Descreve os serviços que o sistema deve fornecer e as restrições sob as quais ele deve operar. Não esperamos ver nenhum nível de detalhe, ou o que exatamente o sistema fará, É mais de requisitos genéricos.
É normalmente escrito em uma linguagem natural e fornecido por diagramas.
Discutiremos diferentes formas de especificar os requisitos mais adiante nesta série.
Requisitos do sistema
Os requisitos do sistema significam uma descrição mais detalhada dos serviços do sistema e das restrições operacionais, como a forma como o sistema será usado, e restrições de desenvolvimento, como as linguagens de programação.
Este nível de detalhe é necessário para aqueles que estão envolvidos no desenvolvimento do sistema, como engenheiros, arquitetos de sistema, testadores, etc.
Funcional &Requisitos não-funcionais
Os requisitos de software são classificados em requisitos funcionais e não-funcionais.
Requisitos funcionais
Cobre as principais funções que devem ser fornecidas pelo sistema. Quando expressos como requerimento do usuário, eles são geralmente descriminados de forma abstrata.
No entanto, requerimentos funcionais mais específicos do sistema descrevem as funções do sistema, suas entradas, processamento; como ele vai reagir a uma determinada entrada, e qual é a saída esperada.
Requisitos não-funcionais
Estas são as restrições sobre as funções fornecidas pelo sistema.
As restrições, como quantos processos o sistema pode lidar (desempenho), quais são as questões (de segurança) que o sistema precisa cuidar, como injeções SQL …
A taxa de falhas (confiabilidade), quais são as linguagens e ferramentas que serão usadas (desenvolvimento), quais são as regras que você precisa seguir para garantir que o sistema opere dentro da lei da organização (legislativa).
Requisitos não-funcionais são muitas vezes críticos do que os requisitos funcionais individuais. Os usuários geralmente podem encontrar maneiras de trabalhar em torno de uma função do sistema que não atende realmente às suas necessidades. No entanto, não atender a um requisito não-funcional pode significar que todo o sistema é inutilizável.
Por exemplo, se uma aeronave não significa atender aos requisitos de confiabilidade, não será segura para a operação, ou se um sistema de controle incorporado não atender aos requisitos de desempenho, as funções de controle não funcionarão corretamente.
Requisitos não-funcionais devem ser mensuráveis
Quando possível, devemos escrever requisitos não-funcionais quantitativamente, para que eles possam ser testados. Você pode medí-los quando o sistema sendo testado para verificar se o sistema atende aos requisitos não-funcionais.
Na prática, os clientes de um sistema muitas vezes acham difícil traduzir seus objetivos em requisitos mensuráveis. Eles não entendem o número que define a velocidade ou confiabilidade necessária. Para alguns objetivos, como a manutenção, não há métricas que possam ser usadas.
O custo de verificar requisitos não-funcionais mensuráveis pode ser muito alto e os clientes podem pensar que esses custos não são justificados.
Requisitos não-funcionais e funcionais são dependentes
Requisitos não-funcionais muitas vezes entram em conflito, interagem ou até mesmo geram outros requisitos funcionais ou não-funcionais.
Um requisito de usuário preocupado com a segurança, como limitar o acesso a usuários autorizados, pode gerar outros requisitos que são funcionais, como a necessidade de incluir facilidades de autenticação de usuário no sistema.
A distinção entre requisitos funcionais e não-funcionais
Na prática, é difícil separar requisitos funcionais e não-funcionais. A distinção não é clara como suas definições sugerem.
Separar entre requisitos funcionais e não-funcionais
Se os requisitos não-funcionais forem declarados separadamente dos requisitos funcionais, a relação entre eles pode ser difícil de entender.
No entanto, devemos destacar explicitamente os requisitos que estão claramente relacionados às propriedades emergentes do sistema, tais como desempenho ou confiabilidade.
As propriedades emergentes são propriedades do sistema como um todo e não propriedades que podem ser derivadas das propriedades dos componentes individuais do sistema.