Trabalho APS 6 Sesmetre Requisito de Software

Prévia do material em texto

UNIVERSIDADE PAULISTA
NOME DOS ALUNOS
 Chrysthyanne Robertha Rodrigues da Silva RA: A93684-0
 Cléber de Jesus cruz  RA: A9552E-8
 
 Guilherme Rodrigues de Souza
 
 João Paulo de Jesus Barbosa
“Especificação de Requisitos de Software”  
		
SÃO PAULO
2013
NOME DOS ALUNOS
 Chrysthyanne Robertha Rodrigues da Silva RA: A93684-0
 Cléber de Jesus cruz  RA: A9552E-8
 Guilherme Rodrigues de Souza
 João Paulo de Jesus Barbosa
“Especificação de Requisitos de Software” 
Trabalho Integrado do quinto
semestre no curso superior de
graduação Sistemas de Informação. Apresentado e avaliado pela Universidade Paulista- UNIP
 Orientador: (profº Gustavo). 
SÃO PAULO
2013
Sumário
1. objetivo do trabalho..............................................02 
2. introdução ..............................................................03 
3. conceitos gerais.......................................................
4. Requisitos de Software...............................................
5.  Engenharia de Requisitos............................................
7. Documento de Requisitos..............................................
8. Conclusão..................................................................
9. bibliografia..................................................................
Objetivo do trabalho
A especificação de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e orçamento adequados. Comprovado a maior parte dos problemas, os de maior impacto negativo e os mais onerosos tem origem nas etapas iniciais do desenvolvimento de software. Justamente nas etapas de especificação dos requisitos é onde as principais atividades são definidas e onde os requisitos do produto devem ser identificados e mapeados com objetividade e clareza. Os requisitos podem ser modelados e validados através de casos de uso que incluem o diagrama de casos de uso e a especificação do caso de uso. Um caso de uso representa uma funcionalidade completa, conforme percebida pelo ator e é definido como um conjunto de sequências de ações que um sistema executa que produzem um resultado observável por um particular ator. A técnica de análise de Pontos por Casos de Uso foi criada para permitir que seja possível estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dos próprios documentos gerados nesta fase de análise como subsídio para efetuar estimativas de tamanho, prazo e custo de software.
Introdução
A estimativa de tamanho é uma das métricas de software mais utilizadas, porque a partir dessa dimensão é possível definir o esforço, o prazo e os custos necessários para o desenvolvimento do software. Atualmente uma das métricas que está sendo testada e adotada nas empresas é a Pontos de Casos de Uso. Na última década, a mudança na tecnologia de comunicação com a popularização da internet influenciou profundamente os processos nas empresas exigindo novas metodologias de análise e desenvolvimento de sistemas de informação. As empresas precisam adequar seus sistemas atuais aos novos volumes de informação, tanto estratégicas quanto operacionais. Para alcançar estes objetivos, as empresas estão utilizando metodologias de desenvolvimento onde se torna necessário estimar o tempo das atividades do processo desde a fase de concepção até as fases de produção e testes. Isto tem exigido a adoção de métricas de estimativas de desenvolvimento de sistemas para medir o esforço e o tempo que um software produzirá. Com esta medição torna-se disponível uma métrica confiável na fase de especificação de requisitos do processo de desenvolvimento de software. Esta proposta visa enfatizar a importância da especificação de requisitos para o trabalho de medição de sistemas, minimizando o esforço dos líderes de projeto, obtendo uma compreensão intuitiva do porte do projeto em termos de Pontos por Função de maneira simples e dinâmica. Verifica-se que caso de uso e pontos por função podem ser usados juntos efetivamente para alcançar sucesso no gerenciamento dos requisitos e do projeto. A técnica de estimativa por Pontos de Caso de Uso foi proposta em 1993 por Gustav Karner, da Objectory (hoje, Rational Software). Ela baseia-se em dois métodos bastante utilizados - o mecanismo de Pontos de Função e uma metodologia conhecida como Mk II, uma adaptação da técnica de PFs. 
A forma de lançar uma estimativa é o principal diferencial da métrica por Casos de Uso: o método trata de estimar o tamanho de um sistema de acordo com o modo como os usuários o utilizarão, a complexidade de ações requerida por cada tipo de usuário e uma análise em alto nível dos passos necessários para a realização de cada tarefa. realizada a medição, poderá ser então feitas estimativas de custos e prazos de término do projeto ou entrega do produto final. O mais importante a ser ressaltado é que as métricas devem ser muitas bem feitas pelos gerentes de projetos e que devem ser mostradas de uma forma clara e que todos possam entender os resultados gerados. Feito isso, o resultado que se tem é um conjunto de dados que darão a idéia do processo e um entendimento do projeto. Permitirá aos Gerentes de Projetos de Software aperfeiçoar e melhorar o processo de desenvolvimento do produto e avaliar a qualidade do produto que está sendo produzido.
Conceitos gerais
Requisitos de Software
O software é uma parte de um sistema computacional mais abrangente e a Análise de Sistemas é uma atividade que serve para identificar os problemas do domínio, apresentar alternativas de soluções e o estudo da viabilidade de cada uma delas. Uma vez que se tenha feito a análise do sistema computacional, e delimitado o escopo do software, devem ser feitos os requisitos do software. 
O objetivo dos requisitos é especificar o que o sistema deverá fazer e determinar os critérios de validação que serão utilizados para que se possa avaliar se o sistema cumpre o que foi definido ou não. 
Requisitos podem ser comparados a objetivos ou restrições estabelecidas pelos clientes e/ou usuários que definem as suas diversas propriedades do sistema. Os requisitos de software são, dentre os requisitos de sistema, os que dizem respeito a propriedades do software. 
É possível definir um conjunto de requisitos como sendo uma condição necessária que o software deve possuir para que o usuário possa resolver um problema, atingir um objetivo ou ainda para atender as necessidades ou restrições da organização ou de outros componentes do próprio sistema. 
De uma forma simplificada, eles são separados em requisitos funcionais e não-funcionais, onde os requisitos funcionais são a descrição das diversas funções que clientes e/ou usuários querem ou precisam que o software possua. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema. 
Alguns exemplos de requisitos funcionais: 
* "o software deve calcular os gastos com despesas de viagens dos funcionários a cada semana". 
* "o software deve emitir relatórios de saída de material da empresa cada vez que houver uma movimentação de patrimônio". 
A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. É importante diferenciar a especificação de requisitos da especificação que ocorre durante o design do software. No design do software deve-se decidir quais a funções o sistema efetivamente terá para satisfazer àquilo que os usuários necessitam.Requisitos não-funcionais são as qualidades globais de um software, referente à manutenção, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa e são difíceis de validar. 
De acordo com sua procedência, os requisitos não funcionais podem ser classificados em: 
• Requisitos de produto: relacionados ao comportamento do produto tais como facilidade de uso, eficiência (desempenho, recursos exigidos), confiabilidade, portabilidade. 
• Requisitos organizacionais: relacionados às organizações do cliente e do fornecedor tais como práticas, padrões e restrições contratuais e de projeto. 
• Requisitos externos: relacionados a restrições impostas por fatores externos ao sistema tais como restrições de interoperabilidade, éticas e legais. 
Há muita dificuldade no que diz respeito à necessidade de se estabelecer os requisitos de forma precisa na medida em que o tamanho e a complexidade do software aumentam. Além disso, os requisitos exercem influência uns sobre os outros o que determina uma maior dificuldade no processo. Por exemplo, o requisito de que o software deve ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho não seja satisfeito. Devido à esta complexidade, faz-se necessário que as atividades associadas aos requisitos sejam gerenciadas durante todo o ciclo de vida do sistema. 
Há também os Requisitos de Domínio, que se originam do domínio da aplicação do sistema e que refletem características desse domínio (Podem ser requisitos funcionais e não funcionais) 
Engenharia de Requisitos
Um dos principais objetivos da engenharia de requisitos é melhorar a modelagem de sistemas e a capacidade de analisá-los, possibilitando maior entendimento de suas características antes da implementação (Robinson 2003). É seu papel realizar a interação entre requisitantes e desenvolvedores, entre “o que” deve ser feito e “como” deve ser feito. É necessário nesta etapa, elicitar, analisar conflitos, validar, priorizar, modificar e reusar requisitos, rastreá-los considerando sua origem, os componentes arquiteturais e o código que os implementa, dentre outras tarefas. 
A reutilização, evolução e rastreabilidade de requisitos estão intimamente relacionados à habilidade de gerenciar interações entre requisitos, que por sua vez, está relacionada à habilidade de separar e compor características, representando-as em modelos. Visto que, geralmente, um único tipo de modelo não é suficiente para explicitar todas as características do sistema, diferentes modelos são utilizados, tornando as informações espalhadas e entrelaçadas, também, em diferentes visões. Em engenharia de requisitos o uso de visões é extremamente importante porque com este artifício consegue-se representar e visualizar os requisitos, focando as características de interesse a cada momento do processo. O uso de visões também é uma maneira de abordar a separação de características. 
Assim, a engenharia de requisitos tem abordado o princípio de separação de características por meio de métodos de modelagem em conjunto com o uso de visões, com o intuito de prover facilidades para o reuso, rastreabilidade e evolução. 
O processo de definição de requisitos é definido por três atividades: 
Elicitação – Onde o engenheiro de requisitos utiliza de técnicas para descobrir os requisitos do sistema a ser desenvolvido. Algumas técnicas conhecidas são de leitura de documentos, observação, entrevistas, reuniões, engenharia reversa, entre outras. 
Modelagem – Utilizando-se dos conceitos de UML, as informações que forem obtidas através da fase de elicitação são organizadas a fim de obter o documento de requisitos (onde constam os requisitos funcionais e não-funcionais), e através dele os desenvolvedores se baseiam para construir a arquitetura e código do sistema. Por vezes é necessário voltar à fase de elicitação por conta de erros ou inconsistências na modelagem do sistema. 
Análise – Nesta etapa são analisados aspectos gerais da construção do sistema, como por exemplo: viabilidade, tempo, custo, reuso, dentre outros fatores. 
Na engenharia de requisitos, uma Visão é a representação do sistema inteiro sob a perspectiva de um conjunto de características relacionadas (IEEE St.1471). As visões são utilizadas como um modo de separar aas características do sistema e focá-las em uma de cada vez, sendo muito importantes no entendimento do funcionamento do sistema e necessárias durante o processo de desenvolvimento. 
A evolução de requisitos pode ocorrer, ou seja, pode haver a necessidade de alterar certos requisitos devido à sua volatilidade, sofrendo alterações para atender as expectativas dos requisitantes. 
O reuso na engenharia de requisitos ocorre em relação ao conhecimento sobre requisitos não funcionais, pois são características ou restrições impostas ao comportamento de um sistema, pois dão origem ou restringem diversas funcionalidades. 
Documento de Requisitos
Conclusão
Bibliografia
http://www.apinfo.com/artigo64.htm
http://www.governoeletronico.gov.br/biblioteca/arquivos/roteiro-de-metricas-de-software-do-sisp-versao-2.0
Anexos
Ficha de Atividades Práticas Supervisionadas