Uma Análise de Requisitos

...

software sendo considerado um processo, deverá ser desenvolvido a partir de vários sub-processos, se tornando com isso mais rápido e fácil.

Para o desenvolvimento de processos ou um software como um todo, é necessário definir formas que permitam que esses processos sejam concluídos. Essas formas são chamadas de métodos. Ou seja, as várias formas que existem para o desenvolvimento de um processo, onde são utilizadas várias ferramentas para a construção do software.

Resumo 1.2 – Engenharia de Requisitos

Requisitos são considerados um fator determinante para o sucesso ou fracasso de um projeto de software. Chama-se de Engenharia de Requisitos o processo de levantar, analisar, documentar, gerenciar e controlar a qualidade dos requisitos.

Muito se fala sobre requisitos, se propagam as necessidades atendimento ao cliente, de gestão de mudanças, fala-se sobre métodos, ferramentas e técnicas para descrição e representação, mas pouco se comenta sobre a prática na aplicação deste conhecimento, onde o requisito é uma condição satisfatória.

Se a condição que deve ser satisfatória, deve-se produzir algo, diz-se com isso que o requisito é funcional. Se a condição é caracterizar algo (atributo, propriedade, comportamento, restrição, etc.), diz-se que o requisito é não funcional.

Descrever requisitos funcionais e requisitos não funcionais requer uma abordagem holística, tratando os aspectos primordiais que são: "Produzir", "Com qualidade".

O processo de produção de software é dependente da definição de qual produto devemos construir fundamentados no conhecimento do problema e na viabilização de oportunidade de negócio com o uso de tecnologia da informação.

O entendimento sobre o que é o projeto, é um fator determinante para definir o ciclo de vida de um produto a ser construído e, por conseguinte, a identificação e descrição dos requisitos.

Portanto, perguntas como: “o quê?”, sobre qual o papel desempenhado, “quem?” Sobre a responsabilidade de quem, “quando?”, no momento oportuno, no contexto em estudo e com o domínio da aplicação “onde?”, “de que forma?” e, principalmente, “por quê?”, ao identificá-los, torna-se certo o sucesso de um projeto, independe de sua complexidade, que é determinada parcialmente por suas funcionalidades (requisitos funcionais), isto é, "o quê" o sistema faz e, parcialmente, pelos requisitos globais dos custos de desenvolvimento e de custos operacionais, já os (requisitos não funcionais) "do que é" e "do que faz", relativamente à precisão, desempenho, segurança, confiabilidade, portabilidade, resposta ao usuário, restrições, premissas, entre outros.

Podemos dizer que os requisitos de um sistema possuem as especificações dos serviços que o sistema deve prover restrições nas quais ele deve operar propriedades gerais do sistema e restrições que devem ser satisfatórias em seu processo de desenvolvimento.

Uma classificação bem aceita quanto ao tipo de informação documentada por um requisito faz uma única distinção entre requisitos funcionais e requisitos não funcionais, os quais são definidos como:

• Funcionais: são declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer, podendo descrever, ainda, como o sistema deve reagir a entradas específicas, como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007). Este requisito descreve uma interação entre o sistema e o seu ambiente.

• Não Funcionais: descrevem restrições sobre os serviços ou funções oferecidas pelo sistema, podendo descrever, ainda, como o sistema deve reagir a entradas específicas, como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007).

Neste sentido, os requisitos não funcionais são muito importantes para a fase de projeto, servindo como base para a tomada de decisões nessa fase. Os requisitos não funcionais têm origem nas necessidades dos usuários, em restrições de orçamento, em políticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislações (SOMMERVILLE, 2007).

Requisitos funcionais são identificados a partir do ponto de vista do usuário.

Requisitos Não-Funcionais determinam características desejáveis do software com relação ao seu desempenho, confiabilidade, segurança, portabilidade (entre muitos outros).

3. Listagem Informal dos Requisitos Obtidos

1. Cadastrar alunos e funcionários;

2. Cadastrar livros e revistas, periódicos e jornais;

3. Administrar os empréstimos as devoluções e reservas;

4. Os alunos serão cadastrados por seus números de matriculas (RA), que serão confirmados pelo funcionário que estiver operando o sistema;

5. Os funcionários serão cadastrados por seus números de matricula que serão utilizados no programa para a autorização da(s) retirada(s) do livro(s);

6. Os livros e revistas serão cadastrados por seus números de ID onde estará registrado o título, o autor, a editora e o código de barras;

7. Os periódicos e os jornais serão cadastrados por sua data de publicação e editora;

8. Os controles das reservas serão realizados através do título especificando a data que o livro estará disponível;

9. Os empréstimos e as devoluções serão feitos através da data de entrada e suposta data de retorno, ao ser excedida a data de devolução o aluno será cobrado por diária excedida.

4. Listagem de Requisitos Funcionais e Não Funcionais validados

4.1 Tabela 1. Requisitos Funcionais do Sistema Computacional da biblioteca da escola “BOM SABER_XY”

R1. O software deve permitir que o usuário efetue o cadastro (inclusão, exclusão e alteração)