3. Engenharia_Software_I_RQS

Prévia do material em texto

Engenharia
de Software I
Flávio Ferro
Engenharia de Software I
Flávio Ferro
FACITEC - Faculdade de Ciências Sociais e Tecnológicas
Bacharelado em Sistemas de Informação
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
1 Identificar os conceitos que permitem levantar requisitos de
sistema e especificá-los.
2 Identificar os elementos da análise e da negociação de
requisitos.
3 Identificar as principais características da especificação de
requisitos.
4 Descrever o processo de validação e gestão de requisitos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Importância dos Requisitos
Requisitos são descrições das necessidades ou dos desejos para
um produto.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Importância dos Requisitos
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
A Engenharia de Requisitos tem sido reconhecida como uma das
mais importantes disciplinas em Engenharia de Software devido
a maior parte dos problemas de desenvolvimento de software
são originados por definições equivocadas de requisitos. As
atividades de Engenharia de Requisitos são executadas de forma
mais intensa nas etapas iniciais do desenvolvimento de software
e direcionam fortemente o uso dos recursos ao longo de todo o
desenvolvimento e, depois, ao longo de todo o ciclo de vida do
produto. Por isso, problemas de correção mais dispendiosa e de
maior impacto negativo no projeto freqüentemente são
decorrência de falhas em Engenharia de Requisitos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Conforme pode ser observado abaixo, as atividades que
compõem o Processo de Engenharia de Requisitos são um
conjunto de boas práticas que apóiam a sua execução:
elicitação;
análise e negociação;
especificação e documentação;
validação.
Normalmente, falhas na realização destas atividades resultam
em documentos de requisitos inconsistentes, incompletos e
conseqüentemente produtos de software de baixa qualidade.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
1 - Elicitação de Requisitos
1.1 - Conceitos
Os requisitos de um projeto de software formam a base para o
planejamento, o acompanhamento do desenvolvimento, e a
aceitação dos resultados do projeto de software. Portanto, é
muito importante que esses requisitos estejam bem definidos e
acordados entre os envolvidos. Se os requisitos são
especificados de forma incompleta ou inconsistente, os artefatos
resultantes das próximas etapas do processo de software (por
exemplo, projeto, implementação e testes) não terão a
qualidade desejada. Quanto mais tarde os problemas na
especificação de requisitos forem detectados no processo de
desenvolvimento, maior será o custo de correção do software.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Com um processo bem definido pode-se obter (elicitar),
entender e validar as necessidades e expectativas do cliente e,
posteriormente, documentá- las no Documento de Requisitos de
Sistema (DRS). O documento de requisitos descreve os serviços
e funções que o sistema deve prover, as limitações sobre as
quais o sistema deve operar, as propriedades gerais do sistema,
isto é, limitações nas propriedades emergentes, as definições de
outros sistemas com os quais o sistema deve integrar, as
limitações no processo usado para desenvolver o sistema e as
descrições sobre o hardware no qual o sistema irá executar.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
O DRS constitui a base para as estimativas de tamanho, de
esforço, de cronograma, e de custo. Assim, quando as
estimativas de tamanho, prazo e custo são gerados a partir de
requisitos incompletos, ambíguos, omissos ou inconsistentes, as
estimativas não serão precisas resultando em prejuízo e
descumprimento dos prazos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Os requisitos descrevem ‘o que o sistema deve fazer’ - e
também ‘o que ele não deve fazer’ - sem dizer (ou detalhar) ‘o
como fazer’ e devem ter as seguintes características:
Verificáveis: se podemos ou não verificar o atendimento de
um dado requisito. A verificação ocorre mediante
procedimentos de teste, experimentos e provas ou por meio
de acordos de aceitação previamente definidos;
Precisos: requisitos devem ser expressos precisamente, de
outro modo não se pode garantir que irão ser interpretados
da mesma forma por todas as pessoas envolvidas;
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Corretos: requisitos devem expressar corretamente o que é
requerido;
Consistentes: requisitos não devem conter conflitos;
Completos: tudo que é requerido deve ser expresso;
Compreensíveis: todas as pessoas envolvidas devem
entender, no seu nível de participação, o que está expresso
em um requisito;
Manuteníveis: podemos alterar com facilidade um requisito
quando este muda ou evolui.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Quando a organização não dispõe deste processo formalmente
definido e amplamente divulgado, os desenvolvedores elaboram
as especificações de requisitos de uma forma empírica,
executando atividades não padronizadas e definidas
individualmente. Se isto ocorre, a qualidade da especificação
dependerá exclusivamente da experiência e formação das
pessoas, havendo assim uma elevada probabilidade de
ocorrerem conflitos, incoerências e re-trabalho.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
A etapa de elicitação de requisitos corresponde à fase de
entendimento do problema. Elicitação é o processo responsável
por descobrir informações, compreender os fatos descobertos e
adquirir conhecimentos. Para tanto, são utilizadas diversas
técnicas que serão vistas posteriormente, como a análise dos
fluxos de trabalho dos usuários, a definição dos atributos de
qualidade do sistema e o desenvolvimento de mecanismos que
possibilitem o reuso de requisitos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Na elicitação de requisitos, a redação de uma declaração de
visão e escopo do sistema, a definição dos procedimentos para
desenvolvimento dos requisitos, a identificação das classes de
usuários e dos diferentes grupos de interesse no sistema, a
identificação dos casos de uso constituem boas práticas.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Algumas das atividades envolvidas na análise de requisitos
incluem:
classificação: agrupamento de requisitos em
"módulos"para facilitar a visão global do funcionamento
pretendido para o sistema;
resolução de conflitos: dada a multiplicidade e diversidade
de papéis das partes interessadas envolvidas na captura e
análise de requisitos, é inevitável a existência de conflitos
nos requisitos identificados; é importante resolver estes
conflitos o mais breve possível;
priorização: consiste na atribuição de uma "prioridade"a
cada requisito (por exemplo elevada/média/baixa);
obviamente, este pode ser um fator gerador de conflitos;
confirmação: é confirmada com as partes interessadas a
completude dos requisitos, sua consistência e validade (de
acordo com o que se pretende do sistema).
Estas fases não são independentes entre si, pois uma
informação obtida numa delas pode servir para as demais fases.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Na fase de especificação e documentação se dá a produção
propriamente dita do documento de especificação de requisitos.
Em todos os tipos de especificação há 2 tipos de requisitos a
considerar:
Requisitos funcionais: descrevem as funcionalidades que se
espera que o sistema disponibilize, deuma forma completa
e consistente. É aquilo que o utilizador espera que o
sistema ofereça, atendendo aos propósitos para qual o
sistema será desenvolvido.
Requisitos não-funcionais: referem-se a aspectos
não-funcionais do sistema, como restrições nas quais o
sistema deve operar ou propriedades emergentes do
sistema.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Na fase de validação pretende-se demonstrar que o documento
de requisitos produzido corresponde, de fato, ao sistema que o
cliente pretende.Corresponde à confirmação dos conhecimentos
adquiridos junto aos clientes/usuários. Tudo isso é feito sob
uma gerência responsável pelo acompanhamento das fases por
meio de avaliação contínua dos resultados obtidos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
São participantes do processo de engenharia de requisitos:
1 Clientes (Usuários) do Sistema: definem os requisitos e
verificam se eles satisfazem suas necessidades;
2 Líderes de Projeto: definem e usam os requisitos para
planejarem uma proposta e o processo de desenvolvimento
do sistema;
3 Analistas e Analistas Desenvolvedores: usam os requisitos
para entender e especificar o sistema em construção;
4 Analistas de teste do sistema: usam os requisitos para
desenvolver testes de validação do sistema;
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
5 Analistas de manutenção do sistema: usam os requisitos
para entender o sistema.
6 Representantes da Área de Infra-estrutura: usam requisitos
não funcionais para a concepção do sistema.
7 Representantes da Área de Operação de Sistemas: usam
requisitos não funcionais para a implantação do sistema.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
1.2 - Atividades da elicitação de requisitos
Conforme pode ser visto na Figura 2, os componentes da
elicitação de requisitos são: entendimento do domínio da
aplicação, entendimento do problema a ser resolvido,
entendimento do contexto do negócio e entendimento das
necessidades das partes interessadas (stakeholders).
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Entender o domínio da aplicação é o ponto inicial de todo o
processo de análise. Os usuários e desenvolvedores possuem
visões diferentes e fazem suposições diferentes sobre a natureza
da solução. Uma mesma linguagem compartilhada tanto por
desenvolvedor como por usuário melhora a comunicação e o
entendimento entre ambos. Em outras palavras, a análise do
domínio consiste em estudá-lo de forma a identificar, formalizar
e classificar as características elementares (objeto, regras e
limitações).
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
O entendimento do problema corresponde a compreensão
detalhada da situação/problema existente que demanda uma
solução que seja a mais apropriada e otimizada possível.
O entendimento do contexto do negócio corresponde a
compreensão de como os sistemas envolvidos interagem entre si
e contribuem de forma direta ou indireta com os objetivos do
negócio em questão.
Por último, é imprescindível entender detalhadamente as
necessidades específicas dos usuários e demais pessoas que
requerem suporte do sistema em seu trabalho.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
1.3 - Dificuldades da elicitação
As principais dificuldades na atividade de elicitação de
requisitos, em geral, estão relacionadas à postura dos usuários
diante da situação atual e do sistema proposto, são elas:
Os usuários podem não ter uma idéia exata do sistema por
eles requerido ou mesmo das soluções possíveis a serem
oferecidas pelo sistema.
Em geral, os usuários têm dificuldades para descrever seus
conhecimentos sobre o domínio do problema.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Usuários e analistas têm pontos de vista diferentes
referente ao problema e a possíveis soluções devido às
diferentes formações profissionais.
Os usuários podem ter restrições de uso em relação ao
novo sistema e, com isso, se recusarem a participar da
elicitação de requisitos, ou mesmo fornecer informações
erradas.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
1.4 - Técnicas de elicitação
As Técnicas de Elicitação correspondem às técnicas que podem
ser utilizadas para coletar conhecimento sobre os requisitos dos
usuários. O conhecimento deve ser estruturado segundo as
técnicas de particionamento (agregação dos conhecimentos
relacionados), abstração (expressões de alto nível de
comportamento de sistema que permitem identificar
generalidades) e projeção (organização das informações de
acordo com futuras perspectivas).
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Alguns problemas, no entanto, devem ser superados como, por
exemplo, o tempo reduzido dedicado para a etapa de elicitação,
a falta de preparo dos engenheiros quanto às técnicas de
elicitação e a própria postura dos stakeholders que nem sempre
se encontram totalmente convencidos da necessidade de um
novo sistema.
De forma prática, o processo de elicitação de requisitos deve
começar pelas perguntas óbvias do tipo: ‘o que?’, ‘por quê?’,
‘por quem?’, ‘como?’, porém existem técnicas que podem ser
seguidas para obter as informações necessárias de forma precisa
e completa.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
As principais técnicas de elicitação são:
Técnicas tradicionais - inclui o uso de questionários, de
entrevistas e de análise de documentação existente.
1 Questionários - questões pré-estabelecidas são distribuídas
para uma amostragem significante e representativa de
stakeholders e, por fim, os resultados são avaliados. São
extremamente úteis quando a quantidade de stakeholders é
grande.
2 Entrevistas - o engenheiro de requisitos ou analista levanta
questões relacionadas aos stakeholders e/ou suas
necessidades referente ao problema a ser resolvido.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
3 Análise de documentação existente - requer abstração e
conhecimento do vocabulário da aplicação para extrair as
informações relevantes. A maior vantagem é a facilidade
de acesso à grande quantidade de informações. Por outro
lado, tem-se grande dispersão das informações e volume de
trabalho.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Técnicas de elicitação de grupo - são técnicas de dinâmica
de grupo cujo objetivo é entender de forma mais detalhada
as necessidades dos usuários, dentre elas, o brainstorming.
No brainstorming, os stakeholders são reunidos em
ambiente apropriado, onde a participação é encorajada de
forma que todas as idéias possam ser declaradas em voz
alta (para que os demais sejam influenciados) e escritas
(para que não sejam perdidas). Esta técnica é mais eficaz
quando cada stakeholder possui uma parte do
conhecimento de algum aspecto do problema.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Prototipação - corresponde à implementação parcial e
rápida de um sistema enfatizando principalmente a
interface visual de forma a coletar informações para o
processo de requisitos. O protótipo pode ser descartado ou
evoluir para o produto final. Tal técnica é usada para
elicitar requisitos quando há um alto grau de incerteza ou
quando é necessário um rápido feedback dos usuários.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Técnicas de modelagem - técnica que visa representar os
requisitos em modelos conceituais que descrevem as
necessidades encontradas na elicitação, ou seja, fornece um
modelo específico das informações que serão adquiridas, e
usa o modelo para orientar o processo de elicitação. Uma
técnica bastante utilizada é o usode cenários para
representar as tarefas que os usuários executam
normalmente e aquelas que eles desejam executar. Inclui
métodos baseados em metas e métodos baseados em
cenários.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Etnografia - técnica que prima pela observação dos
potenciais usuários em seu ambiente natural. Resulta em
uma percepção mais precisa do problema do que
simplesmente perguntar aos usuários o que eles fazem.
Essa técnica é bastante útil para suporte à automação de
uma função pouco ou não automatizada, particularmente
quando são disponíveis a observadores treinados sem
noções pré-concebidas do problema e de sua solução.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
1.5 - Processos para a elicitação de requisitos
Os processos para a Elicitação de Requisitos podem ser
observados na Figura 3. Em geral, o processo de Elicitação de
requisitos de software recebe novos requisitos por meio de uma
Solicitação de serviço ou Solicitação de alteração de requisitos
entre outras fontes e, uma vez documentados e analisados, são
elaboradas as Matrizes de rastreabilidade e o Documento de
requisitos de software (DRS) que, por sua vez, entram em um
processo para negociação de prioridades, conforme detalhado a
seguir.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Efetuar a reunião inicial com o cliente - participam da
reunião inicial com o cliente todas as partes interessadas
(stakeholders). Nessa reunião devem ser obtidos os
principais assuntos que deverão estar presentes no
Documento de Visão.
Entender o domínio da aplicação - a reunião inicial com o
cliente fornecerá a base para determinar os principais
domínios para proceder o desenvolvimento do sistema.
Uma das principais dificuldades enfrentadas pelo
desenvolvedor de software é a complexidade do domínio do
problema, ou seja, estabelecer um entendimento do
domínio da aplicação procurando descobrir o máximo de
informações sobre o ambiente onde o sistema atuará;
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Identificar as partes interessadas (stakeholders) - ou seja,
identificar as pessoas interessadas pelo produto, ou que
participarão do seu desenvolvimento. Para cada
stakeholder é importante identificar nome e função;
Escolher a técnica de elicitação - ao escolher a técnica de
elicitação, devem ser consideradas quais as fontes dos
requisitos, a disponibilidade e nível de cooperação das
pessoas, além dos tipos de requisitos a serem elicitados. A
escolha da técnica apropriada para elicitar requisitos
depende do tempo e dos recursos disponíveis, assim como
do tipo de informação necessária.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Elaborar a lista de Requisitos Candidatos - o objetivo desta
atividade é descrever os requisitos relevantes do sistema,
ou seja, aqueles que contribuem para atender os objetivos
do projeto, de forma a representar as principais
necessidades e funcionalidades do sistema, devendo ser
incluídos no Documento de Visão.
Estudar os Requisitos candidatos, os sistemas similares e os
documentos coletados com o cliente - documentos,
arquivos e sistemas similares devem ser inspecionados e
abstraídos para melhor compreender o contexto do sistema,
além de permitir uma avaliação da possibilidade de
re-usabilidade de requisitos e de soluções.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Elaborar o glossário - a definição de um glossário é
necessária para evitar ambigüidades e facilitar a leitura de
documentos do sistema onde os principais termos
utilizados no domínio da aplicação e pelos desenvolvedores
e usuários devem ser definidos.
Elaborar o documento de Visão - deve-se avaliar o
conjunto de requisitos essenciais para a definição do
Documento de visão do software e este deve incluir o
escopo do projeto e suas limitações, bem como as
principais características do software a ser desenvolvido.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
2 - Análise e Negociação de Requisitos
O objetivo da análise é descobrir problemas, incompletude e
inconsistência nos requisitos elicitados. Neste caso, os requisitos
normalmente são retornados aos stakeholders para resolução por
meio de um processo de negociação. Outro importante objetivo
da análise de requisitos é descobrir as interações entre requisitos
e informar os conflitos e sobreposições de requisitos.
As atividades da análise de requisitos começam com o
reconhecimento do problema, a avaliação do problema e síntese
da solução (modelagem), a especificação dos requisitos do
software e por fim a revisão.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
A análise é intercalada com elicitação, pois os problemas são
levantados quando os requisitos são elicitados. Além disso, uma
lista de verificação de problemas poderá ser utilizada para
auxiliar o processo de análise onde cada requisito poderá ser
avaliado em contrapartida a esta lista.
A lista de verificação da análise consta de basicamente oito
itens que conduzem às perguntas que devem ser respondidas na
análise dos requisitos. Os itens são:
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Projeto prematuro - Os requisitos incluem informação
prematura de projeto ou de implementação?
Requisitos combinados - A descrição dos requisitos
especifica um requisito único ou pode ser desmembrada em
vários requisitos diferentes?
Requisitos desnecessários - O requisito é realmente
imprescindível ou será que é uma mera adição supérflua ao
sistema?
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Uso de hardware não padronizado - Os requisitos implicam
uso de uma plataforma de hardware não padronizada?
Para tomar esta decisão, é necessário conhecer os
requisitos de plataforma do computador.
Está de acordo com os objetivos de negócio - O requisito é
consistente com os objetivos de negócio definidos na
introdução do documento de requisitos?
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Ambigüidade de requisitos - O requisito é ambíguo, ou
seja, poderá ser interpretado de forma diferente por
pessoas diferentes? Quais são as possibilidades de
interpretação dos requisitos?
Realismo dos requisitos - O requisito é real no que se refere
à tecnologia usada para a implementação do sistema?
Teste dos requisitos - Há possibilidade de teste para
comprovar se o sistema satisfaz os requisitos?
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Durante a negociação e priorização de requisitos (Figura 4), as
seguintes atividades são realizadas:
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Escolher a técnica de negociação - o processo de
negociação de requisitos tenta solucionar conflitos entre
usuários sem comprometer a satisfação dos objetivos de
cada um. Em geral, os modelos de negociação identificam
as principais necessidades de cada usuário, ou seja,
atribuem prioridades aos requisitos, em seguida analisam
esses resultados para tentar garantir que os requisitos mais
críticos sejam atendidos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Priorizar os requisitos - uma vez escolhida a técnica de
negociação, a mesma deve ser utilizada não apenas para
resolver conflitos, mas também para priorizar os requisitos.
Na definição de prioridades para os requisitos, é importante
que os riscos e a complexidade dos requisitos sejam
observados de forma a minimizar possíveis atrasos nos
milestones estabelecidos. Milestones correspondem aos
pontos de controle em um cronograma os quais
representam a conclusão de um conjunto de tarefas oufase, passiva de aprovação e de formalização por parte do
cliente. Os requisitos podem ter três níveis de prioridade:
alta, média e baixa.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
- Alta: requisitos obrigatórios, ou seja, requisitos que deixam o
desenvolvedor sob força de contrato perante o cliente ou
entidades externas à equipe de desenvolvimento.
- Média: requisitos que possuem importância significativa para
o cliente, mas que podem ser negociados com a gerência para
serem retirados do escopo, caso não seja viável sua
implementação.
- Baixa: requisitos de menor importância para a realização dos
objetivos do software.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Definir os milestones e os pontos de revisão - de acordo
com a priorização, os requisitos são agrupados para
estabelecer linhas de base de implementação, facilitando a
definição dos milestones e de pontos de revisão.
Atualizar o Documento de Requisitos de Software - o
resultado obtido a partir da técnica de priorização deve ser
incorporado ao Documento de Requisitos de Software
(DRS), enriquecendo a documentação sobre os atributos
dos requisitos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
2.1 - Solicitações x necessidades
O grupo de pessoas ou representantes de uma organização que
tem interesse ou influência no projeto são chamados de
interessados (na literatura em inglês, é utilizado o termo
"stakeholder"). O interessado mais óbvio é o usuário final, mas
devem ser levados em consideração outros interessados
importantes: um comprador, um contratante, um
desenvolvedor, um gerente de projeto ou qualquer outro que se
preocupe bastante ou que apresente necessidades que devem ser
satisfeitas pelo projeto.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
É importante que sejam agrupados todos os tipos de solicitações
de interessados ao longo do ciclo de vida do desenvolvimento.
As solicitações correspondem aos dados brutos de entrada
usados para levantar as necessidades. No início do projeto, são
usadas técnicas de entrevistas, questionários e seminários. Em
um estágio mais adiantado do desenvolvimento, são feitas a
coleta das solicitações de mudanças, relatórios de defeito e
solicitações de melhoria. É comum que as solicitações sejam
vagas e ambíguas, declaradas até mesmo como necessidades.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
A partir das solicitações, são realizadas algumas verificações
referentes aos requisitos levantados (Figura 5):
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Verificação da necessidade - a necessidade dos requisitos é
analisada. Em alguns casos, alguns requisitos propostos
podem não ser relevantes, pois não contribuem para os
objetivos de negócio da organização ou para o problema
específico tratado pelo sistema.
Verificação de consistência e completude - os requisitos são
verificados entre si para determinar consistência e
completude. Consistência significa que nenhum requisito
deve ser contraditório e completude significa que nenhum
serviço (ou limitação) necessário seja esquecido.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Verificação de viabilidade - Os requisitos são verificados
para garantir que são viáveis dentro do orçamento e do
prazo estabelecido para o desenvolvimento do sistema.
Antes de se avançar com uma análise mais detalhada dos
requisitos de um projeto, deve ser feito um estudo de
viabilidade. Pretende-se com este estudo avaliar se, de um
ponto de vista tecnológico e organizacional, o projeto é viável.
Algumas questões precisam ser levantadas, por exemplo:
1 Será que o sistema contribui para os objetivos da
organização?
2 Dadas as restrições tecnológicas, organizacionais
(econômicas, políticas, ambientais, recursos disponíveis) e
temporais associadas ao projeto, será que o sistema pode
ser implementado?
3 Caso haja necessidade de integração entre diferentes
sistemas, será que esta é possível?
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
2.2 - Encontros de negociação
Problemas nos requisitos são inevitáveis quando um sistema
possui muitos stakeholders. Os conflitos não são
necessariamente falhas, mas refletem necessidades e prioridades
diferentes entre as partes interessadas. A negociação de
requisitos é o processo de discussão dos conflitos de requisitos e
a busca de um compromisso no qual, por meio de um consenso,
todas as partes interessadas concordem com as soluções
sugeridas. Sendo assim, no planejamento do processo de
engenharia de requisitos, é desejável deixar um tempo
considerável reservado para a negociação. Alcançar o consenso
aceitável por todas as partes pode tomar um tempo
considerável.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
Os encontros de negociação correspondem ao estágio de
informação no qual a natureza dos problemas associados com os
requisitos é explicada. A partir daí, as partes interessadas
discutem como o problema poderá ser resolvido.
Todas as partes interessadas no requisito devem ter a
oportunidade de participar com comentários e opiniões, devendo
ser atribuídas prioridades aos requisitos.
Como resultado deste processo, soluções para os problemas dos
requisitos são identificadas e um conjunto de requisitos é
acordado. Geralmente, isso envolve mudanças, eliminação ou
elicitação para obter mais informações sobre alguns dos
requisitos.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
3 - Especificação de Requisitos
Os requisitos podem ser classificados como:
Requisitos funcionais;
Requisitos não-funcionais.
A diferença entre requisitos funcionais e não-funcionais está no
fato de os primeiros descreverem ‘o quê’ o sistema deve fazer,
enquanto que os outros fixam restrições sobre ‘como’ os
requisitos funcionais devem ser implementados.
Os requisitos funcionais têm efeito localizado, isto é, afetam
apenas a parte do sistema onde as funcionalidades foram
implementadas. Os requisitos não-funcionais têm efeito global,
pois a satisfação afeta vários componentes do sistema.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
3.1 - Atividades da elicitação de requisitos
Requisitos funcionais expressam o comportamento de um
sistema especificando a contribuição e as condições esperadas
de saída, ou seja, correspondem à descrição das diversas
operações que clientes e usuários solicitam para que possam ser
implementadas e oferecidas pelo sistema.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos
3.2 - Requisitos não-funcionais
Requisitos não-funcionais correspondem aos atributos que não
são especificamente descritos pelos requisitos funcionais do
sistema, mas são imprescindíveis para atingir a qualidade
necessária do software.
Requisitos não-funcionais são difíceis de descrever, porém,
tratá-los durante o processo de desenvolvimento pode ser vital
para o sucesso dos sistemas.
Além disso, os requisitos não-funcionais são críticos para o
sucesso de sistemas de software e estão diretamente
relacionados com a satisfação dos usuários. Devido a essa
importância, alguns requisitos funcionais podem ser sacrificados
para atender às restrições impostas pelos requisitos
não-funcionais.
Engenharia
de Software I
Flávio Ferro
Engenharia de Requisitos