Please enable JavaScript.
Coggle requires JavaScript to display documents.
Engenharia de Requisitos- Aula 01 (O que é um requisito? (Por isso,…
Engenharia de Requisitos- Aula 01
O que aprender?
Conhecer
como se dá os processos da Engenharia de requisitos
Conhecer
as principais técnicas e ferramentas de elicitação e verificação
Compreender
os fundamentos da Engenharia de requisitos
Conhecer
métodos e técnicas não convencionais de elicitação e verificação de requisitos
Os requisitos de sistema são
as descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento
Mundo do usuário
Sistema computacional
Engenharia de requisitos é
o processo de descobrir, analisar, documentar e
verificar esses serviços e restrições
Descobrir
Analisar
Documentar
verificar
O que é um requisito?
O termo requisito
não é usado
consistentemente
pela indústria
Tanto pode ser uma descrição abstrata em alto
nível de um serviço que o sistema deve oferecer
ou uma restrição ao sistema
Quanto pode ser uma descrição detalhada e
formal de uma função do sistema
Isso pode gerar problemas e falhas para o sistema
Davis (1993) explica porque
estas diferenças existem
Se uma empresa pretende fechar um contrato para um projeto de desenvolvimento de sofware de grande porte, deve definir as necessidades de uma forma abstrata o suficiente para que a solução para essas necessidades não seja predefinida. Os requisitos precisam ser escritos de modo que vários contratantes possam concorrer pelo contrato e oferecer diferentes maneiras de atender às necessidades da organização do cliente. Uma vez que o contrato tenha sido atribuído, o contratante deve escrever para o cliente uma definição mais detalhada do sistema, para que este entenda e possa validar o que o sistema fará. Ambos os documentos podem ser chamados de documentos de requisitos para o sistema.
Por isso, Sommerville (2011) faz
uma distinção entre
os termos:
Requisitos de usuário (requisitos abstratos de alto nível)
Requisitos de sistema (requisitos contendo uma descrição mais detalhada do que o sistema deve fazer)
Requisitos de usuário
Declarações, em linguagem natural com diagramas, de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais deve operar
Requisitos de sistema
Descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software
Os requisitos precisam ser escritos em diferentes níveis de detalhamento de forma que diferentes leitores possam utilizá-los de diferentes maneiras
Há leitores que não costumam se preocupar com a forma como o sistema será implementado:
Gerente do Cliente; usuários finais; Engenheiros do cliente; Gerente de Contrato; Arquiteto de Sistema
Leitores que precisam saber mais detalhes do funcionamento do sistema, pois estão interessados em como o sistema apoiará os processos do negócio ou porque estão envolvidos na implementação do sistema:
Usuários Finais; Engenheiro do cliente; Arquiteto de software; Desenvolvedores de software
Requisitos Funcionais e
Não funcionais
Requisitos não
funcionais
São restrições aos serviços e funções oferecidos pelo sistema. Incluem restrições de Zming, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características individuais ou serviços do
sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo
requisitos funcionais
Descrevem o que o sistema deve fazer
Dependem do tipo de software a ser desenvolvido, de quem são os seus possíveis usuários e da abordagem geral
adotada pela organização ao escrever os requisitos
Requisitos funcionais expressos como requisitos do usuário são descritos de forma abstrata para serem
compreendidos pelos usuários do sistema
Requisitos funcionais expressos como requisitos de sistema descrevem em detalhes as funções do sistema, suas entradas e saída, exceções, etc.
Problemas surgem quando requisitos não são escritos precisamente
Requisitos ambíguos podem ser interpretados de maneira diferente pelos desenvolvedores e usuários
Requisitos devem ser
completos e consistentes
Completo
Todos os serviços requisitados pelo usuário devem ser definidos
Consistente
Requisitos não devem ter definições contraditórias
Na prática isso é impossível!!
Requisitos não funcionais
São requisitos que não estão diretamente relacionados
com os serviços específicos oferecidos
pelo sistema a seus usuários
Estão relacionados às propriedades emergentes
do sistema, como confiabilidade, tempo de
resposta, usabilidade, etc.
Deixar de atender a um requisito não funcional
pode significar a inutilização de todo o sistema!!!
Requisitos não funcionais podem afetar a
arquitetura geral do sistema ao invés de
componentes individuais
Por exemplo, para assegurar que
um requisito de
performance seja atendido,
você deve minimizar
a comunicação entre
componentes
Um único requisito não funcional, tal como um
requisito de segurança, pode gerar um conjunto de
requisitos funcionais relacionados
Além de requisitos que restrinjam os já definidos
Inserir aqui o "organograma dos
requisitos não funcionais
Requisitos
organizacionais
São os requisitos gerais de sistemas derivados das
políticas e procedimentos da organização do cliente e do
desenvolvedor.
Exemplos são requisitos do processo operacional, que
definem como o sistema será utilizado, requisitos de
desenvolvimento que englobam as normas do
processo que serão usadas e os requisitos ambientas
que especificam o ambiente operacional do sistema.
Requisitos de produto
Especificam ou restringem o
comportamento do software
Exemplos são requisitos de desempenho quanto à
rapidez com que o sistema deve executar e quanta
memória ele requer, os requisitos de confiabilidade
que estabelecem a taxa de aceitável de falhas, os
requisitos de proteção e os de usabilidade.
Requisitos externos
Abrange os requisitos que derivam de fatores externos
ao sistema e seu processo de desenvolvimento
Exemplos são requisitos reguladores, que definem o
que deve ser feito para que o sistema seja aprovado
para uso; requisitos legais, que devem ser seguidos
para garantir que o sistema opere dentro da lei; e
requisitos éticos, que asseguram que o sistema será
aceitável para os usuários e o público em geral.
Requisitos não funcionais podem ser difíceis de
definir precisamente e, por isso, difíceis de testar
Normalmente, eles são definidos como uma meta
Metas estabelecem boas intenções, mas podem
causar problemas para os desenvolvedores do
sistema
No entanto, podem ser definidos
como um requisito
não funcional testável
Afirmação contendo alguma métrica que pode
ser objetivamente testada
Requisito não funcional de usabilidade
Definido como Meta
O sistema deve ser de fácil uso pelo pessoal médico e
deve ser organizado de tal maneira que os erros dos
usuários sejam minimizados.
Definido como Requisito
não funcional testável
A equipe médica deve ser capaz de usar todas as
funções do sistema após quatro horas de treinamento.
Após esse treinamento, o número médio de erros
cometidos pelos usuários experientes não deve
exceder dois por hora de uso do sistema.
Requisitos de Domínio
Requisitos derivados do domínio da aplicação do
sistema, em vez das necessidades específicas dos
usuários do sistema
Por exemplo, um controle de sistema de trem tem que
levar em consideração características de parada
diferentes para condições de tempo diferentes
Eles podem ser novos requisitos funcionais,
restrições a requisitos existentes ou definir cálculos
específicos
Se não forem atendidos, o sistema pode não
funcionar
Alguns problemas com os
requisitos de domínio
podem ser:
Eles são redigidos na linguagem do domínio da
aplicação e geralmente engenheiros de software
tem dificuldade em entendê-los
Especialistas do domínio podem deixar
informações de fora de um requisito,
simplesmente por serem muito óbvias para eles
Quer dizer "caminho para chegar a um fim." É a maneira de conduzir pensamento ou ações para alcançar um objetivo. E, também, a disciplinação do pensamento e das ações para obter maior eficiência no que se deseja realizar
Método e mais amplo do que a técnica. A técnica é mais adstrita a formas de apresentação imediata da matéria. Método indica aspectos gerais de ação especifica, e técnica indica o modo de agir, objetivamente, para alcançar um objetivo.
Mas PERA pode ser algo mais: (P)lanejamento, (E)xecução, (R)esultado e (A)valiação. Fornece um caminho estruturado de pensamento para um determinado fim.
Documento de Requisitos de Software
O documento de requisitos de software é a
declaração oficial que os desenvolvedores do
sistema devem implementar
Devem incluir tanto os requisitos de usuários
quanto os requisitos de sistema
Ele NÃO é um documento de projeto
Por isso, ele deve definir O QUE o sistema
deve fazer ao invés de COMO ele deve fazê-lo
Documentos de requisitos de software e os modelos ágeis
Métodos ágeis argumentam que produzir os
requisitos mudam tão rapidamente que produzir
um documento de requisitos está ultrapassado
Abordagens como XP coletam os requisitos de
usuário de forma incremental e escrevem-nos
em cartões como estórias de usuário
Isso é prático para sistemas de negócio, mas
problemático para sistemas críticos ou
desenvolvidos por diferentes equipes (às vezes,
localizadas geograficamente distantes)
Documento de requisitos de software
possuem usuários diversificados
O nível de detalhes em um documento de
requisitos depende do tipo de sistema de
desenvolvimento e o processo usado
Sistemas críticos ou sistemas que estejam sendo
desenvolvidos por diferentes empresas devem ter
especificações detalhadas e precisas
Sistemas desenvolvidos incrementalmente dentro
de uma mesma empresa (e.g., onde a comunicação
é rápida e fácil) pode usar um documento menos
detalhado
Possível organização de um documento de
requisitos baseada em uma norma IEEE
estendida por Sommerville (2011)