Introdução
Antes de modelar telas, escolher tecnologias ou escrever código, é necessário compreender com precisão qual situação precisa ser transformada, para quem essa transformação importa e até onde o sistema deverá atuar. Essa compreensão inicial pertence ao campo da engenharia de requisitos e sustenta decisões posteriores de análise, projeto, implementação, teste e validação.
A ementa do componente curricular Análise de Projetos e Sistemas do Curso Técnico em Informática PROSUB inclui, entre seus fundamentos, a engenharia de software, a entrevista com o cliente, a identificação de requisitos e as atividades de análise e projeto de sistemas. Nesse contexto, compreender problema, necessidade, objetivo, escopo, stakeholders e restrições não é uma etapa burocrática: é o mecanismo que permite transformar uma demanda inicialmente vaga em uma visão de sistema que possa ser discutida, delimitada e validada antes do desenvolvimento.
Calazans apresenta a elicitação como o momento em que se busca conhecer os problemas do cliente, os atores envolvidos, as necessidades relacionadas ao sistema, o escopo e as restrições. Gonçalves e Cortés reforçam que a documentação das necessidades delimita e alinha o escopo entre cliente e equipe de desenvolvimento. Freitas, ao tratar da engenharia de requisitos, também destaca que problemas de escopo e de entendimento surgem quando o objetivo é mal definido ou quando os usuários têm dificuldade para expressar aquilo de que realmente necessitam.
Esses conceitos formam uma cadeia lógica. Um sintoma chama atenção para uma situação indesejada; a investigação procura suas causas; a análise formula o problema; desse problema decorrem necessidades; as necessidades orientam o objetivo do sistema; o objetivo é delimitado por um escopo; e todo esse conjunto precisa considerar as pessoas, grupos e sistemas afetados, além das restrições que condicionam a solução. Somente depois dessa base é possível especificar requisitos e avaliar alternativas tecnológicas com maior segurança.
A sequência não elimina revisões: novas informações dos stakeholders podem levar a reformular etapas anteriores.
Do problema organizacional à necessidade do usuário
Em projetos de sistemas, é comum a demanda começar com uma frase como “precisamos de um aplicativo”, “o setor precisa de um sistema novo” ou “temos que automatizar esse processo”. Essas frases já apontam para uma solução, mas ainda não explicam adequadamente o problema. A engenharia de requisitos procura inverter essa ordem: primeiro compreende o domínio e a situação existente; depois identifica necessidades; somente então avalia o que deverá ser construído.
Problema, sintoma e causa
Um problema organizacional é uma condição atual que produz consequências indesejadas para uma organização, processo ou grupo de pessoas. Ele precisa ser descrito em termos do contexto real de trabalho, e não apenas como ausência de tecnologia. Dizer “não temos um sistema” informa uma condição tecnológica, mas não revela, por si só, qual prejuízo operacional precisa ser resolvido.
Os sintomas são manifestações observáveis do problema. Atrasos frequentes, retrabalho, registros divergentes, dificuldade para localizar informações, filas de atendimento, erros recorrentes e necessidade de conferir manualmente os mesmos dados podem indicar que algo precisa ser investigado. Entretanto, corrigir apenas um sintoma pode não eliminar a origem do problema.
As causas são fatores que contribuem para a ocorrência desses sintomas. Um atraso no atendimento pode decorrer de registros dispersos em várias planilhas; divergências de estoque podem ser causadas pela atualização manual em momentos diferentes; retrabalho pode resultar da ausência de integração entre setores. A mesma situação pode ter diversas causas, e uma mesma causa pode produzir vários sintomas. Por isso, a análise não deve presumir causalidade apenas porque dois eventos acontecem juntos: entrevistas, observação, documentos e dados do processo ajudam a confirmar a relação entre eles.
Considere uma biblioteca que registra empréstimos em planilhas separadas. Os sintomas podem incluir demora para localizar a situação de um livro, divergências sobre quem está com determinado exemplar e dificuldade para saber quais obras estão disponíveis. Uma investigação pode revelar como causas a duplicidade de registros, a atualização não simultânea das planilhas e a inexistência de um cadastro centralizado. O problema, então, não é simplesmente “falta um software”, mas a baixa confiabilidade e a demora no controle da circulação do acervo em razão de um processo de registro fragmentado.
Necessidade do usuário e necessidade do negócio
A necessidade expressa aquilo que precisa mudar, ser possibilitado ou ser melhorado para que o problema seja reduzido ou eliminado. Ela é mais próxima do resultado desejado do que da tecnologia empregada. No exemplo da biblioteca, uma necessidade poderia ser “dispor de informação única e atualizada sobre empréstimos, devoluções e disponibilidade do acervo”. Essa formulação abre espaço para avaliar diferentes soluções sem perder de vista o resultado esperado.
As necessidades não pertencem apenas ao usuário que opera diretamente o futuro sistema. Um gestor pode necessitar de dados consolidados para acompanhar o serviço; um setor administrativo pode precisar de informações para auditoria; outro sistema pode depender de dados gerados pela solução. A elicitação, portanto, precisa abranger os diferentes stakeholders e não somente a pessoa que utilizará a interface diariamente.
Calazans ressalta que a elicitação deve identificar as necessidades do cliente e os atores envolvidos, enquanto Gonçalves e Cortés destacam que a diversidade de perfis exige uma visão abrangente do domínio. Essa abrangência evita que a equipe transforme a perspectiva de um único entrevistado em uma representação incompleta do problema.
Solução tecnológica
A solução tecnológica é a combinação de recursos técnicos escolhidos para atender às necessidades identificadas. Ela pode envolver software, integração com sistemas existentes, banco de dados, serviços em nuvem, dispositivos, automação de etapas ou alterações no próprio processo de trabalho. O software é parte da solução quando sua utilização contribui para o objetivo definido; ele não deve ser tratado automaticamente como a resposta para qualquer problema organizacional.
Essa separação entre necessidade e solução é especialmente importante porque decisões técnicas carregam custos, dependências e restrições. Uma organização pode desejar acesso móvel, mas possuir conectividade limitada em parte de suas unidades; pode desejar disponibilidade contínua, mas ter infraestrutura de manutenção apenas em determinados horários. A análise inicial deve tornar essas condições explícitas antes que uma alternativa tecnológica seja assumida como obrigatória.
Objetivo do sistema
O objetivo do sistema estabelece qual resultado a solução deverá produzir ou apoiar dentro do problema delimitado. Ele funciona como referência para decisões de escopo e para a análise posterior dos requisitos. Freitas observa que, na análise de requisitos, é necessário verificar se cada requisito atende aos objetivos do sistema. Isso significa que o objetivo não deve ser apenas uma frase introdutória; ele deve orientar o que entra, o que fica de fora e o que precisa ser validado.
Um objetivo bem formulado descreve a contribuição esperada do sistema de forma suficientemente específica para orientar o projeto, mas sem antecipar detalhes de implementação que pertencem a etapas posteriores. “Criar um sistema moderno e fácil de usar” é vago, pois não esclarece qual transformação deve ocorrer. No exemplo da biblioteca, uma formulação mais útil seria: “centralizar e manter atualizadas as informações de acervo, empréstimos, devoluções e reservas, reduzindo inconsistências no controle da circulação de livros”.
O objetivo precisa manter ligação clara com o problema e com as necessidades. Se o problema identificado é a falta de confiabilidade nos registros de empréstimo, um objetivo centrado apenas em “disponibilizar um catálogo visualmente moderno” pode ser relevante em outro contexto, mas não responde ao núcleo do problema. Essa relação de coerência pode ser entendida como uma cadeia de justificativa: o sistema existe porque há um problema; suas capacidades são necessárias porque contribuem para um objetivo; e o objetivo é pertinente porque responde a necessidades verificadas junto aos stakeholders.
Objetivo do sistema e critérios de sucesso
Na etapa inicial, é útil associar o objetivo a evidências que permitam reconhecer se a situação melhorou. Essas evidências não precisam assumir, desde o início, a forma de indicadores sofisticados, mas devem tornar o objetivo menos abstrato. No caso da biblioteca, a redução de divergências entre registros, a capacidade de consultar imediatamente a disponibilidade de um exemplar e a eliminação de controles paralelos podem servir como sinais de que a solução está produzindo o efeito esperado.
Essa ligação entre objetivo e evidência também facilita a validação posterior. Gonçalves e Cortés distinguem teste, voltado a verificar o comportamento do software, de validação, na qual o cliente avalia se o produto atende às suas necessidades. Um sistema pode executar corretamente suas funções técnicas e, ainda assim, não resolver o problema que motivou o projeto. Por isso, a compreensão do objetivo precisa permanecer rastreável ao longo do desenvolvimento.
Escopo, fronteiras e limites da solução
Definir o escopo significa estabelecer o conjunto de capacidades, serviços e responsabilidades que serão tratados pelo projeto e pelo produto. Gonçalves e Cortés observam que a documentação dos requisitos permite delimitar e acordar o escopo entre cliente e fornecedor. Calazans acrescenta que a fronteira representa o limite de atuação do sistema, indicando o que está dentro e o que está fora de seus objetivos.
Escopo e fronteira são conceitos próximos, mas não idênticos. O escopo expressa o conteúdo acordado do produto e do projeto; a fronteira ajuda a visualizar o limite que separa o sistema de elementos externos. Uma funcionalidade interna pertence ao escopo quando será responsabilidade do sistema. Uma pessoa, organização, equipamento ou outro sistema pode ficar fora da fronteira e, ainda assim, interagir com o sistema como ator externo.
O que está dentro e o que está fora
A definição explícita do que está fora do escopo é tão importante quanto a descrição do que será incluído. Sem essa delimitação, diferentes stakeholders podem assumir expectativas incompatíveis. Um solicitante pode imaginar que o sistema também controlará compras; um usuário pode esperar integração com um serviço externo; a equipe técnica pode considerar que determinada rotina continuará sendo manual. Se essas diferenças permanecerem implícitas, o conflito tende a aparecer mais tarde, quando alterações custam mais e afetam cronograma, arquitetura e testes.
| Dentro do escopo | Fora do escopo inicial | Relação com a fronteira |
|---|---|---|
| Cadastro e consulta do acervo | Processo de compra de novos livros | O acervo é administrado pelo sistema; a aquisição permanece em processo externo. |
| Cadastro de usuários da biblioteca | Gestão acadêmica completa dos alunos | O sistema mantém os dados necessários ao serviço de biblioteca, sem substituir o sistema acadêmico. |
| Empréstimo, devolução e reserva | Contabilidade institucional | As operações de circulação pertencem à solução; processos contábeis permanecem externos. |
O exemplo dialoga com a situação apresentada por Calazans para um sistema de biblioteca: manutenção do acervo e dos clientes, empréstimos, devoluções e reservas ficam dentro da fronteira inicial, enquanto compra de livros e contabilidade permanecem fora. Caso, posteriormente, surja a necessidade de integração com o sistema financeiro, a fronteira pode ser revisada e esse sistema passa a ser considerado um ator externo relevante.
Escopo não é imutável
Delimitar o escopo não significa supor que ele jamais poderá mudar. Durante a elicitação, novos stakeholders podem ser identificados, restrições podem surgir e necessidades podem ser refinadas. A mudança, entretanto, precisa ser tratada de forma consciente: deve-se compreender o impacto sobre objetivos, requisitos, prazos, custos e integrações já assumidas. A fronteira serve justamente como referência para reconhecer quando uma nova demanda amplia ou altera aquilo que havia sido acordado.
Uma definição inicial de escopo também reduz um problema apontado por Freitas: quando o objetivo é mal definido ou quando os usuários fornecem informações que não contribuem para o problema central, a elicitação pode se dispersar. O escopo ajuda a distinguir informação relevante de demandas que pertencem a outro projeto, outra fase ou outro sistema.
Partes interessadas, atores e papéis no projeto
A palavra stakeholder, ou parte interessada, é usada para representar qualquer pessoa ou grupo afetado pelo sistema de forma direta ou indireta. Essa definição é mais ampla do que a de ator. Na abordagem apresentada por Calazans, um ator representa um papel que interage com o sistema; pode ser uma pessoa, uma organização, outro sistema ou mesmo um equipamento. Assim, todo ator relevante tende a ser um stakeholder, mas nem todo stakeholder precisa interagir diretamente com a solução.
Essa distinção evita um erro frequente: entrevistar apenas os futuros operadores da interface. Um gestor pode não realizar empréstimos no sistema da biblioteca, mas depende de relatórios e define políticas de funcionamento. Um setor de tecnologia pode não utilizar o sistema como usuário de negócio, porém impõe requisitos de infraestrutura e segurança. Um cliente solicitante pode financiar ou aprovar o projeto sem operar a aplicação. Todos podem influenciar requisitos e restrições.
| Papel | Relação com o sistema | Contribuição para a análise | Risco se não for considerado |
|---|---|---|---|
| Usuário direto | Interage diretamente com as funcionalidades do sistema. | Explica tarefas, regras, exceções, dificuldades do processo e condições reais de uso. | Funções incompatíveis com o trabalho cotidiano, fluxo inadequado e omissão de situações operacionais. |
| Usuário indireto | É afetado por informações, decisões ou resultados do sistema, mesmo sem operá-lo. | Apresenta necessidades relacionadas a saídas, prazos, qualidade da informação e efeitos do processo. | Relatórios insuficientes, decisões mal suportadas ou impactos não previstos sobre outros setores. |
| Cliente solicitante | Formaliza ou patrocina a demanda e representa interesses do negócio. | Ajuda a esclarecer problema, prioridades, objetivo, orçamento, critérios de aceitação e limites do projeto. | Expectativas divergentes sobre o que será entregue e dificuldade de validação. |
| Gestor | Responsabiliza-se pelo processo, setor ou resultado organizacional relacionado ao sistema. | Explica regras de negócio, indicadores, políticas, prioridades e dependências organizacionais. | Solução alinhada ao operador, mas desalinhada às regras e aos resultados do processo. |
| Equipe técnica | Analisa, projeta, desenvolve, testa, implanta ou mantém a solução. | Identifica viabilidade, integrações, dependências, riscos técnicos e restrições de infraestrutura. | Escolhas inviáveis, integração tardia, custos não previstos ou dificuldades de manutenção. |
Calazans chama atenção para outra distinção importante: desenvolvedores e analistas participam do processo de criação do sistema, mas não são automaticamente atores do sistema. Eles se tornam atores somente quando exercem algum papel que interage com a aplicação. Essa separação ajuda a manter claro o ponto de vista da modelagem: participar do projeto é diferente de interagir com o produto em operação.
Identificação e cobertura dos stakeholders
A identificação de stakeholders deve considerar quem define necessidades e escopo, quem utiliza o sistema, quem é afetado por suas saídas e quem avaliará ou aprovará o produto. Gonçalves e Cortés também apontam como possíveis fontes de requisitos o ambiente físico, documentos, dados existentes, recursos existentes, sistemas legados e aspectos de segurança. Isso amplia a análise para além das entrevistas e permite reconhecer atores externos que, muitas vezes, não aparecem espontaneamente na primeira conversa.
Uma visão completa não significa dar o mesmo peso a todas as opiniões. Diferentes stakeholders podem ter interesses conflitantes. Um operador pode priorizar rapidez; um gestor, rastreabilidade; a área de segurança, controles adicionais; o patrocinador, limitação de custos. A análise precisa registrar essas perspectivas, compreender seus motivos e negociar prioridades de modo coerente com o objetivo e com as restrições do projeto.
Restrições iniciais
Restrições são limitações internas ou externas que condicionam o projeto ou o funcionamento do sistema. Calazans apresenta exemplos relacionados a prazo e disponibilidade tecnológica e ressalta que restrições ajudam a definir os limites do projeto. Elas não são necessariamente defeitos; são condições que a solução precisa respeitar ou administrar.
Algumas restrições já existem antes do projeto: orçamento máximo, prazo legal, infraestrutura disponível, política institucional, padrão tecnológico obrigatório, integração com sistema legado, disponibilidade limitada de especialistas, janelas de manutenção ou requisitos regulatórios. Outras surgem durante a análise, quando se compreende melhor o ambiente em que o software deverá funcionar.
É importante não confundir restrição com requisito funcional. “Permitir reservar um livro” descreve uma capacidade do sistema. “O sistema deve operar na infraestrutura já disponível no laboratório” descreve uma condição que limita decisões técnicas. Em certos casos, uma restrição pode ser expressa posteriormente como requisito não funcional ou de domínio, mas seu papel inicial é tornar explícita uma condição que afeta o projeto.
| Tipo | Exemplo | Possível impacto |
|---|---|---|
| Prazo | O sistema precisa entrar em operação antes do início do período letivo. | Influência sobre priorização, sequência das entregas e tamanho do escopo inicial. |
| Orçamento | Há limite financeiro para aquisição de licenças e infraestrutura. | Restringe tecnologias, serviços contratados e capacidade de expansão imediata. |
| Tecnologia | A solução deve integrar-se ao sistema acadêmico já utilizado pela instituição. | Impõe dependências de interface, formatos de dados e disponibilidade do sistema externo. |
| Operação | Manutenções de servidores ocorrem em janela fixa semanal. | Afeta disponibilidade esperada e planejamento de implantação. |
| Pessoas | O especialista do processo está disponível apenas em períodos determinados. | Condiciona entrevistas, validações e ritmo de esclarecimento de requisitos. |
Uma restrição deve ser registrada juntamente com sua origem e consequência quando isso for relevante. Saber que uma data é fixa porque decorre de obrigação institucional é diferente de tratá-la como simples preferência. Da mesma forma, registrar que uma tecnologia é obrigatória por compatibilidade com sistemas existentes permite compreender por que alternativas aparentemente melhores não foram escolhidas.
Documento de visão simplificado
Depois de identificar problema, necessidades, objetivo, escopo, stakeholders e restrições, é necessário consolidar essas informações em um artefato que possa ser compartilhado e validado. Calazans apresenta um modelo detalhado de documento de visão baseado em Medeiros e observa que cada organização pode adaptá-lo às suas necessidades. Entre os elementos do modelo estão introdução, escopo, problema a ser solucionado, descrições de stakeholders e usuários, módulos, requisitos não funcionais, requisitos de sistemas e ambientes e uma visão geral do sistema.
Para uma etapa inicial de um curso técnico ou para projetos de menor complexidade, é possível sintetizar esses elementos em um documento de visão simplificado. O objetivo não é substituir a especificação de requisitos, casos de uso, histórias de usuário ou modelos posteriores, mas estabelecer uma base comum de entendimento antes que esses artefatos sejam produzidos.
Estrutura sugerida
1. Contexto e problema
Descreve a situação atual, os sintomas relevantes, as causas já confirmadas e os impactos observados. Deve explicar por que o projeto existe sem começar pela tecnologia escolhida.
2. Necessidades principais
Registra as mudanças ou capacidades necessárias aos usuários e ao negócio. As necessidades devem permanecer compreensíveis mesmo que a alternativa tecnológica ainda mude.
3. Objetivo do sistema
Define o resultado que o sistema deverá apoiar, mantendo relação explícita com o problema e com as necessidades identificadas.
4. Escopo e fronteiras
Apresenta as capacidades incluídas, os limites da solução e os elementos externos com os quais o sistema poderá interagir. Quando necessário, registra também o que está explicitamente fora do escopo inicial.
5. Stakeholders, usuários e atores externos
Identifica os papéis envolvidos, seus interesses, sua relação com o sistema e sua participação em decisões, validações ou operação.
6. Restrições iniciais
Relaciona condições de prazo, custo, tecnologia, infraestrutura, operação, integração, regulamentação ou disponibilidade de pessoas que precisam ser consideradas desde o início.
7. Capacidades esperadas em alto nível
Resume os principais serviços que o produto deverá oferecer, ainda sem detalhar fluxos, regras e critérios de aceitação. Esses elementos serão refinados na especificação de requisitos.
8. Critérios de validação da visão
Registra quem deverá concordar com a visão inicial e quais pontos precisam estar alinhados antes do detalhamento: problema, objetivo, limites, principais necessidades, stakeholders e restrições.
Exemplo integrado de visão inicial
Em uma biblioteca com registros fragmentados, o problema pode ser descrito como baixa confiabilidade e demora no controle de empréstimos e disponibilidade do acervo. A necessidade central é manter uma fonte única e atualizada de informação. O objetivo do sistema é centralizar o controle de acervo, empréstimos, devoluções e reservas, reduzindo divergências operacionais. O escopo inicial inclui cadastro do acervo e usuários da biblioteca, circulação e reserva; compras e contabilidade ficam fora. Usuários diretos incluem bibliotecários e, se houver autoatendimento, leitores; gestores e setores administrativos podem atuar como usuários indiretos ou stakeholders. Restrições podem incluir integração com cadastro acadêmico, infraestrutura existente e prazo de implantação.
A partir dessa visão, a equipe pode avançar para a escrita de requisitos funcionais, não funcionais e de domínio, para a modelagem de casos de uso ou para outros artefatos compatíveis com o processo de desenvolvimento adotado. O ponto central é preservar a rastreabilidade: cada requisito deve poder ser relacionado a uma necessidade e a um objetivo que justificam sua existência.
Síntese
A análise inicial de um sistema começa pela compreensão da situação que motiva o projeto. Sintomas indicam que algo precisa ser investigado; causas ajudam a explicar por que a situação ocorre; o problema organiza essas evidências em uma condição indesejada e delimitada. A necessidade expressa a mudança necessária para superar ou reduzir esse problema, enquanto a solução tecnológica representa uma escolha posterior sobre como essa mudança será apoiada.
O objetivo do sistema traduz o resultado esperado e serve como referência para avaliar a pertinência das funcionalidades. O escopo determina quais capacidades serão assumidas pelo produto, e a fronteira distingue o sistema dos elementos externos com os quais ele se relaciona. Uma delimitação explícita reduz ambiguidades e permite reconhecer quando uma nova demanda representa alteração de escopo.
Stakeholders abrangem pessoas e grupos afetados direta ou indiretamente pelo sistema. Atores são papéis que interagem com a solução. Usuários diretos, usuários indiretos, cliente solicitante, gestor e equipe técnica oferecem perspectivas diferentes e complementares; ignorar uma delas pode produzir requisitos incompletos ou decisões inviáveis. As restrições, por sua vez, registram condições de prazo, orçamento, tecnologia, operação, integração ou disponibilidade que limitam as alternativas possíveis.
O documento de visão simplificado reúne esses elementos em uma representação compartilhável da intenção do projeto. Ele conecta problema, necessidades, objetivo, escopo, stakeholders e restrições antes do detalhamento dos requisitos, criando uma base para negociação, validação e rastreabilidade durante as etapas seguintes do desenvolvimento de software.
Referências
- BAHIA. Secretaria da Educação. Superintendência da Educação Profissional e Tecnológica. Ementa - Técnico em Informática - PROSUB. Salvador: SUPROT, s.d.
- CALAZANS, Angélica Toffano Sedel. Análise e Projeto de Sistemas. Curso Técnico em Informática. Brasília: Instituto Federal de Brasília, s.d.
- FREITAS, Romualdo Rubens de. Análise e Projeto de Software. Cuiabá: Rede e-Tec Brasil; Universidade Federal de Mato Grosso, 2015.
- GONÇALVES, Enyo José Tavares; CORTÉS, Mariela Inés. Análise e Projeto de Sistemas. 3. ed. Fortaleza: EdUECE, 2015.