SWEBOK

Guide to the Software Engineering Body Of Knowledge

Teresa Maciel tmmaciel@gmail.com

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

Organizaes pblicas e privadas; Instituies de ensino da engenharia de software;

Pblico Alvo

Instituies certificadoras; Engenheiros de Software; Estudantes de Engenharia de Software; Educadores e Instrutores.

reas de Conhecimento SWEBOK

Requisitos de Software Design (Projeto) de Software Construo de Software Teste de Software Manuteno de Software Gerncia da Configurao de Software Gerncia do Desenvolvimento de Software Processo de Software Mtodos e Ferramentas de Engenharia de Software Garantia da Qualidade de Software

reas de Conhecimento SWEBOK

Requisitos de Software Design (Projeto) de Software Construo de Software Teste de Software Manuteno de Software Gerncia da Configurao de Software Gerncia do Desenvolvimento de Software Processo de Software Mtodos e Ferramentas de Engenharia de Software Garantia da Qualidade de Software

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

Requisitos No-Funcionais NoDesempenho Confiabilidade Manutenibilidade Usabilidade Portabilidade

Stakeholders
Stakeholder uma pessoa que ter alguma influncia direta ou indireta sobre os requisitos do sistema.

Engenharia de Requisitos de Software

Descobrir; Obter; Analisar; Especificar; Documentar; Verificar; Gerenciar.

Processo Bsico de Requisitos

Elicitar requisitos Analisar requisitos Especificar requisitos Validar requisitos

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

Domnio da Aplicao Necessidades e restries

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.

Adquirir conhecimento do contexto

Assimilar a organizao onde o sistema ser instalado, o domnio de aplicao do sistema e sistemas relacionados existentes.

Levantar os requisitos dos stakeholders

Informaes sobre os requisitos que faro parte do software.

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.

Adquirir conhecimento do contexto

Assimilar a organizao onde o sistema ser instalado, o domnio de aplicao do sistema e sistemas relacionados existentes.

Levantar os requisitos dos stakeholders

Informaes sobre os requisitos que faro parte do software.

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 Ativa do Usurio

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.

Caractersticas de uma Boa User Story

Independente Negocivel Valiosa para o cliente ou usurio Estimvel Curta Testvel

Prtica

Especificando Requisitos com User Stories

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.