Introducao A Requisitos

Tpicos em SI
Introduo Requisitos de Software
Roteiro
Fundamentos Requisitos de Software Critrios de Qualidade de Requisitos Atributos de Requisitos Documentos de Especificao de Requisitos Dificuldades Associadas a Requisitos Processos de Engenharia de Requisitos Elicitao de Requisitos Anlise de Requisitos Especificao de Requisitos Avaliao de Requisitos Gerncia de Requisitos Exemplos de Boas Prticas Alguns Segredos
Roteiro
Fundamentos
Engenharia de Requisitos (ER) media interesses de adquirentes e fornecedores Resultado: hierarquia de requisitos
Entendimento pr-acordado entre stakeholders Validao contra necessidades do mundo real Referncia para implementao do produto Base para verificao de designs e aceitao de solues
Fundamentos
Engenharia de Requisitos (ER) media interesses de adquirentes e fornecedores Resultado: hierarquia de requisitos
Entendimento pr-acordado entre stakeholders Validao contra necessidades do mundo real Stakeholders: interessados, envolvidos Referncia para implementao do produto - usurios Base para verificao de designs e aceitao de solues
- adquirentes - fornecedor/desenvolvedor/mantenedor - entidades regulatrias ...
Fundamentos
Intenes dos stakeholders (necessidades)
Fundamentos
Intenes dos stakeholders (necessidades)
Muitas vezes, falta s necessidades: - Definio clara - Anlise - Consistncia - Viabilidade
Fundamentos
Intenes dos stakeholders (necessidades) Sentenas mais formais
Fundamentos
Requisitos de stakeholders
Fundamentos
Requisitos de sistema
Fundamentos
Requisitos de componentes de sistema
Requisitos de sistema
Roteiro
Requisitos de Software
Qual o significado de requisito?
Segundo o Dicionrio Aurlio

(1) Condio necessria para a obteno de certo objetivo Para ingressar no programa de mestrado da UFMS preciso ter um diploma de graduao reconhecido pelo MEC (2) Exigncia legal Para se emitir uma carteira de motorista para um brasileiro ele deve ter 18 anos de idade, ou mais
Um requisito de um produto
uma sentena que traduz ou expressa uma necessidade, e suas restries e condies associadas Pode ser escrito em linguagem natural Cuidado com as palavras!
ISO/IEC/IEEE 29148:2011
uma sentena que traduz ou expressa uma necessidade, e suas restries e condies associadas Pode ser escrito em linguagem natural Cuidado com as palavras! Restries: limitam o projeto da soluo
ou o processo de engenharia. Exemplos: interfaces com outros sistemas existentes, limitaes de tamanho fsico, leis, plataformas tecnolgicas...
uma sentena que traduz ou expressa uma necessidade, e suas restries e condies associadas Pode ser escrito em linguagem natural Cuidado com as palavras!
Condies: atributos quantitativos ou qualitativos, mensurveis, que so estipulados para um requisito.
Algumas sintaxes possveis:

[Condio] [Sujeito] [Ao] [Objeto] [Restrio]

[Condio] [Sujeito] [Ao] [Objeto] [Restrio]
Quando o sinal x recebido, o sistema deve configurar o bit do sinal x recebido dentro de 2 segundos.

[Condio] [Ao ou Restrio] [Valor]

[Condio] [Ao ou Restrio] [Valor]
No mar com estado 1, o sistema de radar deve detectar alvos a distncias de at 100 milhas nuticas.

[Sujeito] [Ao] [Valor]

[Sujeito] [Ao] [Valor]
O Sistema de Faturamento, deve mostras as faturas pendentes de clientes em ordem descendente de data pagamento.
Roteiro
Critrios de Qualidade de Requisitos
Cada requisito deveria ser, individualmente

Necessrio Vivel Correto Conciso No ambguo Completo Consistente Verificvel Explicitar os requisitos quantitativamente: nada de palavras como fcil, muito, frequentemente... Rastrevel
Cada requisito deveria ser, individualmente:

Alocado a algum componente Independente de design ou de implementao No redundante Exposto usando conceitos padro Exemplo: uso do verbo dever Associado com um nico identificador Desprovido de clusulas de escape No incluir termos especulativos ou genricos como geralmente, frequentemente, tipicamente, muito, fcil

Exemplo de mtricas que ajudam os requisitos a serem verificveis:
Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Robustez Portabilidade
Mtrica Transaes processadas/seg Tempo de resposta do usurio/evento K bytes Tempo de treinamento Nmero de quadros de ajuda Tempo mdio entre falhas Taxa de ocorrncia de falhas Tempo de reincio aps falha Percentual de eventos causando falhas Probabilidade de corrupo de dados aps falha Percentual de declaraes dependentes do destino Nmero de sistemas destino
O conjunto de requisitos de um sistema deveria ser
Completo Consistente Bem delimitado Vivel
Critrios para a linguagem na formalizao dos requisitos
Foco em o qu fazer e no em como fazer Evitar termos gerais e vagos:

Superlativos: melhor, maior

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo Pronomes vagos: isso, aquilo

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo Pronomes vagos: isso, aquilo Advrbios e adjetivos ambguos: quase sempre, significativo, mnimo

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo Pronomes vagos: isso, aquilo Advrbios e adjetivos ambguos: quase sempre, significativo, mnimo Termos em aberto, no verificveis: fornecer suporte, no limitado a, no mnimo

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo Pronomes vagos: isso, aquilo Advrbios e adjetivos ambguos: quase sempre, significativo, mnimo Termos em aberto, no verificveis: fornecer suporte, no limitado a, no mnimo Frases comparativas: melhor que, de maior qualidade

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo Pronomes vagos: isso, aquilo Advrbios e adjetivos ambguos: quase sempre, significativo, mnimo Termos em aberto, no verificveis: fornecer suporte, no limitado a, no mnimo Frases comparativas: melhor que, de maior qualidade Vlvulas de escape: se possvel, conforme apropriado, conforme aplicvel

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo Pronomes vagos: isso, aquilo Advrbios e adjetivos ambguos: quase sempre, significativo, mnimo Termos em aberto, no verificveis: fornecer suporte, no limitado a, no mnimo Frases comparativas: melhor que, de maior qualidade Vlvulas de escape: se possvel, conforme apropriado, conforme aplicvel Referncias incompletas

Superlativos: melhor, maior Linguagem subjetiva: amigvel, fcil de usar, efetivo Pronomes vagos: isso, aquilo Advrbios e adjetivos ambguos: quase sempre, significativo, mnimo Termos em aberto, no verificveis: fornecer suporte, no limitado a, no mnimo Frases comparativas: melhor que, de maior qualidade Vlvulas de escape: se possvel, conforme apropriado, conforme aplicvel Referncias incompletas Sentenas negativas
Roteiro
Atributos de Requisitos
Algumas caractersticas que todos requisitos deveriam ter
Identificao nica Priorizao definida pelos stakeholders Dependncias esclarecidas Riscos conhecidos e analisados Fonte conhecida Base lgica esclarecida (motivao, modelagem, simulao) Dificuldade estimada Tipo identificado (funcional, no-funcional, de processo, restrio)
Tipos de Requisitos
Requisitos Funcionais
Servios que o sistema deve fornecer Como o sistema deve reagir a determinadas entradas Como o sistema deve se comportar em determinadas situaes O que o sistema no deve fazer
Requisitos No-Funcionais
No especificam funes especficas Restries sobre os servios ou funes fornecidos pelo sistema Geralmente no se associam a funes especficas se aplicam ao sistema como um todo
Tipos de Requisitos
Requisitos Funcionais
O usurio deve ser capaz de realizar buscas tanto em todo o conjunto inicial de bases de dados ou escolher apenas um subconjunto A cada pedido deve ser atribudo um identificador nico, o qual o usurio deve ser capaz de copiar para a rea de armazenamento permanente da conta
Suportar pelo menos 20 transaes por segundo Ser demonstrvel para o pblico cliente da biblioteca em no mximo 10 minutos
Se um requisito funcional no atendido pode ser que outras partes do sistema ainda sejam teis Se um requisito no-funcional no atendido provavelmente o sistema inteiro no ser til
Tipos de Requisitos
Se um sistema de uma aeronave no satisfaz requisitos de confiabilidade, provavelmente no ser considerado seguro para operao Se um sistema de controle de tempo real deixa de satisfazer seus requisitos de desempenho, no ir operar adequadamente para o uso pretendido
Obs.: apesar disso, no to difcil esquecer de falar dos requisitos no-funcionais
Requisitos de Produto
Especificam comportamento do produto Requisitos de desempenho, eficincia, confiabilidade... Ex.:Toda consulta ao banco de dados baseada em cdigo de barras no deve exceder 5s
Requisitos Organizacionais
Derivados de polticas e procedimentos Padres de processos, mtodo de design e implementao, data de entrega... Ex.: Todos os documentos entregues devem seguir o padro de relatrios XYZ-00
Requisitos Externos
Derivados de fatores externos ao sistema e ao processo de software Legislao... Ex.: O sistema no deve usar informaes pessoais do usurio com os operadores do sistema
Requisitos de Implementao
Definem como o sistema deve ser implementado Exemplo: O sistema precisa estar disponvel na Web
Requisitos de Desempenho
Restries sobre a velocidade de execuo Exemplo: O sistema deve atender pelo menos 10 transaes por segundo
Requisitos de Usabilidade
Descrevem como o sistema deve ser usado As funes disponveis para o pblico devem ser demonstrveis em menos de 10 minutos
Requisitos de Segurana
Restries sobre o acesso e a guarda do software Exemplo: O acesso ao sistema deve ser controlado por senha
H vrias outras classificaes de requisitos

Requisitos de documentao, de dados, de interface, de qualidade (eficincia, usabilidade, manutenibilidade, confiabilidade e portabilidade), de ambiente fsico...
Roteiro
Documentos de Especificao de Requisitos

Especificaes so definies que descrevem vrias perspectivas do software
Viso macroscpica: Especificao de Requisitos Representaes intermedirias: Artefatos de Design Viso detalhada: Cdigo de Programas, DDL, etc.
Uma especificao de requisitos deve

Ser a base para o desenvolvimento Permitir o controle de qualidade do produto Estabelecer a comunicao entre o pessoal envolvido no projeto Auxiliar no entendimento do problema Validar o design e o produto resultante
Documento de Viso define o escopo

Qual o problema que queremos resolver com o produto? Quais so as causas para que o problema exista? Como o problema afeta os envolvidos no projeto? Quem so os usurios do sistema? Quais os benefcios que o produto trar para os usurios? Por que o produto precisa ser desenvolvido? Quem ser afetado pelos produtos do sistema? Quem ir avaliar e aprovar o sistema quando ele for implantado? Existe algum outro usurio interno ou externo cujas necessidades tambm sero atendidas? Com quais sistemas j existentes o novo produto deve interagir?

H um padro para documento de requisitos: IEEE 8301.Introduo
1.Propsito do documento de requisitos 2.Escopo do produto 3.Definies, acrnimos e abreviaes 4.Referncias 5.Viso geral do restante do documento 2.Descrio Geral 1.Perspectiva do produto 2.Funes do produto 3.Caractersticas do usurio 4.Restries gerais 5.Suposies e dependncias 3.Requisitos Especficos 4.Apndices 5.ndice

Sugere sete formas de organizar o captulo 3 do documento Cada forma est associada a um critrio especfico
Modo (de operao, utilizao, etc...) Classe de usurio Objeto Facilidade (feature) Estmulo Hierarquia funcional Mltiplos critrios Facilidade + classe de usurio + ...

3.Requisitos especficos 1.Requisitos de interfaces externas 1.Interfaces com o usurio 2.Interfaces de hardware 3.Interfaces de software 4.Interface de comunicao 2.Requisitos funcionais 3.Requisitos de desempenho 4.Restries de projeto 5.Atributos do sistema de software 6.Outros requisitos
Roteiro
Dificuldades Associadas a Requisitos

Estabelecer uma compreenso homognea na equipe de desenvolvimento Refletir as reais necessidades dos usurios e do negcio Modificar requisitos que j foram acordados Impreciso na especificao de requisitos a causa de muitos problemas de engenharia de software
natural para um desenvolvedor interpretar um requisito ambguo mas no correto!
O que fazer???
Engenharia de Requisitos!
Roteiro
Processos de Engenharia de Requisitos

A Engenharia de Requisitos um processo de descobrimento, refinamento, modelagem e especificao de Sistemas Baseados em Computador Define as caractersticas operacionais do software
Aquisio de Sistema
Engenharia de Requisitos
Projeto de Sistema
O objetivo do Processo de Engenharia de Requisitos criar e manter um documento de requisitos de sistema H dois processos no MPS.BR relacionados com Engenharia de Requisitos
Desenvolvimento de Requisitos Criar O propsito do processo Desenvolvimento de Requisitos estabelecer os requisitos dos componentes do produto, do produto e do cliente Gerncia de Requisitos Manter O propsito do processo Gerncia de Requisitos gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto

A Engenharia de requisitos contm cinco grandes reas
Elicitao Identificar/descobrir os requisitos Anlise Modelar e negociar os requisitos Especificao Documentar os requisitos Avaliao Validar os requisitos Gerncia Cuidar dos requisitos
Roteiro
Elicitao de Requisitos
Antes que os requisitos possam ser analisados, modelados ou especificados eles precisam ser identificados e reunidos A meta reconhecer os elementos bsicos do problema tal como so percebidos pelos clientes e usurios Para isto preciso
Entender o problema Revisar o escopo
As principais atividades relacionadas com a elicitao de requisitos so
Descoberta de requisitos Interao com os stakeholders para identificar os requisitos Classificao e organizao dos requisitos Estruturao do conjunto de requisitos identificados Priorizao e negociao dos requisitos Identificao e resoluo de conflitos Identificao dos requisitos mais importantes Documentao dos requisitos Registro dos resultados Formal ou informal
Podem existir vrias fontes de requisitos para um determinado sistema
Informaes do domnio Stakeholders Sistemas com os quais far interface Sistemas semelhantes Leis, regulamentos, padres Ambiente operacional
um trabalho rduo, por vrias razes

Stakeholders muitas vezes no sabem o que querem do sistema de forma especfica Stakeholders geralmente se expressam nos seus prprios termos e de acordo com o conhecimento implcito que tm do seu trabalho pode implicar em requisitos implcitos Stakeholders diferentes tm requisitos diferentes possivelmente conflitantes Fatores polticos podem influenciar os requisitos O ambiente em que a anlise de requisitos ocorre dinmico Mudanas de prioridades Novos requisitos
Um fornecedor de requisitos adequado CRACK
C Collaborative colabora com a equipe R Representative pode falar por todos stakeholders A Authorized tem autoridade para falar C Commited est comprometido com o projeto K Knowledgeable conhece do que fala
H vrias tcnicas disponveis Entrevistas
Questes sobre o sistema Entrevistas fechadas x abertas No deveria ser usada para obter informaes sobre o domnio No deveria ser a nica forma de obter requisitos
Anlise de documentos
Extremamente importante na manuteno de sistemas Documentao de usurio e de sistema Procedimentos formais Estudos (associados ao negcio)
Brainstorming
Gerar ideias identificar o nmero mximo de ideias possvel Reduzir ideias avaliar as ideias, identificando aquelas de maior interesse para o grupo Encoraja originalidade e ideias no usuais
Workshops
Muito interessantes quando h vrios stakeholders Podem ser realizados com o intuito de obter consenso Sentimentos de comprometimento com o projeto e de trabalho em equipe Custam menos do que mltiplas entrevistas H workshops especiais na literatura de Engenharia de Requisitos JAD, FAST
Prototipagem
Construo de uma verso do sistema que pode ser analisada quanto ao que se deseja no sistema Pode promover a ideia de que o projeto est mais adiantado do que o real
Storyboards
Conjunto de desenhos que ilustram um conjunto de atividades de usurios que ocorrem em um sistema existente ou proposto So como prottipos de papel
Cenrios e Casos de Uso
Cenrios so descries de uma ou mais interaes com o teis sistema para descobrir detalhes sobre os requisitos inicia-se com um outline e finaliza-se com uma descrio detalhada da interao Informaes importantes: situao inicial, passos tpicos, passos alternativos, excees, estado do sistema ao fim Casos de uso so uma tcnica baseada em cenrios
Etnografia
Tcnica observacional que pode ser usada para entender requisitos organizacionais e sociais Imerso no dia-a-dia do ambiente em que o sistema ser inserido Ajuda a ver processos reais em contraste com processos formais
Roteiro
Anlise de Requisitos
Envolve modelagem e negociao de requisitos Criamos modelos para obter maior entendimento da entidade real a ser construda Duas vises
Essencial Funes a serem realizadas e informao a ser processada Abstrai os detalhes de implementao De implementao Forma de atendimento dos requisitos por meio de funes de processamento e estruturas de informao
Modelos de requisitos deveriam focar a essncia
Modelagem conceitual
Modelagem conceitual
Apoio na compreenso do problema e no no design Modelos de entidades do domnio do problema de forma a refletir seus relacionamentos e dependncias no mundo real
H vrios tipos de modelos e as escolhas de quais usar depende muito da situao O importante saber que...
O valor de um modelo depende da viso adotada, mas nenhum o melhor para todos os propsitos
e que...
Todos modelos so errados. Alguns so teis
Exemplos de vises
Dados estruturas de dados e relacionamentos entre dados Processos atividades, interconexes Estados estados e eventos associados Estrutura objetos, classes, componentes Comportamento Interfaces, mensagens
UML Unified Modeling Language
Roteiro
Especificao de Requisitos
Registro formal dos requisitos Requisitos de usurio Documento de viso, ConOps Requisitos de sistema IEEE 830
Roteiro
Avaliao de Requisitos
Avaliar e validar os requisitos

Encontrar problemas com os requisitos Ver se os requisitos realmente definem o que se quer
Relevncia mais caro consertar um problema inserido na fase de requisitos do que nas demais Os critrios de qualidade de requisitos so teis aqui! adequado conduzir revises formais para avaliar os requisitos
Roteiro
Gerncia de Requisitos
Pontos principais
Aceitao e comprometimento com os requisitos Validao dos requisitos Uso de critrios objetivos Rastreabilidade de requisitos Relacionamentos entre requisitos e demais produtos de trabalho Verificao de consistncia Avaliao da consistncia entre requisitos e demais produtos de trabalho Controle de mudana Avaliao da mudana Monitoramento da implementao da mudana
Conceitos importantes
Rastreabilidade bidirecional Rastreabilidade vertical x horizontal
O registro da rastreabilidade relevante para...

A manuteno de um sistema A anlise de impacto em mudanas
Mudanas de requisitos...
so uma constante
Mudanas no podem ser feitas de qualquer jeito
preciso analisar o impacto de uma mudana no sistema Verificar se todos os envolvidos (stakeholders) concordam Avaliar a dimenso da mudana preciso negociar viabilidade e comprometimento! preciso acompanhar de perto a mudana Garantir que tudo que tinha que ser mudado de fato foi mudado Garantir que nada alm do que deveria ser mudado foi mudado
Roteiro
Exemplos de Boas Prticas
Definir uma estrutura de documento padro Definir precisamente termos bsicos Usar cenrios para elicitar requisitos Identificar univocamente cada requisito Especificar requisitos quantitativamente Usar listas de verificao para anlise e validao Estabelecer polticas para gerncia de requisitos Reutilizar requisitos de outros projetos
Exemplos de Boas Prticas

Melhorar continuamente o processo Entender o problema antes de comear a documentar modelos Desenvolver prottipos que auxiliem ao usurio visualizar como seus requisitos sero atendidos Registrar a origem e a justificativa de cada requisito Utilizar mltiplas vises dos requisitos Priorizar requisitos Trabalhar para eliminar ambigidade
Roteiro
Alguns Segredos
Metade das caractersticas fornecidas na maioria dos softwares entregues no utilizada nem uma nica vez Mais da metade do esforo na maioria de projetos de sistema e de software perdido 80% dos erros encontrados durante o teste de sistema so resultado de fatos incorretos ou omisses de requisitos Gastar muito esforo em teste pode enganar melhor investir mais em um processo efetivo de ER Os documentos que produzimos muitas vezes so cheios de erros quanto mais cedo os descobrirmos, menos caro ser repar-los
Referncias
Sommerville, I. (2007) Software Engineering. Oitava Edio. Addison-Wesley Pressman, R. S. (2005) Software Engineering A Practitioner's Approach. Sexta Edio. MCGraw-Hill Young, R. R. (2006) Twelve Requirements Basics for Project Success. CROSSTALK The Journal of Defense Software Engineering. 19(11). pp 4-8. Jacobs, D. (2004) Requirements Engineering So Things Don't Get Ugly. CROSSTALK The Journal of Defense Software Engineering. 17(10). pp 19-25. Young, R. R. (2002) Recommended Requirements Gathering Practices. CROSSTALK The Journal of Defense Software Engineering. 15(04). pp 9-12.

Introducao A Requisitos

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Introducao A Requisitos

Diunggah oleh

Hak Cipta:

Format Tersedia

Tpicos em SI

Introduo Requisitos de Software

Muitas vezes, falta s necessidades: - Definio clara - Anlise - Consistncia - Viabilidade

Requisitos de componentes de sistema

Qual o significado de requisito?

Segundo o Dicionrio Aurlio

Algumas sintaxes possveis:

Algumas sintaxes possveis:

Algumas sintaxes possveis:

Algumas sintaxes possveis:

Algumas sintaxes possveis:

Algumas sintaxes possveis:

Critrios de Qualidade de Requisitos

Cada requisito deveria ser, individualmente

Critrios de Qualidade de Requisitos

Cada requisito deveria ser, individualmente:

Critrios de Qualidade de Requisitos

Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Robustez Portabilidade

Critrios de Qualidade de Requisitos

O conjunto de requisitos de um sistema deveria ser

Completo Consistente Bem delimitado Vivel

Critrios de Qualidade de Requisitos

Critrios para a linguagem na formalizao dos requisitos

Foco em o qu fazer e no em como fazer Evitar termos gerais e vagos:

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Critrios de Qualidade de Requisitos

Obs.: apesar disso, no to difcil esquecer de falar dos requisitos no-funcionais

H vrias outras classificaes de requisitos

Documentos de Especificao de Requisitos

Uma especificao de requisitos deve

Documentos de Especificao de Requisitos

Documento de Viso define o escopo

Documentos de Especificao de Requisitos

Documentos de Especificao de Requisitos

Documentos de Especificao de Requisitos

Dificuldades Associadas a Requisitos

natural para um desenvolvedor interpretar um requisito ambguo mas no correto!

Processos de Engenharia de Requisitos

Processos de Engenharia de Requisitos

Processos de Engenharia de Requisitos

Entender o problema Revisar o escopo

Podem existir vrias fontes de requisitos para um determinado sistema

um trabalho rduo, por vrias razes

Um fornecedor de requisitos adequado CRACK

Modelos de requisitos deveriam focar a essncia

Todos modelos so errados. Alguns so teis

UML Unified Modeling Language

Avaliar e validar os requisitos

O registro da rastreabilidade relevante para...

Mudanas no podem ser feitas de qualquer jeito

Exemplos de Boas Prticas

Exemplos de Boas Prticas

Anda mungkin juga menyukai