Escolar Documentos
Profissional Documentos
Cultura Documentos
DEINFO/UFRPE
Iniciativa do IEEE (Institute of Electrical and Electronics Engineers) Computer Society. (www.ieee.org) Propsito de criar um consenso sobre as reas de conhecimento da Engenharia de Software e seu escopo.
Promover uma viso consistente da Engenharia de Software no mundo; Caracterizar o contedo da disciplina de Engenharia de Software;
Objetivos
Classificar em tpicos a rea de conhecimento da Engenharia de Software; Prover uma fundao para o desenvolvimento do currculo, para certificao individual e para licenciamento de material.
3
Pblico Alvo
Requisitos de Software
Requisito de Software
Caractersticas que o produto de software dever apresentar para atender s necessidades e expectativas do cliente.
Requisito de Software
Podem ser categorizados em funcionais (relacionados a funcionalidades a serem implementadas); noou no-funcionais (relativos a caractersticas de segurana, desempenho e outros aspectos no inerentes funes do software).
9
Funcionais
Descrevem o que o sistema deve fazer
"o software deve possibilitar armazenar os pedidos de oramento" "o software deve possibilitar a consulta de alunos em uma disciplina
NoNo-Funcionais
Descrevem as restries e caractersticas na implementao dos requisitos funcionais
"o sistema deve permitir armazenar pelo menos 500 pedidos de oramento por ano" "o sistema operacional a ser adotado deve ser linux
Stakeholders
Stakeholder uma pessoa que ter alguma influncia direta ou indireta sobre os requisitos do sistema.
Gerenciar mudanas
Elicitar Requisitos
Descobrir, tornar explcito e assimilar todo conhecimento possvel sobre o requisito em questo, com base nas necessidades do cliente.
15
Elicitar Requisitos
Problema
Contexto de Negcio
Escopo da Elicitao
Entendimento do domnio da aplicao, conhecimento geral onde o sistema ser aplicado. Entendimento do problema, detalhes dos problemas especficos do problema do cliente onde o software ser aplicado deve ser entendido. Entendimento do negcio, como os sistemas interagem e contribuem de forma geral com os objetivos de negcio. Entendimento das necessidades e limitaes dos stakeholders do software, necessidades especficas das pessoas que requerem suporte do sistema no seu trabalho.
Atividades de Elicitao
Definir objetivos
Os objetivos organizacionais devem ser estabelecidos incluindo objetivos gerais do negcio, um descrio geral do problema a ser resolvidos porque o sistema necessrio e as limitaes do sistema.
Negociao de Requisitos
Priorizao de Requisitos
Os requisitos devem ser rankeados em termos de valor agregado ao negcio. O cliente prioriza os requisitos mais relevantes e estes so os candidatos a serem desenvolvidos primeiro.
Atividades de Elicitao
Definir objetivos
Os objetivos organizacionais devem ser estabelecidos incluindo objetivos gerais do negcio, um descrio geral do problema a ser resolvidos porque o sistema necessrio e as limitaes do sistema.
Tcnicas de Elicitao
Entrevistas Leitura de documentos Questionrios Participao ativa dos usurios Cenrios Observaes Reuso de requisitos Prottipos
Entrevista
Entendimento dos requisitos atravs de discusses com usurios. Vantagens: contato direto com o usurio e validao Imediata. Desvantagens: conhecimento tcito e diferenas de Cultura.
Leitura de Documentos
Abstraes Vocabulrio da aplicao Documentao Vantagens: facilidade de acesso e volume de informaes Desvantagens: disperso das informaes e volume de trabalho
Questionrios
Adequado quando existe conhecimento sobre o problema e grande nmero de clientes Do idia definida sobre como certos aspectos universo de informao/software so percebidos Possibilitam anlises estatsticas Vantagens: padronizao das perguntas e tratamento estatstico das respostas Desvantagens: limitao do universo de respostas e pouca iterao
Participao do Usurio
Incorporao dos usurios ao time de desenvolvimento. Vantagens: envolvimento dos clientes e usurios Desvantagens: possvel indisponibilidade do usurio.
Participao do Usurio
Etnografia uma tcnica das cincias sociais que se mostrou til no entendimento das processos reais realizados nos trabalhos. Os processo reais de trabalho geralmente diferem daqueles processos formais descritos. Um etngrafo passa algum tempo observando as pessoas no trabalho e constri uma imagem de como o trabalho realizado.
Reuso de Requisitos
Reuso envolve considerar requisitos que foram desenvolvidos para um sistema e us-los em sistemas diferentes. O reuso de requisitos economiza tempo e esforo, pois requisitos reutilizados j foram analisados e validados em outros sistemas. Atualmente o reuso de requisitos um processo informal. Contudo, um reuso mais sistemtico economizaria muito esforo.
Prottipos
Um prottipo uma verso inicial de um sistema que poder ser usado para experimentao. Atravs deles, os usurios podero experimentar com o software ir interagir e identificar pontes fortes e fracos. O desenvolvimento rpido dos prottipos essencial para que eles fiquem disponveis logo para o processo de elicitao .
Anlise de Requisitos
Est de acordo com os objetivos de negcio O requisito consistente com os objetivos de negcio definidos na introduo do documento de requisitos? Ambigidade de requisitos O requisito ambguo, isto poder ser lido de forma diferente por pessoas diferentes? Quais so as possibilidades de interpretao dos requisitos? Teste dos requisitos Podemos testar os requisitos, ou seja, eles foram escritos de tal forma que um engenheiro de teste poder derivar o teste que mostrar se o sistema satisfaz os requisitos?
Anlise de Requisitos
O objetivo da anlise descobrir problemas, incompletude e inconsistncia nos requisitos elicitados. A anlise intercalada com elicitao pois problemas so descobertos quando os requisitos so elicitados
Anlise de Requisitos
Cenrios Casos de Uso Estrias de Usurios
User Story
Tcnica para identificao e especificao de requisitos. Uma ou duas frases, escrita pelo usurio na sua linguagem, sobre algo que a aplicao deve fazer.
User Story
Normalmente um cliente escreve as histrias e as apresenta na reunio de planejamento inicial e posteriormente sero detalhados. Em uma segunda reunio de planejamento detalhados os desenvolvedores fazem perguntas para o cliente para entender melhor do que cada estria se trata. Ao longo do desenvolvimento os desenvolvedores devem voltar ao cliente e pedir mais detalhes de qualquer dvida que tenham.
User Story
As estrias de usurios podem guiar tambm os testes de aceitao, j que seu objetivo ajudar o cliente a validar se o trabalho desenvolvido est de acordo com o que havia sido pedido. Para o cliente no interessa se a comunicao com o banco de dados est correta ou se a integrao entre duas classes foi bem sucedida, o que importa confirmar que a aplicao sendo desenvolvida est de acordo com o que ele espera ter em produo no futuro.
User Story
As estrias de usurios podem guiar tambm os testes de aceitao, j que seu objetivo ajudar o cliente a validar se o trabalho desenvolvido est de acordo com o que havia sido pedido. Para o cliente no interessa se a comunicao com o banco de dados est correta ou se a integrao entre duas classes foi bem sucedida, o que importa confirmar que a aplicao sendo desenvolvida est de acordo com o que ele espera ter em produo no futuro.
User Story
A idia usar papel e caneta, as ferramentas mais simples possveis, para se gerenciar as estrias. As estrias estarem em cartes tem vrias vantagens. Primeiro, o espao para escrever limitado e ningum vai tentar colocar detalhes em excesso nela.
Cartes
Aps serem preenchidos com as estrias, os cartes ficam pregados em quadros e so movidos de acordo com seu status no iniciado, em andamento e pronto, por exemplo. Olhar para o quadro uma maneira intuitiva e eficiente de se saber como anda um projeto, fcil perceber em que categoria os cartes esto se acumulando.
Cartes
Aps serem preenchidos com as estrias, os cartes ficam pregados em quadros e so movidos de acordo com seu status no iniciado, em andamento e pronto, por exemplo. Olhar para o quadro uma maneira intuitiva e eficiente de se saber como anda um projeto, fcil perceber em que categoria os cartes esto se acumulando.
Prtica
Bibliografia de Apoio
Software Enginnering Body of Knowledge SWEBOK, IEEE. Engenharia de Software, Roger Pressman. Engenharia de Requisitos, Ian Sommerville. User Stories Applied: For Agile Software Development, Mike Cohn.