por Gabriel Machado 7 anos atrás
1319
Mais informações
Desvantagens
Difícil escrever os requisitos de forma clara e inequívoca, especialmente quando processamentos complexos (como, por exemplo, calcular a dose de insulina) devem ser especificados
Solução: adicionar informações extras aos requisitos em linguagem natural, usando tabelas ou modelos gráficos do sistema
Vantagens:
Os requisitos são organizados de forma mais eficaz
Reduz-se a variabilidade na especificação
7. Uma descrição dos efeitos colaterais da operação
6. Se uma abordagem funcional é usada, uma pré-condição define o que deve ser verdade antes que a função seja chamada, e é chamada uma pós-condição, especificando o que é verdade depois da função
5. Uma descrição da ação a ser tomada
4. Informações sobre a informação necessária para o processamento ou outras entidades usadas no sistema
3. Uma descrição de suas saídas e para onde elas irão
2. Uma descrição de suas entradas e de onde elas vieram
1. A descrição da função ou entidade a ser especificada
Não assumir que os leitores compreendem a linguagem técnica da engenharia de software
Use uma forma de destacar as partes fundamentais do requisito (negrito, itálico ou cores)
Use uma linguagem consistente para distinguir entre os requisitos obrigatórios e os desejáveis
"deve" para obrigatórios e "pode" para não essenciais
Invente um formato-padrão e garanta que todas as definições de requisitos aderem a esse formato
A padronização do formato torna menos prováveis as omissões e mais fácil a verificação dos requisitos
Precisa ser compreensível para os usuários do sistema que não tenham conhecimentos técnicos detalhados
Devem ser: claros, inequívocos, de fácil compreensão, completos e consistentes
Além do alfabético normal, índices do documento podem ser de diagramas, de funções, entre outros pertinentes
Banco de dados
Definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre esses dados
Hardware
Define as configurações mínimas ideais para o funcionamento do sistema
Fornece informações detalhadas e específicas relacionadas à aplicação em desenvolvimento
Ajuda os projetistas a evitar decisões capazes de restringir possíveis mudanças futuras no sistema
Mudanças nas necessidades do usuário
Qualquer mudanças previstas em decorrência da evolução de hardware
Descreve os pressupostos fundamentais em que o sistema se baseia
Inclui gráficos do sistema que mostram os relacionamentos entre os componentes do sistema, o sistema e seu ambiente
Pode definir interface com sistemas externos
Descreve em detalhes os requisitos funcionais e não funcionais
Destaca componentes de arquitetura que são reusados
Mostra distribuições de funções entre os módulos do sistema
Apresenta uma visão geral em alto nível da arquitetura do sistema
Pode usar linguagem natural, diagramas ou outras notações que facilitem o entendimento
Especificar normas de produto e processos que devem ser seguidos
Inclui os requisitos não funcionais
Descreve os serviços fornecidos ao usuário
Defini os termos técnicos usados no documento
Descreve a maneira que o sistema atende os objetivos globais de negócio ou estratégicos da organização contratante
Descreve brevemente as funções do sistema e sua interação com outros sistemas
Descreve a necessidade para o sistema
Descreve histórico de versões com justificativa para criação de uma nova versão e resumo das mudanças de cada uma
Defini os possíveis leitores do documento
Exemplos
Detalhamento básico das especificações
Processo de desenvolvimento interno
Ambiguidades ou dúvidas podem ser resolvidas durante o desenvolvimento
Alto detalhamento das especificações
Sistemas desenvolvidos por uma companhia separada
Sistemas críticos
Engenheiros de manutenção
Entender o sistema e os relacionamentos entre suas partes
Engenheiros de teste
Desenvolver testes de validação
Engenheiros de sistema
Entender o sistema que será desenvolvido
Gerentes
Planejar uma proposta para o sistema e planejar o processo de desenvolvimento
Clientes
Verificar se os requisitos satisfazem suas necessidades
Escrevem os requisitos em cartões como estórias de usuários
Desperdício de tempo e trabalho
Verificar se os requisitos estão sendo cumpridos
Podem ser objetivamente testados
Requisitos externos
Requisitos que derivam de fatores externos ao sistema e seu processo de desenvolvimento
Requisitos organizacionais
Requisitos derivados das políticas e procedimentos da organização do cliente e do desenvolvedor
Requisitos de produto
Especificam ou restringem o comportamento do software
Um requisito não funcional pode gerar uma série de requisitos funcionais
Podem afetar a arquitetura geral do sistema
Em sistemas grandes é quase impossível alcançar completude e consistência
Consistente
Definições dos requisitos não devem ser contraditórias
Completa
Definir todos os serviços requeridos pelo usuário
Restrições aos serviços ou funções oferecidos pelo sistema
Comportamento do sistema em determinadas situações
Reação do sistema a entradas específicas
Declarações de serviços que o sistema deve fornecer
Já em outros é necessários saber dos detalhes de implementação (requisitos de sistema)
Em certos momentos é necessária uma abstração dos detalhes de implementação (requisitos de usuário)
Desenvolvedores de software
Arquitetos de sistema
Gerentes contratantes
Engenheiros clientes
Usuários finais
Gerentes clientes
Razão para a diferenciação
É anotado com informações adicionais
Confiabilidade requerida do sistema
Desempenho
Descreve o comportamento do sistema
Servem como uma especificação do sistema
Modelos de casos de uso
A espiral pode acabar depois da definição de alguns ou de todos os requisitos de usuário
A etnografia informa o desenvolvimento do protótipo, para que menos ciclos de refinamento do protótipo sejam necessários
Requisitos derivados da cooperação e conhecimento das atividades de outras pessoas
Requisitos derivados da maneira como as pessoas realmente trabalham, e não da forma como as definições dos processos dizem que deveriam trabalhar
Ajuda a descobrir requisitos implícitos do sistema que refletem as formas reais com que as pessoas trabalham, em vez de refletir processos formais definidos pela organização
É uma técnica de observação que pode ser usada para compreender os processos operacionais e ajudar a extrair os requisitos de apoio para esses processos
requisitos de software do sistema podem ser derivados ou restringidos desse contexto
O fracasso de alguns sistemas, é que não levam em conta a forma como o contexto social e organizacional afeta o funcionamento prático do sistema
satisfazer a esses requisitos sociais e organizacionais é crítico para o sucesso do sistema
descobrir requisitos de domínio
dos não funcionais em alto nível
dos requisitos de negócios
das restrições
pode ser ligada a outros modelos UML que desenvolverão o cenário com mais detalhes
Outros encapsulam um conjunto de cenários em um único caso de uso
Alguns consideram cada caso de uso um cenário único
Suplementada por informações adicionais que descrevem a interação com o sistema
Essa informação pode ser
modelos gráficos
estado UML
diagramas de sequência
descrição textual
capturar detalhes que serão incluídos nesses cenários
identificar o cenário
Uma descrição do estado do sistema quando o cenário acaba
Informações sobre outras atividades que podem acontecer ao mesmo tempo
Uma descrição do que pode dar errado e como isso é tratado
Uma descrição do fluxo normal de eventos no cenário
Uma descrição do que o sistema e os usuários esperam quando o cenário se iniciar
estimulam o convidado a participar de discussões
trabalhando em conjunto em um protótipo do sistema
uma proposta de requisitos
questão-trampolim
estão dispostos a mudar de ideia sobre o sistema
evitam ideias preconcebidas sobre os requisitos
estão abertos a novas ideias
Conhecimento sobre os requisitos e restrições organizacionais
A maioria das pessoas é relutante em discutir questões políticas e organizacionais que podem afetar os requisitos
O conhecimento de domínio é tão familiar aos stakeholders que eles têm dificuldade de explicá-lo ou pensam que é tão fundamental que não vale a pena mencionar
Uso de terminologias e jargões pelos especialistas em aplicações, desconhecido dos engenheiros de requisitos
as dificuldades que eles enfrentam com os sistemas atuais
como eles podem interagir com o novo sistema
o que os stackholders fazem
Discussões totalmente abertas raramente funcionam bem
É preciso fazer algumas perguntas para começar e manter a entrevista centrada no sistema que será desenvolvido
Na prática, costuma ser um mistura dos dois
Aberta
A equipe explora uma serie de questões com os stackholders do sistema
desenvolvendo uma melhor compreensão de suas necessidades
Não existe uma agenda predefinida
Fechada
Possui um conjunto de perguntas é predefinido
Os requisitos surgem a partir das respostas
Stakeholders do sistema
Variam desde os usuário finais, até os stakeholders externos
Utiliza se cenários e protótipos para ajudar os stakeholders a compreenderem o que o sistema vai ser
Interação por meio de
entrevista
observação
Sistemas que interagem com o sistema especificado
Especificação de sistemas similares
Documentos
Separar dessas informações os requisitos de
sistema
usuário
Reunir informações sobre
Sistemas existentes
Sistemas requeridos
Utilizando
Cartões
Facilitam para os stakeholders lidarem, mudarem e organizarem os requisitos
Planilhas
O ambiente econômico e empresarial no qual a análise ocorre é dinâmico
Novos requisitos podem surgir
A importância dos requisitos específicos pode mudar
Fatores políticos podem influenciar os requisitos de um sistema
Os gerentes podem exigir requisitos específicos, porque estes lhes permitirão aumentar sua influência na organização
Diferentes stakeholders têm requisitos diferentes e podem expressar essas diferenças de várias maneiras
Engenheiros de requisitos precisam descobrir todas as potenciais fontes de requisitos e descobrir as semelhanças e conflitos.
Os stakeholders expressam requisitos em seus próprios termos e com o conhecimento implícito de seu próprio trabalho
Engenheiros de requisitos, sem experiência no domínio do cliente, podem não entender esses requisitos
Os stakeholders costumam não saber o que querem de um sistema computacional
Podem fazer exigências inviáveis
Podem achar difícil articular o que querem que o sistema faça
Entre outros
Restrições de hardware
Desempenho do sistema
Serviços que o sistema deve oferecer
Domínio da aplicação
O desenvolvimento de testes a partir dos requisitos do usuário antes de qualquer código ser escrito é parte integrante do Extreme Programming
Se é difícil ou impossível projetar um teste, os requisitos devem ser reconsiderados
Os requisitos devem ser testáveis
Podem experimentar o modelo para verificar se ele atende a suas reais necessidades
Um modelo executável do sistema em questão é demonstrado para os usuários finais e clientes
Os requisitos são analisados sistematicamente por uma equipe de revisores que verifica erros e inconsistências
É necessário ser capaz de escrever um conjunto de testes que demonstrem que o sistema entregue atende a cada requisito especificado
Os requisitos devem ser verificados para assegurar que realmente podem ser implementados
Considerarando o orçamento e o cronograma para o desenvolvimento do sistema
O documento de requisitos deve incluir requisitos que definam todas as funções e as restrições pretendidas pelo usuário do sistema
Não deve haver restrições contraditórias ou descrições diferentes da mesma função do sistema
Ter maior reflexão e análise mais aprofundada podem identificar funções necessárias, adicionais ou diferentes
Quando descobertos durante o desenvolvimento ou após o sistema já estar em serviço
Implementação de mudanças
O documento de requisitos e, quando necessário, o projeto e implementação do sistema são modificados.
Análise de mudanças e custos
Quando a análise é concluída decide-se prosseguir ou não com a mudança de requisitos
O custo de fazer a mudança é estimado em termos de modificações no documento de requisitos e, no projeto e implementação do sistema.
O efeito da mudança proposta é avaliado por meio de informações de rastreabilidadee conhecimentos gerais dos requisitos do sistema
Análise de problema e especificação de mudanças
A análise é transmitida a quem solicitou a mudança
retirar a solicitação
que pode responder com uma proposta mais específica de mudança de requisitos
Analisa-se o problema ou a proposta de mudança a fim de se verificar sua validade
Ferramentas de apoio servem para
Gerenciamento de rastreabilidade
Permitem descobrir requisitos relacionados
Gerenciamento de mudanças
O processo de gerenciamento de mudanças é simplificado quando as ferramentas ativas de apoio estão disponíveis
Armazenamento de requisitos
Os requisitos devem ser mantidos em um repositório de dados gerenciado e seguro, acessível a todos os envolvidos no processo de engenharia de requisitos
Políticas de rastreabilidade
Definem os relacionamentos entre cada requisito e entre os requisitos e o projeto de sistema que deve ser registrado
Ferramenta de apoio
Ferramentas que podem ser usadas variam desde sistemas especializados em gerenciamento de requisitos até planilhas e sistemas de banco de dados simples
Processo de gerenciamento de mudanças
Conjunto de atividades que avaliam o impacto e o custo das mudanças
Identificação de requisitos
Cada requisito deve ser identificado unicamente para poder ser comparado com outros requisitos e usado em avaliações de rastreabilidade
Mas, deve se começar o planeamento de como gerenciar as mudanças de requisitos durante o processo de elicitação de requisitos
Estabelecer um processo formal para fazer propostas de mudanças e a ligação destas às exigências do sistema.
Ter conhecimento sobre as necessidades individuais e manter as ligações entre as necessidades dependentes para conseguir avaliar o impacto das mudanças nos requisitos
Sistemas de grande porte têm uma comunidade de diversos usuários, com diferentes requisitos e prioridades, que podem ser conflitantes ou contraditórios
As pessoas que pagam por um sistema e os usuários desse sistema raramente são os mesmos
novos recursos podem ser adicionados, para dar suporte ao usuário, a fim de que o sistema cumpra suas metas
Após a instalação, o ambiente técnico e de negócios do sistema sempre muda
Podem ser introduzidas novas legislações e regulamentos aos quais o sistema deve respeitar
As prioridades do negócio podem mudar
Pode ser necessário fazer a interface do sistema com outros sistemas
Um novo hardware pode ser introduzido
É o processo de compreensão e controle das mudanças nos requisitos do sistema
