Efter- og videreuddannelse i sundhedssektoren

A Figura II.8 abaixo destaca os quatro subprocessos da Engenharia de Requisitos. O estudo de viabilidade verifica se o sistema a ser desenvolvido é útil ao negócio. As fases de elicitação e análise tratam da descoberta dos requisitos, a especificação converte estes requisitos em alguma forma padrão e a fase de validação verifica se os requisitos realmente definem o sistema que os stakeholders esperam (SOMMERVILLE, 2007).

Figura II.8 - Subprocessos do processo de Engenharia de Requisitos Fonte: baseado em Kotonya e Sommerville (1998); Sommerville (2007)

Estudo de viabilidade

A entrada do estudo de viabilidade corresponde a um conjunto preliminar de requisitos do negócio e corresponde a uma descrição resumida do sistema e de que modo este deverá dar apoio aos processos de negócio. O resultado do estudo de viabilidade pode ser um relatório que recomende se vale a pena seguir o processo de levantamento de requisitos.

Neste estudo, várias fontes devem ser consultadas, tais como gerentes de departamentos onde o sistema será utilizado, engenheiros de software com familiaridade no sistema proposto, especialistas em tecnologia e usuários finais desse sistema. Dependo do resultado deste estudo, poderão ser propostas mudanças em seu escopo, orçamento e cronograma do sistema, além de requisitos complementares ao mesmo.

Elicitação e análise de requisitos

Essencialmente, o subprocesso de elicitação de requisitos é relacionado com a descoberta dos requisitos do sistema e compreensão das necessidades dos usuários. Assim, analistas e engenheiros de software trabalham com clientes e usuários finais no domínio da aplicação para descobrir o problema a ser resolvido, os serviços do sistema, o desempenho necessário, restrições de hardware e outras informações. Nos dados do Quadro II.2, Kotonya e Sommerville (1998) apresentam os papéis essenciais para a execução da atividade de elicitação de requisitos.

Quadro II.2 - Papéis no processo de Engenharia de Requisitos

Papel Descrição

Especialista do domínio Responsável por prover informações sobre o domínio de aplicação e do problema específico a ser resolvido naquele domínio

Usuário final Responsável pelo uso do sistema após a entrega

Engenheiro de Requisitos Responsável por identificar e especificar os requisitos do sistema

Engenheiro de Software Responsável por desenvolver o protótipo do sistema

Gerente de Projeto Responsável pelo planejamento do projeto Fonte: Kotonya e Sommerville (1998)

Observa-se que nenhuma definição fornece a real dimensão da dificuldade na condução da atividade. Tal dificuldade surge da natureza menos técnica e mais social da atividade de ER, como destacam Goguen e Linde(1993).

A forte influência das questões sociais acaba por introduzir problemas nos requisitos levantados, e estes problemas precisam ser identificados para que possam ser tratados. Entre os problemas comuns enfrentados na atividade de elicitação, Kotonya e Sommerville (1998) citam:

A forma dispersa como são encontrados os requisitos (em livros, manuais, conhecimento de pessoas específicas, etc.);

A terminologia específica do domínio da aplicação que precisa ser compreendida para garantir o entendimento do problema no contexto do domínio da aplicação;

A tarefa de auxiliar no levantamento de requisitos é, via de regra, secundária no contexto de trabalho dos stakeholders, constituindo uma barreira à

execução do trabalho de requisitos, culminando com o não envolvimento dos stakeholders no processo de requisitos;

Questões organizacionais e fatores políticos que exercem grande influência sobre os requisitos, este fatores nem sempre são identificados pelos usuários finais e podem passar despercebidos pelo engenheiro de requisitos.

Além destes problemas, a possibilidade de automação altera a perspectiva dos stakeholders sobre o próprio trabalho, fazendo com que não tenham uma correta percepção sobre os requisitos do sistema (KRUCHTEN, 2003).

Segundo Sommerville (2007), a fase de elicitação de requisitos é apresentada em quatro atividades:

Descoberta dos requisitos: corresponde ao processo de reunir informações sobre o sistema proposto e o SI existente, extraindo os requisitos dos usuários e do sistema destas informações. As fontes de informação utilizadas na descoberta de requisitos incluem documentação, stakeholders do sistema e especificações de sistemas similares. Várias técnicas são usadas para a descoberta destes requisitos que são discutidas no item II.8. Somando-se aos stakeholders de sistema, devem ser empregados os requisitos oriundos do domínio da aplicação e de outros sistemas que interagem com o sistema que está sendo especificado. Estas fontes de requisitos (stakeholders, domínio e sistema) podem todas ser representadas por pontos de vista de sistema, pois cada ponto de vista representa um subconjunto dos requisitos do sistema (NUSEIBEH et al., 2003; SABETZADEH et al., 2010);

Classificação e organização dos requisitos: esta atividade trabalha com requisitos vindos de diferentes stakeholders distribuídos em coleções desestruturadas, grupos relacionados e sobreposição entre requisitos, organizando-os em famílias coerentes. A maneira mais comum de agrupar os requisitos é pela utilização dos modelos da arquitetura do sistema para identificar subsistemas e requisitos associados a cada subsistema;

Negociação e priorização dos requisitos: quando múltiplos tipos de stakeholders estão envolvidos, inevitavelmente, haverá conflito nos requisitos. Esta atividade relaciona-se com a priorização dos requisitos, encontrando e resolvendo conflitos por meio da negociação.

Documentação de requisitos: nesta atividade, os requisitos que foram descobertos são documentados de modo que poderão ser empregados na ajuda de novas descobertas de requisitos.

Especificação de requisitos

A especificação de requisitos ou documento de requisitos tem por finalidade formalizar os requisitos que serão utilizados como referência para as outras fases do ciclo de vida do software.

O documento de requisitos é o meio empregado para descrever as restrições quanto às características do produto e quanto ao processo de desenvolvimento, a interface com outras aplicações, a informação a respeito do domínio da aplicação e informações de suporte ao conhecimento do problema, tais como: modelos, termos especializados do negócio, recuperação e gerenciamento de informações em mudança.

A informação que deve ser incluída na especificação, depende do tipo de software que está sendo desenvolvido e da abordagem de desenvolvimento utilizada. Se uma abordagem evolucionária é adotada para o desenvolvimento do software, a especificação de requisitos pode deixar fora muitos detalhes sobre os mesmos. O objetivo será definir os requisitos do usuário e os requisitos não funcionais de alto nível. Neste caso, os programadores e projetistas devem usar seu julgamento para decidir como alcançar requisitos do sistema (SOMMERVILLE , 2007).

Validação

Após a documentação dos requisitos ter sido produzida, inicia-se o processo de validação, buscando verificar se os requisitos estão certos, ou seja, descritos de forma apropriada, procurando eliminar os problemas dos requisitos incompletos, ambiguidade, inconsistência, facilidade de verificação por meio de testes e verificação de validade entre requisitos. A validação dos requisitos sobrepõe-se à descoberta e análise, na medida que a mesma também se refere à busca de problemas nos requisitos.

Uma das técnicas mais importantes utilizadas na validação corresponde à revisão dos requisitos, no qual são analisados sistematicamente por um grupo de revisores.

Na revisão, o grupo de desenvolvimento do sistema caminha com o cliente do sistema por meio dos requisitos, explicando as implicações de cada um deles. Os revisores devem verificar cada requisito com respeito à sua consistência, assim como observar se os requisitos estão completos (KOTONYA; SOMMERVILLE, 1998).

Gerenciamento

Embora não seja uma, permeia todas as fases da Engenharia de Requisitos, sendo responsável por controlar a evolução dos requisitos de um sistema, seja pela constatação de novas necessidades, seja pela comprovação das deficiências nos requisitos registrados até o momento.

Sempre que os requisitos alocados forem alterados, os planos de software, os artefatos e as atividades afetadas devem sofrer ajustes para continuarem consistentes. Um aspecto importante é que os requisitos sejam dinâmicos e estejam em uso durante todo o ciclo de vida, sendo a base para a modelagem do sistema. Congelar os requisitos, após a etapa de validação, é inviável, já que os negócios não são estáveis. Como eles se adaptam às mudanças, os sistemas também devem se adaptar. A capacidade de adaptação do processo do desenvolvimento é hoje um diferencial estratégico entre as empresas de software. Esta capacidade de adaptação é mérito em grande parte do processo do gerenciamento de requisitos.