Existe a divisão de requisitos sendo Requisito funcional e Requisito não-funcional, esta parte do processo o analista faz as primeiras entrevistas com os clientes e/ou usuários do software para conhecer as funcionalidades do sistema que será desenvolvido. Mas atenção é aqui que acontece a maior parte dos erros, pois a falta de experiência dos clientes ou usuários faz com que eles nem sempre tenham claro em sua mente quais funcionalidades o software necessita.
A grande questão da analise de requisitos é: como como saber se as necessidades do domínio do sistema foi captada? O objetivo dessa fase é justamente levantar os requisitos e garantir o amadurecimento deles, gosto muito de adicionar o básico diagrama de classes da UML nessa fase pois pelo menos eu consigo ter algo "palpavel" rsrs. Pois bem já deu para perceber que essa fase é imprescindível não é? E depois disso como eu começo a pensar no meu "ecosistema"?.
A especificação é a definição do que se espera que um software faça. Ela pode ser informal, neste caso ela pode ser considerada como um blueprint ou manual de usuário do ponto de vista do desenvolvedor, ou formal, no caso de ela ser definida principalmente em termos matemáticos ou programáticos.
Na prática, as especificações mais bem sucedidas são escritas para a compreensão e ajustes em uma aplicação que já se encontra bem desenvolvida, embora sistemas de sistemas de segurança críticos sejam cuidadosamente especificados antes do desenvolvimento da aplicação. Especificações são mais importantes para interfaces externas que devem permanecer estáveis. Aqui na especificação é que acontece o tão "famoso" prototípo que costumam chamar de fase de prototipação, sinceramente não curto muito essa montagem "coxinha" da especificação pois na minha opinião usando UML e criando pequenos wireframes já conseguimos abordar muita coisa, e como eu disse antes as coisas devem ser feitas em pequenos trechos, imagine que vc vá desenvolver um e-commerce vão não vai especificar TUDO não é? melhor começarmos pelo catalogo, depois carrinho, logística do armazém e etc, assim garantimos mais exatidão na hora da entrega :D.
A arquitetura de software é a fase que o desenvolvedor da as cartas, claro que se pensarmos no Domain Driven Design o desenvolvedor participa de TUDO, mas veja bem, é aqui que ele decide os componentes de software, sua regras básicas internas, suas propriedades externas, e seus relacionamentos com outros softwares. Essa fase tem como objetivo manter o sistema organizado no quesito estrutural e comportamental, garantindo que os dados tratados pelo software tenham comportamento coeso e definido, permitindo também mudanças lógicas sem afetar seu funcionamento. A arquitetura de software é necesserária para definir padrões e o design de uma aplicação, é aqui por exemplo que iriamos falar de Hexagonal Architecture, mas não vou falar sobre isso hoje pois eu me alongaria muito e tbm n tenho conhecimentos soloidos sobre isso rs.
Vou pegar um trecho que escrevi no segundo ano da faculdade sobre a arquitetura de software (que trabalho para copiar do caderno kkkkkk)
"O campo da ciência da computação tem lidado com problemas associados, como a complexidade da informação, desde sua criação. Os primeiros problemas de complexidade foram resolvidos pelos desenvolvedores através da escolha da estrutura de dados, do desenvolvimento de algoritmos e pela aplicação de conceitos de separação de escopos. Embora o termo arquitetura de software seja relativamente novo na indústria, os princípios fundamentais deste campo vêm sendo aplicados esporadicamente pela engenharia de software desde o início dos anos 80. As primeiras tentativas de capturar e explicar a arquitetura de software do sistema foram imprecisas e desorganizadas – freqüentemente caracterizadas por um conjunto de diagramas. Durante o decorrer da década de 90 houve um esforço concentrado para definir e codificar os aspectos fundamentais desta disciplina. Inicialmente um conjunto de padrões de projeto, estilo, melhores práticas, descrição de linguagens, e lógica formal foram desenvolvidas durante este período."
Analistas falem o que for essa é a parte mais PICA de todas, todo software é escrito em uma linguagem de programação, embora seja possível, com alguma dificuldade, escrevê-lo diretamente em linguagem de máquina. Diferentes partes de um programa podem ser escritas em diferentes linguagens, diferente do que o processo de software comum prega nessa fase também testamos o nosso código como prega o processo TDD
"TDD é o desenvolvimento de software orientado a testes. Entenda mais detalhes e como usá-lo! TDD é o desenvolvimento de software orientado a testes, ou em inglês, Test Driven Development. Mas mais do que simplesmente testar seu código, TDD é uma filosofia, uma cultura.".