Documento de Requisitos: Essencial ao Desenvolvimento de Software

Transcrição

1 Documento de Requisitos: Essencial ao Desenvolvimento de Software 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: Especificaçã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 especificaçã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:

2 É 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 abaixo apresenta uma relação dos itens consideradas imprescindíveis em um documento de requisitos. A relação de itens destacados na tabela abaixo 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 abaixo, leva em consideração as recomendações de documento padrão IEEE-Std recomendado pelo IEEE. 1. Introdução 2. Requisitos Funcionais 3. Requisitos Não-Funcionais 4. Escopo Não- Contemplado 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. 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. 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. 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.

3 Esqueleto de Documento de Requisitos Simples (versão 1) 1. Descrição atual da empresa: descrever aqui a situação atual da empresa, se ela já tem algum sistema instalado (e se este sistema funciona corretamente, atendendo a todas as necessidades da empresa), se ela utiliza somente papel para organizar os dados (ficha de clientes, contas a pagar e receber, tabela de preços, etc), descrever também um histórico da empresa (quantos anos ela foi fundada, se sempre trabalhou com os mesmos produtos de hoje, se houve alguma alteração nos donos da empresa, etc). 2. Descrição do que se espera do software a ser desenvolvido: descrever aqui o que se espera após a instalação do sistema na empresa, o que será melhorado, quais os objetivos do sistema? 3. Documento de requisitos do sistema: aqui começa a descrever o que o sistema deverá ter, quais serão os cadastros (com seus atributos e métodos), quais serão as movimentações (com seus atributos e métodos), quais serão os relatórios do sistema (que informações são importantes para a tomada de decisão da empresa), etc. 4. Modelagem de dados do sistema: aqui serão descritos todos os diagramas do sistema (de classe, de caso de uso, etc). Os diagramas auxiliam o programador do sistema a desenvolver o software conforme as especificações escritas no item 3 (acima), de forma a documentar os processos que irão automatizar o controle de dados da empresa. 5. Mapeamento objeto-relacional: aqui entrará a parte de banco de dados, será inserido o diagrama do modelo relacional do sistema, para facilitar o desenvolvimento das tabelas do banco de dados e também os seus relacionamentos. 6. Dicionário de dados: é uma lista organizada de elementos (atributos e métodos) de dados de um sistema informando seu tipo de dados, se é nulo ou não, dentre outras características que formalizam a especificação da base do banco de dados. 7. Interfaces do sistema: neste item serão colocadas a) as telas (interfaces) e b) os relatórios do sistema a fim de facilitar o entendimento de cada um deles e demonstrar como as informações serão apresentadas aos usuários.

4 Exemplo de um Documento de Requisitos de Salão de Beleza 1. Descrição atual da empresa Software Nanis Hair Institute O Salão de Beleza Nanis Hair foi fundado no ano de 2009 por duas amigas (Elaine e Patricia) na cidade de Umuarama. A princípio Elaine fazia as manicures e Patricia fazia os penteados. Nenhuma das duas faziam cortes de cabelo e nem tinturas. Com o passar dos anos houve a necessidade de aprimorar o atendimento às clientes, então as duas fizeram cursos de cabeleireira e hoje fazem de tudo no salão. Até o momento não houve a necessidade de ser instalado um software para organizar os dados do salão, no entanto, com o crescimento dos clientes, as duas proprietárias se cansaram de organizar os dados dos clientes em caderninhos e também de controlar os horários em uma agenda de papel, pois em alguns casos, havia esquecimento de agendar no caderno e então criava-se alguns transtornos no salão. Além disso o controle das contas a receber (o que as clientes devem ao salão), ficam anotados em fichário a parte, em que cada cliente tem uma ficha e ali são anotadas cada conta pendente que é feita no salão. Outro problema encontrado é na venda das mercadorias (shampoos, máscaras, cremes, perfumes) que o salão disponibiliza às clientes, pois também não se tem um bom controle do estoque muito menos dos recebimentos das vendas realizadas no salão. 2. Descrição do que se espera do software Nanis Hair Institute Com o desenvolvimento do software, espera-se um melhor controle de todos os dados, desde as informações das clientes, do estoque de produtos para a venda e também para o próprio consumo do salão, dos horários de atendimento das clientes, assim como de todo valor de compra e venda que são realizadas pelas donas do salão. 3. Documento de requisitos do sistema Para efetivar o controle do salão Nanis Hair serão necessários alguns cadastros, movimentações e relatórios, que serão descritos a seguir.

5 3.1. Cadastros Cadastro de Cliente: este módulo será responsável por controlar todos os dados dos clientes a fim de organizar os contatos e informações dos mesmos para facilitar a comunicação e cobranças do salão. Terá como atributos do cliente: nome, endereço completo, bairro, CEP (código de endereçamento postal), cidade, UF (unidade federativa), telefone 1, telefone 2, , RG (registro geral), CPF (cadastro de pessoa física), data de nascimento, local de trabalho, função, status (ativo/inativo/inadimplente). Terá como métodos do cliente: cadastrar (novo cliente), alterar (dados do cliente existente), excluir (somente se o cliente não tiver nenhuma movimentação registrada no sistema), cancelar (fecha a edição do cadastro do cliente) Cadastro de Fornecedor: este módulo será responsável por controlar todos os dados dos fornecedores a fim de organizar os contatos e informações dos mesmos para facilitar a comunicação e aquisição de produtos do salão. Terá como atributos do fornecedor: nome, endereço completo, bairro, CEP, cidade, UF, telefone 1, telefone 2, , IE (inscrição estadual), CNPJ (cadastro nacional de pessoa jurídica), contato, status (ativo/inativo). Terá como métodos do fornecedor: cadastrar (novo fornecedor), alterar (dados do fornecedor existente), excluir (somente se o fornecedor não tiver nenhuma movimentação registrada no sistema), cancelar (fecha a edição do cadastro do fornecedor) Cadastro de Produtos: este módulo será responsável por controlar todos os dados dos produtos para que se possa saber o estoque e valores financeiros. Terá como atributos dos produtos: nome, quantidade, marca, tipo, unidade de medida, massa (quantos quilos ou litros ou unidades), preço de custo, preço de venda, data de vencimento, código de barras, status (ativo/ inativo/em falta). Terá como métodos do produto: cadastrar (novo produto), alterar (dados do produto existente), excluir (somente se o produto não tiver nenhuma movimentação registrada no sistema), cancelar (fecha a edição do cadastro do produto).

6 Cadastro de Funcionários: este módulo será responsável por controlar todos os dados dos funcionários do salão de beleza para organização da agenda. Terá como atributos dos funcionários: nome, endereço completo, bairro, CEP, cidade, UF, telefone 1, telefone 2, , RG, CPF, data de nascimento, data de admissão, data de demissão, função, status (ativo/inativo). Terá como métodos do funcionário: cadastrar (novo funcionário), alterar (dados do funcionário existente), excluir (somente se o funcionário não tiver nenhuma movimentação registrada no sistema), cancelar (fecha a edição do cadastro do funcionário) Cadastro de Serviços: este módulo será responsável por armazenar os tipos de serviços que o salão poderá oferecer para as clientes (Ex corte, tintura, química, manicure, pedicure, hidratação, luzes/mechas, etc). Terá como atributos dos serviços: nome, preço, tempo aproximado, status (ativo/inativo). Terá como métodos do serviço: cadastrar (novo serviço), alterar (dados do serviço existente), excluir (somente se o serviço não tiver nenhuma movimentação registrada no sistema), cancelar (fecha a edição do cadastro do serviço) Movimentações Agenda de Atendimento: este módulo será responsável em agendar as clientes para determinados serviços com os funcionários do salão e principalmente não ocorrer choques de horários. Terá como atributos dos atendimentos: data, hora inicial, serviço, hora final (prevista conforme o tipo do serviço a ser feito), funcionário que realizará o serviço Venda de Produtos: este módulo será responsável em dar baixa no estoque quando um produto for vendido a um cliente e também alimentar o caixa por meio do recebimento da venda. Terá como atributos da Venda: data, hora, nome do cliente, produtos vendidos (com as quantidades e preços de venda), valor total da venda, status (se o cliente acertou ou não a aquisição do produto).

7 Terá como métodos da venda: cadastrar (nova venda), alterar (dados da venda em execução), excluir (somente se a venda não tiver nenhuma movimentação registrada no sistema como baixa no estoque e/ou lançamento de contas a receber/recebimento), cancelar (fecha a edição do cadastro da venda no caso da desistência do cliente no momento de fechar a venda) Compra de Produtos: este módulo será responsável em adicionar novos produtos comprados de um fornecedor a fim de disponibilizar as quantidades para a venda ao cliente. Terá como atributos da Compra: data, hora, nome do fornecedor, produtos comprados (com as quantidades e preços de custo), valor total da compra, status (se o salão já pagou esta compra ou deixou pendente). Terá como métodos da compra: cadastrar (nova compra), alterar (dados da compra em execução), excluir (somente se a compra não tiver nenhuma movimentação registrada no sistema como alta no estoque e/ou lançamento de contas a pagar/pagamento), cancelar (fecha a edição do cadastro da compra no caso da desistência do fornecedor ou comprador no momento de fechar a venda) Relatórios Relatório de clientes: este relatório disponibilizará ao sistema dois relatórios que envolve os clientes, tais como: a) relatório de dados de todos os clientes b) relatório dos clientes ativos, inativos, adimplentes e inadimplentes Relatório de produtos: este relatório disponibilizará ao sistema relatórios que envolve os produtos, tais como: a) relatório de produtos vencidos b) relatório de preços de custo e de venda dos produtos c) relatório de produtos por determinados fornecedores d) relatório de produtos em falta

8 Relatório de fornecedores: este relatório disponibilizará ao sistema dados dos fornecedores ativos Relatório de horas marcadas: este relatório disponibilizará ao sistema dados da agenda por período (dia, semana) ou por funcionária, tais como: a) relatório de agendamento por dia ou por semana b) relatório de agendamento por funcionário a atender c) relatório de agendamento por serviço a realizar Relatórios de compras: este relatório disponibilizará ao sistema os dados das compras realizadas dos fornecedores, tais como: a) relatório de compra por período (semana, mês) b) relatório de compra por fornecedor c) relatório de compras pagas d) relatório de compras não pagas Relatórios de vendas: este relatório disponibilizará ao sistema os dados das compras realizadas dos clientes, tais como: a) relatório de venda por período (semana, mês) b) relatório de venda por cliente c) relatório de venda pagas d) relatório de venda não pagas