Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objetivos e requisitos para os quais foi construído. De forma geral, a Engenharia de Requisitos de Software é o processo de identificar todos os envolvidos, descobrir seus objetivos e necessidades e documentá-los de forma apropriada para análise, comunicação e posterior implementação.
Requisito e Tipos de Requisitos
As descrições das funções que um sistema deve incorporar e das restrições que devem ser satisfeitas são os requisitos para o sistema. Isto é, os requisitos de um sistema definem o que o sistema deve fazer e as circunstâncias sob as quais deve operar. Em outras palavras, os requisitos definem os serviços que o sistema deve fornecer e dispõem sobre as restrições à operação do mesmo.
Requisitos são, normalmente, classificados em requisitos funcionais e não funcionais. Requisitos funcionais, como o próprio nome indica, apontam as funções que o sistema deve fornecer e como o sistema deve se comportar em determinadas situações. Já os requisitos não funcionais descrevem restrições sobre as funções oferecidas, tais como restrições de tempo, de uso de recursos etc. Alguns requisitos não funcionais dizem respeito ao sistema como um todo e não a funcionalidade específica. Dependendo da natureza, os requisitos não funcionais podem ser classificados de diferentes maneiras, tais como requisitos de desempenho, requisitos de portabilidade, requisitos legais, requisitos de conformidade etc.
O Processo da Engenharia de Requisitos
O processo de descobrir, analisar, documentar e verificar / validar requisitos é chamado de processo de engenharia de requisitos. Os processos de engenharia de requisitos variam muito de uma organização para outra, mas, de maneira geral, a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades:
• Elicitação / Descoberta / Levantamento de Requisitos: Nesta fase, os usuários, clientes e especialistas de domínio são identificados e trabalham junto com os engenheiros de requisitos para descobrir, articular e entender a organização como um todo, o domínio da aplicação, os processos de negócio específicos, as necessidades que o software deve atender e os problemas e deficiências dos sistemas atuais. Os diferentes pontos de vista dos participantes do processo, bem como as oportunidades e restrições existentes, os problemas a serem resolvidos, o desempenho requerido e as restrições também devem ser levantados.
• Análise de Requisitos: visa a estabelecer um conjunto acordado de requisitos consistentes e sem ambigüidades, que possa ser usado como base para o desenvolvimento do software. Para tal, diversos tipos de modelos são construídos. Geralmente, a análise de requisitos inclui também a negociação para resolver conflitos detectados.
• Documentação de Requisitos: é a atividade de representar os resultados da Engenharia de Requisitos em um documento, contendo os requisitos do software.
• Verificação e Validação de Requisitos: A verificação de requisitos avalia se o documento de Especificação de Requisitos está sendo construído de forma correta, de acordo com padrões previamente definidos, sem conter requisitos ambíguos, incompletos ou, ainda, requisitos incoerentes ou impossíveis de serem testados. Já a validação diz respeito a avaliar se esse documento está correto, ou seja, se os requisitos e modelos documentados atendem às reais necessidades e requisitos dos usuários / cliente.
• Gerência de Requisitos: se preocupa em gerenciar as mudanças nos requisitos já acordados, manter uma trilha dessas mudanças, gerenciar os relacionamentos entre os requisitos e as dependências entre o documento de requisitos e os demais artefatos produzidos no processo de software, de forma a garantir que mudanças nos requisitos sejam feitas de maneira controlada e documentada.
É possível notar que, das cinco atividades do processo de Engenharia de Requisitos anteriormente listadas, as três últimas são, na realidade, instanciações para a Engenharia de Requisitos de atividades genéricas já discutidas no capítulo 4, a saber: documentação, garantia da qualidade e gerência de configuração. Assim sendo, neste capítulo, somente as duas primeiras atividades (Levantamento e Análise de Requisitos) são discutidas.
Levantamento de Requisitos
O levantamento de requisitos é uma atividade complexa que não se resume somente a perguntar às pessoas o que elas desejam e também não é uma simples transferência de conhecimento. Várias técnicas de levantamento de requisitos são normalmente empregadas pelos engenheiros de requisitos (ou analistas de sistemas), dentre elas entrevistas, questionários, prototipação, investigação de documentos, observação, dinâmicas de grupo etc.
Análise de Requisitos
A análise de requisitos (muitas vezes chamada análise de sistemas) é, em última instância, uma atividade de construção de modelos. Um modelo é uma representação de alguma coisa do mundo real, uma abstração da realidade, e, portanto, representa uma seleção de características do mundo real relevantes para o propósito do sistema em questão. Modelos são fundamentais no desenvolvimento de sistemas. Tipicamente eles são construídos para:
• possibilitar o estudo do comportamento do sistema;
• facilitar a comunicação entre os componentes da equipe de desenvolvimento e clientes e usuários;
• possibilitar a discussão de correções e modificações com o usuário;
• formar a documentação do sistema.
Um modelo enfatiza um conjunto de características da realidade, que corresponde à dimensão do modelo. Além da dimensão que um modelo enfatiza, modelos possuem níveis de abstração. O nível de abstraçãode um modelo diz respeito ao grau de detalhamento com que as características do sistema são representadas. Em cada nível há uma ênfase seletiva nos detalhes representados. No caso do desenvolvimento de sistemas, geralmente, são considerados três níveis:
‰conceitual: considera características do sistema independentes do ambiente computacional (hardware e software) no qual o sistema será implementado. Essas características são dependentes unicamente das necessidades do usuário. Modelos conceituais são construídos na atividade de análise de requisitos.
lógico: características dependentes de um determinado tipo de sistema computacional. Essas características são, contudo, independentes de produtos específicos. Tais modelos são típicos da fase de projeto.
físico: características dependentes de um sistema computacional específico, isto é, uma linguagem e um compilador específico, um sistema gerenciador de bancos de dados específico, o hardware de um determinado fabricante etc. Tais modelos podem ser construídos tanto na fase de projeto quanto na fase de implementação.
Conforme apontado acima, nas primeiras etapas do processo de desenvolvimento (levantamento de requisitos e análise), o engenheiro de software representa o sistema através de modelos conceituais. Nas etapas posteriores, as características lógicas e físicas são representadas em novos modelos. Para a realização da atividade de análise, uma escolha deve ser feita: o paradigma de desenvolvimento. Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e, portanto, definem as características básicas dos modelos a serem construídos. Por exemplo, o paradigma orientado a objetos parte do pressuposto que o mundo é povoado por objetos, ou seja, a abstração básica para se representar as coisas do mundo são os objetos. Já o paradigma estruturado adota uma visão de desenvolvimento baseada em um modelo entrada-processamento-saída. No paradigma estruturado, os dados são considerados separadamente das funções que os transformam e a decomposição funcional é usada intensamente.
fonte: UFES
Pronto! Pronto!