Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Modelagem de Requisitos baseada em Cenários, Histórias de Usuário e Casos de Uso by Mind Map: Modelagem de Requisitos baseada
em Cenários, Histórias de Usuário
e Casos de Uso
5.0 stars - 1 reviews range from 0 to 5

Modelagem de Requisitos baseada em Cenários, Histórias de Usuário e Casos de Uso

Importância dos Objetivos na Engenharia de Requisitos

Objetivos estimulam a elaboração de requisitos na medida que fornecem uma justificativa para o requisito, ou seja, um requisito existe devido a algum objetivo subjacente (ROBISON). Objetivos estimulam a elaboração de requisitos sendo a sua base além de que proporcionam um critério para a integralidade da especificação dos requisitos -  a especificação é completa se todos os objetivos declarados são obtidos pela especificação Os objetivos fornecem uma justificação para a exigência de requisitos - um requisito existe devido a algum objetivo subjacente que fornece uma base para o mesmo e ainda representam as raízes para a detecção de conflitos entre requisitos e para a resolução  eventual dos mesmos. Em resumo, requisitos "implementam" objetivos da mesma forma como programas implementam especificações de projeto (design).

Definições fundamentais

Dominio da Aplicação

Objetivo

Requisito

Especificação

Tipos de Objetivos

Objetivos de Obtenção

Objetivos de Término

Objetivos de Manutenção

Objetivos de Não Ocorrência

Hierarquia de Objetivos

Em softwares grandes e complexos existem muitos objetivos que se relacionam uns comos outros resultando em uma hierarquia estruturada de objetivos. Na hierarquia o objetivo mais abstrato é mostrado na parte superior e os objetivos mais especificos são obtidos em refinamentos do objetivo mais geral, sendo que os subobjetivos devem ser satisfeitos como meio para cumprir um objetivo.

Partterns de Refinamento objetivos, Disjunção, Conjunção, Marco, Baseado em Casos

Principais Utilizações

Cockburn é frequentemente citado como tendo introduzido objetivos  na análise orientada a objeto (Cockburn 1997). Ele define casos de uso para satisfazer os objetivos: Ele vê  cinco possibilidades para o uso de objetivos: (1) atribuir requisitos não-funcionais a objetivos (2) acompanhar o projeto pelos objetivos (3) obter  requisitos diferentes  a partir do não alcance dos objetivos (4) utilização objetivos associados a design das suas realizações (5) casar objetivos do usuário com conceitos operacionais. Mais recentemente, Bock demonstrou  como objetivos podem auxiliar na escolha de parâmetros a partir de  modelos de objeto (Bock 2001).

Especificações a partir de objetivos - Método

Elicitação

Definir objetivos

Derivar requisitos

Elaborar casos de uso

Elaborar outros arterfatos da UML

KAOS - Método a objetivos

Requisitos

Engenharia de Requisitos é um amplo campo de pesquisa para a Engenharia de Software. Como área específica de atuação, apresenta avanços tecnológicos e meios próprios voltados para pesquisa em terminologia, métodos, linguagens e ferramentas que compõem o esforço de pôr em prática o campo de conhecimento gerado Talvez o maior problema que enfrentamos no desenvolvimento de sistemas desoftware grandes e complexos seja o da engenharia de requisitos. Ela está relacionada com a definição do que o sistema deve fazer, suas propriedades emergentes desejáveis e essenciais e as restrições quanto à operação do sistema e quanto aos processos de desenvolvimento de software. A engenharia de requisitos é, portanto, o processo de comunicação entre os clientes e os usuários de software e os desenvolvedores de software (SOMMERVILLE). O domínio do problema é, portanto, o ambiente de atuação do software. Neste ambiente principiam as atividades da engenharia de software, a definição das necessidades do software. É tarefa dos engenheiros de requisitos entender o problema, na cultura e linguagem dos usuários, e definir um sistema que atenda às suas necessidades [LARMAN]. Para tal, o engenheiro de requisitos deve descobrir e estabelecer o universo de informações, de onde obtém os recursos na tarefa de elucidação do problema. Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e suas restrições operacionais. Esses requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema (PRESSMAN). Requisitos são capacidades e condições às quais o sistema ou projeto deve atender. Um desafio básico de determinar os requisitos é encontrar,comunicar e registrar o que realmente é necessário, expressando isso de forma clara para o cliente e os membros da equipe dedesenvolvimeto.(LARMAN) A modelagem de requisitos não é somente um processo técnico. Os requisitos do sistema são influenciados pelas preferências, recusas e preconceitos dos usuários, além das questões politicas e organizacionais. Esses fatores são caracteristicas humanas fundamentais e novas tecnologias, como casos de uso, cenários e métodos formais, não nos ajudam muito na resolução desses difíceis problemas(SOMMERVILLE). Conhecer sobre o que trata o assunto em questão e quais os fenômenos presentes no ambiente são as condições fundamentais para a descrição de requisitos. Portanto, é necessário: conhecer o domínio da aplicação, o ambiente onde os requisitos dos clientes são encontrados, a definição do alvo do problema e a abrangência do domínio da solução; identificar o problema a resolver, promovendo o entendimento, a especialização e o domínio do conhecimento, compreendendo: o quê, com quê, para quê e para quem; delimitar o contexto do negócio do cliente, estabelecendo objetivos, dominando assuntos organizacionais, fatores políticos, conflitos de poder, relações de influência, entendendo o histórico e estrutura organizacional e a organização do conhecimento acerca da organização; identificar qual o universo de fonte de informação (stakeholder); identificar as exigências e condições para satisfação das necessidades ou desejos do ponto de vista dos stakeholder; validar as informações obtidas e o relacionamento entre elas e compatibilizar idéias; administrar, revisar e negociar conflitos de interesse no atendimento às necessidades; priorizar a demanda pela solução dos problemas; planejar a ordem de implementação e compatibilizar emergência de requisitos; documentar os requisitos, com recuperação acessível do ciclo de vida; aperfeiçoar o processo de comunicação; gerenciar as mudanças nos requisitos.  

Tipos

Os requisitos de sistema de software são, frequentemente classificados em requisitos funcionais e requisitos não funcionais apesar de que alguns autores desaprovam essa generalização ampla, mas ela é bastante usada.

Funcionais

Não Funcionais

Niveis de especificação

Requisitos de Negócios

Requisitos de Usuários

Requisitos Funcionais

Dificuldades e problemas existentes na área

O engenheiro de requisitos deve gerenciar os seguintes problemas: administração de conflitos de interesses e de poder; definição do que é prioritário no interesse da organização; delimitação da fronteira de aplicação da solução; conhecimento do universo de stakeholder atual e futuro; gerenciamento continuado da dinâmica dos requisitos para alinhamento às mudanças organizacionais; restrições de recursos de produção quer sejam humanos, financeiros ou tecnológicos?

Imprecisão na especificação de objetivos / requisitos

A imprecisão na especificação de requisitos é o motivo de muitos problemas de engenharia de software. É natural que um desenvolvedor de sistema interprete um requisito ambiguo de modo a simplificar sua implementação. Frequentemente, no entanto, isso não é o que o cliente quer. Novos requisitos precisam ser definidos e mudanças devem ser feitas no sistema. Naturalmente isso atrasas a entrega do sistema e aumenta os custos do projeto (LARMAN). Em princípio, a especificação de requisitos de um sistema deve ser completa e consistente. Completeza siginifica que todos os serviços exigidos pelo usuário devem ser definidos. Consistência siginifica que os requisitos não devem ter definições contraditórias. Na prática, em sistemas grandes e complexos, é praticamente impossível atingir a consistência e a completeza de requisitos (SOMMERVILLE).

Diferentes Stakeholders com necessidades diferentes e inconsistentes

O universo de pessoas envolvidas no processo produtivo, também denominado stakeholder abrange aqueles que, direta ou indiretamente, influenciam ou são afetados pelo software. Ou seja, o pessoal envolvido com os processos de definição, criação, desenvolvimento, gerenciamento, comercialização, bem como o pessoal identificado como cliente e usuário demandante do produto ou simplesmente qualquer usuário compulsório. É fácil cometer erros e omissões quando se redigem especificações para sistemas grandes e complexos. Outra razão é que diferentes stakeholders no sistema tem diferentes e inconsistentes necessidades. Essas inconsistências podem não ser obvias quando os requisitos são especificados inicialmente, de modo que requisitos inconsistentes sejam incluídos na especificação (SOMMERVILLE). É evidente que satisfazer necessidades ou desejos vai depender da vontade de solução do problema pelo demandante. Nem sempre o produto resultante é um novo software. Pode simplesmente ser uma característica adicional, uma substituição para uma versão mais eficaz da solução existente. O software produto com certeza deve ser adequado à demanda de quem irá utilizá-lo.    

Volatilidade

O cliente vive em um ambiente de contínuas mudanças, que podem ser traduzidas em oportunidades de negócios ou agregação de novos problemas e restrições. Portanto, a solução de software atual nem sempre estará adequada a demandas futuras. Conseqüentemente, a mudança será inevitável.

Escopo

As restrições são limitações que delineiam o espaço de solução do problema. As mais comuns referem-se às limitações para o conhecimento e acesso ao universo de fonte de informação, atual e o potencial futuro. Um dos fatores restritivos mais complexos é que a solução de negócio passa muitas vezes por uma necessidade de novos procedimentos de trabalho, de reestruturação organizacional e por mudanças no relacionamento entre clientes e fornecedores.

Possíveis estratégias de ação

Resultados esperados

A expectativa com o resultado deste trabalho é ordenar conceitualmente a atividade descritiva do processo de descoberta de conhecimento, em etapas sucessivas e complementares, alimentadas de forma recursiva. Especialmente, em promover o espírito crítico e a real necessidade de se reforçar o domínio do conhecimento do ambiente em estudo e os requisitos. Com isto, além de documentar o processo descritivo com o foco no problema, propiciar o preenchimento de uma lacuna na fase inicial de extração de requisitos, especificações e o domínio do conhecimento que não é coberta em sua totalidade pelas metodologias e linguagens de modelagem. Muitas técnicas auxiliam a documentação, entretanto, o uso adequado de uma ferramenta, não a qualifica como infalível nos critérios de validação de requisitos de engenharia de software.

Importância da modelagem de requisistos e a Relação dessa área com demais áreas correlatas.

Segundo pesquisa do Standish Group, as razões principais que levam a problemas de projeto são identificadas na tabela abaixo: Fatores de Projetos Críticos % de Respostas 1. Falta de Especificação do Usuário 12.8% 2. Requisitos Incompletos 12.3% 3. Mudança de Requisitos 11.8% 4. Falta de Apoio Executivo 7.5% 5. Tecnologia Imatura 7.0% 6. Falta de Recursos 6.4% 7. Expectativas irreais 5.9% 8. Objetivos obscuros 5.3% 9. Tempo irreal 4.3% 10. Tecnologia nova 3.7% 11. Outros 23.0%   Juntando com os dados de projetos da Força Aérea Americana sobre o levantamento da fonte de erro por fase do ciclo de vida do software, relatados no gráfico abaixo: Avaliando os dados da tabela das razões principais de problemas de projeto com o gráfico de fonte de erro por fase do ciclo de vida, sob o foco do quadro abaixo de custo relativo de reparo por fase do ciclo de vida, originado por estudos independentes das empresas GTE, TRW e IBM em meados da década de 1970 [1]; Podemos concluir que identificar um erro na fase de manutenção tem um custo relativo 200 vezes maior em relação à descoberta do mesmo erro na fase de análise de requisitos, a etapa inicial do ciclo de vida. Devemos, então, orientar nossos esforços na definição e melhoramento contínuo de processos formais a serem executados durante esta fase, como forma de aumentarmos a qualidade do software desenvolvido, bem como, minimizar o custo deste desenvolvimento. No final da década de 80, com a incumbência de definir processos formais para orientar o estudo da descoberta do problema e do levantamento dos requisitos do software a ser construído, surgiu a engenharia de requisitos. Muitos autores descrevem diferentes atividades para o cumprimento da fase inicial do ciclo de vida, conhecida como análise de requisitos. Segundo Roger Pressman (PRESSMAN, 2009), as atividades a serem desenvolvidas são as seguintes: Extração de requisitos – etapa onde os requisitos são descobertos através de consultas aos envolvidos, documentos, domínio do conhecimento e estudos de mercado; Análise e negociação – os requisitos são analisados em detalhe e recusados ou aceitos; Documentação – onde os requisitos aceitos são documentados em um nível apropriado de detalhe; Validação – os requisitos são checados cuidadosamente para verificação de consistência e completeza. Gerenciamento – onde os requisitos são controlados em função da dinâmica das mudanças ambientais. Como o mundo dos negócios está a cada dia mais ágil, mudanças nos requisitos são uma constante. Isto significa que o processo de tratamento de requisitos é iterativo durante todo o ciclo de vida do software. Após a etapa de validação dos requisitos, temos como resultado o documento formal dos requisitos, que passa a ser o acordo entre os envolvidos no projeto e deve refletir as necessidades que o software deve atender. Este documento norteará todos os esforços das fases seguintes do ciclo de vida. É por este motivo que requisitos bem definidos antes do início do projeto lógico podem evitar retrabalho, minimizando custo e esforço de implementação. A dificuldade de comunicação é o fator crucial dos problemas com requisitos. Uma citação que reflete este problema pode ser encontrada no livro de Engenharia de Software de Roger Pressman (PRESSMAN, 2006), a seguir:   A contribuição fundamental para a pesquisa na área de engenharia de requisitos é a visão conceitual da descrição como arte e técnica no descobrimento e na documentação do conhecimento e representação de requisitos. Deve ser utilizada extensiva e intensivamente até exaurir possibilidades de dúvida e discordâncias e, especialmente, ambigüidades. A descrição é uma tarefa árdua, trabalhosa e complexa, muitas vezes incompreendida por pessoas alheias ao processo de engenharia de software, especificamente o cliente contratante da solução do problema, cuja expectativa de resultado é imediatista. O processo de análise dos requisitos não deve ser uma fato posterior à extração de requisitos e sim concomitante. A ordem não é representar, modelar, para depois ver para que serve e sim, descrever o mais detalhadamente possível os fenômenos do ambiente que caracterizam o problema e, moldar uma solução de sistema de software com critérios de viabilidade de implementação, antes do início do desenvolvimento do software.

Casos de Uso

Fundamentos e Conceitos

Analistas tem dificuldades na decomposição e estruturação de casos de uso para a especificação de software. A modelagem baseada em objetivos ajuda a guiar o desenvolvimento de casos de uso. Casos de uso foram introduzidos por Jacobson como parte da metodologia de desenvolvimento de software OOSE (Object-Oriented Software Engineering) (LARMAN, 2004). Sua definição original é “Um caso de uso é uma maneira específica de usar um sistema usando alguma parte da funcionalidade. Constitui um curso completo de interação que acontece entre um ator e o sistema”. Por definição, o termo “caso de uso”, introduzido nesta metodologia, não é sinônimo do termo “cenário”. Um cenário deve ser entendido como uma instância específica de um caso de uso (SOMMERVILLE, 2008), ao passo que o caso de uso é uma coleção de cenários, representando múltiplos caminhos.

Aplicação

Notações

Estrutura, Exemplo de diagrama de casos de uso

Dimensões

Em (VEDOATO, 2003), encontra-se um estudo onde é apontado que as diversas definições de casos de uso diferem sobre quatro dimensões: Propósito: casos de uso podem ter o propósito de descrever histórias dos usuários ou especificar requisitos; Conteúdo: o conteúdo de um caso de uso pode ser contraditório ou consistente; quando consistente, pode estar na forma de narrativa textual ounotação formal; Pluralidade: casos de uso podem ser apenas um cenário ou conter múltiplos cenários; Estrutura: uma coleção de casos de uso pode ser representada através de umaestrutura formal, uma estrutura informal, ou, simplesmente, através de um conjunto não estruturado.

Utilização de Casos de Uso

Casos de uso são um mecanismo simples compreensivel para capturar objetivos e requisitos de sistemas. Vistos de modo informal, eles são narrativas que mostram como usar um sistema para atingir objetivos.  

Descobrir requisitos funcionais

Pontos Fortes, Escalabilidade, Simplicidade

Pontos Fracos

Tipos de Casos de Uso

Reconhecemos três tipos comuns de casos de uso, com base em seus atores e no uso de declarações de especificação ( Larman, 2004)

Casos de uso de negócios

Casos de uso de tarefas

Casos de uso de baixo nível

Cenários

É uma sequencia especifica de ações e interações entre atores e o sistema em discussão, é também chamado de instância de casos de uso. É uma história particular de uso do sistema ou de um caminho por meio do caso de uso.

Cenários X Casos de uso, http://3.bp.blogspot.com/_8UAUN_oPgSU/SaoQ8dV9_fI/AAAAAAAAACc/ewA0O_AeILs/s1600-h/Cockburn_adornment.JPG