Requisitos Externos

São requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento, como:

• Requisitos Éticos;
• Requisitos Legais (como política de privacidade e direitos autorais);
• Requisitos Reguladores.

Exemplos: o sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes, além de seus nomes e o número de referência (legislação de privacidade); em razão das restrições referentes aos direitos autorais, alguns documentos devem ser excluídos imediatamente ao serem fornecidos; utilização de uma interface padrão utilizando uma determinada norma; disponibilização de arquivos somente para leitura por causa dos direitos autorais.

Etapas da Engenharia de Requisitos

A Engenharia de Requisitos reúne as primeiras atividades a serem realizadas nos diversos modelos de processo de software. Seu objetivo é definir o que deve ser feito e não a forma como será implementado o sistema. Serve como ponte entre o projeto e a construção do software e define as bases do contrato entre o desenvolvedor e o cliente. Realiza a aquisição, o refinamento e a verificação das necessidades do sistema. A meta é sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa do sistema para elaboração do DERS (Documento de Especificação de Requisitos de Software).

A Engenharia de Requisitos fornece um mecanismo adequado para entender o que o cliente deseja, analisar as suas necessidades, negociar uma solução adequada ao seu problema, validar a especificação e administrar os requisitos à medida que eles são transformados em um sistema em operação. De acordo com Pressman (2011, p. 127), o processo de ER abrange as etapas de concepção, levantamento, elaboração, negociação, especificação, validação e gestão, que são apresentadas a seguir.

Engenharia de requisitos. Fonte: Danang Setiawan/shutterstock

Concepção ou Estudo de Viabilidade do Sistema

O estudo de viabilidade é um estudo breve, direcionado, que se destina a responder a algumas perguntas:

• O sistema contribui para os objetivos gerais da empresa?
• O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo?
• O sistema pode ser integrado com outros sistemas já em operação?

Após responder essas questões é necessário questionar as fontes de informação (stakeholders). Para isso, são recomendadas algumas perguntas, como:

• Como a empresa se comportaria se esse sistema não fosse implementado?
• Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas?
• Que contribuição direta o sistema trará para os objetivos da empresa?
• As informações podem ser transferidas para outros sistemas e também podem ser recebidas a partir deles?
• O sistema requer tecnologia que não tenha sido utilizada anteriormente na empresa?
• O que precisa e o que não precisa ser compatível com a empresa?
• Quem vai usar o sistema?

Após obter essas respostas, deve-se preparar um relatório de viabilidade.

Levantamento dos Requisitos

O levantamento de requisitos busca descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve oferecer, o desempenho exigido, dentre outros. O levantamento de requisitos pode envolver diferentes tipos de pessoas da empresa, os stakeholders. Frequentemente os clientes não sabem o que querem do sistema computacional, a não ser em termos muito gerais. Costumam expressar os requisitos utilizando seus próprios termos e com o conhecimento implícito de sua área de atuação. Diferentes stakeholders têm em mente diferentes requisitos e podem expressá-los de maneiras distintas. Além disso, fatores políticos podem influenciar os requisitos do sistema. O ambiente econômico e de negócios, no qual a análise de requisitos ocorre, é dinâmico, ou seja, inevitavelmente o ambiente se modifica durante o projeto. Como consequência, a importância dos requisitos específicos pode mudar. Assim, novos requisitos podem surgir por parte dos novos stakeholders, que não haviam sido consultados inicialmente.

Análise de Requisitos

As informações obtidas do cliente durante a concepção e o levantamento são expandidas e refinadas durante a análise (ou elaboração) de requisitos. Esta atividade da ER tem por objetivo desenvolver um modelo técnico refinado das funções, características e restrições do software. É guiada pela criação e refinamento de cenários do usuário que descrevem como o usuário final (e outros atores) vão interagir com o sistema.

Negociação de requisitos. Fonte: Reenya/shutterstock

Negociação dos Requisitos

A negociação categoriza e organiza os requisitos em subconjuntos relacionados. Neste passo, as seguintes perguntas devem ser respondidas:

• Cada requisito está consistente com o objetivo global do sistema?
• Todos os requisitos foram especificados no nível de abstração adequado?
• O requisito é realmente necessário ou representa uma característica adicional que pode não ser essencial para o objetivo do sistema?
• Cada requisito é limitado e não ambíguo?
• Cada requisito tem atribuição (será utilizado por alguém)?
• Algum requisito conflita com outros requisitos?
• Cada requisito é realizável no ambiente técnico?
• Cada requisito pode ser testado quando estiver implementado?
• Qual é a prioridade desse requisito?

Especificação dos Requisitos

Especificação de Requisitos geralmente é um documento escrito, que contém o detalhamento do sistema, os requisitos funcionais e não funcionais e os modelos do sistema que podem ser representados por meio de diagramas como IDEF0 (Integration Definition for Function Modeling), diagramas de casos de uso da UML (Unified Modeling Language), diagramas de classes preliminar, diagramas de sequência e prototipação.

Validação dos Requisitos

A validação de requisitos examina a especificação de requisitos para garantir que todos os requisitos do sistema tenham sido identificados e detalhados, que as inconsistências, omissões e erros tenham sido detectadas e corrigidas e que as prioridades tenham sido estabelecidas. Tem a função de mostrar que os requisitos realmente definem o sistema que o cliente deseja. São realizadas diversas verificações, como:

• Verificações de validade: Um usuário pode pensar que um sistema é necessário para realizar certas funções, mas mais estudos e análises podem identificar funções adicionais ou diferentes necessárias.
• Verificações de consistência: Os requisitos em um documento não devem ser conflitantes, ou seja, não devem existir restrições contraditórias ou descrições diferentes para uma mesma função do sistema.
• Verificações de completeza: O documento de requisitos (DERS) deve incluir requisitos que definam todas as funções e restrições exigidas pelo usuário do sistema.
• Verificações de realismo: Utilizando o conhecimento da tecnologia existente, os requisitos devem ser verificados, a fim de assegurar que eles realmente podem ser implementados. Essas verificações devem também levar em conta o orçamento e os prazos para o desenvolvimento do sistema.
• Facilidade de verificação: Para reduzir o potencial de divergências entre cliente e desenvolvedor, os requisitos do sistema devem sempre ser escritos de modo que possam ser verificados. Isso significa que um conjunto de verificações pode ser projetado para mostrar que o sistema entregue cumpre com esses requisitos, como:
• O requisito é realmente passível de ser testado, como foi definido?
• O requisito pode ser adequadamente compreendido pelos compradores ou usuários finais do sistema?
• A origem do requisito é claramente definida?
• O requisito é adaptável?
• Ele pode ser modificado sem que isso provoque efeitos em grande escala em outros requisitos do sistema?

De acordo com Pressman (2011, p. 381) um dos mecanismos de validação de requisitos é a RTF (Revisão Técnica Formal). Em uma RTF com esse propósito, a equipe de desenvolvimento deve conduzir o cliente pelos requisitos do sistema, explicando as implicações de cada requisito. A equipe de revisão deve verificar cada requisito, em termo de sua consistência e verificar os requisitos como um todo sob o ponto de vista de sua completeza. A RTF é uma atividade que garante a qualidade do software.

Gestão de Requisitos

 

 

Gestão de requisitos. Fonte: Iconic Bestiary/shutterstock

Gestão de Requisitos é um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos a qualquer momento no desenvolvimento do sistema. Para auxiliar na gestão de requisitos tabelas de rastreamento são criadas com o objetivo de verificar as relações entre requisitos e o impacto da mudança de requisitos. Os requisitos mudam e há uma série de razões para isso, como: os problemas podem ser muito intricados, as especificações podem ficar incompletas, o aumento do entendimento do sistema ocorre ao longo do projeto,como há vários usuários, há várias visões,  quem paga pelo sistema geralmente é diferente de quem o usa, a empresa e o ambiente se modificam e, na medida em  que os  usuários se familiarizam com o sistema, novos requisitos surgem. A gestão de requisitos precisa de apoio automatizado, como ferramentas CASE (Computer Aided Software Engineering), para:

• Armazenamento de requisitos: os requisitos devem ser mantidos em um depósito de dados seguro, gerenciado, que seja acessível por todos os envolvidos no processo de engenharia de requisitos.
• Gerenciamento de mudanças: esse processo pode ser simplificado se o apoio de ferramentas estiver disponível.
• Gerenciamento de facilidade de rastreamento: o apoio de ferramentas para a rastreabilidade permite que requisitos relacionados sejam descobertos.

Sommerville (2011, p. 70) apresenta as atividades de Engenharia de Requisitos, conforme ilustra a figura.

Visão em espiral das atividades da Engenharia de Requisitos

Fonte: SOMMERVILLE (2011, p. 70)

O autor define a ER como um conjunto de atividades que visam avaliar se o sistema é útil para a organização (estudo de viabilidade), realizar o levantamento de requisitos (elicitação e análise), converter os requisitos para um padrão (especificação) e verificar se realmente os requisitos são capazes de definir o que o cliente deseja (validação). Essas atividades são organizadas em torno de uma espiral, como um processo iterativo, cuja saída resulta no DERS (Documento de Especificação de Requisitos de Software).