--- title: "Análise de Sistemas em TI" source: "https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI" wiki: "systems-analysis.info/int" article: "Análise_de_Sistemas_em_TI" language: "pt" categories: - "Category:Portuguese" - "Category:Systems analysis" revision_id: 402 wiki_created_at: 2026-09-06T22:33:13Z wiki_modified_at: 2026-09-06T22:33:13Z downloaded_at: 2026-09-07T22:39:48Z --- # Análise de Sistemas em TI **Análise de Sistemas em TI** (*Systems Analysis and Design*) — é uma abordagem para o projeto e desenvolvimento de sistemas de informação, desde a concepção até a operação, incluindo a identificação de necessidades, a formalização de requisitos, a modelagem do domínio e dos processos, bem como a avaliação de alternativas e riscos. Em outras palavras, a análise de sistemas em TI é a fase do desenvolvimento na qual os especialistas estudam o problema, definem o que o sistema deve fazer e elaboram soluções para sua criação. **A análise de sistemas clássica** abrange uma vasta gama de áreas de aplicação, *não apenas o desenvolvimento de software, mas também mudanças organizacionais, estratégias e outros aspectos.[1] [2]* ## Objeto e Tarefas da Análise de Sistemas em TI O **objeto** da **análise de sistemas em TI** é o sistema de informação (produto de software e/ou serviço) em todo o seu ciclo de vida — desde a concepção e justificativa até a implementação e operação. A **tarefa da análise de sistemas** é transformar as necessidades de negócio em um conjunto coerente e verificável de requisitos e decisões de arquitetura: identificar e documentar os objetivos e as restrições dos stakeholders, formalizar requisitos, modelar o domínio e os processos, avaliar a viabilidade e os riscos das alternativas e justificar a arquitetura escolhida. Como resultado, são criados documentos consistentes e estabelecidos vínculos rastreáveis entre requisitos, decisões de projeto e testes. Isso garante a governabilidade e o controle sobre o processo de desenvolvimento. As tarefas da análise de sistemas incluem: - **Identificação das necessidades e objetivos dos stakeholders**. O analista coleta e esclarece as expectativas dos clientes, usuários e outras partes interessadas; para isso, utiliza entrevistas, pesquisas, observação e análise dos processos atuais. O resultado é uma **especificação de requisitos** preliminar, com a divisão entre requisitos funcionais ("o que o sistema deve fazer") e não funcionais (confiabilidade, desempenho, segurança, etc.).^{[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-Zowghi-2)} - **Formalização e documentação de requisitos**. As solicitações são transformadas em requisitos verificáveis. Um requisito bem formulado deve ser claro e inequívoco, completo, consistente, verificável e rastreável a objetivos de nível superior; o conjunto de requisitos deve ser coerente e íntegro.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA7123-4)} Na prática, utilizam-se documentos padronizados: SRS (*Software Requirements Specification*) conforme a ISO/IEC/IEEE 29148, bem como, em alguns setores, URS (*User Requirements Specification*) e especificações funcionais.^{[\[5\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-5)[\[6\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-6)[\[7\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-7)} - **Análise e modelagem do sistema**. Para entender *como* o sistema funcionará e interagirá com o mundo externo, são construídos modelos: diagramas de caso de uso (Use Case) para cenários de utilização, DFD para fluxos de dados e processos de negócio, diagramas de classes/componentes, entre outros. Os modelos servem como base para a comparação de soluções e arquiteturas alternativas.^{[\[8\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-8)[\[9\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-9)[\[10\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO42010-10)} - **Avaliação de viabilidade e escolha da solução**. Realiza-se um *estudo de viabilidade* (*feasibility study* — viabilidade técnica, organizacional, econômica e de cronograma) e a comparação de alternativas de arquitetura (*trade-off*). Para avaliar a qualidade da arquitetura com base em atributos (por exemplo, desempenho, escalabilidade, modificabilidade), são aplicados métodos como o ATAM (*Architecture Tradeoff Analysis Method*).^{[\[11\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-11)[\[12\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ATAM-12)} A escolha entre, por exemplo, uma arquitetura monolítica e de microsserviços [3] baseia-se em compromissos explícitos (complexidade de operação vs. escalabilidade independente e velocidade de entrega), seguindo as recomendações de guias da indústria.^{[\[13\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-13)[\[14\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-14)} - **Preparação dos artefatos de projeto**. Com base na análise, são elaborados: - a especificação de requisitos aprovada (com indicação de sua importância), - o modelo conceitual do sistema (diagramas/descrições), - as decisões de arquitetura e projeto (esquemas de dados, interfaces de sistemas externos), - o plano de implementação (fases/módulos). - É crucial garantir a *rastreabilidade* (bidirectional traceability) dos requisitos até os elementos de design e testes.^{[\[15\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-15)[\[4\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA7123-4)} O sucesso de um projeto de TI depende em grande parte da maturidade das práticas de trabalho com requisitos e arquitetura. Uma pesquisa realizada pela McKinsey e pela Universidade de Oxford mostrou que grandes projetos de TI frequentemente excedem o orçamento e os prazos. Este estudo também destacou a importância de gerenciar adequadamente a estratégia, interagir com as partes interessadas e coletar requisitos de forma competente. Tudo isso pode influenciar fortemente o sucesso ou o fracasso de um projeto.^{[\[16\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-16)} ## Abordagens e Metodologias na Análise de Sistemas em TI **A análise de sistemas em TI** baseia-se nos princípios do pensamento sistêmico e em metodologias adaptadas para o desenvolvimento de software. Na prática, combinam-se abordagens "rígidas" e "suaves", metodologias estruturadas, notações orientadas a objetos, bem como linguagens de modelagem de processos e requisitos. - **Abordagens rígidas e suaves**. Em projetos de TI, a abordagem rígida (hard systems) pressupõe objetivos e requisitos formalizáveis desde o início, decomposição e projeto "top-down". A abordagem suave (soft systems) é aplicada quando os objetivos são incertos e existem múltiplos pontos de vista: utilizam-se elementos da Soft Systems Methodology (SSM) (por exemplo, *rich picture*, definições-raiz, CATWOE) para alinhar a compreensão do problema e das mudanças desejadas; em seguida, os resultados são traduzidos em requisitos formais.^{[\[17\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-17)[\[18\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-18)} - **Metodologia SSM (Soft Systems Methodology)**. Originalmente desenvolvida por *Peter Checkland* para mudanças organizacionais, a SSM é útil nas fases pré-projeto em TI: desde a investigação da situação-problema e formulação de definições-raiz (inclusive através do CATWOE) até a comparação de modelos conceituais com a realidade e o alcance de um acordo entre os stakeholders.^{[\[19\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-19)[\[20\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-20)} - **Metodologias estruturadas: SADT/IDEF0**. O SADT modela o sistema como uma hierarquia de funções; a notação padrão IDEF0 (IEEE 1320.1) registra as funções e suas interfaces I-C-O-M (Inputs, Controls, Outputs, Mechanisms). O método é conveniente para a decomposição funcional e para o alinhamento dos limites do sistema, independentemente dos algoritmos.^{[\[21\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-21)[\[22\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-22)} - **Análise orientada a objetos:** UML e SysML (MBSE). A UML tornou-se a linguagem base para requisitos e design (diagramas de caso de uso, classes, sequência, etc.) e facilita a validação de cenários com os usuários; a SysML estende a UML para a engenharia de sistemas (diagramas de requisitos, diagramas paramétricos) e se baseia na abordagem MBSE, onde o modelo é o artefato central em todas as fases, desde os requisitos até os testes.^{[\[23\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-23)[\[24\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-24)[\[25\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-25)} - **Modelagem de processos de negócio:** BPMN. O padrão BPMN é usado para a descrição gráfica de processos (piscinas, fluxos de trabalho, eventos, gateways), incluindo a comparação *as-is/to-be* em especificações de requisitos e integrações.^{[\[26\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-26)[\[27\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-27)} - **Relação com a engenharia de requisitos**. O processo inclui as etapas de elicitação–análise–especificação–validação–gerenciamento de mudanças; os critérios de um "bom requisito" e a estrutura da SRS são regulamentados pela ISO/IEC/IEEE 29148. Para priorização, aplicam-se técnicas como **MoSCoW** (Must/Should/Could/Won’t) e métodos de escolha multicritério, como o AHP. Em processos ágeis, a atividade de análise de sistemas se reflete no refinamento do backlog e na rastreabilidade dos requisitos.^{[\[28\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-28)[\[29\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-29)[\[30\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-30)[\[31\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-31)} - **Relação com a engenharia de sistemas**. Para sistemas complexos (ciberfísicos), aplica-se o Modelo V: no ramo "esquerdo" — análise de sistemas e arquitetura; no ramo "direito" — integração, verificação e validação, com vínculo aos artefatos do ramo esquerdo. Métodos de avaliação de arquitetura por atributos de qualidade incluem o ATAM (análise de trade-off).^{[\[32\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-32)[\[33\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-33)} A análise de sistemas em TI combina abordagens comprovadas — desde metodologias suaves de alinhamento de visão até notações e padrões formais. A escolha das ferramentas é determinada pelo grau de definição do problema: com alta incerteza, o papel da SSM e da facilitação se fortalece; com limites claros, prevalecem modelos formais (UML/SysML, IDEF0, BPMN) e regulamentos. ## Relação com a Arquitetura de TI e a Arquitetura Corporativa A análise de sistemas em projetos de TI está intimamente ligada ao projeto de arquitetura. Os papéis do analista e do arquiteto se sobrepõem: o analista formula os requisitos e o modelo lógico, enquanto o arquiteto define a estrutura-alvo da solução e os compromissos técnicos; o trabalho é realizado em conjunto. - **Arquitetura de sistemas de TI**. Em um sentido estrito, a arquitetura de software é a organização dos componentes, suas relações e os princípios que guiam o projeto da solução. Para o analista, é importante considerar os estilos de arquitetura (em camadas, cliente-servidor, microsserviços, orientada a eventos, etc.), pois os requisitos não funcionais (confiabilidade, escalabilidade, modificabilidade) frequentemente determinam as decisões de arquitetura e seus compromissos.^{[\[34\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SEI_ATAM-35)} Em uma fase inicial da análise, forma-se uma **visão de arquitetura** (high-level vision) e elabora-se um esboço da solução para verificar a viabilidade dos requisitos (a duração das iterações e o nível de detalhe dependem da metodologia).^{[\[36\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-TOGAFIntro-36)} - **Padrões e decisões preliminares**. Para atender aos requisitos não funcionais, aplicam-se padrões de arquitetura (architectural patterns). Por exemplo, para interação assíncrona e baixo acoplamento, utiliza-se o padrão publish-subscribe através de um message broker em uma arquitetura orientada a eventos.^{[\[37\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-AzureEvent-37)} - **TOGAF (The Open Group Architecture Framework)**. Um dos frameworks de arquitetura corporativa mais difundidos; inclui o método ADM (Architecture Development Method) e artefatos de governança de arquitetura (repositório, catálogos/matrizes, princípios). No TOGAF, o gerenciamento de requisitos é um processo contínuo, integrado a todas as fases do ADM.^{[\[36\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-TOGAFIntro-36)} Para apoiar os requisitos e a rastreabilidade, utilizam-se catálogos e matrizes (por exemplo, requisitos ↔ serviços, funções ↔ componentes), e distinguem-se os ***Architecture Building Blocks*** e os ***Solution Building Blocks***.^{[\[38\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-38)[\[39\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-39)} Os princípios e padrões da empresa são registrados nos catálogos correspondentes e atuam como **requisitos** não funcionais externos para as equipes de projeto.^{[\[40\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-40)} A conformidade das soluções com a arquitetura-alvo é confirmada através do procedimento de revisão de conformidade de arquitetura (Architecture Compliance Review).^{[\[41\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-41)} A abordagem TOGAF pressupõe uma **Visão de Arquitetura** preliminar e um detalhamento subsequente (dados/aplicações/tecnologias) com um plano de migração e gerenciamento de mudanças de requisitos.^{[\[42\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-42)[\[43\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-43)} - **Framework Zachman**. Uma ontologia pioneira e influente de artefatos de arquitetura corporativa, apresentada como uma matriz 6×6 (perspectivas × aspectos "o quê/como/onde/quem/quando/por quê"). A linha "designer" corresponde à análise e ao projeto de sistemas; as colunas definem a completude da análise de dados, funções/processos, papéis, localização e motivação. O framework serve como uma classificação (e não uma metodologia) e ajuda a garantir a completude da descrição da solução no cenário da empresa.^{[\[44\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-Zachman1987-44)} - **Relação com a arquitetura corporativa (Enterprise Architecture, EA)**. O analista de sistemas trabalha no contexto da EA: novos requisitos são rastreados até as capacidades de negócio e o modelo operacional; aplicam-se padrões e restrições de princípio da empresa (segurança, compatibilidade, etc.).^{[\[45\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-45)[\[36\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-TOGAFIntro-36)} Na fase de iniciação, forma-se a ***Architecture Vision*** (objetivos/restrições, requisitos de alto nível); em seguida, o analista detalha, mantendo a rastreabilidade com a visão e os padrões corporativos; o não cumprimento dos padrões é identificado nas revisões de arquitetura e pode levar a ajustes na solução.^{[\[36\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-46)} Em resumo: a análise de sistemas e o projeto de arquitetura formam uma ligação "requisitos → decisões de arquitetura → compromissos de atributos de qualidade". A escolha dos métodos (estilos/padrões, artefatos TOGAF, classificação de Zachman) é determinada pela natureza do projeto e pelos limites da arquitetura corporativa. ## Processos e Práticas A análise de sistemas está integrada em todo o ciclo de vida de desenvolvimento e operação de software, conectando objetivos de negócio, arquitetura e entrega. Inclui investigação pré-projeto, escolha da abordagem, criação de artefatos verificáveis e requisitos de confiabilidade, desempenho, segurança e manutenção. No modelo em cascata, a análise é realizada antes do projeto e da implementação; em métodos ágeis, ocorre continuamente através de iterações; e em DevOps, com foco em objetivos operacionais. Independentemente da abordagem, a análise garante rastreabilidade, gerenciamento de mudanças e riscos, documentação de compromissos de arquitetura e conformidade com restrições regulatórias, tornando o desenvolvimento previsível e gerenciável. - **SDLC Clássico (Cascata)**. A fase de Análise de Sistemas e Definição de Requisitos precede o projeto e a implementação; os requisitos são fixados em uma **SRS** detalhada como base para o planejamento e contratos. É eficaz em domínios estáveis e regulados; os riscos de "congelamento" de requisitos são mitigados por SRR/revisões e pelo gerenciamento de mudanças através de um **CCB**.^{[\[47\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_CCB-49)} - **Metodologias Ágeis (Agile)**. A análise é contínua: em vez de uma SRS final, mantém-se um backlog de produto com user stories e critérios de aceitação, refinado nas sessões de backlog refinement; aplica-se o **BDD** (Given–When–Then); o risco de perda de uma arquitetura coesa é compensado por uma elaboração arquitetônica inicial e uma rastreabilidade transparente dos requisitos ↔ implementação/testes.^{[\[50\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-MS_Trace-52)} - **DevOps e SRE**. Lançamentos frequentes exigem requisitos operacionais "por padrão": automação, observabilidade, rollback. Requisitos não funcionais são formulados como SLO/SLI, gerenciados com um error budget; tarefas de logs/métricas/traces/alertas são adicionadas ao backlog; para lançamentos sem tempo de inatividade, usam-se padrões como **blue/green**, entre outros.^{[\[53\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-AWS_BlueGreen-55)} - **Gerenciamento de Requisitos e Riscos**. Os requisitos em uma ferramenta ALM têm status e conexões com tarefas/releases/defeitos; são obrigatórios o controle de versão, a análise de impacto de mudanças e a repriorização regular.^{[\[56\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-Azure_Backlog-57)} - **Garantia de Qualidade (QA)**. A qualidade é incorporada na fase de requisitos: revisões, "Three Amigos", plano de *Acceptance Test Plan*, testes automatizados dos critérios de aceitação (BDD/ATDD).^{[\[58\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-MS_SpecFlow-59)} - **Observabilidade e Confiabilidade**. Nos requisitos incluem-se SLA/SLO, MTTR e MTBF com metas mensuráveis e métodos de controle; os parâmetros vêm do negócio/operação e são incorporados na arquitetura e nos testes de confiabilidade.^{[\[60\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-GCloud_Obs-61)} ## Métricas e Qualidade dos Artefatos Para avaliar o trabalho do analista de sistemas e a qualidade de seus resultados, aplicam-se critérios universalmente aceitos. **Requisitos e modelos de qualidade** são a base de um projeto bem-sucedido, por isso são gerenciados ao longo de todo o ciclo de vida (elicitação → especificação → verificação/validação → gerenciamento de mudanças). Os atributos básicos de qualidade dos requisitos são estabelecidos nas normas ISO/IEC/IEEE 29148 e (historicamente) IEEE 830.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} - **Correção (Correctness)** — o requisito reflete uma necessidade genuína e está alinhado com os especialistas do domínio; é confirmado por validação (revisão/inspeção, protótipos, cenários).^{[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA7123-4)} - **Completude (Completeness)** — aspectos e condições essenciais são considerados. - *Completude de um requisito individual*: detalhes necessários são especificados (ex.: "o indicador muda para o status **vermelho em caso de falha**", e não apenas "torna-se vermelho"). - *Completude da especificação*: cenários/papéis são cobertos, NFRs são definidos; isso é alcançado com checklists e rastreabilidade aos objetivos de negócio; uma auditoria independente de completude (QA/revisão) é útil.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_SEH-63)} - **Ausência de Ambiguidade (Unambiguity)** — as formulações são interpretadas de uma única maneira; um glossário, modelos como "o sistema **deve fazer A, quando B, se C**", e exemplos ajudam; diagramas são acompanhados por legendas. A verificação é feita pelo princípio dos **"quatro olhos"**.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} - **Consistência (Consistency)** — os requisitos não contradizem uns aos outros nem restrições externas; usa-se estruturação, tabelas de atributos consolidadas, revisões em equipe; verifica-se a conformidade com regulamentos/padrões.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_SEH-63)} - **Verificabilidade/Testabilidade (Verifiability)** — o seu cumprimento é confirmado por teste/demonstração/análise; formulações não verificáveis são substituídas por critérios mensuráveis; para NFRs, definem-se métricas e critérios de aceitação com antecedência.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_SEH-63)} - **Modificabilidade e Rastreabilidade (Modifiability & Traceability)** — IDs únicos, estrutura lógica ("uma ideia, um parágrafo"), ausência de duplicatas; mantêm-se os vínculos "requisito ↔ fonte/objetivo/design/teste", e uma matriz de **rastreabilidade (RTM)** é mantida.^{[\[64\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)} - **Classificação e Priorização** — qualidade do conjunto de requisitos; usam-se técnicas como **MoSCoW** e MCDM (ex., **AHP**); a priorização em conjunto com o negócio influencia o planejamento e os riscos.^{[\[65\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-Saaty-66)} **Métricas de qualidade de requisitos** (exemplos):^{[\[63\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} - densidade de defeitos nos requisitos (observações por 100 requisitos); - número de alterações após a fixação da linha de base; - métricas de cobertura: percentual de requisitos com testes; percentual de requisitos rastreáveis a objetivos de negócio; - estabilidade dos requisitos (relação de adicionados/removidos em relação ao total por período); - tamanho/complexidade da especificação (número médio de requisitos por caso de uso, profundidade da decomposição); - satisfação dos stakeholders (pesquisa). Em processos maduros (ex., **CMMI** nível 3+), existem regulamentos de qualidade de requisitos: verificações formais, auditorias de conformidade com modelos, coleta/análise de métricas.^{[\[67\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SEI_CMMI-67)} Em domínios críticos (aviônica, espacial, etc.), aplicam-se **métodos formais** para aumentar a confiabilidade.^{[\[68\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_FM-68)} ## Erros Típicos Em projetos de TI, erros de análise de sistemas são comuns: requisitos incompletos e ambíguos, contradições, escopo mal definido, negligência de aspectos não funcionais, integrações esquecidas e segurança tardia. Isso leva a retrabalho, atrasos, aumento de custos e defeitos. Abaixo, problemas típicos, suas consequências e formas de prevenção. - **Incompletude e requisitos omitidos**. Papéis com permissões especiais, casos de borda e NFRs são esquecidos. *Consequências:* retrabalho na arquitetura e adiamento do lançamento. Como evitar: checklists, brainstormings de "e se...", envolvimento precoce de testadores, rastreabilidade aos objetivos de negócio.^{[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SEI_Pitfalls-69)} - **Formulações vagas e ambíguas**. *Consequências:* desenvolvedores implementam "a coisa errada", cliente insatisfeito. Como evitar: critérios mensuráveis, glossário, modelos "A, quando B, se C", peer-review.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SEI_Pitfalls-69)} - **Requisitos contraditórios**. *Consequências:* atrasos para esclarecimentos, retrabalho na integração. Como evitar: estruturação, verificação de regras de negócio/regulamentação, sessões de resolução de conflitos, verificação de consistência em revisões.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} - **Síndrome de "banhar a ouro" (gold-plating)**. *Consequências:* aumento do escopo, complexidade, novos pontos de falha. Como evitar: vincular cada requisito a um objetivo/métrica; em Agile, não incluir o desnecessário no backlog; fixar o escopo; ver YAGNI. - **Detalhamento excessivo onde não é necessário.** Como evitar: separar *o quê/por quê* (requisitos) de *como* (design/implementação); aplicar *design-free requirements* onde for apropriado.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)} - **Violação da governabilidade dos requisitos**. *Consequências:* confusão de versões, implementação da "coisa errada". Como evitar: uma única fonte da verdade em ALM, versionamento e status, RTM e análise de impacto de mudanças; gerenciamento de mudanças via CCB.^{[\[64\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} - **Falta de participação dos usuários**. Como evitar: entrevistas, observação, protótipos, demonstrações regulares; validação explícita com os stakeholders.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} - **"Paralisia por análise" excessivamente longa**. Como evitar: zona de suficiência, iteração e timeboxing; lançamento de MVP/incrementos e ajuste com base no feedback.^{[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} - **Ignorar requisitos não funcionais**. Como evitar: destacar NFRs (ex., FURPS+), definir critérios mensuráveis, incluí-los no plano de testes e nas decisões de arquitetura.^{[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)} - **Erros de comunicação e "fator humano"**. Como resolver: desenvolver habilidades de entrevista e facilitação, manter a neutralidade, registrar decisões e fontes de requisitos (rastreabilidade aos objetivos).^{[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} A maioria dos problemas se resume à qualidade das formulações, completude e governabilidade dos requisitos; a aplicação de padrões como ISO/IEC/IEEE 29148 e práticas do SWEBOK (validade, rastreabilidade, iteração) reduz significativamente o risco de atrasos e retrabalho.^{[\[3\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-SWEBOK-1)} ## Limitações Apesar de sua eficácia em reduzir a incerteza, a análise de sistemas tem suas limitações: - **A realidade é mutável e complexa.** É impossível levar em conta todos os fatores, especialmente em projetos de longo prazo. Alguns requisitos inevitavelmente surgirão após o lançamento do sistema. É importante buscar minimizar as surpresas, mas é preciso estar preparado para mudanças. - **Os requisitos dependem das pessoas.** As prioridades do negócio, as leis e o mercado podem mudar. A análise de sistemas registra o estado atual e não pode prever todas as mudanças externas. Para se adaptar, é necessário atualizar regularmente os requisitos e trabalhar de forma iterativa. - **Os usuários nem sempre sabem o que querem até verem.** Esta é uma limitação bem conhecida. Prototipagem e metodologias ágeis, como o Agile, ajudam a superar esse problema. A análise no papel tem seus limites, e para obter dados precisos é necessário o feedback das implementações. - **Equilíbrio entre tempo e qualidade.** Uma análise excessivamente detalhada pode se tornar obsoleta. Em áreas inovadoras, é melhor criar rapidamente um produto mínimo viável (MVP) e obter dados reais. A análise de sistemas é eficaz em áreas estáveis, mas em projetos de pesquisa e desenvolvimento (P&D) seu papel é limitado. - **O fator humano.** Mesmo as melhores metodologias não compensam a incompetência do analista ou a indisponibilidade do cliente. É crucial que todos os participantes do processo estejam engajados e motivados. ## Influência das Tecnologias Modernas na Análise de Sistemas em TI A análise de sistemas em TI evolui constantemente sob a influência das inovações tecnológicas. O analista do século XXI trabalha em um ambiente de crescimento explosivo de dados, implementação generalizada de IA, ciclos de desenvolvimento rápidos e uma atenção redobrada à segurança. Uma prática bem-sucedida de análise de sistemas exige a aquisição de novos conhecimentos (Data Science, cibersegurança, tecnologias em nuvem) e flexibilidade na aplicação de métodos. - **Dados e AI/ML: o que é adicionado à análise**. Para sistemas com IA, desde o início são definidos os objetivos e o contexto de aplicação, os requisitos para as fontes e a qualidade dos dados, bem como as métricas de confiança nas decisões do modelo (confiabilidade, segurança, explicabilidade, confidencialidade, justiça). São planejadas verificações **TEVV** (testing, evaluation, verification, validation), monitoramento em operação e desativação/retirada segura do modelo. Esses passos correspondem às funções **GOVERN–MAP–MEASURE–MANAGE** do framework NIST para gerenciamento de riscos de IA; eles são refletidos na SRS, na arquitetura e nos planos de verificação/operação.^{[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)} - **DevSecOps: segurança "à esquerda" e por padrão**. A incorporação da segurança em cada estágio do **CI/CD** está se tornando a norma: verificações automáticas (SAST/DAST), escaneamento de dependências e contêineres, políticas de implantação, observabilidade básica. Utilizam-se registros de artefatos confiáveis e imagens "endurecidas" padronizadas; aplicam-se os princípios de confiança zero. Na análise de sistemas, são descritos antecipadamente os **pontos de controle do pipeline** (condições para passar de estágio), a ligação dos requisitos com os controles de segurança e as regras de transição entre ambientes (dev/test/stage/prod).^{[\[71\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-DoD_DevSecOps-71)} - **O que muda nos documentos (artefatos)**. Qual seção surge ou é refinada nos documentos-chave na presença de Big Data e AI/ML e ao trabalhar com DevSecOps: - **SRS / Especificação de Requisitos**: objetivos e contexto de aplicação da IA; requisitos de dados (origem, qualidade, restrições éticas e legais); métricas do modelo (precisão, confiabilidade, tempo de resposta); plano TEVV (testing, evaluation, verification, validation); requisitos de transparência/explicabilidade e privacidade; critérios para desativação/retirada do modelo de operação.^{[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)} - **Arquitetura e Decisões (Architecture, ADR)**: resultados da modelagem de ameaças; medidas de "segurança por padrão" (criptografia, controle de acesso, gerenciamento de segredos, princípio do menor privilégio); restrições ao uso de dados/modelos; registros de ADR com avaliação de riscos e compromissos.^{[\[71\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)} - **Plano de Verificação e Validação (V&V / TEVV)**: cenários de teste para modelos e dados; limiares de aceitação para métricas de qualidade; monitoramento de desvio de dados/modelo; procedimentos para reavaliação periódica e revalidação.^{[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)} - **Políticas de CI/CD e "portões" do pipeline**: verificações automáticas SAST/DAST, SCA (dependências), escaneamento de contêineres; assinatura e armazenamento de artefatos em registros confiáveis; regras para promoção entre ambientes (dev/test/stage/prod) e condições para bloquear a build em caso de falha nas verificações; requisitos de observabilidade por padrão.^{[\[71\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-DoD_DevSecOps-71)} - **Plano de Gerenciamento de Dados e Modelos**: catálogo de fontes e linhagem; critérios de qualidade e disponibilidade de dados; versões de datasets/modelos; cronograma de (re)treinamento e controle de viés; política de acesso e armazenamento; plano para desativação segura do modelo e exclusão de dados, se necessário.^{[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)} - **Operação e Observabilidade (Ops/Runbook)**: métricas de confiança na IA e SLOs; auditoria e logging; alertas para degradação/anomalias; plano de resposta a incidentes; fallback/kill-switch para componentes de IA; requisitos para relatórios e análise pós-incidente.^{[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-DoD_DevSecOps-71)} - **Rastreabilidade** (end-to-end): vínculos explícitos "**requisito ↔ controle/verificação no pipeline**" e "**requisito ↔ teste/monitoramento em operação**", para que a segurança e a qualidade possam ser comprovadamente verificadas em todo o ciclo de vida.^{[\[71\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)} - **Papel do analista de sistemas**. - gerencia o contexto e os riscos da IA (atores, cenários de uso, suposições e limitações dos dados); - garante a rastreabilidade "**requisito ↔ controle de segurança no pipeline**"; - formula requisitos não funcionais verificáveis (segurança, transparência, observabilidade) em todo o ciclo de vida do sistema.^{[\[70\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-DoD_DevSecOps-71)} ## Diferenças da Análise de Sistemas Clássica O termo "análise de sistemas" é historicamente mais amplo que o desenvolvimento de software. A análise de sistemas clássica é uma abordagem para resolver problemas complexos e interdisciplinares (sociais, econômicos, gerenciais), baseada no pensamento sistêmico e em métodos quantitativos, geralmente para apoiar decisões gerenciais. Em TI, a análise de sistemas é entendida como uma disciplina aplicada no campo da engenharia de software, focada na criação de sistemas de informação. Abaixo, as principais diferenças. - **Objetivos e objeto de análise**. A análise clássica resolve problemas mal estruturados e "difusos" e melhora sistemas sociotécnicos já existentes (rede de transporte urbano, estratégia de uma empresa, política ambiental). O objeto é um sistema real; a tarefa é ajudar o tomador de decisão a escolher um curso de ação. Para a análise de sistemas em TI, o objetivo é projetar e criar um novo sistema de informação ou produto de software que atenda aos requisitos. O objeto é o sistema a ser projetado; o foco está no comportamento e nas características necessárias aos usuários. - **Bases metodológicas**. As escolas clássicas baseiam-se no pensamento sistêmico e, frequentemente, na matemática. A abordagem rígida (hard systems) envolve a formalização do problema, critérios quantitativos e otimização (como na *pesquisa operacional*). As metodologias suaves (soft systems) reconhecem a multiplicidade de pontos de vista; um exemplo é a *Soft Systems Methodology (SSM)*, onde, através de discussões e modelos conceituais, as mudanças desejadas são acordadas. Em TI, a base são as disciplinas de engenharia: engenharia de requisitos, projeto de software, frameworks de arquitetura. Aplicam-se processos padronizados (ISO/IEC/IEEE 15288, 12207, 29148), notações UML/SysML e práticas de gerenciamento de mudanças. - **Papéis e artefatos**. Na análise clássica, o papel de "analista de sistemas" é muitas vezes informal; os resultados são um relatório analítico, recomendações, modelos matemáticos, cenários "what-if". Em TI, o papel do analista (ou analista de negócios) é formalizado; são produzidas especificações de requisitos, modelos de sistema (UML, ER), especificações de interface, user stories e backlog — artefatos usados diretamente por desenvolvedores e testadores. - **Ciclo de vida e processo**. A análise clássica não tem um modelo único: os passos dependem do problema (na SSM, desde o estudo da situação até a implementação das mudanças). Em TI, são adotados ciclos de vida de desenvolvimento de software (SDLC) padrão: no modelo em cascata, há uma fase separada de análise de requisitos; em abordagens iterativas e ágeis, a análise é uma atividade contínua a cada sprint. Práticas modernas (DevOps, CI/CD) expandem o escopo da análise para a operação: são considerados requisitos de manutenção, observabilidade e atualizabilidade. Em outras palavras, a análise de sistemas em TI está integrada ao ciclo de vida de desenvolvimento, enquanto a análise clássica é mais frequentemente realizada como uma atividade de projeto/consultoria. ## O Analista de Sistemas **O analista de sistemas em TI** é o especialista responsável pelo pensamento sistêmico no projeto e desenvolvimento de sistemas de informação: formação e validação de requisitos, modelagem (UML/BPMN), alinhamento de decisões de arquitetura e garantia de integração. O papel e os requisitos de qualificação na Federação Russa são definidos no padrão profissional e nos padrões educacionais federais estaduais (FGOS). **Objetivo principal do tipo de atividade profissional:** Garantir a conformidade do serviço de TI, sistema automatizado, sistema de informação automatizado, sistema de gerenciamento automatizado, produto ou ferramenta de software ou informação (doravante denominado Sistema) com o ambiente, requisitos e restrições iniciais, objetivos de automação e atividades automatizadas, através do desenvolvimento e da entrega de soluções de projeto de qualidade e inter-relacionadas às partes interessadas, ao iniciar e coordenar o trabalho de executores individuais em todo o ciclo de vida do Sistema (*Padrão Profissional "Analista de Sistemas" (ordem do Ministério do Trabalho da Federação Russa de 27.04.2023 nº 367n*).^{[\[72\]](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_note-72)} ## Glossário de Termos-Chave ### Conceitos Básicos e Participantes - Análise de Sistemas em TI — disciplina cujo objeto é o sistema de informação em todo o seu ciclo de vida, desde a concepção até a operação. - Stakeholders — indivíduos ou grupos interessados ou afetados pelo projeto (clientes, usuários, gerentes). - Artefatos de Projeto — documentos e resultados criados durante o projeto, como especificações, modelos, planos e decisões. ### Requisitos: Tipos e Documentação - Requisitos Funcionais — descrevem o que o sistema deve fazer; suas funções e comportamento. - Requisitos Não Funcionais — descrevem atributos de qualidade do sistema (confiabilidade, desempenho, segurança, usabilidade, escalabilidade, etc.). - Especificação de Requisitos (preliminar) — documento que contém o conjunto inicial de requisitos coletados nas fases iniciais do projeto. - SRS (Software Requirements Specification) — documento padronizado que descreve detalhadamente os requisitos do software, conforme padrões internacionais (por exemplo, ISO/IEC/IEEE 29148). - URS (User Requirements Specification) — documento que descreve os requisitos do usuário para o sistema do ponto de vista dos processos de negócio e das expectativas do usuário final. - Requisitos Arquiteturalmente Significativos (ASR) — requisitos que influenciam significativamente as decisões e os compromissos de arquitetura. - Requisitos Transversais (CFR) — sinônimo de requisitos não funcionais, enfatizando sua natureza abrangente. - Critérios de Aceitação (Acceptance Criteria) — condições verificáveis que, quando cumpridas, consideram o trabalho sobre um requisito como aceito. - Definition of Ready (DoR) — acordo sobre a prontidão de um item do backlog para o desenvolvimento (clareza, estimativa, critérios). - Definition of Done (DoD) — acordo sobre o que significa "concluído" para um trabalho (código, testes, documentação, implantação). - Restrição (Constraint) — condição rígida que limita as soluções (prazos, plataformas, padrões, licenças). - Pressuposto (Assumption) — suposição aceita sem prova, que requer validação posterior. - Qualidade dos Requisitos — propriedades segundo a ISO 29148: ausência de ambiguidade, completude, consistência, verificabilidade, atomicidade. ### Formalização, Rastreabilidade e Priorização de Requisitos - Formalização de Requisitos — processo de transformar solicitações informais em requisitos claros, verificáveis e inequívocos. - Rastreabilidade de Requisitos — capacidade de rastrear o ciclo de vida de um requisito desde sua origem até a implementação, teste e implantação. - Bidirectional traceability (rastreabilidade bidirecional) — capacidade de rastrear as conexões entre requisitos, elementos de design e cenários de teste, tanto na direção direta quanto na inversa. - MoSCoW — técnica de priorização de requisitos que os classifica como Must-have (deve ter), Should-have (deveria ter), Could-have (poderia ter) e Won't-have (não terá). - BDD (Behavior-Driven Development) — metodologia de desenvolvimento na qual os testes são escritos em linguagem natural, orientada ao comportamento do sistema do ponto de vista do usuário (formato Given–When–Then). ### Notações e Modelagem - UML (Unified Modeling Language) — linguagem gráfica padronizada para especificar, visualizar, construir e documentar os componentes de sistemas de software. - SysML (Systems Modeling Language) — extensão da UML para engenharia de sistemas, que suporta a modelagem de vários aspectos de sistemas complexos, incluindo requisitos, comportamento, estrutura e parâmetros. - BPMN (Business Process Model and Notation) — padrão de notação gráfica para descrever processos de negócio, permitindo visualizar fluxos de trabalho, eventos, gateways e piscinas. - MBSE (Model-Based Systems Engineering) — abordagem da engenharia de sistemas onde o modelo é o artefato central em todas as fases do ciclo de vida do sistema, desde os requisitos até os testes. - ArchiMate — notação de arquitetura corporativa (negócios, aplicações, tecnologias) e suas relações. - DMN (Decision Model and Notation) — modelagem de decisões de negócio e tabelas de regras. - DFD (Data Flow Diagram) — diagramas de fluxo de dados (contexto, níveis de decomposição). - ERD (Entity-Relationship Diagram) — modelo de domínio com entidades, relacionamentos e atributos. - Matriz CRUD — correspondência entre as operações Create/Read/Update/Delete e entidades e papéis/funções. ### Estilos de Arquitetura e Avaliação de Soluções - Arquitetura Monolítica — abordagem arquitetônica na qual todo o sistema é desenvolvido como um módulo único e indivisível. - Arquitetura de Microsserviços — abordagem arquitetônica na qual o sistema é construído como um conjunto de serviços pequenos, implantáveis e escaláveis de forma independente. - Trade-off (compromisso) — escolha entre características ou soluções mutuamente exclusivas ou conflitantes, onde a melhoria de uma característica ocorre em detrimento de outra. - ATAM (Architecture Tradeoff Analysis Method) — método de avaliação de arquitetura de software usado para analisar os compromissos entre atributos de qualidade (por exemplo, desempenho, escalabilidade). ### Arquitetura Corporativa e Frameworks - TOGAF (The Open Group Architecture Framework) — um dos frameworks de arquitetura corporativa mais comuns, que inclui o método ADM (Architecture Development Method) para desenvolver e gerenciar a arquitetura. - Zachman Framework — ontologia de artefatos de arquitetura corporativa, apresentada como uma matriz 6×6, que classifica diferentes aspectos da arquitetura de várias perspectivas. ### Abordagens de Análise e Processos de Desenvolvimento - Abordagem Rígida (Hard Systems) — metodologia de análise de sistemas que pressupõe objetivos e requisitos formalizáveis desde o início, decomposição e projeto "top-down", eficaz para tarefas bem definidas. - Abordagem Suave (Soft Systems) — metodologia de análise de sistemas aplicada quando os objetivos são incertos e existem múltiplos pontos de vista dos stakeholders, visando alinhar a compreensão do problema e das mudanças desejadas. - SSM (Soft Systems Methodology) — metodologia específica da abordagem de sistemas suaves, desenvolvida por Peter Checkland, que utiliza ferramentas como rich picture, definições-raiz e CATWOE. - Waterfall (modelo em cascata) — metodologia clássica de desenvolvimento de software, onde as fases (análise, projeto, implementação, teste, implantação) são executadas sequencialmente, com a conclusão completa da fase anterior antes do início da próxima. - Agile — grupo de metodologias ágeis de desenvolvimento de software, orientadas para o desenvolvimento iterativo, adaptação a mudanças, colaboração com o cliente e entrega contínua de valor. ### Métodos de Escolha e Erros Típicos - AHP (Analytic Hierarchy Process) — método de escolha multicritério que permite estruturar problemas complexos e avaliar alternativas com base em uma hierarquia de critérios. - Gold-plating (síndrome de "banhar a ouro") — erro na análise de sistemas que consiste em adicionar funcionalidades não solicitadas pelos stakeholders, o que leva ao aumento do escopo e da complexidade do projeto. ## Literatura - ISO/IEC/IEEE (2023). *15288: System Life Cycle Processes*. - INCOSE (2023). *INCOSE Systems Engineering Handbook*, 5ª ed. - ISO/IEC/IEEE (2018). *29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering*. - IIBA (2015). *A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3*. - The Open Group (2022). *The TOGAF® Standard, 10th Edition*. Versão oficial gratuita. - OMG (2017). *Unified Modeling Language (UML®) 2.5.1 Specification*. PDF. - OMG (2014). *Business Process Model and Notation (BPMN™) 2.0.2 Specification*. PDF. - OMG (2024). *Systems Modeling Language (SysML®) 1.7 Specification*. PDF. - The Open Group (2022). *ArchiMate® 3.2 Specification*. Download oficial gratuito (sob licença). - Bass, L.; Clements, P.; Kazman, R. (2021). *Software Architecture in Practice*, 4ª ed. - Wiegers, K.; Beatty, J. (2013). *Software Requirements*, 3ª ed. - Rozanski, N.; Woods, E. (2012). *Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives*, 2ª ed. - Meadows, D. (2008). *Thinking in Systems: A Primer*. - Senge, P. M. (2006). *The Fifth Discipline: The Art & Practice of the Learning Organization* (rev. ed.). - Blanchard, B. S.; Fabrycky, W. J. (2010). *Systems Engineering and Analysis*, 5ª ed. - Robertson, J.; Robertson, S. (2012). *Mastering the Requirements Process: Getting Requirements Right*, 3ª ed. - van Lamsweerde, A. (2009). *Requirements Engineering: From System Goals to UML Models to Software Specifications*. - Hull, E.; Jackson, K.; Dick, J. (2017). *Requirements Engineering*, 4ª ed. - Kendall, K. E.; Kendall, J. E. (2023). *Systems Analysis and Design*, 11ª ed. - Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). *Systems Analysis and Design: An Object-Oriented Approach with UML*, 8ª ed. - Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). *Systems Analysis and Design in a Changing World*, 7ª ed. - Fowler, M. (2003). *UML Distilled: A Brief Guide to the Standard Object Modeling Language*, 3ª ed. - Delligatti, L. (2013). *SysML Distilled: A Brief Guide to the Systems Modeling Language*. - Silver, B. (2011). *BPMN Method and Style*, 2ª ed. - Lankhorst, M. et al. (2017). *Enterprise Architecture at Work: Modelling, Communication and Analysis*, 4ª ed. - Richards, M.; Ford, N. (2020). *Fundamentals of Software Architecture*. - Fairbanks, G. (2010). *Just Enough Software Architecture: A Risk-Driven Approach*. - Keeling, M. (2017). *Design It!: From Programmer to Software Architect*. - Evans, E. (2003). *Domain-Driven Design: Tackling Complexity in the Heart of Software*. - Vernon, V. (2013). *Implementing Domain-Driven Design*. - Brandolini, A. (2018). *Introducing EventStorming: An Act of Deliberate Collective Learning*. - Simsion, G.; Witt, G. (2015). *Data Modeling Essentials*, 4ª ed. - Silverston, L. (2008–2009). *The Data Model Resource Book*, Vols. 1–3 (rev. eds.). - Keeney, R. L.; Raiffa, H. (1993). *Decisions with Multiple Objectives: Preferences and Value Trade-Offs*, 2ª ed. - Saaty, T. L. (1980). *The Analytic Hierarchy Process*; (1990) *Decision Making for Leaders*. ## Bibliografia - ISO/IEC/IEEE 15288:2023 — System life cycle processes - ISO/IEC/IEEE 12207:2017 — Software life cycle processes - ISO/IEC/IEEE 29148:2018 — Requirements engineering - ISO/IEC/IEEE 42010:2022 — Architecture description - ISO/IEC 25010:2023 — Product quality model (SQuaRE) - ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288 - ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation) - ISO/IEC/IEEE 42020:2019 — Architecture processes - ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts - IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation - UML 2.5.1 — OMG Specification - BPMN 2.0.2 — OMG Specification - SysML v1.7 — OMG Specification - TOGAF Standard, 10th Edition — The Open Group - ArchiMate 3.2 — The Open Group - SEI ATAM — Architecture Tradeoff Analysis Method - NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF) - SWEBOK Guide v4.0a — IEEE Computer Society (PDF) - Guide to the Systems Engineering Body of Knowledge (SEBoK) - BABOK Guide v3 — IIBA - Google SRE Books — Official site - Microsoft Azure Well-Architected Framework — Official docs - Análise de Sistemas em palavras simples. YouTube (Russo) - Análise de Sistemas em TI em palavras simples. YouTube (Russo) ## Notas 1. ↑ ^{[1.00](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-0)} ^{[1.01](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-1)} ^{[1.02](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-2)} ^{[1.03](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-3)} ^{[1.04](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-4)} ^{[1.05](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-5)} ^{[1.06](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-6)} ^{[1.07](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-7)} ^{[1.08](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-8)} ^{[1.09](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-9)} ^{[1.10](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-10)} ^{[1.11](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-11)} ^{[1.12](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SWEBOK_1-12)} IEEE Computer Society (2025). *Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a*. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf 2. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-Zowghi_2-0) Zowghi, D.; Coulin, C. (2005/2014). *Requirements Elicitation: A Survey of Techniques, Approaches, and Tools*. https://eecs481.org/readings/requirements.pdf 3. ↑ ^{[3.00](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-0)} ^{[3.01](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-1)} ^{[3.02](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-2)} ^{[3.03](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-3)} ^{[3.04](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-4)} ^{[3.05](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-5)} ^{[3.06](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-6)} ^{[3.07](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-7)} ^{[3.08](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-8)} ^{[3.09](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-9)} ^{[3.10](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-10)} ^{[3.11](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-11)} ^{[3.12](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO29148_3-12)} ISO/IEC/IEEE 29148 (2011/2018). *Systems and software engineering — Requirements engineering*. *ISO* overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html 4. ↑ ^{[4.0](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA7123_4-0)} ^{[4.1](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA7123_4-1)} ^{[4.2](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA7123_4-2)} NASA (2020). *NPR 7123.1C — Systems Engineering Processes and Requirements*. Definição de «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all 5. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-5) GMU (George Mason University). *IEEE Software Requirements Specification Template (SRS)*. https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc 6. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-6) Westfall, L. (Cal Poly, .edu). *The What, Why, Who, When and How of Software Requirements* (menciona a URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf 7. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-7) Stanford University IT (.edu). *Functional Specification Document Template*. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx 8. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-8) Penn State (.edu). *Elements of a Use Case Diagram*. https://www.e-education.psu.edu/geog468/l8_p4.html 9. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-9) UC Irvine (.edu). *Data Flow Diagram*. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/ 10. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ISO42010_10-0) ISO/IEC/IEEE 42010 (2011/2022). *Architecture description* — requisitos para a descrição da arquitetura e pontos de vista. https://standards.ieee.org/ieee/42010/5334/ 11. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-11) Cornell University (.edu). *CS 5150 — Feasibility Studies*. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf 12. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-ATAM_12-0) Carnegie Mellon SEI. *Architecture Tradeoff Analysis Method (ATAM) — overview*. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/ 13. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-13) Microsoft Azure Architecture Center. *Architecture styles: microservices — benefits & complexity*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/ 14. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-14) Google Cloud. *What Is Microservices Architecture? — Monolithic vs. microservices (overview)*. https://cloud.google.com/learn/what-is-microservices-architecture 15. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-15) NASA (2023). *Requirements Management — Traceability, Bidirectional traceability (definitions)*. https://www.nasa.gov/reference/6-2-requirements-management/ 16. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-16) McKinsey (2012). *Delivering large-scale IT projects on time, on budget, and on value*. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value 17. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-17) University of Cambridge, IfM. *Soft Systems Methodology (SSM) — CATWOE, 3Es*. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/ 18. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-18) Lancaster University (ePrints). *Soft Systems Methodology and root definitions*. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf 19. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-19) University of Cambridge, IfM. *Soft Systems Methodology (SSM)*. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/ 20. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-20) UCL Discovery (.ac.uk). M. Haklay. *Soft System Methodology (SSM)*. https://discovery.ucl.ac.uk/1296/1/paper13.pdf 21. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-21) IEEE Std 1320.1-1998 (R2004). *Functional Modeling Language — Syntax and Semantics for IDEF0*. https://standards.ieee.org/ieee/1320.1/2003/ 22. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-22) ISO/IEC/IEEE 31320-1:2012. *IDEF0: Function Modeling*. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf 23. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-23) University of Washington (.edu). *UML Class Diagrams / UML overview (course material)*. https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf 24. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-24) JHU/APL (.edu). *Modeling with SysML — tutorial*. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf 25. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-25) MIT OCW (.edu). O. de Weck. *Introduction to Systems Modeling Languages (incl. SysML, MBSE)*. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf 26. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-26) IBM. *What is Business Process Modeling and Notation (BPMN)?*. https://www.ibm.com/think/topics/bpmn 27. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-27) IBM Docs. *Business Process Modeling Notation (BPMN) model*. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model 28. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-28) IEEE/ISO/IEC 29148:2018. *Systems and software engineering — Requirements engineering (overview)*. https://standards.ieee.org/ieee/29148/6937/ 29. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-29) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/ 30. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-30) T. L. Saaty. *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19 31. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-31) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management 32. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-32) MIT OCW (.edu). *V-Model — Fundamentals of Systems Engineering*. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/ 33. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-33) Carnegie Mellon SEI (.edu). *Architecture Tradeoff Analysis Method (ATAM) — overview*. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/ 34. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-AzureStyles_34-0) Microsoft Azure Architecture Center. *Architecture styles*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/ 35. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SEI_ATAM_35-0) Kazman, R.; Klein, M.; Clements, P. *ATAM: Method for Architecture Evaluation*. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf 36. ↑ ^{[36.0](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-TOGAFIntro_36-0)} ^{[36.1](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-TOGAFIntro_36-1)} ^{[36.2](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-TOGAFIntro_36-2)} ^{[36.3](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-TOGAFIntro_36-3)} The Open Group. *Introduction — The TOGAF® Standard*. https://www.togaf.org/chap01.html 37. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-AzureEvent_37-0) Microsoft Azure Architecture Center. *Event-Driven Architecture style*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven 38. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-38) Jonkers, H. et al. *ArchiMate® and the TOGAF® Framework*. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf 39. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-39) Estrem, W. *Building Blocks Revisited*. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf 40. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-40) The Open Group. *Architecture Principles*. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf 41. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-41) The Open Group. *IT Architecture Compliance*. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm 42. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-42) *The TOGAF® Standard, Version 9.2* (especificação). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf 43. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-43) Engelsman, W.; van Sinderen, M. *Supporting Requirements Management in TOGAF and ArchiMate*. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf 44. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-Zachman1987_44-0) Zachman, J. A. *A Framework for Information Systems Architecture*. *IBM Systems Journal*, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276 45. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-45) MIT CISR. *Classic Topics — Enterprise Architecture* (definição de EA como «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture 46. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-46) The Open Group. *IT Architecture Compliance*. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm 47. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-Royce_47-0) Royce, W. W. (1970). *Managing the Development of Large Software Systems*. IEEE WESCON. Reimpressão (PDF): https://www.praxisframework.org/files/royce1970.pdf 48. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-DAU_SRR_48-0) Defense Acquisition University. *System Requirements Review (SRR) — Acquipedia*. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/ 49. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_CCB_49-0) NASA (2023). *Requirements Management — baseline, change control (CCB)*. https://www.nasa.gov/reference/6-2-requirements-management/ 50. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-MS_Agile_50-0) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management 51. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-MS_BDD_51-0) MSDN Magazine (Microsoft). *BDD Primer: Behavior‑Driven Development with SpecFlow*. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin 52. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-MS_Trace_52-0) Microsoft Learn. *End‑to‑end traceability in Azure DevOps*. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability 53. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SRE_SLO_53-0) Google SRE. *Service Level Objectives*; *Error Budget Policy*. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/ 54. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-AzureMon_54-0) Microsoft Learn. *Azure Monitor — Overview*. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview 55. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-AWS_BlueGreen_55-0) AWS Whitepaper. *Blue/Green Deployments on AWS*. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html 56. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-Azure_Workflow_56-0) Microsoft Learn. *Manage change — track, triage, and implement change requests*. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change 57. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-Azure_Backlog_57-0) Microsoft Learn (Azure Boards). *Backlogs overview — create and manage your product backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview 58. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-MS_Test_58-0) Microsoft Learn (Azure Test Plans). *What is Azure Test Plans?*. https://learn.microsoft.com/en-us/azure/devops/test/overview 59. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-MS_SpecFlow_59-0) MSDN Magazine. *Behavior‑Driven Design with SpecFlow*. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow 60. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-IBM_MTTR_60-0) IBM. *MTTR vs. MTBF: What’s the difference?*. https://www.ibm.com/think/topics/mttr-vs-mtbf 61. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-GCloud_Obs_61-0) Google Cloud. *Google Cloud Observability*. https://cloud.google.com/products/observability 62. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-IEEE830_62-0) IEEE Std 830‑1998. *IEEE Recommended Practice for Software Requirements Specifications* (padrão histórico). Cópia de estudo (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf 63. ↑ ^{[63.0](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_SEH_63-0)} ^{[63.1](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_SEH_63-1)} ^{[63.2](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_SEH_63-2)} ^{[63.3](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_SEH_63-3)} NASA. *Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2)*. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf 64. ↑ ^{[64.0](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_RM_64-0)} ^{[64.1](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_RM_64-1)} NASA (2023). *Requirements Management — traceability, baseline, CCB*. https://www.nasa.gov/reference/6-2-requirements-management/ 65. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-MoSCoW_65-0) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/ 66. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-Saaty_66-0) Saaty, T. L. (1994). *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19 67. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SEI_CMMI_67-0) SEI / CMMI Institute. *Capability Maturity Model Integration (CMMI) — Overview*. https://www.sei.cmu.edu/cmmi/ 68. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NASA_FM_68-0) NASA Langley. *What is Formal Methods?*; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf 69. ↑ ^{[69.0](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SEI_Pitfalls_69-0)} ^{[69.1](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-SEI_Pitfalls_69-1)} SEI (CMU). *Common Testing Problems: Pitfalls to Prevent and Mitigate* (sobre problemas típicos de requisitos/rastreabilidade). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/ 70. ↑ ^{[70.0](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-0)} ^{[70.1](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-1)} ^{[70.2](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-2)} ^{[70.3](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-3)} ^{[70.4](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-4)} ^{[70.5](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-5)} ^{[70.6](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-6)} ^{[70.7](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-NIST_AI_RMF_70-7)} NIST (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf 71. ↑ ^{[71.0](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-DoD_DevSecOps_71-0)} ^{[71.1](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-DoD_DevSecOps_71-1)} ^{[71.2](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-DoD_DevSecOps_71-2)} ^{[71.3](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-DoD_DevSecOps_71-3)} ^{[71.4](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-DoD_DevSecOps_71-4)} ^{[71.5](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-DoD_DevSecOps_71-5)} U.S. DoD CIO (2021). *DoD Enterprise DevSecOps Reference Design*. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf 72. [↑](https://systems-analysis.info/int/An%C3%A1lise_de_Sistemas_em_TI#cite_ref-72) Padrão Profissional "Analista de Sistemas" (ordem do Ministério do Trabalho da Federação Russa de 27.04.2023 nº 367n).