类别 全部 - requisitos - negócios - sistema - mudanças

作者:Gabriel Machado 7 年以前

1319

Engenharia de Requisitos

No campo da Engenharia de Requisitos, o gerenciamento de requisitos é um processo crucial que envolve a compreensão e o controle das alterações nos requisitos do sistema. Este processo deve ser iniciado assim que uma versão preliminar do documento de requisitos esteja disponível, embora o planejamento sobre como gerenciar essas mudanças deva começar durante a fase de elicitação de requisitos.

Engenharia de Requisitos

Engenharia de Requisitos

4.3 Especifcação de requisitos

Especifcações estruturadas
Quando um formulário-padrão é usado para especificar requisitos funcionais é necessário:

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

As tabelas são particularmente úteis quando há um número de situações alternativas possíveis e é necessário descrever as ações a serem tomadas para cada uma dela
A especificação pode ser estruturada em torno dos objetos manipulados pelo sistema, das funções desempenhadas pelo sistema, ou pelos eventos processados pelo sistema
Pode definir um ou mais templates para representar esses requisitos como formulários estruturados
Pode destacar elementos-chave pelo uso de sombreamento ou fontes diferentes
Pode usar construções de linguagem de programação para mostrar alternativas e iteração
Todos os requisitos são escritos em uma forma-padrão
A liberdade do escritor dos requisitos é limitada
Especificação em linguagem natural
Diretrizes simples para minimizar os mal-entendidos ao escrever requisitos em linguagem natural

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

Potencialmente vaga, ambígua e seu significado depende do conhecimento do leitor
Cada frase deve expressar um requisito
Os requisitos são escritos em frases numeradas em linguagem natural
É expressiva, intuitiva e universal
Os requisitos de sistema
Devem consistir em uma especificação completa e detalhada de todo o sistema
Pode ser escrito em linguagem natural, em notações com base em formulários, modelos gráficos ou matemáticos de sistema
Eles não devem se preocupar com a forma como o sistema deve ser projetado ou implementado
Eles podem ser usados como parte do contrato para a implementação do sistema
São versões expandidas dos requisitos de usuário
Usados por engenheiros de software como ponto de partida para o projeto do sistema.
Os requisitos de usuário
Devem escrever os requisitos de usuário em linguagem natural, com tabelas simples, formas e diagramas intuitivos
O documento de requisitos não deve incluir detalhes da arquitetura ou projeto do sistema
Devem especificar somente o comportamento externo do sistema
Devem descrever os requisitos funcionais e não funcionais

Precisa ser compreensível para os usuários do sistema que não tenham conhecimentos técnicos detalhados

É o processo de escrever os requisitos de usuário e de sistema em um documento de requisitos

Devem ser: claros, inequívocos, de fácil compreensão, completos e consistentes

4.2 O documento de requisitos de software

Estrutura do documento
Índice

Além do alfabético normal, índices do documento podem ser de diagramas, de funções, entre outros pertinentes

Apêndices

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

Evolução do sistema

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

Modelos do sistema

Inclui gráficos do sistema que mostram os relacionamentos entre os componentes do sistema, o sistema e seu ambiente

Especificação de requisitos do sistema

Pode definir interface com sistemas externos

Descreve em detalhes os requisitos funcionais e não funcionais

Arquitetura do sistema

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

Definição de requisitos de usuário

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

Glossá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

Prefácio

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

Nível de detalhamento do documento
Depende do tipo de sistema em desenvolvimento e do processo usado

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

O documento tem diversos usuários
Leitores

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

Precisa ser entendido por todos os leitores
Métodos ágeis de desenvolvimento argumentam que os requisitos mudam muito rapidamente
Sugerem coletar os requisitos de usuário de forma incremental

Escrevem os requisitos em cartões como estórias de usuários

Quando se termina de escrever o documento de requisitos, este já está ultrapassado

Desperdício de tempo e trabalho

É essencial quando um contratante externo está desenvolvendo o sistema
Devem incluir
Especificação detalhada dos requisitos de sistema
É uma declaração oficial de o que os desenvolvedores dos sistema vão implementar

4.1 Requisitos funcionais e não funcionais

Na prática, é difícil separar os requisitos funcionais dos não funcionais no documento de requisitos
Uni-los gera um melhor entendimento das relações entre os requisitos
http://www.ifc-camboriu.edu.br/~catia/IA16/Engenharia_Software_3Edicao.pdf
Sempre que possível, escrever os requisitos quantitativamente

Verificar se os requisitos estão sendo cumpridos

Podem ser objetivamente testados

Tipos de requisitos não funcionais

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

Implementação dos requisitos pode ser difundida em todo o sistema

Um requisito não funcional pode gerar uma série de requisitos funcionais

Podem afetar a arquitetura geral do sistema

São frequentemente mais críticos, não atender um requisito pode acarretar em inutilizacao do sistema
Normalmente restringem o sistema como um todo
Relacionados por exemplo à confiabilidade, tempo de resposta e ocupação de área
Requisitos que não estão diretamente ligados aos serviços específicos oferecidos pelo sistema
Especificação deve ser

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

Imprecisão na especificação de requisitos é a causa de muito problemas da engenharia de software
Variam de descrições gerais até requisitos muito específicos
Dependem do tipo de software, dos possíveis usuários e da abordagem adotada ao escrever os requisitos
Descreve o que o sistema deve fazer
A distinção entre os tipos de requisitos não é tão clara
O importante é garantir que os serviços e funcionalidades sejam entregues corretamente
Muitas vezes geram ou restringem outros requisitos
Requisitos são independentes
Definição básica
Requisitos não funcionais

Restrições aos serviços ou funções oferecidos pelo sistema

Requisitos Funcionais

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

Importância dos níveis de requisitos
Diferentes usos dos requisitos

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)

Garantir o entendimento dos requisitos pelos diferentes leitores
Requisitos de sistema

Desenvolvedores de software

Informações específicas
Pode ser parte do contrato de compra do software
Contém exatamente o que deve ser implementado
Descrição detalhada das funções, serviços e restrições do sistema
Requisitos de usuário
Leitor alvo

Arquitetos de sistema

Gerentes contratantes

Engenheiros clientes

Usuários finais

Gerentes clientes

Informações generalizadas
Contém os serviços e restrições do sistema
Declarações em linguagem natural e diagramas
Engenharia de requisitos
Processo que busca descobrir, analisar, documentar e verificar os serviços e restrições
Requisitos do sistema
Define a finalidade do sistema
Refletem as necessidades do cliente
Restrições
Serviços oferecidos
Descrição das funções
Conteúdo do capítulo
Importância do gerenciamento de requisitos e como ele suporta outras atividades da engenharia de requisitos
Atividades de elicitação, análise e validação e a relação entre elas
Organização dos requisitos em um documento
Diferenças entre requisitos de software funcionais e não funcionais
Conceitos de requisito de usuário e de sistema

Razão para a diferenciação

Processos envolvidos na descoberta e documentação dos requisitos
Apresentar os requisitos de software

4.4 Processos de engenharia de requisitos

Análise orientada a objetos
Conjunto de modelos

É anotado com informações adicionais

Confiabilidade requerida do sistema

Desempenho

Descreve o comportamento do sistema

Trata-se de analisar o sistema e desenvolver um conjunto de modelos gráficos do mesmo

Servem como uma especificação do sistema

Modelos de casos de uso

Modelo espiral
Os requisitos e a implementação podem ser desenvolvidos em conjunto por meio do desenvolvimento ágil
O número de iterações em torno da espiral pode variar

A espiral pode acabar depois da definição de alguns ou de todos os requisitos de usuário

Os requisitos são desenvolvidos em diferentes níveis de detelhamento
O tempo gasto em cada atividade depende do
Estágio do processo como um todo
Tipo de sistema que está sendo desenvolvido
As atividades são organizadas em torno de uma espiral
Tem como resultado um documento de requisitos de sistema
Como um processo iterativo
Pode incluir quatro atividades de alto nível
Verificando se os requisitos realmente definem o sistema que o cliente quer (validação)
Convertendo-os em alguma forma-padrão (especificação)
Descobrindo requisitos (elicitação e análise)
Avaliando se o sistema é útil para a empresa (estudo de viabilidade)

4.5 Elicitação e análise de requisitos

Etnografa
Não é uma abordagem completa para elicitação
Pode ser combinada com prototipação

A etnografia informa o desenvolvimento do protótipo, para que menos ciclos de refinamento do protótipo sejam necessários

Eficaz para descobrir dois tipos de requisitos

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

Fatores sociais e organizacionais que afetam o trabalho, mas que não são óbvios para os indivíduos, podem ficar claros apenas quando analisados por um observador imparcial.
Importância

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

Sistemas de software são usados em um contexto social e organizacional

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

Casos de uso
Não é eficaz para elicitação

descobrir requisitos de domínio

dos não funcionais em alto nível

dos requisitos de negócios

das restrições

Deve ser documentado com uma descrição textual

pode ser ligada a outros modelos UML que desenvolverão o cenário com mais detalhes

Identificam as interações individuais entre o sistema e seus usuários ou outros sistemas
Não há distinção entre cenários e casos de uso que seja simples e rápida

Outros encapsulam um conjunto de cenários em um único caso de uso

Alguns consideram cada caso de uso um cenário único

O conjunto de casos de uso representa todas as possíveis interações que serão descritas nos requisitos de sistema
Documentados por um diagrama de casos de uso de alto nível
Identifica os atores envolvidos em uma interação e dá nome ao tipo de interação

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

Técnica de descoberta de requisitos introduzida inicialmente no método Objectory
Cenários
Outra possibilidade é uma abordagem mais estruturada, em que cenários de eventos ou casos de uso podem ser usados
Podem ser escritos como texto, suplementados por diagramas, telas, etc
Na elicitação baseada em cenários, é preciso

capturar detalhes que serão incluídos nesses cenários

identificar o cenário

Podem incluir

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

Durante o processo de elicitação, detalhes são adicionados a esse esboço
Começa com o esboço da iteração
Úteis para adicionar detalhes a uma descrição geral de requisitos
Entrevistas
Para evitar que informações deixem de ser capitadas, deve se usar um conjunto com outras técnicas de elicitação de requisitos
Informações recolhidas em entrevistas suplementam outras informações sobre o sistema
Bons entrevistadores

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

Não é eficaz na elicitação de

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

São boas para a compreensão global sobre

as dificuldades que eles enfrentam com os sistemas atuais

como eles podem interagir com o novo sistema

o que os stackholders fazem

Tipos

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 stackholders são questionados sobre o sistema que usam, e o que será desenvolvido

Os requisitos surgem a partir das respostas

Elicitação de requisitos
Fontes de informações

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

Responsável por

Separar dessas informações os requisitos de

sistema

usuário

Reunir informações sobre

Sistemas existentes

Sistemas requeridos

Uma versão inicial do documento de requisitos do sistema pode ser produzida com seções faltantes e requisitos imcompletos

Utilizando

Cartões

Facilitam para os stakeholders lidarem, mudarem e organizarem os requisitos

Planilhas

A opinião de todos os stakeholders devem ser consideras
Durante o processo, deve se organizar as negociações regulares dos stakeholders
O processo é um pouco difícil

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

É um processo iterativo, com feedback contínuo de cada atividade para as outras atividades
Podem envolver diversos tipos de pessoas em uma organização
Os engenheiros de software trabalham com clientes e usuários finais do sistema para obter informações sobre

Entre outros

Restrições de hardware

Desempenho do sistema

Serviços que o sistema deve oferecer

Domínio da aplicação

4.6 Validação de requisitos

Técnicas de validação de requisitos
3. Geração de casos de teste

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

2. Prototipação

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

1. Revisões de requisitos

Os requisitos são analisados sistematicamente por uma equipe de revisores que verifica erros e inconsistências

Tipos de verificação que devem ser efetuados com os requisitos no documento de requisitos
5. Verificabilidade

É necessário ser capaz de escrever um conjunto de testes que demonstrem que o sistema entregue atende a cada requisito especificado

4. Verificações de realismo

Os requisitos devem ser verificados para assegurar que realmente podem ser implementados

Considerarando o orçamento e o cronograma para o desenvolvimento do sistema

3. Verificações de completude

O documento de requisitos deve incluir requisitos que definam todas as funções e as restrições pretendidas pelo usuário do sistema

2. Verificações de consistência

Não deve haver restrições contraditórias ou descrições diferentes da mesma função do sistema

1. Verificações de validade

Ter maior reflexão e análise mais aprofundada podem identificar funções necessárias, adicionais ou diferentes

É importante porque erros em um documento de requisitos podem gerar altos custos de retrabalho

Quando descobertos durante o desenvolvimento ou após o sistema já estar em serviço

É o processo pelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer

4.7 Gerenciamento de requisitos

Gerenciamento de mudança de requisitos
Não se deve modificar o sistema e depois o documento de requisitos, pois pode levar a uma incoerência das informações
Estágios do processo de gerenciamento de mudanças

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

É essencial, pois é necessário decidir se os benefícios da implementação de novos requisitos justificam os custos de implementação
Planejamento de gerenciamento de requisitos
Precisa de apoio automatizado, e as ferramentas de software para esse gerenciamento devem ser escolhidas durante a fase de planejamento

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

Questões que devem ser decididas no estágio de gerenciamento 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

Determina o nível de detalhamento requerido no gerenciamento de requisitos
O é o primeiro estágio essencial no processo de gerenciamento de requisitos
Introdução
O processo de gerenciamento de requisitos deve começar quando uma versão preliminar do documento de requisitos estiver disponível

Mas, deve se começar o planeamento de como gerenciar as mudanças de requisitos durante o processo de elicitação de requisitos

É preciso

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

Razões pelas quais a mudança é inevitável

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

Após a instalação e o uso do sistema, surgirão novos requisitos
O que é

É o processo de compreensão e controle das mudanças nos requisitos do sistema