Especificação de
Sistemas e Especificação
de Requisitos
Universidade Federal do Estado do Rio de Janeiro
Centro de Ciências Exatas e Tecnologia
Escola de Informática Aplicada
Curso: Bacharelado em Sistemas de Informação
Disciplina: Construção de Sistemas
Professor: Luiz Fernando Seibel
Grupo: Eduardo Henrique Cavalcante Fontanha de Oliveira
Pedro Nuno de Souza Moura
Apresentação
Tem este trabalho por objetivo funcionar como um guia à apresentação sobre Especificação de Sistemas e Especificação de Requisitos da disciplina de Construção de Sistemas.
Assim sendo, cabe explicitar qual o objetivo da etapa de Especificação de Sistemas. Esta tem como pilar sustentador a definição dos aspectos concernentes ao sistema, ou seja, qual o processo atual empregado na empresa, quais os problemas a serem resolvidos e a definição do escopo do sistema. Dessa forma, deve-se, portanto, descrever não só tais propriedades, como também quais tecnologias serão utilizadas no desenvolvimento do sistema e a própria metodologia de trabalho.
Analogamente, a etapa de Especificação de Requisitos visa à elicitação, isto é, ao levantamento dos requisitos funcionais que o sistema deve ter, bem como às restrições impostas sobre como o sistema deve executar tais funcionalidades, ou seja, os requisitos não-funcionais. Ademais, é salutar discriminar os não-requisitos (requisitos não-contemplados), aqueles que não serão atendidos pelo sistema.
A fim de que o texto e, conseqüentemente, a apresentação, se torne claro e de fácil compreensão, os assuntos compreendidos pela etapa de Especificação de Sistemas serão abordados em tópicos:
• Visão Geral do Problema
Num primeiro momento, após serem definidos o nome do sistema e o propósito deste, deve-se obter a visão geral do problema a ser resolvido. Sendo assim, é feita uma descrição do processo atual da empresa. Nesta, o processo de negócio da empresa é detalhadamente descrito, a fim de que sejam entendidas as necessidades do cliente e o próprio domínio. Além disso, devem ser identificadas outras áreas ou empresas, isto é, entidades externas, que também estarão envolvidas no projeto. É recomendável e interessante utilizar um Diagrama de Atividades para representar tal processo de negócio, facilitando, assim, a visualização do fluxo de processo da empresa. Como exemplo, segue na próxima página um Diagrama de Atividades que descreve o processo de negócio de um ambiente de gerência de tarefas em uma empresa de desenvolvimento de software.
Além disso, devem ser levantados os problemas atualmente encontrados. É devido, pois, descrever o referido problema, quais os afetados, quais as conseqüências e sugerir possíveis soluções.
Acima de tudo, obteve-se, portanto, uma descrição do processo de negócio da empresa e de seu domínio. A descrição dos problemas a que o sistema se propõe a tratar são de grande valia, dado que auxiliam na definição dos requisitos de negócio e fornecem uma visão aplicada do sistema.
• Identificação dos Envolvidos
Nesta parte, procura-se definir os perfis dos usuários que irão não só utilizar a versão executável do sistema, como também auxiliar o analista a destrinchar o domínio sendo estudado. Desse modo, é conveniente descrever os perfis dos usuários, apontando suas responsabilidades, os resultados esperados e os critérios de sucesso, e o ambiente destes, delineando restrições físicas e sistemas/plataformas utilizados atualmente ou que possam ser utilizados no futuro.
Esta atividade é de extrema utilidade, visto que as informações aqui obtidas se farão necessárias à especificação de Requisitos Não-Funcionais e à etapa de Implantação, em que o sistema será delineado ao ambiente do usuário descrito já nesta parte.
• Requisitos de Negócio
Durante a etapa de Especificação de Sistemas, diversas visitas ao ambiente de trabalho da empresa serão feitas, dado que se faz necessário conhecer o processo de negócio, entender os problemas correntes, iniciar o entendimento do domínio e outros aspectos. Contudo, faz-se imperiosa uma reunião com os gerentes da empresa a fim de que sejam definidos os Requisitos de Negócio. Tais requisitos são necessidades que o fluxo de processo atual da empresa demanda, ou seja, são problemas de que os gerentes da empresa têm conhecimento e procuram resolvê-los.
Para cada requisito apontado e analisado na reunião, devem ser discriminadas as razões de cada problema, como são resolvidos atualmente (solução atual) e qual a solução que o cliente deseja ou precisa (solução proposta). Note-se que tal solução proposta é sob a óptica dos clientes.
É recomendável, ainda, listar tais requisitos de maneira que os de maior prioridade, ou seja, os que foram apontados mais vezes, venham antes. Torna-se de fácil percepção, portanto, que deve Torna-ser feita uma entrevista tanto com os clientes quando com os usuários. Ademais, o responsável por esta parte deve ser o Analista de Negócio, mais experiente e treinado para efetuar visitas ao ambiente da empresa e levantar problemas e necessidades.
• Tecnologia/Restrições Tecnológicas
Esta parte constitui o pilar sobre o qual a fase de Especificação de Sistemas está consolidada. Nesta, devem ser listadas e descritas minuciosamente quais as tecnologias que serão empregadas no desenvolvimento do sistema. Dessa forma, deve-se citar a linguagem, ferramentas CASE, ambientes de desenvolvimento integrado (IDE), arquitetura e outros a serem utilizados. Frameworks de desenvolvimento também devem ser citados.
Além de tais aspectos, devem ser citadas restrições tecnológicas que o próprio domínio da aplicação imponha.
• Visão da Solução
Após tais etapas de compreensão do problema, definição dos macro-requisitos e especificação das tecnologias a serem empregadas, deve-se descrever o sistema de uma maneira mais incisiva. A visão da solução é o cerne disto. Esta pode ser decomposta em:
o Descrição do Sistema: Listagem e descrição das características do sistema a ser implementado. Note-se que não ainda devem ser listados aqui os requisitos funcionais. É recomendado esboçar um Diagrama de Atividades com o fluxo para a possível solução para o sistema.
o Escopo do Sistema: O que será abrangido, isto é, delineado pelo
sistema. Dentre os Requisitos de Negócio apontados, citar aqueles que serão tratados pelo sistema.
o Fronteira do Sistema: Fazer um desenho que mostre a interface do sistema com pessoas, entidades externas ou outros sistemas. Faz-se de extrema importância na definição dos atores dos Casos de Uso.
o Benefícios Esperados: Listagem e descrição do conjunto de benefícios que são esperados com a solução proposta.
o Impactos do Sistema: Quais mudanças são esperadas acontecer
no ambiente de operação do sistema.
o Critérios de Aceite: Critérios definidos pelos clientes que serão utilizados para validar se o sistema está atendendo às expectativas e faz tudo aquilo que lhe foi proposto.
• Riscos
Deve-se destinar atenção especial aos riscos do projeto. Estes podem atrapalhar em demasia o andamento de um projeto ou até mesmo impedir a conclusão deste. Logo, os riscos do projeto devem ser listados e descritos. A sua descrição consiste no impacto que podem causar.
Postos tais preceitos sobre a etapa de Especificação de Sistemas, deve-se analisar a etapa de Especificação de Requisitos. Esta tem como objetivo levantar/coletar os requisitos do sistema, que são as características, as propriedades, necessárias no sistema.
Algumas técnicas para elicitação de requisitos são:
o Entrevistas Individuais: Consiste em entrevistas com os gerentes,
busca-se extrair os problemas correntes no processo de negócio, as necessidades de tais pessoas e seus desejos.
o Brainstorming e Brainwriting: O Brainstorming se caracteriza por
uma sessão de discussão da equipe de desenvolvimento em conjunto com os clientes e usuários, a fim de que idéias sejam geradas e sejam identificadas as necessidades dos clientes.
O Brainwriting é similar ao Brainstorming, porém, em vez de utilizar o meio oral, as pessoas expõem as suas idéias em pedaço de papel. Posteriormente, um membro da equipe lê todos os papéis, que não estão identificados, em voz alta e, então, a idéia é debatida. A vantagem é que pessoas mais tímidas podem participar de maneira ativa, ao passo que no Brainstorming não o podem. Além disso, no
Brainstorming boas idéias são geradas, mas, pelo fato de ninguém
tomar nota, são esquecidas.
o Reutilização de requisitos de projetos anteriores: Caso a empresa de desenvolvimento do software já tenha trabalhado com um domínio similar, então pode reaproveitar os requisitos levantados para tal projeto. Desse modo, economiza tempo e utiliza requisitos que indubitavelmente são consistentes.
o Estudo de documentos: Nesta abordagem, documentos do domínio
são estudados e analisados, a fim de que sejam identificadas as necessidades e restrições. Relatórios e formulários da empresa também são analisados.
Esta abordagem é vantajosa quando utilizada em conjunto com a Metodologia de Desenvolvimento Cleanroom, que é destinada a sistemas que possuem riscos de quebra de patente, e garante que os programadores vão fazer aquilo que foi especificado.
o Observação do ambiente de implantação: Consiste em fazer
visitas ao ambiente da empresa e observar o seu processo de negócio, como agem os seus funcionários e quais lacunas existem. Assim sendo, identifica os problemas e, conseqüentemente, as necessidades da empresa.
o JAD (Join Application Development): Há um coordenador e um
anotador. O coordenadora vai entrevistando os clientes e debatendo com eles acerca das funcionalidades, ao passo que o anotador vai registrando aquilo que estiver sendo gerado.
Os requisitos podem ser classificados de duas maneiras:
o Requisitos Funcionais: Correspondem ao que o sistema deve fazer, ou seja, suas funcionalidades; e
o Requisitos Não-Funcionais: São restrições impostas sobre como o
Os Requisitos Funcionais podem ser classificados de duas maneiras:
o Requisitos Funcionais Evidentes: São aqueles realizados com o
conhecimento explícito do usuário. Correspondem à troca de informação na fronteira do sistema, isto é, com o meio exterior; e
o Requisitos Funcionais Ocultos: São aqueles efetuados pelo sistema sem o conhecimento do usuário.
Por sua vez, os Requisitos Não-Funcionais podem ser classificados de duas maneiras: obrigatórios e desejados. Os obrigatórios são aqueles que invariavelmente devem ser implementados. Já os desejados são aqueles que podem ser implementados caso não causem maiores transtornos ao projeto.
Além disso, os requisitos não-funcionais podem ser classificados por características: de interface, de implementação, de eficiência, de tolerância a falhas, etc. Também podem ser classificados como permanentes (nunca mudará com o tempo) ou transitórios (pode sofrer alterações no futuro).
Mais especificamente, os requisitos não-funcionais podem possuir as seguintes categorias:
o Usabilidade: O sistema ser user-friendly, ser de fácil uso e aprendizado. Desse modo, deve fornecer menus de ajuda para o usuário e/ou manuais.
o Confiabilidade: É o fato de o sistema possuir tratamento de falhas.
Especifica quais falhas o sistema será capaz de gerenciar.
o Performance: São requisitos de eficiência e precisão que o sistema
apresenta.
o Configurabilidade: O que pode ser configurado no sistema.
o Segurança: São os níveis de acesso e a que funcionalidades cada um tem acesso.
o Implementação: A linguagem a ser utilizada e que bancos de dados estarão acessíveis.
o Interface: Especifica como deve ser a interface.
o Empacotamento: Especifica a forma como o software deve ser entregue ao usuário final.
o Legais: Quais os procedimentos que devem ser tomados para que não sejam infringidas normas e regras da área a que o sistema se propõe.
No que tange à organização dos requisitos, é interessante dividi-los em:
o Casos de Uso: As funcionalidades do sistema para que os usuários atinjam seus objetivos.
o Conceitos: Para cada conceito do domínio identificado, listar quais
as operações que podem ser realizadas em relação a ele, ou seja, inclusão, exclusão, alteração e consulta.
o Consultas: Acesso à informação do sistema que não altera o dado em si.
Dessa forma, o Diagrama de Casos de Uso passar a conter apenas as funcionalidades necessárias para que os atores, de fato, atinjam seus objetivos. Torna, pois, mais inteligível o diagrama, facilitando a visualização.
Cabe destaque aos Não-Requisitos (Requisitos Não-Contemplados), que são aqueles que foram analisados e revisados com os usuários e não serão implementados devido a problemas de custo, prazos ou outros. É importante ter isso documentado e assinado pelos clientes para que estes, futuramente, não cobrem algo que foi anteriormente acordado em relação ao não-desenvolvimento.
Por fim, a importância da especificação de requisitos é que esta estabelece o entendimento entre clientes e fornecedores da solução. Serve, também, como referência para a validação final dos produtos. Sabe-se, ainda, que o investimento na verificação de uma especificação tende a reduzir o custo total do projeto.
Ao término da especificação de requisitos, é gerado o documento conhecido como Documento de Requisitos de Software ou Especificação
de Requisitos de Software (Software Requirements Specification – SRS).
O apêndice “Documento de Requisitos de Software” serve como exemplo de um documento que pode ser gerado nas etapas supracitadas, isto é, de especificação de sistemas e requisitos.
A criação de modelos é de suma importância em tais etapas, a fim de seja obtido o entendimento do problema e que seja facilitada a comunicação entre os envolvidos no projeto. “Um modelo é uma simplificação da realidade que nos ajuda a entender um problema grande e complexo que não pode ser compreendido como um todo”. (Phillipe Krutchen, 2000).
Cabe citar os modelos gerados em tais etapas:
• Diagrama de Atividades: Tem como objetivo fazer uma representação do fluxo de trabalho (workflow) do processo de negócio da empresa a que o sistema se propõe a automatizar. Ademais, pode também ser utilizado para descrever o fluxo principal de um Caso de Uso que tenha complexidade considerável (crítico). Um exemplo de diagrama já foi exposto neste texto.
• Diagrama de Casos de Uso: Representa interações entre atores (pessoas, entidades externas, periféricos ou outros sistemas) e o sistema em questão, a fim de que seja realizada uma funcionalidade. Descreve, pois, os requisitos funcionais do sistema.
Garante o entendimento do requisitos e pode ser utilizado como uma espécie de “contrato” do sistema. Em outras palavras, ao término do desenvolvimento, o sistema tem estar realizando todas as funcionalidades que foram discriminadas no Diagrama de Casos de Uso. Um exemplo de tal diagrama sobre um Sistema de Gerência de Tarefas segue na próxima página:
• Modelo Conceitual: Descrevem os principais conceitos de um dado domínio, bem como suas propriedades e associações. Em uma visão mais aplicada, descreve quais serão as informações a serem guardadas no banco de dados. Os modelos conceituais mais disseminados são o
Diagrama de Entidade-Relacionamento (DER) e o Diagrama de Classes e Objetos. Um exemplo de Diagrama de Classes e Objetos referente a um
domínio de um Sistema de Gerência de Tarefas segue abaixo:
Pela análise realizada, torna-se fácil percepção que o investimento e a aplicação em uma especificação de sistemas e de requisitos bem feita é extremamente aconselhável, dado que tende a diminuir a incidência de falhas nas etapas posteriores do ciclo de vida de desenvolvimento. Ademais, seja citada esta estatística: custo de um erro na fase de projeto = 1 unidade; custo de um erro no início dos testes = 6.5 unidades; durante os testes = 15 unidades; depois de liberado o software = 60 a 100 unidades.
Bibliografia
1. BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro: Campus, 2002.
2. WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação
Orientados a Objetos. Rio de Janeiro: Elsevier, 2004.
3. Material didático do professor Asterio Tanaka, referente à disciplina de Modelagem de Sistemas, no período de 2005/2 do curso de Sistemas de Informação da UNIRIO. Disponível em: www.uniriotec.br/~tanaka/TIN0012. 4. Material didático da professora Renata Araújo, referente à disciplina de Análise e Projeto de Sistemas, no período de 2006/1 do curso de Sistemas de Informação da UNIRIO. Disponível em: www.uniriotec.br/~renata.araujo/APS. 5. Material didático do professor Leonardo Azevedo, referente à disciplina de Projeto e Construção de Sistemas com Ambiente de Programação, no período de 2006/2 do curso de Sistemas de Informação da UNIRIO. Disponível em: http://leogazevedo.googlepages.com/pcsap.
6. Notas de aula da disciplina de Modelagem de Sistemas, do curso de Sistemas de Informação da UNIRIO, ministrada pelo professor Asterio Tanaka no período de 2005/2.
7. Notas de aula da disciplina de Análise e Projeto de Sistemas, do curso de Sistemas de Informação da UNIRIO, ministrada pela professora Renata Araújo no período de 2006/1.
8. Notas de aula da disciplina de Projeto e Construção de Sistemas com Ambiente de Programação, do curso de Sistemas de Informação da UNIRIO, ministrada pelo professor Leonardo Azevedo no período de 2006/2.
