Post on 19-Apr-2015
©Jaelson Castro 1998 Slide 1
O Processo da Engenharia de Requisitos
©Jaelson Castro 1998 Slide 2
Objetivos
Introduzir as noções de processos e modelos de processo para a engenharia de requisitos
Explicar o papel crítico das pessoas no processo de engenharia de requisitos
Explicar porque a melhoria do processo é importante e sugerir um modelo de melhoria de processo para a engenharia de requisitos
©Jaelson Castro 1998 Slide 3
Processos
Processo é um conjunto organizado de atividades que transforma entradas em saídas
Descrições de processos encapsulam conhecimento e permitem que sejam reusados
Exemplos de descrições de processo• Manual de instrução de uma máquina de lavar
• Livro de receitas
• Procedimentos manuais para um banco
• Manual de qualidade para o desenvolvimento de software
©Jaelson Castro 1998 Slide 4
O processo de projeto
Processo que envolve criatividade, interação entre um grande número de diferentes pessoas, julgamento de engenharia e experiência e conhecimento prévio
Exemplos do processo de projeto• Escrita de um livro
• Organizar uma conferência
• Projeto de um chip processador
• Engenharia de Requisitos
©Jaelson Castro 1998 Slide 5
Processo de ER - entradas e saídas
Agreedrequirements
Systemspecification
Systemmodels
Requirementsengineering process
Stakeholderneeds
Organisationalstandards
Domaininformation
Regulations
Existingsystems
information
©Jaelson Castro 1998 Slide 6
Descrição da entrada/saída
Input or output Type DescriptionExisting systeminformation
Input Information about the functionality of systems to be replaced orother systems which interact with the system being specified
Stakeholder needs Input Descriptions of what system stakeholders need from the system tosupport their work
Organisationalstandards
Input Standards used in an organisation regarding system developmentpractice, quality management, etc.
Regulations Input External regulations such as health and safety regulations whichapply to the system.
Domain information Input General information about the application domain of the systemAgreed requirements Output A description of the system requirements which is understandable
by stakeholders and which has been agreed by themSystemspecification
Output This is a more detailed specification of the system functionalitywhich may be produced in some cases
System models Output A set of models such as a data-flow model. an object model, aprocess model, etc. which describes the system from differentperspectives
©Jaelson Castro 1998 Slide 7
Variação do Processo de Requisitos
Os processos de requisitos variam radicalmente de uma organização para outra
Fatores que contribuem para esta variação• Maturidade Técnica
• Envolvimento disciplinas
• Cultura Organizacional
• Domínio de aplicação
Portanto não existe um processo ‘ideal’ de engenharia de requisitos
©Jaelson Castro 1998 Slide 8
Modelos de Processos
Um modelo de processo é uma descrição simplificada do processo descrito de um determinado ponto de vista
Tipos de modelo de processo:• Modelos de atividades de alto-nível
• Modelos detalhados de atividades
• Modelos de ações-papéis
• Modelos de entidade-relacionamento
©Jaelson Castro 1998 Slide 9
Modelo de ER de alto nível
Requirementselicitation
Requirementsanalysis andnegotiation
Requirementsdocumentation
Requirementsvalidation
Requirementsdocument
User needsdomain
information,existing system
information,regulations,
standards, etc.
AgreedrequirementsSystem
specification
©Jaelson Castro 1998 Slide 10
Atividades do processo de ER Elicitação de Requisitos
• Os requisitos são descobertos através da consulta com as partes interessadas
Análise e negociação de requisitos• Requisitos são analisados e os conflitos resolvidos através de
negociação
Documentação de requisitos• Um documento de requisitos é produzido
Validação de requisitos • É checada a consistência e completude do documento de requisitos
©Jaelson Castro 1998 Slide 11
O modelo cascata de processo de software
Systemrequirementsengineering Software
requirementsengineering
Softwaredesign
Programmingand unit testing
System testing
Systemoperation
System requirements specification
Software requirements specification
Software design specification
Executable software system
Completed system
©Jaelson Castro 1998 Slide 12
Contexto do Processo de ER
Requirements engineering
System design
System acquisition
©Jaelson Castro 1998 Slide 13
Modelo espiral do processo de ER
Requirements elicitation Requirements analysis andnegotiation
Requirements documentationRequirements validation
Informal statement ofrequirements
Agreedrequirements
Draft requirementsdocument
Requirementsdocument and
validationreport
Decision point:Accept documentor re-enter spiral
START
©Jaelson Castro 1998 Slide 14
Atores do processo de ER Os atores do processo são as pessoal envolvidas na
execução do processo Os atores são normalmente identificados pelos seus
papéis e não individualmente Engenharia de requisitos envolve atores tanto atores
que estão interessados no problema a ser resolvido (usuários finais) como também atores interessados na solução (projetistas, etc.)
Diagramas de papel-ação documentam quais atores estão envolvidos em que atividades
©Jaelson Castro 1998 Slide 15
RAD para prototipagem de software
ROLES
Understandproblem
Establishoutline
requirements
Selectprototyping
system
Developprototype
Evaluateprototype
ACTIONS
Req. engineerDomain expert
End-user
Req. engineerEnd-user
Softwareengineer
Project manager
Req. engineerSoftwareengineer
End-userDomain expertReq. engineer
Software engineer
©Jaelson Castro 1998 Slide 16
Descrição dos papéis
Role DescriptionDomain expert Responsible for providing information about the
application domain and the specific problem in thatdomain which is to be solved.
System end-user Responsible for using the system after deliveryRequirements engineer Responsible for eliciting and specifying the system
requirementsSoftware engineer Responsible for developing the prototype software
systemProject manager Responsible for planning and estimating the
prototyping project
©Jaelson Castro 1998 Slide 17
Fatores Humanos e sociais
Os processos de engenharia de requisitos são dominados por fatores humanos, sociais e organizacionais porque eles sempre envolvem um conjunto de partes interessadas com backgrounds diferentes e com objetivos organizacionais e individuais diferentes
As partes interessadas (stakeholders) pelo sistema podem ter uma variedade de background técnico e não técnico e de diferentes disciplinas
©Jaelson Castro 1998 Slide 18
Tipos de partes interessadas (stakeholder)
Engenheiros de software responsáveis pelo desenvolvimento do sistema
Usuários finais do sistema que irão usar o sistem depois dele ser entregue
Os gerentes dos usuários finais do sistema, que será responsável pelo trabalho deles
Fiscais externos que verificaram se o sistema satisfaz os requisitos legais
Especialistas de domínio que possuem informações essenciais sobre o domínio da aplicação
©Jaelson Castro 1998 Slide 19
Factores influenciando requisitos
Personalidade e status dos stakeholders Os objetivos pessoais dos indivíduos dentro da
empresa O grau de influência política dentro de uma
organização
©Jaelson Castro 1998 Slide 20
Suporte para o processo
Ferramentas CASE proporcionam suporte automático para o processo de software
As ferramenta de CASE mais maduras suportam atividades bem entendidas tais como programação, teste e uso de métodos estruturados
O suporte para a engenharia de requisitos ainda é limitado devido a informalidade e a variação dos processos
©Jaelson Castro 1998 Slide 21
Ferramentas CASE para ER
Ferramentas para modelagem e validação de requisitos que suportam o desenvolvimento de modelos do sistema, que podem ser usadas para checar a completude e consistência entre os modelos
Ferramentas de gerenciamento que ajudam o gerenciamento de um banco de dados de requisitos e apoiam o gerenciamento das modificações dos requisitos.
©Jaelson Castro 1998 Slide 22
Um sistema de gerenciamento de requisitos
Requirementsdatabase
NLrequirements
documentReq. convertor
WP linker
Traceabilitysupport system
Report generator
Traceabilityreport
Requirementsreport
Req. browserReq. query
system
Change controlsystem
©Jaelson Castro 1998 Slide 23
Ferramentas de gerenciamento de requisitos
Folheador (browser) de requisitos Sistema de perguntas (query) de requisitos Sistema de suporte de rastreamento Gerador de relatórios Conversor de requisitos e linker para processador
de texto Sistema de controle de mudanças
©Jaelson Castro 1998 Slide 24
Melhoria de Processo
A melhoria de processo está relacionado com a modificação do processo de forma a alcançar algum objetivo de melhora
Objetivos de melhora• Melhoria de qualidade
• Redução de prazo
• Redução de recursos
©Jaelson Castro 1998 Slide 25
Planejando a melhoria do processo
Quais são os problemas com os processos atuais? Quais são os objetivos de melhora? Como o processo de melhora poderá ser
introduzido para alcançar estes objetivos? Como o processo de melhora poderá ser
controlado e gerenciado?
©Jaelson Castro 1998 Slide 26
Problemas do processo de ER
Falta de envolvimento dos stakeholders As necessidades do negócio não são consideradas Falta de gerenciamento dos requisitos Falta de definição de responsabilidades Problemas de comunicação dos stakeholders Planejamento longo demais e baixa qualidade dos
documentos de requisitos
©Jaelson Castro 1998 Slide 27
Maturidade do Processo
A maturidade do processo de uma empresa pode ser considerada como sendo o grau de definição dos seus processos, como eles são controlados e a existência de suporte sistemático tanto humano como baseado em computador.
O modelo de maturidade da SEI (Capability Maturity Model- CMM) é uma proposta para avaliação da maturidade do processo de software de empresas de desenvolvimento
©Jaelson Castro 1998 Slide 28
O modelo de maturidade
Level 3Defined
Level 2Repeatable
Level 1Initial
Level 4Managed
Level 5Optimizing
©Jaelson Castro 1998 Slide 29
Níveis de maturidade Nível inicial
• As empresas têm um processo não disciplinado e fica a cargo dos indivíduos tanto a escolha das técnicas de desenvolvimento a serem usadas como o gerenciamento do processo.
Nível repetível • As empresas tem funcionando os procedimentos básicos de
gerenciamento de custo e prazo. Provavelmente serão capazes de fazerem previsões consistentes de custo e escalonamento para projetos na mesma área de aplicação.
Nível definido • O processo de software, tanto das atividades de gerenciamento como
engenharia, está documentado, padronizado, e integrado aos padrões de processo de software para toda a organização.
©Jaelson Castro 1998 Slide 30
Maturity levels
Nível gerenciado • Medições detalhadas tanto do processo como da qualidade do
produto são coletadas e usadas para controlar o processo.
Nível otimizado • A empresar possuem uma estratégia de melhoria contínua do
processo, baseada nos objetivos adotados para medição
©Jaelson Castro 1998 Slide 31
Um modelo de maturidade de processo para ER
Level 1 - InitialAd-hoc requirements
engineering; requirementsproblems are common
Level 2 - RepeatableStandardised requirements
engineering; fewerrequirements problems
Level 3 - DefinedDefined process basedon best practice; processimprovement in place
©Jaelson Castro 1998 Slide 32
RE process maturity levels
Nível inicial • Não há processo definido de ER. Sofre de problemas tais como
volatilidade dos requisitos, stakeholders não satisfeitos e alto custo de refeita dos sistemas. Depende de habilidades e experiências individuais.
Nível repetível• Padrões definidos para os documentos de requisitos e políticas
e procedimentos para o gerenciamento de requisitos.
Nível definido• Um processo definido de ER, baseado em boas práticas e
técnicas. Em funcionamento um processo ativo de melhoria.
©Jaelson Castro 1998 Slide 33
Boas práticas para a melhoria do processo de ER
Os processo de ER podem ser melhorados pela sistemática introdução de boas práticas de engenharia de requisitos
Cada ciclo de melhoria identificará diretrizes práticas e trabalhará em direção para a sua introdução na organização
©Jaelson Castro 1998 Slide 34
Exemplos de diretrizes de boas práticas
Defina uma estrutura de documento padronizada Identifique de forma única cada requisito Defina políticas para o gerenciamento de requisitos Use checklists durante a análise de requisitos Use cenários para elicitar requisitos Especifique requisitos de forma quantitativa Use prototipagem para animar requisitos Re-use requisitos
©Jaelson Castro 1998 Slide 35
Pontos principais O processo de engenharia de requisitos é estruturado
como um conjunto de atividades que leva a produção do documento de requisitos.
As entradas do processo de engenharia de requisitos são as informações existentes dos sistemas, necessidade dos stakeholders, padrões organizacionais, regulamentações e informações do domínio.
Os processos de engenharia de requisitos variam radicalmente entre empresas. A maioria dos processos incluem a elicitação de requisitos, análise e negociação dos requisitos e validação dos requisitos.
©Jaelson Castro 1998 Slide 36
Pontos chaves
Os modelos do processo de engenharia de requisitos são descrições simplificadas que são apresentadas de uma perspectiva particular.
Fatores humanos, sociais e organizacionais são influências importantes no processo de engenharia de requisitos.
A melhoria do processo de engenharia de requisitos é difícil, sendo tratada melhor de forma incremental.
Os processos de engenharia de requisitos podem ser classificados de acordo com seus graus de maturidade.