domingo, 13 de julho de 2014

Leia mais um pouco sobre Requisitos Funcionais!

:: Requisitos Funcionais:: 
 São declarações de serviços que o sistema DEVE fornecer, como o mesmo deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações, sendo que em muitas vezes também podem explicar como o sistema DEVE ou não fazer.
 Exemplo:  
  •  o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal.
  • o software deve emitir relatórios de compras a cada quinze dias.
  • os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.  
 I. Especificação dos Requisitos Funcionais utilizando Casos de Uso 
Para realizarmos a especificação desses requisitos podemos criar nossos próprios templates, nossas próprias regras ou podemos contar com os vários templates existente no mercado ou podemos contar com o apoio dosCasos de Uso e sua especificação, que segundo Sommerville (2011), são técnicas de descoberta de requisitos introduzida inicialmente no método Objectory (Jacobson et al., 1993), que se tornaram uma característica fundamental da linguagem de modelagem unificada (UML – do inglês Unified modeling language).   
Os casos de uso são documentos utilizados pelos Diagramas de Caso de Uso da UML e representarão as funcionalidades do sistema. 

Pense no seguinte cenário:

  
 O dono do salão de beleza “Glamour” solicitou um Sistema de Cabeleireiro para sua empresa de desenvolvimento “AllDesenvol”, mas inicialmente ele quer apenas poder controlar o cadastro dos seus clientesserviços fornecidos e os produtos que o futuramente começará a vender e os profissionais que realizarão os serviços. E disse também que quem manipulará essas informações no sistema é a secretária, ou seja, para cada uma das funcionalidades acima ela realizará o CRUD (ver definição). 
  Vamos verificar como modelar isso utilizando o diagrama de caso de uso na Figura 1 abaixo?  
 Figura 1 - Diagrama de Caso de Uso 


 Fonte: Autor
 Vamos entender o Diagrama:  
  •  A secretária, representada por um homem palito, é o Ator do sistema, ou seja, o responsável pela a interação com o sistema. Mas, um ator pode ser uma pessoa (papéis) ou outros sistemas.
  •  E os casos de uso, “Controlar Cliente”, “Controlar Produto”,, “Controlar Serviço” e “Manter Profissionais” estão representados por uma elipse, sendo essas as funcionalidades do sistema, ou seja, aquilo que o sistema DEVE fazer. 
 E para especificação desses requisitos podemos utilizar um template, chamado “Especificação de Requisitos de Software” clique aqui para visualizar. Este template é fornecido pelo RUP (Processo Unificado da Rational). 
 O RUP é baseado nos conceitos da UML (saiba mais no Aprofundando Conhecimento), foi desenvolvido nos laboratórios da Rational e posteriormente a Rational foi adquirida pela IBM.  
Quando nos referimos a este documento como um template é porque o usuário terá a opção de acrescentar ou retirar informações. Veja um novo exemplo de especificação criado a partir do modelo do RUP, clique aqui
 Nota: Criamos um documento de especificação para cada Caso de Uso aqui representado, neste nosso exemplo teríamos que criar 4 documentos.  
Links importantes:

  :: Requisitos não-funcionais ::
 São restrições aos serviços ou funções oferecidas pelo sistema, que incluem restrições de tempo, no processo de desenvolvimento e também restrições impostas por normas/leis. Os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo. 
São exemplos de requisitos não-funcionais:  
  • a base de dados deve ser protegida para acesso apenas de usuários autorizados.
  • o tempo de resposta do sistema não deve ultrapassar 30 segundos.
  • o software deve ser operacionalizado no sistema Linux.
  • o tempo de desenvolvimento não deve ultrapassar seis meses. 
II. Validação de requisitos
              É o processo pelo qual se verifica se os requisitos elicitados definem o sistema que o cliente realmente quer. A validação também é importante, uma vez que o custo para remover erros de requisitos é grande, quando descobertos tardiamente. 
Durante o processo de validação de requisitos, diferentes tipos de verificação devem ser efetuados com os requisitos no documento de requisitos. Essas verificações incluem: 
  1.     Validade - O sistema fornece as funções que melhor atendem as necessidades de todos os usuários?
  2.     Consistência - Existem conflitos de requisitos?
  3.     Completeza - Todas as funções necessárias foram incluídas?
  4.     Realismo - Os requisitos podem ser implementados com a tecnologia e orçamento disponíveis?
  5.     Verificabilidade - Os requisitos podem ser checados?  
Uma série de técnicas de validação podem ser usadas individualmente ou em conjunto, tais como:   
  1.     Revisões de requisitos - é feita uma análise manual sistemática dos requisitos;
  2.     Prototipação - um modelo executável do sistema é demonstrado para os usuários finais para checar os requisitos;
  3.     Geração de casos de teste - os requisitos devem ser testáveis, para tal deve- se desenvolver testes para os requisitos a fim de verificar a testabilidade.  
Aprofundando ConhecimentoAPROFUNDANDO CONHECIMENTO
Na década de 90, Booch, Rumbaugh e Jacobson, conhecido como os 3 amigos, motivaram para criar uma linguagem de modelagem unificada, unindo as melhores características dos métodos citados e criaram a UML, no laboratório da Ratinal, conforme dito acima. Veja o experimento.
Mas afinal o que é a UML?
É uma linguagem gráfica para visualização, especificação, construção e documentação de artefatos de sistemas complexos de software (BOOCH, 2000). Segundo Bezerra (2007) é uma linguagem visual para modelar sistemas orientados a objetos. Independente tanto de linguagem de programação quanto de processo de desenvolvimento de SW. 
A UML possui 13 diagramas para apoiar no Processo de Desenvolvimento de Software, sendo estes divididos em Estruturais e Comportamentais. Saiba mais
 E que é a Orientação a Objetos?
Segundo Rumbaugh (1996) orientação a objeto trata-se de uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real, sendo o principal componente o objeto, que combina dados e comportamento.
 Histórico da linguagens orientadas a objetos:
  • 1966 – SIMULA (Kristen Nogaard, Noruega);
  • 1980 – SMALLTALK (Xerox);
  • 1986 – C++  (AT&T), SMALLTALK V , OBJECTIVE-C;
  • 1988 – EIFFEL (Meyer, França);
  • 1989 – Turbo Pascal 5.5 (Borland);
  • 1995 – JAVA;

Características da OO:
  • Reusabilidade: Reutilização de componentes de software e diminuição do tempo de desenvolvimento.
  • Manutebilidade: Mudanças bem localizadas, não acarretando propagações descontroladas.
  • Confiabilidade: O encapsulamento permite um maior controle e segurança às classes dos objetos.
  • Extensibilidade: Extensibilidade é a medida da facilidade em se adicionar novas funcionalidades (operações) a um componente de uma modelagem existente.

    Saiba mais>>

Nenhum comentário:

Postar um comentário