Resumo das aulas 1 a 10 - REQUISITOS DE SISTEMAS

Prévia do material em texto

Requisitos de Sistemas
Aula 1
Requisito: Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo. Requisitos definem o que o sistema deve fazer
 
Para definir um requisito, é fundamental primeiro definir de forma clara, precisa e completa qual é o objetivo. 
OBJETIVO
REQUISITOS
FUNCIONALIDADES
ESPECIFICAÇÃO
Requisitos Funcionais
Necessidades dos usuários e clientes. Ou seja, “O QUE” se espera que o software faça.
Requisitos não funcionais
Necessidades técnicas. Ex: Funcionalidade, Usabilidade, Confiabilidade, Eficiência, Manutenibilidade, Portabilidade.
Qualidade
Pressman (2006) atribuiu o alcance da qualidade de software como uma consequência formal no desenvolvimento; para tanto, estima-se que seja colocada em prática e não somente uma idéia ou desejo que uma organização venha a ter. Ele cita as seguintes colocações sobre qualidade de software:
Definir explicitamente o termo qualidade de software, quando o mesmo é dito.
Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade.
Realizar atividades de segurança da qualidade em cada projeto de software.
Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como consequência, a qualidade no produto final.
Aula 2
Requisitos de usuário: define o que o sistema deve atender, sem se preocupar como deve atender. O que importa é que o usuário consiga interagir com o software de forma a realizar a operação desejada. 
Os requisitos de usuários descrevem os requisitos funcionais e não funcionais de forma compreensível pelos usuários do sistema que não têm conhecimentos técnicos detalhados
Requisitos de sistema: Requisitos de sistema são descrições mais detalhadas dos requisitos de usuário. São especificados para um grupo de leitores que detém de uma experiência, que seja capaz de interpretar informações técnicas.
Aula 3
Revisão requisitos funcionais e não funcionais.
Aula 4
Estudo de viabilidade: É uma analise na sua fase inicial do projeto de software.
Estudar pontos críticos do projeto
Apresentar diferentes alternativas de soluções para o problema
Verificar opções de custo e prazo
Stakeholders: Indivíduos que estão relacionados direta ou indiretamente com um software. Eles nem precisam fazer uso do sistema, mas mesmo assim, ele é afetado em algum aspecto.
Um requisitos funcional está sempre associado a um ou vários stakeholders. 
Segundo Summerville (2009), podemos definir da seguinte forma:
“Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou preocupações sobre a realização da arquitetura.”
Características dos Stakeholders
São específicos para cada projeto.
Possuem anseios e objetivos distintos em um projeto.
São atores fundamentais para detalhamento do que deve ser desenvolvido.
Levantamento de Requisitos
Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;
Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;
Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
Elicitação:
Tem o objetivo de entender o processo como um todo. Pra tanto, geralmente são feitas entrevistas com as pessoas envolvidas nas atividades relevantes pra execução das tarefas e até avaliações in loco do ambiente de trabalho. Ao término do processo o analista deve entender o fluxo de trabalho, o que cada funcionário consome como entrada e o que gera como saída além do que pode atrapalhar e o que pode melhorar esse fluxo de trabalho. O produto dessa atividade é a lista de requisitos.
Análise:
Essa atividade consiste em organizar os requisitos em categorias, examinar os relacionamentos e dependências entre eles, analisar a consistência, além de omissões e ambiguidades, estabelecer uma ordem de prioridade e reconhecer a origem e a necessidade de cada requisito.
Especificação:
É a descrição dos requisitos levantados. Pode ser feita em linguagem natural (texto informal, tabelas, diagramas), linguagem natural estruturada formulários) ou linguagem formal (notação matemática).
Modelagem:
É a representação dos requisitos levantados de forma a garantir o melhor entendimento. Isso pode ser feito, por exemplo, explicitando as informações que o sistema irá processar, qual o comportamento esperado depois de realizado o processamento, etc.
Validação:
São revisões realizadas pelos clientes e pela equipe de desenvolvimento pra garantir que os requisitos estejam sempre consistentes, comprometidos com o objetivo dos sitema, e não-ambíguos.
Gerenciamento:
Estabelecer padrões de nomenclatura e identificação, divisão por classes, etc.
Etnografia: A etnografia é uma técnica de observação, aonde o analista buscar uma familiarização do cliente, seus valores, sua história. O observador é inserido no ambiente de trabalho. Diariamente são realizadas anotações das tarefas observadas.
Workshops: Trata-se de uma técnica de elicitação desenvolvida em grupo, usada em uma reunião estruturada. 
Entrevistas: A entrevista é tradicionalmente mais simples de utilizar, produz bons resultados na fase inicial de obtenção de dados.
Questionários
Brainstorming: Brainstorming é uma técnica para geração de idéias.
Prototipagem: Fazer um protótipo para explorar requisitos vinculados a um produto que possua aspectos críticos. 
Implementando de maneira mais rápida um pequeno subconjunto de funcionalidades deste produto.
JAD (Joint Application Design): É uma técnica destinada a principalmente promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores. Com a intenção de facilitar a criação de uma visão compartilhada do que o produto de software deve ser, ela ajuda os usuários e desenvolvedores a formular problemas e explorar soluções, no escopo do projeto a ser desenvolvido.
Aula 5
Documento de Requisito de Software
“o documento de requisitos de software, às vezes chamado de Especificação de Requisitos de Software (SRS – do inglês Software Requeriments Specification), é uma declaração oficial do que os desenvolvedores do sistema devem implementar”.
Usuários de um documento de engenharia de requisitos
	Capítulo
	Descrição
	Prefácio
	Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo uma justificativa para a criação de uma nova versão e um resumo das mudanças feitas em cada versão.
	Introdução
	Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e explicar como ele vai funciona com outros sistemas. Também deve descrever como o sistema atende aos objetivos globais do negócio ou estratégicos da organização que encomendou o software.
	Glossário
	Deve definir os termos técnicos usados no documento. Não deve conter suposições sobre o conhecimento ou experiência do leitor.
	Definição de requisitos de usuário
	Deve descrever os serviços oferecidos ao usuário. Os requisitos não funcionais do sistema também devem ser descritos nessa seção. Essa descrição pode usar linguagem natural, diagramas ou outras notações compreensíveis para os clientes. Normas produtos que devem ser seguidosdevem sem especificados.
	Modelos do sistema
	Pode incluir modelos gráficos do sistema que mostram relacionamentos entre os componentes do sistema, o sistema e seu ambiente.
	Evolução do sistema
	Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como quaisquer mudanças previstas, em decorrência da evolução do hardware, de mudanças nas necessidades do usuário, etc. Essa seção é útil para projetistas de sistemas, pois pode ajudá-los a evitar decisões capazes de restringir possíveis mudanças futuras no sistema.
	Apêndices
	Deve fornecer informações detalhadas e especificas em relação à aplicação em desenvolvimento, além das descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações mínimas do sistema. Requisitos de banco de dados, definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre esses dados.
	Índice
	Vários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um índice de diagramas, de funções, dentre outros que sejam pertinentes.
Aula 6 - Viabilidade
Quando falamos em engenharia de requisitos, estamos a tratar de um processo que define atividades para uma produção e manutenção adequada, do documento de requisitos de software, o qual foi estudado na unidade anterior.
A premissa básica então para a engenharia de requisitos de software é definir o que deve ser feito; ou seja, é um trabalho de interpretação. Ela não se preocupa no como deve fazer feito. Com isso, questões tecnológicas como linguagem de programação, sistema gerenciador de banco de dados, topologias de redes de computadores, não representam o cerne a ser detalhado, mas sim todas as necessidades que os “humanos” esperam da “máquina”.
O projeto pode ser cancelado antes mesmo de qualquer digitação de linha de código.
Estudos de Viabilidade: avaliar se de um ponto de vista tecnológico e organizacional, se o projeto é viável e se representará uma solução capaz de ser executada e de agregar valor. Portanto, muito antes de pensarmos em requisitos, temos que saber se o sistema pode ser concluído e/ou mantido.
Aula 7 – Elicitação
É a atividade responsável em compreender as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam.
Quando decidimos construir um sistema, certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os sistemas os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a padronização o procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido.
Um fundamental questionamento que precisa ficar bem esclarecido para todos os envolvidos é: O QUE REALMENTE QUEREMOS?
A identificação de requisitos costuma aparecer de forma cíclica durante sessões tanto de levantamento quando de validação, portanto requer uma combinação de técnicas para que seja completa. Conforme estudamos na primeira unidade, as técnicas de levantamento de requisitos são: brainstorming, análise documental, entrevistas, observação, prototipagem, workshops de requisitos e pesquisa/questionários.
Tarefas do processo da elicitação dos requisitos, temos: a preparação, condução, documentação e confirmação dos resultados da elicitação.
A elicitação de requisitos envolve o processo de identificar junto aos stakeholders, frente ao sistema ou produto, os seguintes pontos:
1. Os alvos a serem alcançados;
2. Os pontos a serem acompanhados;
3. Como se encaixa no contexto das necessidades
    do negócio;
4. O comportamento ou operacionalização da
    solução na rotina da empresa.
Problemas de escopo: excesso ou falta de detalhamento. Os clientes/usuários desconhecem o que é importante (ou até mesmo quer ocultar), inibindo os limites do sistema, o que dificulta uma definição completa.
Problemas de compreensão: omitem informações que julgam óbvias; clientes/usuários desconhecem ou estão em dúvidas sobre as necessidades e como seu papel é fundamental; é leigo ou limitado no conhecimento de seu ambiente computacional ou do domínio do seu negócio e etc.
 
Problemas de volatilidade: mudanças constantes nos requisitos.
Aula 8 – Validação
Documento de requisitos de software
Segue uma relação de propriedades que são avaliadas no tocante ao documento de requisitos de software pela equipe responsável na validação:
• Completude e consistência;
• Conformidade com os padrões;
• Conflitos de requisitos;
• Erros técnicos;
• Requisitos ambíguos.
Sommerville destaca que “o custo para consertar um problema de requisitos por meio de uma mudança no sistema é geralmente muito maior do que o custo para consertar erros de projetos ou codificação. A razão para isso é que a ocorrência de mudança dos requisitos normalmente significa que o projeto e a implementação do sistema devem ser alterados”.
É encontrado e provado pela literatura que detectar um erro em fases finalistas de um projeto, pode chegar a ser danoso a ponto de incompatibilizar a continuidade, visto que pode ser tão custosa que não existe recursos para comportá-la.
Revisão dos Requisitos
É uma técnica, como o nome já sugere, a qual são analisados e revisados sistematicamente todos os requisitos elicitados, executando um checagem no tocante a erros e inconsistências.
É uma boa prática para esta técnica uma reunião formal com representantes ou especialistas de todas as áreas, tanto do contratante como do contratado. Portanto, todas as equipes deverão ter representação.  São recomendadas as seguintes providências:
Planejamento do que será revisado.
Estabelecer e convidar os envolvidos.
Definir local e tempo para a reunião.
Escolher para condução alguém “livre de vícios”, ou seja, que não estava integrado à equipe desenvolveu o documento de requisito.
Realizar procedimento de checklists para os requisitos e nas relações entre eles.
Distribuir previamente todos os documentos a serem utilizados na reunião.
Apresentar cada requisitos individualmente.
Discutir e anotar comentários para cada requisito que apresenta erro ou inconsistência.
Estabelecer um período de soluções após todo o término dos relatos apurados nas análises.
Apurar a qualidade final do documento de requisitos.
Prototipagem
“Nessa abordagem para avaliação, um modelo executável do sistema é demonstrado para os usuários finais e clientes.” (Sommerville, 2009). O objetivo é tornar mais fácil a fase de validação de requisitos, visto que, através da demonstração visual, tornar-se mais intuitivo detectar inconsistências e problemas nos requisitos.
Testes de Requisitos
Uma propriedade importante para cada requisito é o de ser testável. Para cada requisito funcional deve ser possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema cumpre o requisito na integra. Caso tal propriedade não esteja presente, ou até mesmo se for muito difícil testá-lo; tal circunstância indica a necessidade de uma retificação.
A realidade implica em uma probabilidade considerável para que todo o requisito que não pode ser testado muito provavelmente será instituidor de problemas. Deve-se então reconsiderar a presença deste, buscando por alternativas testáveis.
Aula 9 – Gerenciamento
Evolução dos Requisitos
Uma incômoda realidade: não importa o quão cauteloso seja sobre a definição dos seus requisitos, sempre haverá mudanças. Mas não precisa então achar de tudo o que aprendemos deve ser desconsiderado, porque, sem ele, o prejuízo poderá ser muito maior.
Sommerville (2011) “Logo, os requisitos de sistema devem evoluir para refletir as novas percepções do problema pelos stakeholders.”
Toda alteração em um ambiente aonde os recursos utilizados são alterados, requer uma análise geral dos impactos a serem gerados pela alteração a ser aplicada.
Mudanças de Requisitos
Estabelecer uma linha de base (baseline),aonde seja registrado aquele estado atual dos requisitos, principalmente se houverem mudanças. Costumamos dizer que é como tirar uma foto; ou seja, saberemos quais as características dos requisitos de acordo com alguma escala de tempo.
Determinar quais dependências são importantes de serem rastreadas, entendendo os requisitos mais importantes e suas ligações.
Estabelecer a rastreabilidade entre itens correlatos, trata-se de definir os “link” entre os requisitos, permitindo saber as ligações entre eles.
Controle de mudança. É necessário manter a informação do requisito original, ou seja, antes da mudança; o que foi mudado; as alterações estabelecidas e os requisitos alterados.
“O gerenciamento de requisitos é o processo de compreensão e controle das mudanças nos requisitos do sistema.
Você precisa estabelecer um processo formal para fazer propostas de mudanças e a ligação destas às exigências do sistema.
O processo formal de gerenciamento de requisitos deve começar assim que uma versão preliminar do documento de requisitos estiver disponível.
No entanto, você deve começar a planejar como gerenciar mudanças de requisitos durante o processo de elicitação de requisitos.”
Planejamento de gerenciamento de requisitos
1. Identificação de requisitos
Cada requisito deve possuir um identificador, ou melhor, pode ser definida uma política para compor cada identificação. Ela precisa ser única e mesmo que o requisito deixe de ser utilizado, deve mantê-la para fins de histórico.
2. Processo de gerenciamento de mudanças
Política que define conjunto de atividades cujo objetivo está em avaliar o impacto causado e o referenciar o(s) custo(s) inerente(s) a(s) mudança(s).
3. Políticas de rastreabilidade
Definem os relacionamentos entre cada requisito e o projeto de sistema que deve ser registrado. A política de rastreabilidade também deve definir como esses registros serão mantidos.
4. Ferramenta de apoio
Não existe implicação direta em fazer o controle via formulários, contudo, gerenciar requisito abarca sempre grandes volumes de informações. É uma boa prática a utilização de ferramentas tecnológicas, que podem ser desde sistemas especializados em gerenciamento de requisitos até planilhas e sistemas de banco de dados simples.
A importância no gerenciamento de mudanças é fundamental, pois é necessário decidir se os benefícios da implementação de novos requisitos justificam os custos de implementação, ou seja, “os fins justificam os meios”.
Confiar na mente humana e/ou no “bom senso” representa péssimo modelo de gerenciamento.
Quase que na maioria das vezes as mudanças no sistema são feitas, e é esquecido de incluir, acrescentar, atualizar tais alterações no documento de requisitos
Aula 10 –Caso de Uso
Representados por diagramas, os Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. Ele então expõe uma espécie de cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.
O diagrama de Caso de Uso é compostos basicamente por 3 elementos. São eles:
 
• Atores: Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator identifica um usuário do sistema, seja ele humano ou
outro sistema.
• Casos de uso: Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. Um caso de uso define uma grande função do sistema.
• Relacionamentos entre estes elementos
Mediante aspectos inerente a necessidade de fazer uso de casos de uso por outro caso de uso, estes podem se relacionar de duas formas:
Include
Quando um caso de uso “A” inclui (include) outro caso de uso “B”. Isto implica que ao executar o caso de uso “A” executa-se também o caso de uso “B”.
Extends
Quando um caso de uso “A” tem um relacionamento do tipo extends com outro caso de uso “B”. Implica que ao executar o caso de uso “A” não necessariamente “B” será executado. A diferença é que no include existe uma dependência do uso do caso de uso, o que não acontece quando o relacionamento é extend.
UML – Unified Modeling Language
A UML  surgiu a partir de um incentivo (inclusive financeiro) da Rational Software na união entre outras três metodologias de modelagem. Foram eles: (a) o método do americano Grady Booch; (b) o método OMT (Object Modeling Technique) do sueco Ivar Jacobson; e (c) o método OOSE (Object-Oriented Software  Engineering) do americano James Rumbaugh.
	 9a Questão (Ref.: 201308197403)
	
	Quais as atividades envolvidas durante o Levantamento de Requisitos? Explique cada uma delas.
		
	
Sua Resposta: Compreensão de domínio, Coleta de requisitos, Classificação, Resolução de conflitos, Definição das prioridades, Verificação de requisitos
	
Compare com a sua resposta: Elicitação:
Tem o objetivo de entender o processo como um todo. Pra tanto, geralmente são
feitas entrevistas com as pessoas envolvidas nas atividades relevantes pra execução
das tarefas e até avaliações in loco do ambiente de trabalho. Ao término do processo
o analista deve entender o fluxo de trabalho, o que cada funcionário consome como
entrada e o que gera como saída além do que pode atrapalhar e o que pode melhorar
esse fluxo de trabalho. O produto dessa atividade é a lista de requisitos.
Análise:
Essa atividade consiste em organizar os requisitos em categorias, examinar os
relacionamentos e dependências entre eles, analisar a consistência, além de
omissões e ambiguidades, estabelecer uma ordem de prioridade e reconhecer a
origem e a necessidade de cada requisito.
Especificação:
É a descrição dos requisitos levantados. Pode ser feita em linguagem natural
(texto informal, tabelas, diagramas), linguagem natural estruturada (formulários)
ou linguagem formal (notação matemática).
Modelagem:
É a representação dos requisitos levantados de forma a garantir o melhor
entendimento. Isso pode ser feito, por exemplo, explicitando as informações que
o sistema irá processar, qual o comportamento esperado depois de realizado o
processamento, etc.
Validação:
São revisões realizadas pelos clientes e pela equipe de desenvolvimento pra
garantir que os requisitos estejam sempre consistentes, comprometidos com o
objetivo dos sitema, e não-ambíguos.
Gerenciamento:
Estabelecer padrões de nomenclatura e identificação, divisão por classes, etc.
		
	
	
	 10a Questão (Ref.: 201308197404)
	
	Cite as principais dificuldades da etapa de levantamento de requisitos.
		
	
Sua Resposta: A falta de conhecimento do que o cliente realmente quer.
	
Compare com a sua resposta: Frequentemente o cliente não sabe direito o que quer do seu futuro sistema ou tem
visões conflitantes de diferentes partes do sistema. A comunicação entre desenvolvedores
e clientes nem sempre flui harmoniosamente. Algumas pessoas tem dificuldade de se
expressar. Além do mais, o vocabulário técnico muitas vezes acaba por complicar essa
comunicação.