Eu gosto muito da resposta de William Pietri (+1), mas acredito que ela precisa ser adicionada. Mesmo presumindo que o que você entende por sistemas compreenda apenas software.
Mas, antes de entrar no assunto, não conheço um livro para ajudar. Tudo o que se segue, aprendi com a experiência (ou seja, os três pontos que William fez).
O que você está falando abrange, no mínimo, quatro funções amplas. Às vezes, uma pessoa pode preencher todas essas funções, para projetos de pequeno e médio porte, mas quando você inicia em grandes projetos, precisa pelo menos separar essas funções. É difícil para alguém ser especialista em todos eles de qualquer maneira significativa.
Analista de negócios
Essa é a pessoa que conversa com o cliente e traduz seus requisitos em algo que um arquiteto pode entender. Basicamente, uma lista de requisitos adequadamente formulados. Isso inclui os requisitos funcionais óbvios (o que esse sistema deve fornecer?), Mas também os requisitos não funcionais (quais são as características gerais que o sistema deve atender? Isso pode incluir segurança, confiabilidade, disponibilidade, resiliência, capacidade, desempenho, robustez e outros requisitos do ponto de vista do usuário).
Esta é a primeira vez que o sistema deve fazer, o início do pensamento sério.
Arquiteto de sistemas
Essa pessoa produz a estrutura técnica de alto nível dentro da qual trabalhar. Eles fornecem o plano de correspondência de estrutura de tópicos. As ferramentas gerais, técnicas, construções. Eles decompõem todo o sistema em componentes menores, como eles se encaixam, como se encaixam no mundo exterior ...
Isso ajuda de várias maneiras a refinar o que precisa ser pensado. Muitas vezes, problemas são descobertos nesse estágio sobre os requisitos, conforme escrito pelo analista de negócios. Volte a eles para algumas iterações para melhorar sua compreensão do que eles querem e sua expressão.
Designer de sistema
Esse papel é sobre como fazer tudo funcionar. Isso pode ser mais trabalho em equipe do que um show individual. Mas é provável que haja um designer líder para supervisionar todo o design do sistema. Essa pessoa deve se aprofundar nos detalhes e garantir que a visão do arquiteto seja algo que possa realmente ser construído.
Espere um aprimoramento adicional da arquitetura do sistema e, portanto, potencialmente da análise de negócios.
Gerente de testes
Este papel é muitas vezes esquecido. Mas no final do dia, se você não pode testá-lo, como pode provar que pode construí-lo? Deve haver uma revisão dos resultados de todas as etapas: análise de negócios, arquitetura e design por alguém competente em testes, capaz de destacar deficiências e, portanto, permitir correções precoces, muito antes de qualquer código ser escrito.
Esse é um breve resumo.
Esses caras / moças são apenas a direção geral do pessoal da fábrica para pensar sobre o que deve ser pensado.
Para projetos complexos, como grandes aplicativos bancários ou espaciais, apenas para dar dois exemplos (pense de centenas a milhares de dias úteis), existem muitos especialistas no assunto, como os chamamos para revisar e apoiar projetos em todas as etapas. Essas funções incluem análise de segurança, dimensionamento do sistema, capacidade, desempenho, bancos de dados, clustering e muitas outras áreas estreitas de especialização, incluindo áreas de negócios precisas. A variedade de funções depende do tamanho e da complexidade dos sistemas.
Tudo isso para dizer que você não deve tentar saber tudo, não o fará. No entanto, você pode ter uma idéia geral da situação geral e, em pequenos projetos, pode se aprofundar muito mais do que em grandes projetos, simplesmente porque o nível de complexidade permite que você seja mais arredondado.
Se você quiser saber como projetar sistemas, precisará começar a fazer perguntas pensando fora da caixa. Coloque-se o suficiente no lugar do cliente e tente pensar no que poderia dar errado, no que precisa ser testado. Depois, reúna-se com um cliente real e incentive-o a explicar as extensões e os limites do sistema que eles imaginam que precisam. Além disso, sempre que digo "cliente", você deve entender que isso abrange várias pessoas muito diferentes. Existe a pessoa que usa o sistema dia após dia para o que foi projetado para fazer. Há o operador, o suporte técnico, o gerente que precisa de um relatório ou outro, o auditor, a equipe de infraestrutura, a parte interessada que pagou, o gerente de qualidade que precisa de meios para testar seu sistema ... Pergunte a todos eles (e se eles são uma pessoa, peça a eles que coloquem todos esses chapéus um de cada vez), então pergunte a eles tudo o que precisam e você terá um bom começo para saber quais são os requisitos do sistema. De lá, você pode derivar a arquitetura e, a partir daí, o design.
Para sistemas complexos (seja apenas software ou para integrar-se ao hardware no sentido mais genérico), não apenas uma pessoa é suficiente para cada uma das quatro funções listadas acima, mas você precisa gerenciar o projeto até a definição do que o sistema deve fazer, muito menos as outras fases.
HPH, asm.