Engenharia de Requisitos
Documento de Requisitos
Essencial ao Desenvolvimento de Software
De que se trata o artigo:
Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao processo de desenvolvimento de software e ilustrando como ele deve ser elaborado.
Para que serve:
Informar o leitor sobre quais elementos considerar quando da elaboração de um documento de requisitos, levando em consideração o público alvo do documento que engloba cliente, desenvolvedores e gerentes, dentre outros.
Em que situação o tema é útil:
Durante o desenvolvimento de um sistema de software, no qual há a necessidade de elaborar o documento descrevendo o conjunto de requisitos do sistema de modo a informar tanto equipe de projeto quanto cliente, o que será implementado.
Um engenheiro de software é um profissional que deve ter a habilidade de antecipar e gerenciar mudanças de requisitos de um produto de software. Além disso, ele precisa saber se expressar e comunicar-se bem a fim de capturar e registrar adequadamente o documento de requisitos. Os principais problemas no desenvolvimento de um sistema de software decorrem do entendimento errado entre engenheiro de software (produtor), responsável em apresentar o documento de requisitos, e usuário (consumidor). Um documento de requisitos de software precisa ser claro, consistente e completo, porque esse documento servirá de referência aos desenvolvedores, gerente de projeto, engenheiros de software (responsáveis pelos testes e manutenção do sistema), além de servir de base para definir o escopo das funcionalidades a serem registradas num contrato. Perceba que os requisitos compreendem o cerne de qualquer produto e mudanças sobre eles podem ocorrer ao longo do ciclo de vida de um software. Este artigo trata da importância do documento de requisitos de software e exemplifica como ele pode ser elaborado.
Requisitos de Software
Desenvolver um sistema de software requer um processo, o qual informa um conjunto de atividades a serem realizadas, quem as executam, quais artefatos de entrada são necessários e quais artefatos de saída são produzidos. Nesse sentido, detectar erros ou quaisquer outros problemas como, por exemplo, inconsistência e falta de clareza é de suma importância de modo a tornar o processo mais efetivo sob o ponto de vista de custo. Adicionalmente, envolver o usuário no processo é determinante para o sucesso do produto e do processo. Dentro deste contexto, entender adequadamente o requisito é essencial e essa é tarefa do engenheiro de software. Um requisito compreende uma característica ou funcionalidade que o sistema deve possuir ou uma restrição que deve satisfazer para atender uma necessidade do usuário. Dessa forma, o engenheiro de software, desempenhando o papel de engenheiro de requisitos, deve executar duas atividades essenciais para a elaboração do documento de requisitos:
Elicitação de requisitos – atividade na qual os requisitos do sistema a ser desenvolvido são levantados;
Análise de requisitos – atividade na qual os requisitos são analisados e confirmados pelos principais interessados do projeto (isto é, os stakeholders) que incluem cliente, usuário final e gerente de projetos, dentre outros.
Considera-se ainda que a elicitação de requisitos objetiva definir características do sistema sob a perspectiva do cliente, enquanto que a análise de requisitos visa obter a especificação de requisitos, do ponto de vista técnico, conforme entendimento dos desenvolvedores.
Durante a realização destas atividades, o engenheiro de software está preocupado em levantar, entender, analisar e, por fim, documentar os requisitos. Para tanto, ele deve concentrar-se nas características do sistema e atributos de qualidade, e não em como obtê-los. Aqui, é preciso identificar quais requisitos fazem parte ou não do escopo do sistema a ser desenvolvido, ou em outras palavras, entender a interface do sistema considerado e o ambiente externo.
É importante ressaltar a necessidade de definir o ‘limite’, ou também denominado escopo do sistema, a fim de tratar os requisitos funcionais e não funcionais do sistema. Além disso, quando da elaboração do documento de requisitos, o engenheiro de software deve levar em consideração os diferentes pontos de vistas dos stakeholders de modo que o documento resultante possa comunicar adequadamente o conjunto de requisitos do sistema a ser construído.
Documento de Requisitos
O documento de requisitos delimita o escopo do conjunto de funcionalidades que um sistema deve prover, bem como descreve os atributos de qualidade que devem ser suportados. Este documento deve ser elaborado de maneira precisa, completa, consistente e, principalmente, compreensível aos stakeholders (isto é, os principais interessados no sistema). Note que o documento de requisitos será lido por várias pessoas interessadas no projeto como, por exemplo, cliente, gerente de projeto, engenheiro de testes e programadores, e, portanto, precisa comunicar com clareza os requisitos do sistema. Dessa forma, tem-se que um documento de requisitos:
§ É elaborado pelo engenheiro de software e compreende o conjunto de requisitos do sistema a ser desenvolvido;
§ Deve ser analisado e confirmado pelos stakeholders;
§ Integra e relaciona um conjunto de perspectivas dos interessados do projeto;
§ Serve como mecanismo de comunicação para os stakeholders (i.e. as partes interessadas do projeto);
§ Captura e documenta os requisitos do projeto e serve de referência para testes, manutenção e evolução do sistema.
O documento de requisitos de um projeto tem o objetivo de documentar o escopo do sistema a ser desenvolvido. Nesse sentido, o documento de requisitos deve conter:
§ Introdução e visão geral do documento
§ Descrição de requisitos funcionais
§ Descrição de requisitos não-funcionais
§ Escopo não contemplado (de funcionalidades)
§ Documentação de apoio
É importante perceber a importância do documento de requisitos como determinante para o sucesso de um projeto. Ele identifica quais funcionalidades fazem parte ou não do escopo do sistema. A seção seguinte apresenta um exemplo de um documento de projeto ilustrando e complementando os pontos destacados acima.
Exemplificando o Documento de Requisitos
O engenheiro de software, ao elaborar o documento de requisitos, deve buscar um compromisso de comunicar bem as funcionalidades do sistema a ser desenvolvido e da definição em detalhes com clareza e consistência para os programadores e engenheiros de testes (responsáveis pela implementação do sistema e elaboração e execução de plano de testes, respectivamente).
A Tabela 1 apresenta uma relação dos itens consideradas imprescindíveis em um documento de requisitos. A relação de itens destacados na Tabela 1 não pressupõe a intenção de ser completo, mas de apontar os itens considerados como obrigatórios num documento de requisitos. Cabe destacar que os itens sugeridos para compor um documento de requisitos, conforme apresentado na Tabela 1, leva em consideração as recomendações de documento padrão IEEE-Std 830-1998 recomendado pelo IEEE e referenciado no quadro de links deste artigo.
|
Itens de um Documento de Requisitos |
Conteúdo |
|
1. Introdução |
Contém uma descrição dos objetivos do documento, o público ao qual ele se destina e, em linhas gerais, o propósito e escopo do projeto a ser desenvolvido. Pode adicionalmente conter termos e abreviações usadas, tipos de prioridades atribuídas aos requisitos, além de informar como o documento deve evoluir. |
|
2. Requisitos Funcionais |
Esta seção descreve, de maneira sumarizada, as principais funcionalidades que o sistema de software irá realizar. Por exemplo, num sistema de biblioteca, esta seção deveria conter uma descrição das funcionalidades de autenticação de usuário e controle de acesso. Observe que o sumário das funcionalidades de um sistema se faz necessário para permitir o entendimento das funcionalidades do sistema pelos diversos stakeholders. O engenheiro de software deve organizar o conjunto de funcionalidades do sistema de modo a torná-las mais compreensíveis aos clientes e demais stakeholders. Vale ainda ressaltar que o documento de requisitos pode ser complementado por outro documento como, por exemplo, especificações de casos de uso. |
|
3. Requisitos Não-Funcionais |
Apresenta-se uma descrição geral de outros requisitos do produto que limitam opções de desenvolvimento do sistema. Isto inclui a descrição de requisitos de segurança, confiabilidade, timeout de sessão de usuário, usabilidade, dentre outros. Esta seção considera os requisitos do produto, do processo, da interface gráfica e da plataforma tecnológica empregada. |
|
4. Escopo Não-Contemplado |
Contém descrição das funcionalidades não contempladas no escopo do sistema a ser desenvolvido. Outra denominação dada a esta seção é escopo negativo. Isto visa garantir às partes interessadas no sistema (isto é, cliente e equipe de desenvolvimento) quais funcionalidades fazem parte ou não do conjunto a ser implementado. |
