Click here to load reader
Upload
manubbl
View
137
Download
0
Embed Size (px)
Citation preview
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
1
ENGENHARIA DE REQUISITOS
Rafael da Silva Rocha1
Teresinha Moreira de Magalhães2
RESUMO
Este artigo procura descrever a engenharia de requisito como uma condição ou uma
capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema,
para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos
formalmente.
PALAVRAS-CHAVES: Especificação, Requisitos, Processos
INTRODUÇÃO
O interesse por uma abordagem sistemática do conhecimento de problema, levou à busca
de apoio de uma nova área de pesquisa, a engenharia de requisitos. A Engenharia de
Requisitos pode ser definida como o processo sistemático de desenvolvimento de requisitos
através de um processo iterativo e cooperativo de análise de problema, de documentação de
observações resultantes em uma variedade de formatos de representação e de checagem da
precisão do entendimento obtido. O processo de engenharia de requisitos é um conjunto
estruturado de atividades para extrair requisitos, validá-los e mantê-los. As técnicas de
engenharia de requisitos referem-se ao conjunto de ferramentas aplicáveis ao
desenvolvimento dos processos. Requisitos, simplesmente, podem ser definidos como "algo
1 Bacharelando em Sistemas de Informação pela Faculdade de Ciências Gerenciais de Santos Dumont. [email protected] 2 Graduada em Processamento de Dados e Pós Graduada em Redes de Computadores pelo Centro de Ensino Superior de Juiz de Fora, Pós Graduada em Matemática e Estatística pela Universidade Federal de Lavras, Mestre em Engenharia da Produção com ênfase em Produção de Mídias pela Universidade Federal de Santa Catarina e Doutora em Sistemas Computacionais pela Universidade Federal do Rio de Janeiro. [email protected]
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
2
que um cliente necessita". Entretanto, do ponto de vista de um desenvolvedor, requisito pode
também ser definido como "algo que necessita ser projetado".
REQUISITOS
Não há um método em vigência para descrição de requisitos, o usado mais comumente e
por costume é a descrição textual o que tem causado grandes empecilhos a todas as partes
relacionadas no processo. Documentos imprecisos são gerados (requisitos, ao contrário do que
imaginam muitas pessoas ligadas ao processo de desenvolvimento, são difíceis de serem
expressos pelo usuário) quanto às obrigações do sistema e também quanto às não obrigações,
deixando margem às dúvidas. Outro problema encontrado é que a engenharia de requisitos
tem sido vista como um processo muito pessoal e feito aos moldes de cada analista
diminuindo e muito o reuso do documento produzido por outros analistas na resolução de
problemas semelhantes e às vezes até o mesmo problema.
Problemas referentes à engenharia de requisitos funcionais têm sido resolvidos através de
modelos como o diagrama de seqüência, diagrama de classes e diagrama de estados, dentre
outros de acordo com a cultura de cada empresa/consultor que faz a análise. Este método tem
resolvido a questão para os contratados, mas produz um documento muito técnico e de difícil
entendimento para o contratante e muitas vezes não reflete as reais necessidades que o sistema
deve suprir, na visão (limitada, obviamente, do ponto de vista da implementação) do usuário.
Os requisitos não-funcionais, por serem geralmente atrelados à qualidade, não são fáceis de
expressar por modelos, pois a qualidade não é expressa por abstrações de coisa concretas ou
coisas por entidades pertencentes ao domínio do problema, entidades que tem vida
determinada começam e terminam dentro do seu escopo.
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
3
Figura 01 – Classificação dos Requisitos
O PROCESSO DE PRODUÇÃO DE REQUISITOS
• Os quatro sub-processos da Produção de Requisitos:
– Estudo de Viabilidade : Avaliação se o sistema é útil para a empresa;
– Elicitação e Análise : Identificação da fonte de informação. Obtenção dos dados e fatos;
– Documentação : Especificação e conversão dos requisitos em alguma forma-
padrão;Documentação;
– Validação : Verificação se os requisitos realmente definem o sistema que o cliente deseja;
Protótipo.
O PROCESSO DE GERENCIA DE REQUISITOS
• Os quatro sub-processos da Gerência de Requisitos:
– Gerência de Mudanças : Controla as solicitações de mudança do cliente;
– Gerência de Configuração : Controla as versões dos artefatos;
– Gerência de Qualidade dos Requisitos : Define o padrão de produção e verificação da
qualidade dos requisitos;
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
4
– Rastreabilidade : Relação entre as fontes dos requisitos, os requisitos propriamente ditos e
outros artefato.
CONCEITO DE ENGENHARIA DE REQUISITOS
É a engenharia (“Arte de aplicar os conhecimentos científicos à invenção,
aperfeiçoamento ou utilização da técnica industrial em todas as suas determinações” –
Dicionário Michaelis) aplicada a obtenção metódica de requisitos (“Requisitos: Condição
necessária para a obtenção de certo objetivo, ou para o preenchimento de certo objetivo.“ -
Leite 94) do sistema, sejam estes Funcionais ou Não-Funcionais, tratando-os de maneira
sistemática e padronizada com o fim de se ter um reaproveitamento da análise de requisitos
feita, para qualquer outro projeto semelhante ou mesmo para manutenção do mesmo.
� Requisitos Funcionais: Estão intimamente ligados às funcionalidades propostas pelo
sistema, e que serão usadas na resolução do problema do contratante, e atenderá todas as suas
necessidades funcionais. Resumidamente, são os requisitos que objetivamente cumprem as
reais necessidades do usuário do sistema. Exemplo: Controle financeiro, controle de tráfego
aéreo, controle de produção.
� Requisitos Não-Funcionais: Geralmente ligados à qualidade do produto como, por
exemplo, robustez, segurança ou integridade. Dividem-se, assim como a qualidade de
produtos, em dois sub-ramos:
� Dependência positiva:
Quando da presença de um o outro é mais facilmente incorporado.
Figura 02 – Dependência positiva
� Dependência negativa:
São conflitantes entre si, a presença ou existência de um compromete o outro ou diminui seu
grau de atuação.
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
5
Figura 03 – Dependente negativa.
Requisitos não-funcionais podem ser classificados como:
� Orientados ao consumidor: Observáveis pelos clientes, não necessariamente os
contratantes, mas os usuários do software. Por exemplo: eficiência, amigabilidade, ergonomia.
� Atributos orientados tecnicamente: Ligados diretamente ao sistema e que garantem a
sua qualidade como tratamento de erros ou anomalias (robustez), processamento em tempo
real.
Duas abordagens podem ser utilizadas na engenharia de requisitos:
� Orientada ao produto: Uma abordagem onde o produto a ser produzido é focalizado
como principal fonte de elicitação de requisitos não funcionais. Naturalmente a de mais
assimilação pelo contratante, já que é feita de acordo com ponto de fácil mensuração por
alguém que não tenha experiência técnica. Exemplo: Deve ser veloz (eficiente), seguro contra
erros do usuário (robusto), etc.
� Orientada ao processo: Abordagem técnica que prioriza o processo de desenvolvimento
e não somente o produto, usa a premissa que através de um processo bem estruturado e de
qualidade comprovada, o produto final incorpora as qualidades propostas pelo processo de
desenvolvimento. Exemplo: O sistema deve ser feito em Java, deve ser orientado a objetos e
deve usar como base de dados MySQL.
APLICAÇÕES DA ENGENHARIA DE REQUISITOS
Todas as etapas que formam a base de desenvolvimento de software maduro têm sua
importância dentro do contexto geral, sempre com o objetivo principal de auxiliar, dentro de
suas especificações, o andamento desse desenvolvimento. Com a engenharia de requisitos
ocorre da mesma forma. Ela possui uma tarefa inicial muito importante nesse processo, pois
havendo procedimentos bem definidos que ajudem na tarefa de elicitar os requisitos de um
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
6
sistema a ser desenvolvido, isso se torna mais fácil e um pouco menos dependente do talento
das pessoas e de suas experiências nesse tipo de atividade, evitando boa parte do re-trabalho e
de inconsistências desses requisitos.
Define um documento de requisitos funcionais e requisitos não funcionais onde se
deve ter a visão de todos os requisitos do problema a ser resolvido ou de sua face inicial de
acordo com o modelo de ciclo de vida usado na análise.
Também tem a função de diminuir custos de desenvolvimento através de um processo de
amadurecimento de idéias a medida que novos requisitos são expostos, isso se deve a
premissa de que quanto mais cedo que identificar a mudança menos esforço ela resultará. Isso
é feito através, principalmente da conscientização de que os requisitos são mutáveis e através
da escolha de um modelo de ciclo de vida adequado.
Pode fazer o acompanhamento da resolução dos requisitos e da mudança dos mesmos,
dando suporte a avaliação de custos e riscos na mudança dos requisitos ao longo da análise ou
projeto com a finalidade de avaliar a viabilidade da mudança dos mesmos no atual instante de
desenvolvimento.
Quem se beneficia com a engenharia de requisitos?
Contratantes, quem solicita o serviço de análise do problema, por terem um
documento que assegure a resolução dos problemas referentes aos requisitos funcionais
propostos e terem também a garantia da qualidade através de requisitos não funcionais
expressados no mesmo documento.
Contratado, que fornece o serviço de análise de problemas, com o documento
produzido através da engenharia de software este terá uma visão mais precisa e clara dos
verdadeiros requisitos funcionais necessários, não perdendo tempo e sendo mais objetivo, e
também pode focalizar a qualidade do produto de acordo com os requisitos não-funcionais
escolhidos.
Futuros contratados e contratantes, que podem se beneficiar do reuso da engenharia de
requisitos através de documentos bem elaborados feitos anteriormente para resolução de
problemas semelhantes, diminuindo assim o tempo de desenvolvimento e por conseqüência o
custo para o contratante, contextualizando o contratado com o problema a ser resolvido e com
as peculiaridades do mesmo em relação a conhecimentos específicos do domínio do problema
na área proposta.
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
7
Em suma, a engenharia de requisitos traz benefícios a ambas as partes, tanto com
diminuição de custos para os contratantes, como em uma melhor contextualização e um maior
controle sobre os requisitos para o contratado, e também propõe o reuso dos documentos
produzidos, ou seja, incita o reuso do conhecimento adquirido através a iteração entre as
partes ao longo do processo de engenharia de requisitos.
CONCLUSÃO
Identificar e aplicar a técnica mais adequada para o desenvolvimento de um processo de
engenharia de requisitos depende do tipo de produto ou de serviço ou de resultado que se
deseja obter ou oferecer ao cliente. É atribuição do engenheiro de software, em função do
ambiente do negócio e da especificidade do produto, adequar ao processo de desenvolvimento
de requisitos, as ferramentas e as técnicas individualmente ou em conjunto, com o objetivo
único e verdadeiro de se obter o conhecimento do problema, no contexto dos variados pontos
de vista do cliente e das perspectivas de solução.
O método apresentado como modelo de estudo para o contexto organizacional não sozinho,
mas associado a outras técnicas (a exemplo de projeto participativo envolvendo o cliente na
solução), é o que mais se aproxima do entendimento dos problemas.
R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É
4ª Edição ISSN: 2178-3098
8
REFERÊNCIAS
PRESSMAN, Roger S. Engenharia de Software. São Paulo- Makron Books, 1995.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo – Pearson Addison Wesley,
2003.
PAULA FILHO, W. P. Engenharia de Software: Fundamentos, Métodos e Padrões –
LTC, 2003.