Engenharia de requisitos e processos de software

Prévia do material em texto

3ºSemestre
Engenharia de requisitos e processos de software
Professora Gisele Pereira de Oliveira
· Fundamentos de Engenharia de Requisitos
A engenharia de requisitos concentra-se em descobrir o que deve ser desenvolvido. Ela é o processo de adequação dos projetos a um conjunto de requisitos básicos de software. Consiste em um conjunto de atividades cujo propósito é identificar e comunicar a finalidade de um sistema de software e os contextos em que serão utilizados.
Quando mencionamos metas e objetivos, temos por trás de tudo isso o que chamamos de propósito do software!
O design de sistemas intensivos de software pertence a uma classe de problemas conhecidos como heréticos – em referência à dificuldade de se definir bem a qual domínio pertence o problema em questão: atualmente, há muitas áreas “cinzentas” em software, e outras tantas estão contidas nas pessoas e formas de clientes ou de usuários.
· As 4 fases do processo da engenharia de requisitos
1. Estudo de viabilidade: é feita uma estimativa acerca da possibilidade de se satisfazerem as necessidades do usuário identificado e usando as tecnologias atuais de hardware e software. Verifica se o sistema será rentável e se pode ser desenvolvido considerando as restrições orçamentárias;
2. Elicitação e análise de requisitos: observação e análise dos sistemas existentes, discussão com os potenciais usuários e compradores, análise das tarefas etc. Pode compreender o desenvolvimento de um protótipo;
3. Especificação dos requisitos: traduzir as informações obtidas na fase de análise em um documento que defina um conjunto de requisitos;
4. A validação dos requisitos: verifica os requisitos quanto ao realismo, à consistência e completude. Podem ser descobertos erros e o documento deve ser modificado para a correção desses problemas. A análise de requisitos é contínua, pois novos requisitos podem emergir durante o processo.
· Requisitos de sistema
os requisitos do sistema são todos os requisitos, no nível do sistema, que descrevem as funções que deve, como um todo, cumprir para satisfazer às necessidades e aos requisitos das partes interessadas. É expresso por uma combinação apropriada de declarações textuais, visualizações e requisitos não funcionais. Os requisitos do sistema são importantes porque formam a base da arquitetura do sistema.
· Análise de problemas
· Abstração envolve ignorar detalhes para que se possa ter uma visão geral e abrangente.
· Decomposição envolve “quebrar” um conjunto de fenômenos em partes menores para que possamos analisá-las separadamente umas das outras. Tais processos de decomposição nunca são perfeitos devido ao acoplamento entre as partes, mas uma decomposição – o mesmo que dizer análise – bem-feita ainda nos oferece insights sobre como as coisas funcionam;
· • Projeção significa adotar uma visão ou perspectiva específica que pertença a outrem, tentando imaginar e descrever – “projetar” – tudo aquilo que seria relevante para este ou aquele indivíduo, este ou aquele grupo de pessoas.
Requisitos = problema
os requisitos são entendidos e descritos como uma lista de recursos ou funções, propriedades, restrições e tantas outras coisas exigidas pelo cliente. só existem porque há alguém que quer alguma coisa, Um requisito de software é uma descrição dos principais recursos de um produto de software, o seu fluxo de informações, comportamento e atributos.
· Componentes
• Funcional: serve para identificar as atividades do sistema, as ações; 
• Comportamental: demonstra a sequência e se há sobreposição de funções do sistema em uma hierarquia de atividades de controle; tal sequenciamento serve para perceber e controlar as funções do sistema em diversos patamares – são os controles; 
• Não comportamental: toda a parte de engenharia de pessoas e garantia de qualidade; ações e atributos que influenciam na excelência do resultado final
Termo é uma especificação de requisitos, uma descrição do sistema e um plano de garantia da qualidade, bem como dos atributos que precisam ser seguidos pelo time de desenvolvimento.
· Etapas para a identificação de variáveis 
1. Concepção: aqui são definidos o escopo e a natureza do sistema; 2. Elicitação: começa-se a reunir e organizar os requisitos para o software; 3. Elaboração: refinar os requisitos que foram reunidos e minimamente organizados; 4. Negociação: são determinadas as prioridades de cada, anotados os requisitos essenciais e – o que é mais importante – solucionados os conflitos entre os diferentes requisitos; 5. Especificação: agora, os requisitos são reunidos em um único produto, sendo o resultado da engenharia de requisitos; 6. Validação: estabelece-se a qualidade dos requisitos: se são inequívocos, consistentes, completos etc.; 7. Gerenciamento: por fim, são gerenciadas as mudanças que os requisitos devem sofrer ao longo do tempo de vida do projeto.
· Análise de Problemas 
· Classificação de requisitos
Requisitos de negócios: incluem declarações de alto nível de objetivos e necessidades; 
Requisitos das partes interessadas: são as necessidades de determinados grupos que formam as partes interessadas discretas. É necessário especificá-los para definir o que cada parte interessada espera em termos de solução e resultado final; 
Requisitos da solução: as propriedades que um produto deve apresentar para atender da melhor maneira possível às necessidades das partes interessadas e do próprio negócio como um todo: 
Requisitos não funcionais: são as características gerais de um sistema. São também conhecidos como atributos de qualidade; 
Requisitos funcionais descrevem como um produto deve se comportar, os seus recursos e as suas funções. 
Requisitos de transição: é um conjunto adicional de requisitos empregados em momentos de transição entre operações ou sistemas, definindo o que é necessário, da parte de uma organização, para conduzir-se com êxito de seu estado atual para o estado desejado a partir do novo produto/software
Requisitos funcionais Descrevem qualitativamente as funções ou tarefas do sistema a serem executadas em operação. 
Requisitos de desempenho Definem quantitativamente a extensão, ou quão bem e sob quais condições uma função ou tarefa deve ser executada 
Requisitos de interface Definem de que modo o sistema se faz necessário para interagir ou trocar material, energia ou informações, com sistemas externos – interface externa –, ou como os elementos do sistema dentro do sistema, incluindo elementos humanos, interagem uns com os outros – interface interna. 
Requisitos operacionais Definem as condições operacionais ou propriedades necessárias para o sistema operar ou existir. 
Requisitos de modos e/ou estados Definem os vários modos operacionais do sistema e os eventos que conduzem a transições de modos. 
Restrições físicas Definem as restrições de peso, volume e dimensão aplicáveis aos elementos do sistema. 
Restrições de design Definem os limites das opções disponíveis para o projetista de uma solução, impondo limites imutáveis.
Condições ambientais Definem as condições ambientais a serem encontradas pelo sistema em seus diferentes modos operacionais. 
Requisitos logísticos Definem as condições logísticas necessárias para a utilização contínua do sistema. 
Políticas e regulamentos Definem políticas organizacionais relevantes ou aplicáveis, ou requisitos regulatórios que possam afetar a operação ou o desempenho do sistema.
Restrições de custo e cronograma Definem, por exemplo, o custo de um único exemplar do sistema, a data de entrega esperada do primeiro exemplar etc.
· Requisitos funcionais
Os requisitos funcionais são as operações desejadas e esperadas de um programa ou sistema, conforme definido no desenvolvimento de software e na engenharia de sistemas.
os requisitos funcionais podem ser identificados como:• Evidentes: funções executadas com o conhecimento do usuário. Esses requisitos geralmente correspondem à troca de informações entre o usuário e sistema, tais como consultas e entradas de dados que fluem pela interface do sistema; 
• Ocultos: funções desempenhadas pelo sistema sem o conhecimento explícito do usuário. Geralmente estas funções são operações matemáticas e atualizações de dados, realizadas ocultamente pelo sistema, sem conhecimento explícito do usuário – mas como consequência de outras funções desempenhadas pelo usuário.
os requisitos funcionais podem ser visuais como:
• Documento de especificação de requisitos de software: contém descrições de funções e recursos que o produto deve fornecer. 
• Casos de uso: trata-se de um artefato comportamental da UML – Unified Modeling Language – que descreve a interação entre o sistema e os usuários, levando à obtenção de metas/objetivos específicos; 
• Histórias de usuários: é uma descrição documentada de um recurso de software visto da perspectiva do usuário final. 
• Estrutura de decomposição do trabalho, ou EAP – Estrutura Analítica do Projeto –, ou seja, uma decomposição funcional. É um documento visual que ilustra de que maneira os processos complexos se dividem em suas componentes mais simples. EAP é uma abordagem eficaz e que permite uma análise independente de cada parte, além de ajudar a capturar a imagem completa do projeto; 
• Protótipos: em se tratando de software, podemos entender este quesito de forma abrangente, para diferentes tipos de entregas em estágio inicial, criadas para mostrar como os requisitos devem ser implementados. Os protótipos ajudam a dirimir as lacunas de visão e permitem que as partes interessadas e equipes clarifiquem áreas complicadas de produtos em vias de desenvolvimento. 
• Modelos e diagramas: quaisquer outros artefatos gráficos que possam ser úteis para a visualização da proposta de solução.
· Requisitos não funcionais
Os requisitos não funcionais descrevem como um sistema deve se comportar e estabelece restrições para a sua funcionalidade
para requisitos não funcionais associados a produtos há os seguintes elementos:
Usabilidade: é um dos atributos de qualidade ou requisitos não funcionais de qualquer sistema interativo
Manutenibilidade: é geralmente empregado quando nos referimos às modificações feitas após o sistema de software ter sido disponibilizado para uso.
Confiabilidade: é a probabilidade de o software não causar uma falha num sistema durante um determinado período de tempo sob condições especificadas.
Disponibilidade: é uma medida de quão disponível o sistema estaria para uso, isto é, quão disponível o sistema estaria para efetuar um serviço solicitado por algum usuário
Taxa de ocorrência de falha: é uma medida da frequência na qual o sistema falha em prover um serviço como esperado pelo usuário
Probabilidade de falha durante fase operacional: é uma medida da probabilidade que o sistema irá comportar-se de maneira inesperada quando em operação
Tempo médio até a ocorrência de falha, ou Mean Time to Failure (MTTF): é uma medida do tempo entre falhas observadas.
Desempenho: é um atributo de qualidade importante para sistemas de software.
Requisitos de resposta: especificam o tempo de resposta de um sistema de software aceitável para usuários.
Requisitos de processamento (throughput): estes requisitos especificam a quantidade de dados que deveria ser processada num determinado período de tempo
Requisitos de temporização: este tipo de requisito especifica quão rapidamente o sistema deveria coletar dados de entrada de sensores antes que outras leituras de dados de entrada, feitas posteriormente, sobrescrevam os dados anteriores;
Requisitos de espaço: em alguns casos, os requisitos de espaço podem ser considerados. Aqui, podemos nos referir à memória principal ou secundária.
Portabilidade: pode ser definida como a facilidade na qual o software pode ser transferido de um sistema computacional ou ambiente para outro.
Reusabilidade: uma característica das engenharias é fazer uso de projetos existentes a fim de reutilizar componentes já desenvolvidos, objetivando minimizar o esforço em novos projetos.
Segurança: em um sistema de software, este requisito não funcional caracteriza a segurança de que acessos não autorizados ao sistema e dados associados não serão permitidos.
· Requisitos de produtos
Usabilidade
RNF01 O sistema deverá ser operável por usuários sem a necessidade de treinamento prévio. 
RNF02 O sistema deverá fazer uso de design responsivo na implementação de suas interfaces gráficas, de modo a se comportar adequadamente em navegadores acessados via computador, smartphone e tablet. 
RNF03 O sistema deverá ser disponibilizado em português.
Confiabilidade RNF04 Apenas usuários-administradores devem possuir acesso à camada de administração do sistema. RNF05 A senha do usuário será gravada/trafegada utilizando-se o algoritmo PBKDF2 com uma hash SHA256. RNF06 As únicas informações que o sistema poderá exibir, no tocante a cartões de crédito salvos previamente na conta do usuário, são os últimos 4 dígitos, a data de validade e operadora.
Portabilidade RNF07 O sistema deverá funcionar nos navegadores Google Chrome, Mozilla Firefox e Safari.
· Requisitos organizacionais
Entrega
RNF08 O desenvolvimento do sistema deverá ser feito de maneira incremental com os PI seguindo a fundamentação do SAFe. 
RNF09 Os entregáveis relacionados à arquitetura do sistema e ao nível gerencial de equipe deverão ser elaborados de acordo com as datas estimadas no Kanban do projeto. 
RNF10 A priorização das features para cada entrega de incremento do produto deverá ser feita com a estimativa e os critérios de aceitação recomendados pelo SAFe.
Implementação 
RNF11 O sistema será desenvolvido utilizando a linguagem Python sob o framework Django. 
RNF12 Todas as variáveis de entrada terão “vazio”, ou equivalentes, como valor default.
Padrões
RNF13 O sistema será desenvolvido utilizando o paradigma de programação orientado a objetos.
· Requisitos externos 
Éticos
RNF14 O sistema deverá se comunicar com o banco de dados SQLite 3. 
RNF15 O sistema não apresentará aos usuários quaisquer dados de caráter privativo, tais como informações pessoais de outros usuários.
Legais
RNF16 O sistema deverá atender às normas legais no que se refere à comercialização on-line de produtos.
*É importante termos em mente que os requisitos geram um documento que deve ser mantido e atualizado, pois, independentemente do paradigma de engenharia que utilizemos
· Técnicas e Ferramentas da Engenharia de Requisitos
as fontes de requisitos podem ser de três tipos: 
• Stakeholders: são a maior fonte de requisitos. Pessoas ou organizações que têm influência (direta ou indireta) nos requisitos, como usuários, clientes, desenvolvedores; 
• Documentos: norma e legislações que podem delimitar o campo de ação do projeto ou documentos específicos da organização .
• Sistemas em operação: sistemas anteriores ou atualmente em uso podem ensinar muito sobre o processo, assim como sistemas similares de concorrentes.
· Atividades e Técnicas da Engenharia de Requisistos
Elicitação, essa atividade também é conhecida como captura ou levantamento de requisitos. É o processo de gerar uma lista de requisitos funcionais, de sistema, técnicos etc. a partir da necessidade das várias partes interessadas 
há uma série de técnicas úteis que você deve dominar e saber empregar conforme a demanda apresentada: 
• Entrevistas
 • Questionários
• Observação do usuário ou etnografia
• Workshops
• Brainstorming
• Role-playing games (RPG) (jogo de papéis e regras): Em situações em que os requisitos dependem fortemente de diferentes tipos de usuários.
• Casos de uso e cenários: Trata-se de desenvolver diferentes diagramas de casos de uso e cenários que possam ser usados para validara funcionalidade em diferentes situações; 
• Prototipagem: reunir vários protótipos diferentes mostrando como serão ou, ao menos, poderiam ser as telas, as entradas de dados, a dinâmica funcional ou a usabilidade do futuro sistema, para ver se os usuários gostam de tudo, ou de que partes eles gostam. Assim, você pode sintetizar as diferentes partes que eles gostaram dos protótipos e puxar os requisitos a partir deles. 
· Requisitos como Histórias do Usuário
• escritas usando linguagem que possa ser facilmente entendida pelo cliente e pelo usuário final; 
• curtas o suficiente para que sejam compostas por poucas frases e possam caber em um pequeno cartão.
• focadas o suficiente para descreverem pequenos incrementos de funcionalidade, que podem ser concluídos em vários dias ou semanas. 
• permitirem ser alteradas com frequência com base em discussões com o cliente, à medida que a funcionalidade se torna melhor compreendida pelo time de desenvolvimento.
· Gerenciamento
O gerenciamento de requisitos é o processo de capturar, avaliar e justificar os desejos e as necessidades das partes interessadas.
• unicamente identificável: aborda apenas um requisito central; 
• atual: atualizado e relevante para as necessidades do negócio e do sistema; 
• consistente: não contradiz nenhum outro requisito capturado/elicitado; 
• compreensível: concisamente declarado e não aberto a diferentes interpretações; 
• verificável: a conformidade pode ser verificada através de inspeção, demonstração, teste ou análise; 
• rastreável: o requisito pode ser rastreado a partir da necessidade originária, através do plano, até o que é entregue; 
• priorizada: sua importância relativa é entendida.
Um processo simples para gerenciamento de requisitos possui quatro etapas: 
• coletar requisitos das partes interessadas; 
• analisar os requisitos para procurar sobreposições, lacunas e conflitos; 
• justificar os requisitos para distinguir desejos de necessidades; 
• elaborar a linha de base dos requisitos com as necessidades antes de iniciar o processo de desenvolvimento de soluções.
· Documento
O Documento de Requisitos do Sistema (DRS) define os requisitos funcionais e de desempenho no nível do sistema para uma solução de software. um documento de especificação descreve o comportamento e as diferentes funcionalidades de um aplicativo ou software em um ambiente específico.
· Rastreabilidade de Requisitos
Rastreabilidade de requisitos refere-se à capacidade de descrever e seguir a vida de um requisito, tanto para frente como para trás, portanto, desde suas origens, desenvolvimento e especificação, até sua implantação e usos subsequentes, e por todos os períodos de refinamento contínuo que ocorrem durante o ciclo de vida de desenvolvimento de qualquer software, assim como as interações que ocorrem em qualquer uma dessas fases.
Uma boa rastreabilidade de requisitos nos oferece os seguintes benefícios:
• Gerenciar o escopo da solução do software
• Avaliar de maneira ágil potenciais mudanças
• Reduz o risco do projeto
• Promoção de consistência entre os requisitos
• Monitorar e controlar durante todo o ciclo de vida do requisito:
· Matriz de Rastreabilidade de Requisitos(RTM)	
é usada para verificar se todos os requisitos declarados e derivados estão associados aos elementos de sistema, tais como estrutura, componentes, módulos e outras entregas do projeto. Além disso, também usam os a matriz para verificar e documentar a fonte original dos requisitos, de modo que, se surgirem dúvidas do cliente ou do time de sistemas sobre o motivo pelo qual certos recursos foram incluídos/modificados, há uma trilha abrangente e precisa.
Artefatos: requisitos, design, desenvolvimento, teste e manutenção
· diagrama de caso de uso
A modelagem de casos de uso é uma ferramenta útil para a elicitação de requisitos de software e, sem dúvida alguma, fornece uma representação gráfica dos requisitos do sistema de software, colocando-os na forma visual para entendimento melhor por parte dos analistas de sistemas, analistas de negócios, bem como dos engenheiros de solução
· Relacionamento de Comunicação ou Associação: representa a interação entre um ator e um caso de uso por meio de mensagens. É representado por uma linha sólida
· Relacionamento de Inclusão: utilizado quando um comportamento se repete em mais de um caso de uso. 
· Relacionamento de Extensão: utilizado quando se deseja modelar um relacionamento alternativo.
· Relacionamento de Herança: é um relacionamento entre atores, utilizado quando queremos representar uma especialização/generalização
· Ferramentas e Exemplos de Engenharia de Requisitos
Os requisitos ágeis, ou seja, as histórias dos usuários nas metodologias ágeis em geral e, notadamente, no processo XP, é a unidade fundamental das atividades dos times de desenvolvimento.
Há situações importantes para as partes interessadas ou a área de negócios escreverem histórias de usuários:
• “As partes interessadas escrevem histórias de usuários: Um conceito importante é que os envolvidos no projeto escrevem as histórias do usuário, não os desenvolvedores. 
• Use a ferramenta mais simples: As histórias de usuários geralmente são escritas em fichas de índice. Os cartões de índice são muito fáceis de trabalhar e, portanto, são uma técnica de modelagem inclusiva; ]
• Lembre-se dos requisitos não funcionais: As histórias podem ser usadas para descrever uma ampla variedade de tipos de requisitos; 
• Indique o tamanho estimado: Inclua uma estimativa para o esforço de implementar a história do usuário.
• Indique a prioridade: Os requisitos, incluindo os defeitos identificados como parte de suas atividades de testes paralelos independentes ou por suas operações e esforços de suporte, são priorizados pelos envolvidos no projeto e adicionado à pilha no local apropriado
• Inclua um identificador exclusivo. O cartão também deverá possuir um identificador exclusivo para a história do usuário. A
ainda, ter histórias de usuários muito grandes que chamamos de epopeias e grupos de histórias que chamamos de temas.
• Epopeias: são grandes histórias de usuário, normalmente, aquelas que são grandes demais para serem implementadas em uma única iteração e, portanto, precisam ser desagregadas em histórias de usuário menores em algum momento. 
• Tema: é uma coleção de histórias de usuários relacionadas. P
As histórias de usuários é o alfa e o ômega dos requisitos ágeis, e os desenvolvedores costumam escrever testes baseados nelas. As histórias são noções básicas perfeitas para testes, porque são breves e caracterizam os recursos mais importantes do produto final. Os testes são geralmente escritos antes de começar a criação do código do produto. Essa abordagem do desenvolvimento visa a economizar tempo e a atender aos termos do projeto.
· Planning game
O jogo de Planejamento permite-nos encontrar rapidamente um plano aproximado e depois refiná-lo à medida que o projeto avança. Poderíamos dizer que o Jogo do Planejamento é uma reunião, é um ponto vital de interação entre cliente e desenvolvedor. A reunião acontece com a equipe trabalhando em uma pilha de cartões de índice que contêm as histórias do usuário. Os requisitos do usuário são escritos em fichas de índice e são tratados durante o Jogo de Planejamento. Cartões de índice são uma ferramenta altamente eficaz. A utilidade simples dos cartões conecta clientes e programadores para atingir seu objetivo comum. O uso de cartões de índice não é obrigatório no Jogo de Planejamento, e você pode descobrir que outras ferramentas, como aplicativos da Web, podem ser eficazes.
Você pode realizar as estimativas em cima desses cartões de histórias utilizando o Planning Poker, muito útil para as equipes ágeis.
O planejamento aborda duas questões-chave no desenvolvimento de software: prever o que será realizado até a data de vencimento e determinar o que fazer a seguir.
• O Planejamento de Liberação é uma prática em que o Cliente apresenta os recursos desejados aos programadores e os programadores estimam sua dificuldade.Com as estimativas de custos em mãos e com o conhecimento da importância dos recursos, o Cliente estabelece um plano para o projeto
• Planejamento de Iteração é a prática pela qual a equipe recebe orientação a cada duas semanas. As equipes de XP criam softwares em “iterações” de duas semanas, entregando softwares úteis ao final de cada iteração. Durante o planejamento de iteração, o cliente apresenta os recursos desejados para as próximas duas semanas
O jogo de planejamento XP tem dois participantes no processo de planejamento:
• Desenvolvedores: são as pessoas que irão realizar a implementação do que foi definido no cartão; 
• Negócio (cliente): são as pessoas que vão dizer aos desenvolvedores o que eles querem que seja implementado.
· Fases do jogo
1.Exploração: Esta é uma maneira de tentar descobrir coisas novas que o sistema é capaz de fazer. O propósito da fase de exploração é dar aos jogadores uma apreciação do que todo o sistema deve eventualmente fazer. Exploração tem três movimentos:Escreva uma história, Estimar uma história.
 2. Compromisso: Será tomada a decisão quanto aos passos a serem seguidos na realização dos requisitos. O propósito da fase de compromisso é que as empresas escolham o escopo e a data da próxima versão e que o desenvolvimento se comprometa com a entrega. Possui 4 movimentos a saber: • Classificar por Valor, Classificar por risco. Aquelas que não podem estimar, Definir velocidade, Escolher escopo
3. Steer (direção): Esta é a orientação dos desenvolvedores para o requisito do projeto. O propósito da fase de direção é atualização o plano com base no que é aprendido pelo desenvolvimento e pelos negócios. A fase de direção tem quatro movimentos: Iteração, Recuperação, Nova história, Reestimativa
O jogo de planejamento de maneira sumária se resume a:
•Relacionar os itens de trabalho que talvez precisem ser feitos 
• Estimar os itens; 
• Definir um orçamento para o ciclo de planejamento; 
• Concordar com o trabalho que precisa ser feito dentro do orçamento. Ao negociar, não altere as estimativas ou o orçamento.
· Principais Ferramentas para Gestão de Requisitos
Helix RM, jira, ReQtest, Visure requirements
· Método tradicional- cascata
No processo em cascata, todos os requisitos do sistema a serem desenvolvidos são capturados nessa fase de análise com base nas necessidades e nos problemas e estão em um documento chamado DRS ou Documento de Especificação de Requisitos.
O DRS, em sua construção, varia de empresa e de abordagem, portanto não existe um padrão, mas ao menos esses componentes são úteis em sua composição: 
• Introdução: é importante que a equipe de desenvolvimento e os proprietários do produto definam e escrevam essa parte juntos. No final, podemos incluir uma breve visão geral do documento para dar aos leitores uma ideia do que eles podem esperar do documento. Não esqueça de incluir os termos técnicos; 
• Descrição Geral: é importante explicar as diferentes funcionalidades do aplicativo. Nesta parte, as interfaces de hardware e de usuário são definidas. Em que dispositivo os usuários finais esperam acessar o aplicativo; 
• Requisitos específicos: os requisitos são detalhados para facilitar o design do produto e validar o software de acordo com os requisitos. Aqui, é importante descrever todas as entradas que o software manipula e todas as saídas para definir melhor a interação com outros sistemas e facilitar a integração. As funcionalidades enumeradas na seção anterior serão detalhadas aqui; 
• Referências: é importante incluir informações sobre o conteúdo, para que seja mais fácil encontrá-las quando necessário.
são consideradas más práticas num DRE (Documento de Requisitos do Sistema):
 Dicionário incompleto, Misturando conceitos, Inclua instruções de desenvolvimento, ação passiva, Documentação ambígua e incompleta
· Introdução ao Processo de Software
Um Processo de Software, ou se você preferir, Metodologia de Software é um conjunto de atividades inter-relacionadas que leva à produção/construção do software. Essas atividades podem levar ao desenvolvimento do software a partir do zero ou à modificação de um sistema existente/legado.
Qualquer Processo de Software deve incluir as quatro atividades a seguir: 
• Especificação de Software/Requisitos: define as principais funcionalidades do software e as restrições em torno delas; 
• Projeto e implementação: devemos projetar/planejar e criar/codificar o software; 
• Verificação e validação: o que será produzido a partir da codificação deve estar de acordo/conforme as especificações e, claro, atender às necessidades do cliente; 
• Evolução e manutenção: modificações realizadas para atender às mudanças nos requisitos do cliente e do Mercado.
· SDLC: Software Development Life Cicle (Ciclo de Vida do Desenvolvimento de Software)
o ciclo de vida de desenvolvimento de software SDLC é uma terminologia usada para explicar como o software é entregue a um cliente em uma série de etapas. Essas etapas levam o software da fase de ideação para a entrega. O software, como todos os produtos, começa como uma ideia. Seja um documento, diagrama ou software funcional, o artefato criado em uma etapa torna-se a entrada para a próxima etapa. A sequência de etapas usada por esses métodos é comumente chamada de Ciclo de Vida de Desenvolvimento de Software.
SDLC é o termo mais genérico utilizado para dizer, Métodos de Desenvolvimento de Software, sendo que o que varia de um para o outro são as etapas e a ordem com que são executadas, mas, em todos eles, há em comum o conceito de ciclo que pode ser único e crescente como no Cascata ou os que trabalham em ciclo menores, porém em grande número para a conclusão, como é o caso dos ágeis.
* as 7 fases do SDLC
· Modelos Tradicionais de Processo de Software
· Cascata/Cachoeira ou Waterfall
O Modelo em Cascata é uma abordagem sequencial, em que cada atividade fundamental de um Processo é representada como uma fase separada, organizada em ordem linear.
 No Modelo em Cascata, você deve planejar e agendar todas as atividades antes de começar a trabalhar nelas. Podemos chamar isso de um Processo orientado pelo Plano. 
O Processo orientado pelo Plano é aquele em que todas as atividades são planejadas primeiro e o progresso é medido em relação ao plano, enquanto no Processo Ágil, o Planejamento é incremental e é mais fácil alterar o Processo para refletir as mudanças de requisitos. 
As fases do modelo em cascata são: Requisitos, Design, Implementação, Teste e Manutenção.
· Big bang
Esse modelo não possui uma técnica específica para trabalhar no projeto de desenvolvimento de software. O projeto pode começar com apenas uma quantia básica de dinheiro e recursos, portanto, envolve princípios menos planejados e nenhum método formal é seguido. Podemos utilizá-lo em casos em que o cliente não tem certeza sobre seus desejos e os requisitos não são bem analisados ou definidos. Os requisitos são entendidos e implementados conforme começam a chegar. Trata- -se, porém, de um modelo que tende a ser muito mais arriscado do que outros modelos.
· Evolucionário/Evolutivo
O modelo evolutivo é uma combinação do Modelo Iterativo e Incremental do SDLC, e divide o ciclo de desenvolvimento em modelos em cascata menores e incrementais, nos quais os usuários podem obter Acesso em: ao produto no final de cada ciclo. O modelo evolutivo sugere a divisão do trabalho em partes menores, priorizando-as e as entregando ao cliente, uma a uma.
· Espiral 
O modelo em espiral é um dos mais importantes Modelos de Ciclo de Vida de Desenvolvimento de e foi o primeiro a oferecer suporte para tratamento de riscos. Um risco é qualquer situação adversa que possa afetar a conclusão bem-sucedida de um Projeto de Software. Esse modelo suporta o enfrentamento dos riscos, fornecendo o escopo para construir um protótipo em todas as fases do desenvolvimento do software. Em sua representação, lembra uma espiral com muitos loops. O número exato de voltas da espiral é desconhecido e pode variar de Projeto para Projeto
· Prototipagem
É umProcesso de Desenvolvimento de Sistemas no qual um protótipo, ao qual nos referimos como sendo uma aproximação antecipada de um sistema ou produto final, é construído, testado e então retrabalhado conforme necessário, até que um protótipo aceitável seja finalmente obtido a partir do qual o Sistema ou o produto completo agora pode ser desenvolvido. Esse modelo funciona melhor em cenários em que nem todos os requisitos do Projeto são conhecidos em detalhes com antecedência. É um Processo Iterativo de tentativa e erro, que ocorre entre os desenvolvedores e os usuários.
· Incremental
O Modelo Incremental é um Processo de Desenvolvimento de Software em que os requisitos são divididos em vários módulos independentes do Ciclo de Desenvolvimento de Software. É feito em etapas desde o projeto de análise, implementação, teste e verificação e manutenção. Para efeito didático, vamos chamar cada incremento de iteração e cada iteração passa obrigatoriamente pelas fases de análise de requisitos, design, codificação e teste, sendo que cada lançamento subsequente deve adicionar essa função à iteração anterior, portanto, é outra versão. Isso se repete até que toda a funcionalidade esteja implementada e, portanto, o Sistema terminado. O Sistema é colocado em produção quando o primeiro incremento é entregue. Esse primeiro incremento é, geralmente, um produto principal em que os requisitos básicos são abordados e os recursos complementares são adicionados nos próximos incrementos. Uma vez que o produto principal é analisado pelo cliente, há desenvolvimento de Plano para o próximo incremento
· Iterativo
É um Processo que desenvolve o software de tal forma que se concentra, principalmente, no crescimento preliminar e no design e vai ganhando velocidade lentamente, até que atenda aos requisitos, para que se consiga chegar ao final de um produto de software completamente construído e funcional. Portanto, trata-se aqui, de uma abordagem focada em segmentar qualquer grande Processo de Desenvolvimento de Software em partes menores. Então, não há o objetivo de estabelecer um plano de especificação completo, mas é feito para iniciar com requisitos mínimos, especificando e implementando apenas uma parte do software. Temos aqui, novamente, a figura do protótipo que é, então, revisado para inserção de requisitos adicionais, se for o caso. Na prática, então, assume uma forma iterativa para criar uma nova versão do aplicativo, e assim sucessivamente, até seu final.
· Rup
RUP, significa em português, Processo Unificado do Rational e se trata de um Processo de Desenvolvimento de Software da Rational que foi comprada e hoje é uma divisão da IBM, desde 2003. Ele divide o Processo de Desenvolvimento em quatro fases distintas, cada uma envolvendo modelagem de negócios, análise e design, implementação, teste e implantação. RUP fornece uma maneira estruturada para as empresas fazerem software, porque fornece um plano específico para cada etapa do Processo de Desenvolvimento, e ajuda a evitar que os recursos sejam desperdiçados, trabalhando fortemente na redução de custos inesperados de desenvolvimento. Pense que, nesse caso, RUP não é um modelo de desenvolvimento concreto, mas destina-se a ser adaptável às necessidades específicas de um projeto, time ou Empresa.
· Scrum
O Scrum é um Processo de Gerenciamento de Projetos de Software que faz uso da Metodologia de Desenvolvimento de Software Ágil. Essa estrutura é flexível e incentiva formas colaborativas de gerenciar um projeto de software. Um dos benefícios mais reconhecidos dessa Metodologia de Desenvolvimento de Software é que ela permite que você se mova rapidamente e também mude facilmente quando necessário. Ciclos de feedback mais rápidos e a capacidade de reconhecer problemas precocemente tornaram o Scrum uma das metodologias mais populares do mundo. O desenvolvimento se divide em várias fases, sendo que cada uma delas resulta em um produto pronto para uso e, ao final de cada etapa, um produto funcional de software sempre é entregue a um cliente. Chamamos esse ciclo ou essas etapas de entrega funcional ao término de Sprint. O feedback do cliente ajuda a revelar possíveis problemas ou a alterar o Plano Inicial, se necessário, porque é fato que há um cliente localmente alocado junto ao time Scrum.
· XP , TDD E FDD
Programação Extrema – XP
 É um método flexível que permite que alterações sejam feitas nos requisitos. Baseia-se em 4 atividades principais, que são Audição (entendimento de histórias de usuários), Design, Codificação e Testes. Todos eles se reúnem para criar um software que se beneficia com os requisitos do cliente. XP é melhor quando é necessário criar um software em um ambiente instável, portanto, desenvolvedores que trabalham com XP são capazes de entregar em prazos mais curtos do que a maioria das outras metodologias, além de incentivar o feedback de seus clientes que são compilados quando estamos testando o Sistema e, a partir de entradas de outros desenvolvedores trabalhando no mesmo projeto, além, é claro, diretamente do cliente.
Desenvolvimento Orientado por Recurso – FDD
O FDD começa por uma revisão do escopo do Sistema antes que os modelos de domínio sejam criados em grande detalhe para cada recurso e depois revisados novamente. Os modelos de domínio selecionados são, então, mesclados em um modelo único geral.
Desenvolvimento Orientado a Teste – TDD
O TDD pode ser definido como uma prática de programação que instrui os desenvolvedores a escrever um novo Código apenas se um teste automatizado falhar. Isso evita a duplicação de código. E torna o código mais claro, simples e livre de erros. Ele inicia com o design e o desenvolvimento de testes para cada pequena funcionalidade de um aplicativo, então, primeiro, o teste é desenvolvido, especifica e valida o que o código fará, o que é uma abordagem de trás para frente, já que, num Processo normal, primeiro geramos o código e depois o testamos. Como se trata de um teste, pode falhar, até porque, nessa abordagem, os testes são desenvolvidos antes mesmo da etapa de desenvolvimento propriamente dita.