Visão 4+1
Desenvolvida por Philippe Cruchten com o objetivo de descrever o funcionamento de sistemas de software.
As visões são usadas para mostrar o sistema sob várias perspectivas, como usuário final, engenheiros de software, desenvolvedores e gerentes de projetos.
As quatro visões de modelo são: visão lógica (1), visão de desenvolvimento (2), visão de processo (3) e visão física (4). A visão de caso de uso é usada para ilustrar a arquitetura e representa a visão +1.
Visão lógica : Se concentra na funcionalidade que o sistema disponibiliza para o usuário final.
Na UML: Diagrama de classes e de Estado.
Visão de implementação: Ilustra o sistema do ponto de vista do desenvolvedor e se preocupa com o gerenciamento de projeto.
Na UML: Diagrama de componentes e de Pacotes.
Visão de processo : Permite visualizar as partes dinâmicas do sistema, explicar os processos e como eles se comunicam, focando no comportamento do sistema. A visão de processo se encarrega da concorrência, distribuição, integração, performance e escalabilidade.
Na UML: Diagrama de atividades, de Sequencia e de Comunicação.
Visão implantação : Mostra o sistema do ponto de vista do engenheiro de sistemas. Se preocupa com a topologia dos componentes de software (no contexto físico) assim como a comunicação entre esses componentes.
Na UML: Diagrama de implantação.
Cenário (+1) : Descreve a arquitetura do sistema através do uso de Diagramas de casos de uso. Cada diagrama descreve sequências de interações entre os objetos e processos. São usados para identificar elementos de arquitetura e ilustrar e validar o design de arquitetura.
SMART
Diferente da metodologia SMART, em arquitetura especificamente, o T do acrônimo significa "traceable".
Specific
Um requisito deve dizer exatamente o que é necessário.
Measurable
A funcionalidade é possível, uma vez que o sistema esteja construído. Assim é possível verificar (testes) que o requisito foi contemplado.
Attainable
Significa que o requisito é fisicamente viável. Não estando além da percepção humana ou soluções teóricas.
Realisable
Significa que ele pode ser contemplado considerando as restrições dentro das quais o projeto e os sistema estão sendo desenvolvidos.
Traceable
É a característica de um requisito ser rastreado “para trás e para frente” a partir da sua concepção até a sua especificação, design, implementação e testes
FURPS+
O modelo, desenvolvido na Hewlett-Packard, foi pela primeira vez publicamente elaborado por Grady e Caswell. FURPS+ agora é amplamente utilizado na indústria de software. O símbolo "+" foi posteriormente adicionado ao modelo após várias campanhas da HP para estender a sigla, de forma a enfatizar vários atributos.
Functionality
Principais requisitos funcionais do produto. Os que possuem impacto arquitetural.
Usability
Usabilidade considera aspectos de interatividade, design e experiência de uso. (Sim, isso pode determinar o sucesso do sistema!)
Reliability
Diz respeito à disponibilidade do sistema (Up Time), precisão de cálculos e tolerância a falha.
Performance
Diz respeito à capacidade do sistema em processar tarefas como o tempo de resposta de funcionalidades, inicialização, encerramento e restauração de backups e falhas.
Supportability
Está relacionado à capacidade do sistema em ser testado, adaptável, mantido, compatibilizado, parametrizado, escalado, internacionalizado e implantado.
+ Design, Implementation, Interface e Physical
Design: relacionado ao projeto do sistema. Como especificar o BD que
será utilizado. Implementation: especifica restrições de implementação, como uso de
bibliotecas nativas ou de terceiros. Interface: especifica integrações e acessos externos. Por exemplo,
integração via WS, REST etc. Pyhsical (Físico): determina restrições de hardware e implantação, por
exemplo, HD, RAM etc.
Referência: https://pt.wikipedia.org/wiki/FURPS