• É um detalhamento da necessidade transformada em solução.
• É uma descrição de como o sistema de informação deve se comportar, ou uma propriedade ou atributo do sistema.
• Pode ser uma restrição sobre o processo de desenvolvimento do sistema.
• Requisito é uma especicação que deve ser implementada.

A solução ser viável.

• Estabelecer e manter concôrdancia sobre o que o sistema deve fazer.
• Oferecer aos desenvolvedores uma compreensão melhor do sistema a ser desenvolvido.
• Delimitar o sistema.
• Planejar o desenvolvimento do sistema.
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento de sistema.

Pode ser a partir de:

Necessidades, desejos e sonhos

Caracteristcas

Principios, missão, valor.

Saidas (interfaces).

Caso de Usos.

Domínio de conhecimento.

Cenários.

Processos e procedimentos.

Dados.

Modelo de negocio.

Regras de negocio.

Plano de projeto.

Qualidade, Comunicação.

requisito: 'idrequisito:' condicao  elemento {'|'+ elemento}

Requisitos são ações objetivas, desejo, solicitação.

Quem pede: Contratante, quem tem uma necessidade de informação

Quem faz: Especialista, Engenheiro de requisito, Analista de requisto , Analista de negócio, Analista de sistema, Desenvolvedor.

Quem usa: Desenvolvedor, Programador, Testador, Implementador, Implantador.

Requisito de Negocio - Um objetivo de negócio de alto nível da organização que constrói um produto/serviço ou adquire isso de um fornecedor.

Regra de negócio - Uma política, orientação, norma ou regulamento que define ou restringe algum aspecto do negócio. Não é um requisito de software em si, mas a origem de vários tipos de requisitos.
Regras de negócio são premissas e restrições aplicadas a uma operação comercial de uma empresa, que precisam ser atendidas para que o negócio funcione da maneira esperada.
Perceber quando há condições: “somente, quando, requer, se, obrigatório, sempre”.

Limitações - Uma restrição que é imposta sobre as opções disponíveis para o desenvolvedor para a concepção e a construção de um produto/serviço.

Requisisitos de interface externa - Uma descrição de uma conexão entre um sistema de software e um usuário, um outro sistema de software ou um dispositivo de hardware.

Carcteristicas (feacture) - Um ou mais recursos do sistema relacionados logicamente que fornecem valor a um usuário e são descritos por um conjunto de requisitos funcionais.

Requisito funcional - Uma descrição de um comportamento que um sistema irá expor sob condições especiais.

Requisito não funcional - Uma descrição de uma propriedade ou característica que um sistema deve apresentar ou uma restrição que deve respeitar.

Atributos de qualidade - Um tipo de requisitos não-funcional que descreve uma característica de serviço ou desempenho de um produto.

Requisito de sistema - Um requisito de nível superior para um produto que contém vários subsistemas, que poderia ser todo um software ou um hardware com software.

Requisito do usuário - Uma meta ou tarefa que specifica classes de usuários que devem ser capazes de executar com um sistema, ou um atributo do produto desejado.

POR ONDE COMEÇAR?:

Pelas necessidades, desejos e sonhos.

ATIVIDADES que determinam os objetivos de um software e as restrições associadas, bem como a elaboração da especificação do software:



• ELICITAR
Entender dominio da aplicação, especificar problema, necessidades e limitações organizacionai.
. Identifique origens de informações sobre o sistema e descubra os requisitos destes.
Algumas técnicas poderam ser utilizadas:
• Utilização de workshops acompanhados de brainstorms;
• Entrevistas fundamentadas no preenchimento de questionários;
• Observação do ambiente;
• Revisão da documentação técnica;
• Análise de Marketing;
• Simulações, modelagem e prototipagem;
• Processos e sistemas de benchmarking;
• Técnicas de análise organizacional (Análise SWOT – Strengh Weaknesses, Opportunities, Threats, análise de portfólio)

Fazer um checklist:
• Missão: Como o sistema irá cumprir sua missão?
• Como o sistema será capaz de contribuir para as operações organizacionais?
• Cenário operacional: Definições que envolvem o alcance do produto e com quais plataformas e outros produtos o mesmo terá interações.
• Ambiente operacional e contexto de uso: Definições que envolvam restrições de uso ou contexto ao sistema, como horários de funcionamento ou nível crítico de operação.
• Inserção operacional: Caso o produto seja uma continuação, ou parte dos produtos de um escopo maior, tal definição demonstra em que ponto do produto do cliente será inserido.
• Performance: Parâmetros essenciais na garantia do cumprimento da missão do sistema.
• Efetividade: Definição de quão efetiva deveria ser o sistema atuando em sua missão, assim como quais seriam as maneiras de medir sua eficiência.
• Ciclo de vida operacional: Qual será o tempo de vida do sistema?
• Porquanto tempo ele deve ser estável e, principalmente, ainda cumprir sua missão.
• Características do usuário e operador: Definição de quem são os usuários do sistema, qual serão seus papéis, nível de habilidade ou carga de trabalho.
• Restrições que envolvem o sistema e sua construção, cenários de execução e aplicações de casos de uso. Diversos fatores podem gerar restrições ao Sistema, tais como consequências de decisões e acordos, contratuais ou não, já existentes nos requisitos do sistema, organizações externas, sistemas externos ou legados, atividades de outra fase do ciclo do sistema, restrições orçamentárias e estratégicas de aplicação e vendas.

• ANALISAR
Entenda os requisitos, suas sobrecargas, e seus conflitos.
Necessidade de checar requisitos, checar completeza e checando viabiliadde.
Como resultado da análise obtem-se a identificação dos requisitos e os classifica em: funcionais, não funcionais e regra de negócio agrupados por modulo dentro de um Escopo.

Técnica de análise usando o modelo Requisitos x Canvas :

Requisitos	Perguntas à serem respondidas	Bloco no modelo
Funcionais	Que tarefas serão executadas pelo sistema? A	Atividades chave
Não-funcionais	Qual o sistema operacional? Quais navegadores? Nec	Necessidades
De performance	Qual a exigência de performance para o	Atividades chave
De usabilidade	O produto é intuitivo? A usabilidade é válida? D	O produto é intuitivo? A usabilidade é válida? D
De interface \ Cenário operacional	Com que outros sistemas o produto irá interagir? Como é a interface com o usuário? O que ele pode fazer?	Consumidor final/ Necessidades
De processos	Quais leis ou regras de negócio são aplicadas ao produto?	Necessidades
De qualidade	Como será a manutenção do produto? Haverá portabilidade? Qual o nível de segurança do sistema e dos usuários?	Necessidades/ Atividades chave
De fatores humanos	Quais são as mensuráveis de satisfação?	Consumidor final / Diferencial
Objetivos	Qual o problema a ser resolvido? Qual o objetivo do sistema?	Objetivo / Diferencial
Missão	Como o sistema resolve o problema?	Objetivo / Atividades / Recursos chave
Ambiente operacional	Em qual ponto do flow do consumidor o produto será inserido?	Necessidades
Efetividade	Quais são as mensuráveis de efetividade do sistema?	Necessidades / Receita
Ciclo de vida	Qual o tempo esperado de duração do sistema e de utilização de suas funções?	Receita / Necessidades / Objetivo
Características de usuário e operador	Quais são os usuários internos e externos do sistema? Qual seu nível de segurança?	Consumidor final / Necessidades

Comentários:
Uma funcionalidade pode realizar um ou mais Requisitos Funcionais.
Requisito funcional não é uma funcionalidade, é uma necessidade funcional (uma função) que o software deve atender.
Uma funcionalidade será executada por um ator (um ator sistêmico [pelo próprio sistema] ou um ator humano [usuário final]). É onde Requisitos Funcionais serão viabilizados.
Usar Caso de Uso, Cenários, Pontos vistas, padrões
Os requisitos inversos estarão como itens do Escopo negativo ou seja os itens que não estarão incluidos.

Model Canvas
Descobrir como estruturar todas as atividades necessárias para gerar valor aos seus clientes e lucro para o seu negócio.
Mapear os requisitos no modelo Canvas

• VALIDAR
Entendabilidade, redundância, completeza e ambiguidade.
Volte para os interessados no sistema e cheque se os requisitos são o que eles realmente tem necessidade.

• NEGOCIAR
Discussão, priorização e acordo.
priority = value % / (cost % + risk %)

• DOCUMENTAR


Um Caso de Uso é uma especificação do comportamento de uma funcionalidade. Nele se tem detalhes sobre como a funcionalidade “funcionará”, com restrições, premissas e diretrizes pertinentes à funcionalidade.
Regra de negócio refere-se a premissas ou restrições de negócio que o sistema deverá atender, regras que poderão ou não estar associadas a um requisito funcional, mas que sempre serão realizadas por uma ou mais funcionalidades do sistema. Na visão da modelagem conceitual, Regras de negócio são o “como”, requisitos funcionais são o “o que”.
Requisitos Não Funcionais são premissas ou restrições que o sistema deverá atender, mas que não são realizados através de funcionalidades. Podem ou não estar associados a Requisitos Funcionais, mas não tem, necessariamente, relação com o negócio, na visão do usuário.

• GERENCIAR REQUISITOS

Controle as mudanças de requisitos que inevitavelmente surgirão.
No gerenciamento de mudanças o impacto deverá ser avaliado pelo planejamento da mudança.A maior dificuldade esta em estabelecer em que contexto (escopo) em que estas atividades serão executadas. Este escopo faz parte dos requisitos gerenciais ou do negócio e deverá ser estabelecido pelo patrocinador

Funcional	. Matriz crud (consulta, leitura, atualização, exclusão )
Não Funcional Propriedades do sistema e/ou restrições sobre serviços ou funções por ele providas	Produto	Usabilidade
		Comportamento	. Esforço . Frequência
		Eficiência	. Performace . Espaço
		Portabilidade
		Recuperação
	Organização	Implementação
		Padrões
		Entregas
	Externo	Domínio	Éticos
		Usuário	Legais	. Segurança . Privacidade
		Sistema	Interoperabilidade

EXEMPLOS DE REQUISITOS:

DO NEGÓCIO:
Construir um quiosque que os passageiros podem usar para check-in de seus voos no aeroporto.

REGRA DE NEGOCIO:
• RN-1 Janelas de tempo de entrega são de 15 minutos, começando em cada quarto de hora. (Fato, dinamico,gerente)
• RN-2 O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.(Computação, dinamico, politica de ..)
• RN-3 Um professor só pode lecionar disciplinas para as quais esteja habilitado.(Limite, dinamico, gerente)
• RN-4 Um cliente do banco não pode sacar mais de R$ 500,00 por dia de sua conta.
• RN-5 Para alugar um carro, o proponente deve estar com a carteira de motorista válida.
• RN-6 O número máximo de alunos por turma é igual a 30.
• RN-7 Particularidades que o sistema possa executar e o mais importante

DO SISTEMA (OU PRODUTO):
• S-1 Senhas devem ter, no mínimo, seis caracteres, entre números, letras e símbolos.

DO USUÁRIO:
• U-1 - Abertura de conta
• U-2 - Consulta de saldo
• U-3 - Fechamento de conta
• U-4 - Adtivo de contrato

FUNCIONAIS:
• RF-1 – Incluir cliente pessoa física
• RF-2 – Alterar cliente pessoa física
• RF-3 – Consultar cliente pessoa física
• RF-4 – Excluir cliente pessoa física
• RF-5 – Incluir cliente pessoa jurídica

NÃO FUNCIONAIS:
• RNF-1 Tempo limite para processamento de todos os lotes de fatura na rotina diária.

INTERFACE EXTERNA
USUÁRIO
• UI-1 As páginas da Web devem permitir completa navegação e seleção de item de alimentos usando o teclado sozinho, além de usar combinações de mouse e teclado.

SOFTWARE
• SI-1 Sistema de pagamento
• SI-1.1 sistema comunicam-se com o sistema de folha de pagamento, através de uma interface de programação para as seguintes operações:
Para enviar uma solicitação de pagamento para uma refeição adquirida.
• SI-2 Sistema de inventário
• SI-2.1O sistema transmitirá as quantidades de alimentos itens encomendados para o sistema de inventário através de uma interface de programação

COMUNICAÇÃO
• CI-1 O sistema deve enviar uma e-mail ou mensagem de texto (baseada em configurações de conta de usuário) ao ator.. para comunicar qualquer problema com uma ordem de refeição ou entrega.

ATRIBUTOS DE QUALIDADE
USABILIDADE
• USO-1: O sistema deve permitir recuperar a refeição anterior ordenada com uma interação única.
PERFORMANCE
• PER-1: O sistema deve acomodar um total de 400 usuários e um máximo de 100 usuários simultâneos durante a janela de tempo de uso máximo de 09:00 a 10:00 hora local, com uma duração de sessão média estimada de 8 minutos.
SEGURANÇA
• SEC-1: Toda a rede transacções que envolvam informações financeiras ou informações pessoalmente capazes de identicar devem ser criptografadas por BR-33.
PRIVACIDADE
• SAF-1: O usuário deve ser capaz de ver uma lista de todos os ingredientes em quaisquer itens de menu, com ingredientes destacadas que são conhecidos por causar reações alérgicas em mais de 0,5 por cento da população norte-americana.
DISPONIBILIDADE
• AVL-1: O sistema deve dispor, pelo menos 98% do tempo entre 05:00 e meia-noite hora de local e pelo menos 90% do tempo entre a meia-noite e a hora local de 05:00, excluindo manutenção programada;
ROBUSTEZ
• ROB-1: Se a conexão entre o usuário e o sitema é quebrado antes de uma nova ordem, sendo também confirmado ou encerrado, o sitema deve permitir ao usuário recuperar uma ordem incompleta e continuar a trabalhar nele.

Parceiros Chave	Atividade Chave Que tarefas serão executadas pelos sistema? Qual a exigência de performance para o cumprimento da missão? Como o sistema resolve o problema? Como o sistema resolve o problema? Como será a manutenção do produto? Haverá portabilidade? Qual o nível de segurança do sistema e dos usuários?	Objetivos Qual o problema a ser resolvido? Qual o objetivo do sistema? Como o sistema resolve o problema? Qual o tempo esperado de duração do sistema e de utilização de suas funções? Como o sistema resolve o problema? O produto é intuitivo? A usabilidade é válida? Quais são as mensuráveis de efetividade do sistema?	Diferencial O produto é intuitivo? A usabilidade é válida? Quais são as mensuráveis de satisfação? Qual o problema a ser resolvido? Qual o objetivo do sistema?	Consumidor Final Com que outros sistemas o produto irá interagir? Como é a interface com o usuário? O que ele pode fazer? Quais são as mensuráveis de satisfação?O que ele pode fazer? Quais são os usuários internos e externos do sistema? Qual seu nível de segurança? Como o sistema resolve o problema?
	Recursos Chave Como o sistema resolve o problema?		Canais
Necessidades Quais leis ou regras de negócio são aplicadas ao produto? Como é a interface com o usuário? Com que outros sistemas o produto irá interagir? Como é a interface com o usuário? O que ele pode fazer? Como será a manutenção do produto? Haverá portabilidade? Qual o nível de segurança do sistema e dos usuários? Qual o sistema operacional? Quais navegadores? Quais são os usuários internos e externos do sistema? Qual seu nível de segurança? Em qual ponto do flow do consumidor o produto será inserido? Quais são as mensuráveis de efetividade do sistema? Quais são as mensuráveis de efetividade do sistema?			Receita Qual o tempo esperado de duração do sistema e de utilização de suas funções? Quais são as mensuráveis de efetividade do sistema?

Velocidade:
• Transações processadas por segundo.
• Tempo de resposta ao usuário

Tamanho:
• Tamanho em bytes do softeare final
• Memória
Facilidade de uso:
• Tempo de treinaemto necessário
• Número de telas de ajuda
Confiabilidade:
• Tempo médio para falhar
• Porcentual de eventos que causam falhas
Portabilidade:
• Número de ambientes operacionais nos quais o sistema pode rodar

RASTREAMENTO (Referencias cruzadas entre):
• Requisito do usuario x requisito funcional(elemento de desgn/codigo/teste).
• Requisito funcional x Caso de uso

FONTES DE RASTREAMENTO:
• Rquisitos de negocio
• Regra de Negocio
• Requisitos do sistema
• Requisitos do usuário
• Requisitos funcionais

• Projetos ágeis:
As funcionalidades são as mesmas. Porém projetos ágeis lidam com exigências de forma diferente em vários aspectos, particularmente no que se refere o tempo e a profundidade das atividades de requisitos e a extensão da documentação escrita de requisitos.
• Projetos de melhoria e substituição
• Projetos de solução de pacote:
• Projetos terceirizados:
• Projetos de automação de processos de negócios :
• Projetos de análise de negócios:
• Projetos de sistemas de tempo real embarcado e outros:

• VISÃO e ESCOPO:
1. Requistos de negocios.
1.1 Background
1.2 Oportunidade de negócio
2.Escopo e limitações
2.1 Pricipais caracteristicas

• ESPECIFICAÇÃO DE REQUISITOS SOFTWARE
1. Introdução
1.1 Proposta
2. Descrição geral
2.1 Pespectiva Produto
3. Caracteristicas do sistema
3.1
3.1.1
3.2
4.Requisitos de dados
4.1 Mer
4.2 DD
4.3 Relatórios/Telas
4.4 Integração de dados
5. Requisitos interfaces externas
5.1 Usuários
5.2 Interface de software
5.2.1 Sistama X
5.2.2 Interface de hardware
5.2.3 Interface de comunicação
6. Atrutos de qualidade
6.1 Usabilidade

Apendice
Modelo de analise (diagrama transição)
Regras de negocio

REFERÊNCIA EXTERNA
Até o momento Requisitos de software. em 24/09/21

Frases de requisitos.

Modelo para especificação de requisitos.

Uso do algoritmo PageRank para priorizar requisitos.

Livro Software_Requirements_3rd_Edition .