1.
Introdução
Os sistemas de informação estão presentes em diversas, senão
todas, áreas de aplicação e são reconhecidamente importantes ativos
estratégicos para diversas organizações, pois, apresentam um papel vital de
apoio nos processos organizacionais e nas tomadas de decisões. Entretanto, é de
fundamental importância que estes sistemas de informação apoiem adequadamente e
corretamente todos os requisitos estabelecidos no domínio da aplicação,
respeitando sempre, o escopo pré-determinado. Neste contexto, a identificação e
o entendimento dos requisitos se tornam as principais tarefas do
desenvolvimento de software.
A Engenharia de Requisitos é descrita por SOMMERVILLE (2011)
como o processo de descobrir, analisar, documentar e verificar as funções e
restrições do sistema, tendo como objetivo criar e manter um documento de
requisitos de sistema.
Este texto apresenta os conceitos relacionados a Engenharia
de Software, relatando, inicialmente, o que são requisitos de um sistema e
alguns tipos de requisitos, seguido por uma maior explanação sobre a Engenharia
de Requisitos e seus subprocessos, que são a elicitação e análise de requisistos,
a especificação e a validação dos requisitos.
É importante ressaltar que este texto considera o público
discente dos cursos técnicos e tecnológicos do eixo de informação e comunicação
do IFPR câmpus Paranavaí.
2. Requisitos
Os requisitos de software tem um papel fundamental no
processo de desenvolvimento de software, e eles são considerados fatores
determinantes para o sucesso ou fracasso de um projeto de software.
SOMMERVILLE (2011) conceitua requisito de um sistema como
sendo descrições dos serviços que devem ser fornecidos por este sistema e suas
restrições operacionais. E a IEEE conceitua requisito como uma condição ou uma
funcionalidade necessária ao usuário para resolver um problema (PRESSMAN, 2011).
A partir destas definições, podemos dizer que os requisitos
de um sistema incluem as especificações dos serviços que os sistemas devem
prover as restrições sobre as quais ele deve operar, as propriedades gerais que
o software deve atender e as necessidades e limitações que devem ser
satisfeitas ao longo do processo de desenvolvimento.
As definições de requisitos apontam para diferentes tipos de
requisitos, de forma genérica, podemos classificar os requisitos como
requisitos funcionais, requisitos não funcionais e requisitos de domínio.
Entretanto, há na literatura os requisitos de sistema e requisitos de
interface.
2.1. Requisitos Funcionais
Os requisitos funcionais estão diretamente relacionados às
funcionalidades dos sistemas. São declarações de serviços que o sistema deve
fornecer; como o sistema deve reagir a entradas específicas; e como o sistema
deve se comportar em determinadas situações. Podendo, em algumas situações,
determinar explicitamente o que o sistema não deve fazer (SOMMERVILLE, 2011).
Também é de responsabilidade dos requisitos funcionais
descrever as interações entre o sistema e seu ambiente, por exemplo: “O
software deve permitir que o atendente realize o cadastro do paciente”
(SOMMERVILLE, 2011).
2.2. Requisitos Não Funcionais
Os requisitos não funcionais descrevem as restrições sobre
os serviços ou funções que o sistema deve prover, expressando condições que o
software deve atender ou qualidades específicas que o software deva ter
(PRESSMAN, 2011; SOMMERVILLE, 2011). Estes requisitos são muito importantes
para a fase de projeto, servindo como base para tomada de decisão nesta fase.
A origem dos requisitos não funcionais está em fatores como:
nas necessidades dos usuários; em restrições de orçamentos; em políticas
organizacionais; necessidades de interoperabilidade com outros sistemas ou
hardware; e, até mesmo, fatores externos como regulamentos e legislações. Estes
requisitos podem ser mais críticos do que os requisitos funcionais, pois, caso
o software não venha a atender algum requisito não funcional pode se tornar
inútil (SOMMERVILLER, 2011). Logo, os requisitos não funcionais podem ser
classificados quanto à sua origem. SOMMERVILLE (2011) classifica-os em:
- Requisitos de produto: especificam o comportamento do software. Referem-se a atributos de qualidade que o sistema deve apresentar, tais como confiabilidade, usabilidade, eficiência, portabilidade, manutenibilidade e segurança;
- Requisitos organizacionais: são derivados de metas, políticas e procedimentos das organizações do cliente e do desenvolvedor. Incluem requisitos de processo (padrões de processo e modelos de documentos que devem ser usados), requisitos de implementação (tal como a linguagem de programação a ser adotada), restrições de entrega (tempo para chegar ao mercado, restrições de cronograma etc.), restrições orçamentárias (custo, custo-benefício) etc
- Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos de interoperabilidade com sistemas de outras organizações, requisitos legais (tais como requisitos de segurança e privacidade) e requisitos éticos.
É importante ressaltar que a identificação de um requisito
não funcional deve ser realizada de forma que o mesmo possa ser validado. Logo,
um requisito não funcional deve ser mensurável. Portanto, os requisitos não
funcionais devem ser elaborados até que os mesmos se tornem verificáveis.
2.3 Requisitos de Domínio
Além da classificação de requisitos funcionais e não
funcionais, SOMMERVILLE (2011) considera também os requisitos de domínio e o
define como requisitos provenientes do domínio de aplicação do sistema e
refletem características e restrições desse domínio. Estes requisitos são
derivados do domínio da aplicação e podem ser requisitos funcionais novos,
restrições sobre requisitos existentes ou computações específicas, refletindo
fundamentos do domínio da aplicação. Para exemplificar, um requisito de domínio
pode ser um cálculo que deve ser realizado para uma determinada funcionalidade.
Na literatura, encontramos autores que
compreendem requisitos de domínio como sendo regras de negócio e essas regras
de negócio, assim como os requisitos de domínio, incluem terminologias
específicas do domínio da aplicação e são mais facilmente capturadas em uma
fase de modelagem conceitual.
2.4 Requisitos de Usuários e Requisitos de Sistema
Considerando que os requisitos devem ser passíveis de
entendimento a todos os envolvidos com o seu processo, como os stakeholders[1]
(cliente, usuários, desenvolvedores) e que, cada envolvido possui expectativas
diferentes, SOMMERVILLE (2011) sugere mais dois níveis de classificação para
requisitos, sendo os requisitos de sistema e requisitos de usuários.
Os requisitos de usuários são declarações em linguagem
natural acompanhadas de diagramas intuitivos de quais serviços são esperados do
sistema e das restrições sob as quais ele deve operar. Devem estar em um nível
de abstração mais alto, de modo que sejam compreensíveis pelos usuários do
sistema que não possuem conhecimento técnico.
Os requisitos de sistema definem detalhadamente as funções,
serviços e restrições do sistema. São versões expandidas dos requisitos de
usuário usados pelos desenvolvedores para projetar, implementar e testar o
sistema. Como requisitos de sistema são mais detalhados, as especificações em
linguagem natural são insuficientes e para especificá-los, portanto, notações mais especializadas, como o exemplo
diagramas da UML (Linguagem de Modelagem Unificada) devem ser utilizadas.
Vale destacar que esses níveis de descrição de requisitos
são aplicados em momentos diferentes e com propósitos distintos. Requisitos de
usuário são elaborados nos estágios iniciais do desenvolvimento (levantamento
preliminar de requisitos) e servem de base para um entendimento entre clientes
e desenvolvedores acerca do que o sistema deve contemplar. Esses requisitos
são, normalmente, usados como base para a contratação e o planejamento do
projeto. Requisitos de sistema, por sua vez, são elaborados como parte dos
esforços diretos para o desenvolvimento do sistema, capturando detalhes
importantes para as fases técnicas posteriores do processo de desenvolvimento,
a saber: projeto, implementação e testes.
3. Engenharia de Requisitos
A
engenharia de requisitos pode ser descrita como um processo que compreende das
atividades relacionadas à produção (levantamento, registro, validação e
verificação) e gerência dos requisitos (controle de mudanças, gerencia de
configuração, rastreabilidade e gerencia de qualidade dos requisitos). Este
processo pode variar de organização para organização ou, até mesmo, de projeto
para projeto dentro de uma organização. A Figura
1 exibe estas atividades.
Figura 1: Atividades da Engenharia de Requisitos (Fonte: DevMidia)
Ao analisar a Figura 1
identificamos dois conceitos base para a realização do processo da Engenharia
de requisitos, que é a produção de requisitos e a gerencia de requisitos. A
produção de requisitos fornece o conjunto de requisitos que será gerenciado na
gerencia de requisitos que, por sua vez, assegura que as mudanças que ocorram
nos requisitos sejam tratadas de forma adequada durante o processo de
desenvolvimento. Logo, podemos concluir que ter um processo de gerencia de
requisitos estabelecido representa ter capacidade de lidar com mudanças que
possam ocorrer ao longo do ciclo de vida de desenvolvimento de software, além
também, de poder melhor garantir a qualidade dos requisitos elicitados. Desta
forma, é importante ressaltar que as atividades de gerencia de requisitos devem
ocorrer paralelamente as atividades de elicitação, análise e modelagem dos
requisitos, como pode ser visto na Figura 2.
Figura 2: Produção e Gerencia de Requisitos
Dentre os objetivos da engenharia de requisitos, vamos
destacar alguns neste texto:
- Estabelecer uma visão comum entre o cliente e a equipe do projeto em relação aos requisitos que serão atendidos pelo projeto de software;
- Registrar e acompanhar os requisitos ao longo de todo o processo de desenvolvimento de software;
- Documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da engenharia de software;
- Manter planos, artefatos e atividades de software consistentes com os requisitos alocados.
- Para alcançar a todos estes objetivos citados, é importante que se tenha um processo de engenharia bem definido e seguido corretamente.
SOMMERVILLE (2011)
considera que um processo de engenharia de requisitos deve contemplar, tipicamente,
as atividades mostradas na Figura 3.
Figura 3: Processo da Engenharia de Requisitos
O processo inicia-se pelo levantamento de requisitos, no
qual são identificados os requisitos que irá compor o software, levando em
conta as necessidades do cliente e usuários, informações disponíveis,
legislações, regulamentos, sistemas existentes, etc. Após a identificação dos
requisitos então inicia-se a etapa de análise, nesta etapa, os requisitos
levantados são utilizados como base para a modelagem dos requisitos. Nestas
etapas é importante documentar os requisitos, conforme já discutido
anteriormente. Após a produção dos documentos de definição e de especificação
dos requisitos, então estes são verificados e validados. Adicionalmente, um
esforço de garantia da qualidade deve ser realizado, visando garantir
conformidade em relação a padrões e ao processo estabelecidos pela organização.
Caso os cliente, usuários e desenvolvedores estejam de acordo com os requisitos
levantados, as próximas etapas do ciclo de vida de desenvolvimento de software
pode avançar, caso contrário deve-se retornar as atividades anteriores para a
eliminação dos problemas identificados.
Não há limites entre as atividades destacadas na Figura 3,
na prática elas são intercaladas e existem um alto grau de interação e feedback
entre elas. O processo é executado até que todas as partes envolvidas estejam
satisfeitos e concordem com os requisitos identificados (SOMMERVILLE, 2011).
A seguir as atividades do processo de engenharia de
requisitos são discutidas com mais detalhe.
3.1 Elicitação e Análise de Requisitos
A elicitação ou levantamento de requisitos corresponde a
fase inicial do processo de desenvolvimento de software. É uma fase
extremamente complexa e não se resume em apenas questionar os usuários do
sistema, mas sim, analisar cuidadosamente a organização, o domínio da aplicação
e todos os processos de negócio que irão compor o sistema. Nesta etapa ocorre
um trabalho conjunto entre analistas de sistemas, usuários, cliente e
especialistas do domínio da aplicação (PRESSMAN, 2011; SOMMERVILLE, 2011).
A tarefa de levantamento compreende da realização de
atividades que permitem obter informações sobre o domínio da aplicação, estas
atividades podem ser dinâmicas como: entrevistas, observações, aplicações de
questionários, realização de seminários envolvendo sempre os stakeholders, além
de consultas a documentos como legislações, tutoriais, manuais e/ou normas
internas e prototipação . Neste contexto, devemos considerar quatro dimensões
distintas, sendo:
- Entendimento do Domínio da Aplicação: compreende do entendimento geral da área que o software será aplicado.
- Entendimento do Problema: compreende do entendimento do problema específico, ou seja, compreender detalhadamente o problema específico que será implementado.
- Entendimento do negócio: compreende em entender como o sistema irá afetar a organização e como contribuirá para o desenvolvimento da organização. Para isso, deve-se conhecer, intimamente, as regras que compõem o negócio;
- Entendimento das necessidades e das restrições dos interessados: compreende em entender as demandas de apoio de trabalho de cada um dos interessados, ou seja, compreender com clareza o que cada interessado necessita que o sistema o apoie para a realização de suas atividades.
PRESSMAN (2011) comenta que a tarefa de levantamento de
requisitos é complexa pelo fato de ser dominada por fatores humanos, sociais e
organizacionais. Envolvendo pessoas diferentes com culturas e objetivos
diferentes, o que pode resultar em alguns problemas como a má definição do
escopo do projeto, no qual, leva os stakeholders a relatar detalhes técnicos
desnecessários ou omitir outros importantes; problemas de entendimento, no qual
os stakholders podem não estar totalmente certos de suas necessidades, ou
ainda, ter pouco conhecimento ou limitação sobre o domínio da aplicação, ter
dificuldades de comunicação, omitir informações que para eles podem ser óbvias,
especificar requisitos conflitantes com as necessidades de outros usuários ou
ainda, especificar requisitos ambíguos ou impossível de ser testado; e por fim,
problemas de volatilidade, no qual, os requisitos mudam ao longo do tempo.
3.2 Análise de Requisitos
Após a etapa de levantamento de requisitos, inicia-se a
etapa de análise. Nesta etapa, os requisitos são analisados e utilizados como
base para os modelos que são desenvolvidos.
De maneira bem simples, a fase de análise de requisitos se
resume em atividades de modelagem destes requisitos, no qual, é realizado a
modelagem conceitual preocupando-se apenas com o domínio do problema e não com
soluções técnicas para este problema. Os modelos construídos nesta fase são
elaborados para obter uma maior e melhor compreensão acerca do sistema que será
desenvolvido e podem ser construídos para representar diferentes perspectivas,
como:
- Perspectiva estrutural: busca modelar os conceitos, propriedades e relações do domínio que são relevantes para o sistema em desenvolvimento. Provê uma visão estática das informações que o sistema necessita tratar e, portanto, refere-se às representações que o sistema terá de prover para abstrair entidades do mundo real. Diagramas de classes são usados para modelar esta perspectiva.
- Perspectiva comportamental: visa modelar o comportamento geral do sistema, de uma de suas funcionalidades ou de uma entidade específica ao longo do tempo. Provê uma visão do comportamento do sistema ou de uma parcela do sistema. Diagramas de casos de uso, diagramas de atividades, diagramas de estados e diagramas de interação podem ser utilizados para modelar essa visão.
Por fim, é nesta etapa que são identificados problemas e
conflitos nos requisitos elicitados, e estes, devem
ser eliminados totalmente
antes de ir para a próxima etapa de engenharia de requisitos.
3.3 Documentação de Requisitos
Os documentos de requisitos, também chamado de documento de
especificação de requisitos de software é a declaração oficial do que os
desenvolvedores de sistema devem implementar (SOMMERVILLE, 2011; PRESSMAN,
2011).
Considerando que os requisitos de usuários e os requisitos
de sistemas possuem propósitos e públicos diferentes, é útil descrever o
documento de requisitos de maneira diferente, podendo ser:
- Documento de definição de requisitos: deve ser escrito de forma que o cliente[2] possa entender, deixando claro o que o cliente espera que o software faça. Este documento representa um consenso entre o cliente e o desenvolvedor na definição do escopo do software.
- Documento de especificação de requisitos: redefini os requisitos de usuários em termos técnicos, apropriados para o desenvolvimento do software, sendo produzido por analistas de requisitos.
Ambos os documentos podem ter uma correspondência direta, podendo,
o documento de definição de requisitos complementar e ser complementado pelo
documento de especificação de requisitos.
A composição dos itens do documento de especificação de
requisitos pode variar de acordo com o padrão e modelo de desenvolvimento que
está sendo seguido pela equipe de desenvolvimento.
A IEEE cita que uma boa documentação fornece muitos benefícios, como: (i) facilita a comunicação dos requisitos; (ii) reduz o esforço de desenvolvimento, pois sua preparação força usuários e clientes a considerar os requisitos atentamente, evitando retrabalho nas fases posteriores; (iii) fornece uma base realística para estimativas; (iv) fornece uma base para verificação e validação; (v) facilita a transferência do software para novos usuários e/ou máquinas e (vi) serve como base para futuras manutenções ou incremento de novas funcionalidades.
3.4 Verificação & Validação de Requisitos
A IEEE cita que uma boa documentação fornece muitos benefícios, como: (i) facilita a comunicação dos requisitos; (ii) reduz o esforço de desenvolvimento, pois sua preparação força usuários e clientes a considerar os requisitos atentamente, evitando retrabalho nas fases posteriores; (iii) fornece uma base realística para estimativas; (iv) fornece uma base para verificação e validação; (v) facilita a transferência do software para novos usuários e/ou máquinas e (vi) serve como base para futuras manutenções ou incremento de novas funcionalidades.
3.4 Verificação & Validação de Requisitos
As atividades de Verificação & Validação (V&V) devem
ser iniciadas o quanto antes no processo de desenvolvimento de software, pois
quanto mais tarde os defeitos são encontrados, maiores os custos associados à
sua correção. Uma vez que os requisitos são a base para o desenvolvimento, é
fundamental que eles sejam cuidadosamente avaliados. Assim, os documentos
produzidos durante a atividade de documentação de requisitos devem ser submetidos
à verificação e à validação.
A verificação consiste em assegurar que o software esteja
sendo construído de forma correta e a validação, por sua vez, assegura que o
software desenvolvido é o correto, ou seja, irá atender as necessidades
identificadas no levantamento de requisitos (PRESSMAN, 2011; SOMMERVILLE, 2011).
No caso de requisitos, a verificação é feita, sobretudo, em
relação à consistência entre requisitos e modelos e à conformidade com padrões
organizacionais de documentação de requisitos. Já a validação tem de envolver a
participação de usuários e clientes, pois somente eles são capazes de dizer se
os requisitos atendem aos propósitos do sistema.
As atividades de V&V consistem em examinar os documentos
de requisitos gerados para assegurar que: (i) todos os requisitos do sistema
tenham sidos declarados de modo não ambíguo. (ii) as inconsistências,
conflitos, omissões e erros tenham sido identificados e corrigidos. (iii) os
documentos estão em conformidade com
os padrões estabelecidos. (iv) os requisitos realmente satisfazem as necessidades
dos usuários (PRESSMAN, 2011; SOMMERVILLE, 2011). Em outras palavras,
idealmente um requisito, seja ele uma regra de negócio, um requisito funcional
ou um requisito não funcional deve estar completo, correto, consistente,
realista com as necessidades dos usuários, realmente necessários, passíveis de
ser priorizado, verificável e passível de confirmação e rastreável.
SOMMERVILLE (2011) comenta que das atividades de V&V, a
atividade de teste é o elemento mais crítico para garantir a qualidade do
artefato do produto e, por consequente, do produto final, porém, exceto por
meio de protótipos não é possível testar requisitos, entretanto, uma das
características de um requisito bem elaborado é que ele seja testável,
portanto, uma boa maneira de identificar problemas nos requisitos é definir
casos de testes para eles. Outra etapa imprescindível das atividades de V&V
é realizar revisões dos documentos de requisitos.
De forma geral, em uma revisão os processos, documentos e
outros artefatos são revisados por um grupo de pessoas com o objetivo de
avaliar se os mesmos estão em conformidade com os padrões do projeto e com os
objetivos do produto de software, logo, em uma revisão o objetivo principal é
encontrar erros e inconsistência nos artefatos e nos processos. A revisão de
requisitos pode ocorrer por meio de diversas técnicas, como leitura ad-hoc,
leitura baseada em checklist, leitura de modelos orientados a objetos e outras
dispostas na literatura.
3.5 Gerencia de Requisitos
Gerenciar requisitos consiste de atividades que auxiliam as
equipes de desenvolvimento a identificar, controlar e rastrear requisitos,
permitindo assim gerenciar as mudanças que ocorra ao longo do ciclo de vida de
desenvolvimento de software (PRESSMAN, 2011; SOMMERVILLE, 2011).
As mudanças em requisitos podem ocorrer em qualquer fase do
ciclo de vida de desenvolvimento de software e são decorrentes de fatores
externos ou internos, tais como descobertas de erros, omissões ou conflitos,
inconsistência nos requisitos, problemas técnicos, problemas de cronograma ou
custo, mudança de prioridades, mudança de negócio, mudanças econômicas,
mudanças na equipe ou mesmo no ambiente onde o software será implantado, ou
ainda mudanças organizacionais ou legais.
Os objetivos da gerencia de requisitos são:
- Gerenciar alterações nos requisitos acordados;
- Gerenciar relacionamentos entre os requisitos;
- Gerenciar dependência entre os requisitos e outros documentos produzidos durante o processo de desenvolvimento de software.
As atividades que compõem o gerenciamento de requisitos são:
- Controle de mudança: defini os procedimentos, processos e padrões que devem ser utilizados para gerenciar alterações de requisitos. Deve assegurar que qualquer proposta de mudança seja analisada conforme os critérios estabelecidos pela organização.
- Controle de versão: Defini o esquema de identificação da versão, identificando versões de documentos de requisitos e versões de cada requisito.
- Acompanhar o estado do requisito: nesta atividade deve-se ser capaz de identificar e definir os possíveis estados para um requisito, armazenando e documento todos os estados de cada requisito.
- Rastrear os requisitos: Deve-se definir ligações com outros requisitos e com outros documentos.
Os requisitos guiam diversas atividades do processo de
software, como o planejamento, projeto, codificação e testes e, portanto, estes
requisitos devem ser rastreáveis para e a partir dos requisitos.
Logo, para manter a consistência entre as várias alterações
pedidas (e para estas serem feitas de um modo controlado), é importante que o
processo de gestão de mudanças esteja definido de um modo formal, sendo que
deverá incluir as seguintes três fases:
- Análise do problema e especificação da alteração a fazer: identificação do problema existente nos requisitos originais e proposta de alteração a fazer aos requisitos do sistema.
- Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas previamente, avaliação do impacto da alteração no sistema.
- Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário, no design e implementação.
É importante seguir este processo conforme foi enunciado já
que cair na tentação de implementar a alteração diretamente e só depois,
retrospectivamente, atualizar os requisitos pode levar a "dessincronização" entre
requisitos e implementação.
4. Conclusão
A engenharia de requisitos representa uma das principais
atividades da engenharia de software. Definir um processo de engenharia de
requisitos capacita os desenvolvedores a lidar com mudanças durante o processo
de desenvolvimento de software e a sua importância é destacada na literatura
por diversos autores como SOMMERVILLE (2007), PRESSMAN (2006).
Neste texto foi apresentado uma visão geral de requisitos, conceituando-os
e classificando-os, a fim, de que se proporcione uma melhor compreensão sobre o
processo de gerenciamento de requisitos. Além da abordagem sobre requisitos,
também foi tratado neste texto, de forma geral, uma contextualização sobre
documentos de requisitos apresentando os tipos de documentos que são gerados
relacionados a requisitos.
Por fim, foi abordado também o conceito, objetivo e as
atividades que compõem a engenharia de requisitos. Desde as atividades de
levantamento, analise, documentação, verificação e validação de requisitos até
as atividades de gerenciamento de requisitos.
Referências
PRESSMAN, R. Engenharia
de Software. São Paulo. Ed. Makron Books, 2011.
SOMMERVILLE, I. Engenharia
de Software. São Paulo. Ed. Addison-Wesley, 2011.
Nenhum comentário:
Postar um comentário