O Desenvolvimento do Escopo de um Projeto de um Produto de Software

...

Nesse trabalho iremos desenvolver um escopo de um projeto para um produto para a ONG Jovens Ambientalistas que recolhe e oferece uma formação profissionalizante para jovens sem lar. Eles recebem cursos gratuitos de professores que já estiveram na mesma situação. Com isso eles têm uma mão de obra capacitada para prestarem serviços remunerados para fábricas de brinquedos, que tenham o conceito e a prática de ambientalmente correto, nos quais são vendidos no Brasil e no exterior.

Temos como proposta instalar uma solução para melhorar o controle das informações referente aos serviços, produtos e financeiro da instituição.

Iremos desenvolver a proposta baseado em seus problemas atuais de gestão e prever possíveis problemas futuros.

O desenvolvimento desse escopo irá nos ajudar a compreender melhor o fluxo do negócio do cliente, exibir as falhas e corrigi-las.

---------------------------------------------------------------

3 CONCEITOS GERAIS

3.1 Requisitos de Software

Atualmente, assumiu-se o conceito que requisitos não se trata apenas de funções que o software deve exercer, requisitos são também, os objetivos, propriedades, restrições que o sistema deve ter para atender contratos, padrões ou especificações de acordo com o que foi descrito pelo usuário. Como mencionado na introdução, um requisito é uma condição necessária para que o sistema alcance o objetivo desejado, de acordo com as especificações feitas pelo usuário.

Sendo assim, requisito é um aspecto que o sistema proposto deve fazer ou restringir no desenvolvimento do sistema, sempre tendo como base as especificações e as necessidades do usuário ou cliente. Então, podemos dizer também que, requisito é um acordo que é negociado entre as partes interessadas no projeto, para que o desenvolvimento seja bem definido e o objetivo final, o sistema, seja alcançado e opere com eficiência, atendendo as necessidades do usuário e sem problemas para a equipe de desenvolvimento de software.

Os requisitos tem como objetivos o estabelecimento e manuntenção de um acordo entre todas as partes interessadas no sistema, acordo esse que rege as funcionalidades desse sistema, as especificações, o que ele deve e o que não deve fazer. Tem como objetivo também, aplicar fronteiras ao sistema definindo o que deve e o que não deve fazer parte do sistema.

3.1.1 Classificação de Requisitos:

Existem os Requisitos Funcionais (RF) e os Requisitos Não Funcionais (RNF):

Os Requisitos Funcionais representam as funcionalidades do sistema, o que ele deve fazer e as suas informações.

Sendo assim, os requisitos funcionais são voltados as funções e os serviços oferecidos pelo sistema ao usuário, e principalmente como o sistema se comporta em determinadas situações.

Abaixo, temos alguns exemplos de requisitos funcionais de um sistema de um consultório médico:

[RF001] O sistema deve cadastrar médicos profissionais (entrada)[RF002] O sistema deve emitir um relatório de clientes (saída)[RF003] O paciente pode consultar seus dados no sistema

Já os Requisitos Não Funcionais representam os critérios que qualificam os requisitos funcionais, critérios esses que podem ser tanto qualidade de software, ou seja, requisitos de performance (usabilidade, confiabilidade, robustez, etc.), quanto de qualidade de processo de software (requisitos de entrega, implementação, etc.). Geralmente, os RNF são mensuráveis, existe a possibilidade de medi-los, então devemos preferencialmente associar sempre uma medida a cada RNF. Abaixo, temos alguns exemplos de RNF:

[RNF001] O sistema deve imprimir o relatório em até 5 segundos.

[RNF002] Todos os relatórios devem seguir o padrão de relatórios especificados pelo setor XYZ.

[RNF003] O sistema deve ser implementado em Java.

3.2 Engenharia de Requisitos

A Engenharia de Requisitos, se trata de um processo que abrange as atividades necessárias para o desenvolvimento do documento de requisitos, ou seja, têm como principal objetivo a identificação, o levantamento dos requisitos que serão definidos para o sistema a ser criado.

Lamsweerde (2000, p. 5) define ER como:

[...] a identificação dos objetivos a serem atingidos pelo futuro sistema, a operacionalização 3 de tais objetivos em serviços e restrições, e a atribuição de responsabilidades pelos requisitos resultantes a agentes humanos, dispositivos e software.

Esse processo, é composto por quatro atividades de alto nível: indentificação; análise e negociação; especificação e documentação; e validação.

3.2.1 Identificação:

O processo de Engenharia de Requisitos deve ser precedido de Estudo de Viabilidade, que á partir das restrições impostas ao sistema, visando o atendimento da solicitação do cliente, analisa-se a viabilidade do projeto. Caso se determine que o projeto seja viável, o passo seguinte é a identificação dos requisitos.

Algumas das atividades envolvidas nesta fase incluem:

Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas.

Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não funcionais) pretendidos para o sistema.

Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.

3.2.2 Análise e negociação dos requisitos

Após a identificação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação.

Algumas das atividades envolvidas na análise de requisitos incluem:

Classificação: agrupamento de requisitos em "módulos" para facilitar