View
219
Download
0
Category
Preview:
Citation preview
Adaptado a partir de Gerald Kotonya and Ian Sommerville
Gestão de Requisitos
Análise e Concepção de Sistemas de Informação
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Gestão de requisitos
Objectivos:– Gerir alterações aos requisitos acordados– Gerir ligações entre requisitos – Gerir dependências entre o documento de requisitos e
outros documentos produzidos no processo de engenharia de sistemas
Rastreabilidade de requisitos é essencial para uma gestão efectiva dos requisitos
A rastreabilidade de requisitos tem várias vertentes:Quem sugeriu o requisitoPorque é que o requisito existeQue requisitos estão relacionados Como é que o requisito está relacionado com outra informação, tal como, o desenho do sistema, a implementação e manuais do utilizador
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Sistema de gestão de requisitos
Requirementsdatabase
NLrequirements
documentReq. convertor
WP linker
Traceabilitysupport system
Report generator
Traceabilityreport
Requirementsreport
Req. browser Req. querysystem
Change controlsystem
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Requisitos estáveis e voláteis
Alterações aos requisitos ocorrem durante as fases de levantamento, análise e validação dos requisitos e após o sistema estar operacionalAlguns requisitos estão mais sujeitos a mudanças do que outros– Requisitos estáveis estão associados à essência do sistema
e o seu domínio de aplicação – Requisitos voláteis são especificos a uma instância do
sistema para um cliente e para um contexto particular
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Factores de alteração de requisitos
Erros, conflitos e inconsistências nos requisitos– Durante a análise e implementação dos requisitos, podem
emergir erros e inconsistencias que têm que ser corrigidos– Estes problemas podem ser encontrados durante a fase de
análise e validação dos requisitos ou nas fases seguintes do processo de desenvolvimento
Evolução do conhecimento do sistema pelos clientes/utilizadoresProblemas técnicos, de planificação, ou de custo– Podem surgir problemas durante a implementação de um
requisito. O custo ou o tempo de implementação pode ser demasiado elevado
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Factores de alteração de requisitos
Alteração das prioridades do cliente– As prioridades do cliente podem mudar durante o
desenvolvimento devido a vários factoresnovos competidores mudanças de pessoal na organização...
Alterações ao contexto do sistema – O meio no qual o sistema vai ser instalado pode mudar,
causando alterações nos requisitos do sistema Alterações na organização– A organização pode sofrer alterações na sua estrutura e nos
seus processos criando novos requisitos do sistema
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Tipos de requisitos voláteis
Requisitos mútaveis– Requisitos que mudam devido a alterações ao
contexto onde o sistema irá operarRequisitos emergentes– Estes requisitos não podem ser completamente
definidos quando o sistema é especificado, mas quando o sistema é desenhado e implementado
Requisitos de compatibilidade– Requisitos que dependem de outro equipamento
ou processos
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Gestão da mudança
A gestão da mudança involve procedimentos, processos e standards para gerir alterações aos requisitos do sistema As politicas de gestão de mudança podem abordar:– O processo associada aos pedidos de mudança e a
informação necessária para o processamento de cada um desses pedidos
– O processo usado para analisar o impacto e os custos da mudança e a informação associada à rastreabilidade
– Definir quem deve pertencer à equipa que considera formalmente os pedidos de mudança
– O software de suporte ao processo de controlo da mudança
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Fases da gestão da mudança
Changeimplementation
Change analysisand costing
Problem analysis andchange specification
Identifiedproblem
Revisedrequirements
É identificado um problema num requisito – Os requisitos são analisados com base no problema
encontrado e é definida uma proposta de mudançaA proposta de mudança é analisada– Verificar quantos requisitos são afectados pela mudança e
determinar os custos temporais e monetários dessa mudança
A mudança é implementada – Produzir uma nova versão ou um conjunto de emendas ao
documento de requisitos
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Formulário para propor mudanças
DOORS
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Análise da mudança e custos associados
Check requestvalidity
Find directlyaffected
requirements
Find dependentrequirements
Proposerequirements
changes
Assess costsof change
Assess costacceptability
Acceptedchange
Changerequest
Rejected request
Validrequest
Req. list
Requirements change list
Requirementschanges
Customerinformation
Costinformation
Rejected request
Rejected requestCustomer
information
Rejected request
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Actividades da análise da mudança
Verificar a validade do pedido de mudança. Os clientes podem não compreender os requisitos e sugerir mudanças desnecessarias Determinar os requisitos directamente afectados pela mudançaA informação de rastreabilidade é usada para encontrar os requisitos dependentes que são afectados pela mudançaPropor as mudanças a efectuar nos requisitosEstimar os custos associados à mudançaVerificar com os clientes se os custos associados àproposta de mudança são aceitáveis
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Rejeitar pedidos de mudança
Se o pedido de mudança é inválido. O cliente pode propror uma mudança aos requisitos que é desnecessáriaSe o pedido de mudança resulta em mudanças de consequência que os utilizadores consideram inaceitáveisSe o custo ou o tempo de implementação da mudança é demasiado elevado
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Rastreabilidade
A informação de rastreabilidade permite determinar o impacto da mudança nos requisitos. Faz a ligação entre requisitos relacionados e outras representações do sistemaTipos de informação de rastreabilidade– Rastreabilidade Backward-from
Ligação entre os requisitos e as suas origens em outros documentos ou pessoas
– Rastreabilidade Forward-from Ligação entre os requisitos e as componentes de desenho e implementação
– Rastreabilidade Backward-toLigação entre os componentes de desenho e implementação e os requisitos
– Rastreabilidade Forward-toLigação com outros documentos e requisitos relevantes
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Rastreabilidade backward/forward
Business plan Design SpecificationRequirements Document
Forward-to traceability Forward-from traceability
Backward-from traceability Backward-to traceability
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Tipos de rastreabilidade
Rastreabilidade requisito-fonte– Ligação entre o requisito e as pessoas ou
documentos que especificaram o requisitoRastreabilidade requisito-racional– Ligação entre o requisito e a descrição que
justifica a especificação desse requisitoRastreabilidade requisito-requisito– Liga requisitos com outros requisitos que, de
alguma forma, dependem deles. Deve ser uma ligação bi-direcional
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Tipos de rastreabilidade
Rastreabilidade requisito-arquitectura– Ligação entre requisitos e os sub-sistemas que os
implementam. Esta informação é importante se existem sub-sistemas desenvolvidos por sub-contratação
Rastreabilidade requisito-design– Ligação entre requisitos e os componentes
especificos de hardware ou software Rastreabilidade requisito-interface– Ligação entre requisitos e as interfaces para
sistemas externos
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Tabela de rastreabilidade
Depends-onR1 R2 R3 R4 R5 R6
R1 * *R2 * *R3 * *R4 *R5 *R6
As tabelas de rastreabilidade mostram as relações entre requisitos ou entre componentes do desenho
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Políticas de rastreabilidade
Definem que informação de rastreabilidade deve ser mantida e como a manterPolíticas de rastreabilidade podem incluir– A informação de rastreabilidade que deve ser mantida– As técnicas a usar para a manutenção da rastreabilidade – Definir quando colectar a informação de rastreabilidade
durante a engª de requisitos e o processo de desenvolvimento do sistema
– Definir os papeis das pessoas responsáveis pela manutenção informação de rastreabilidade
– Descrever a forma de abordar e documentar políticas de excepção
– O processo de gestão da informação de rastreabilidade
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Número de requisitos – Quanto mair for o número de requisitos, maior a
necessidade de uma política formal de rastreabilidade
Estimar o “tempo de vida” do sistema– Sistemas com um tempo de vida longo, necessitam políticas
de rastreabilidade mais compreensivas
Nível de maturidade da organização– Políticas de rastreabilidade detalhadas são mais efectivas
em termos de custo em organizações com um maior nível de maturidade
Factores que afectam a política de rastreabilidade
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Tamanho e composição da equipa do projecto – Numa equipa pequena pode ser possível determinar o
impacto da mudança sem informação estruturada de rastreabilidade. Contudo, em equipas maiores é necessário ter políticas formais de rastreabilidade
Tipo de sistema– Sistemas críticos necessitam the políticas de rastreabilidade
mais detalhadas do que os sistemas não-críticos
Requisitos especificos do cliente– Os clientes podem exigir que determinada informação de
rastreabilidade seja entregue com a documentação do sistema
Factores que afectam a política de rastreabilidade
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Gestão de Requisitos no RUPVisão Geral
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Gestão de Requisitos no RUPGestão de Pedidos de Alterações - Conceitos
Change Request (CR) – A formally submitted artifact that is used to track all stakeholder requests (including new features,
enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle.
Change (or Configuration) Control Board (CCB) – The board that oversees the change process consisting of representatives from all interested parties,
including customers, developers, and users. In a small project, a single team member, such as the project manager or software architect, may play this role. In the Rational Unified Process, this is shown by the Change Control Manager role.
CCB Review Meeting– The function of this meeting is to review Submitted Change Requests. An initial review of the contents of
the Change Request is done in the meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group. This meeting is typically held once per week. If the Change Request volume increases substantially, or as the end of a release cycle approaches, the meeting may be held as frequently as daily.
Change Request Submit Form– This form is displayed when a Change Request is being Submitted for the first time. Only the fields
necessary for the submitter to complete are displayed on the form.Change Request Combined Form
– This form is displayed when you are reviewing a Change Request that has already been submitted. It contains all the fields necessary to describe the Change Request.
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Gestão de Requisitos no RUPGestão de Pedidos de Alterações – Actividades Comuns
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Gestão de Requisitos no RUPGestão de Pedidos de Alterações – D.E. “Change Request”
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Gestão de Requisitos no RUPGestão de Pedidos de Alterações – Change Control Manager Role
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Resumo dos pontos-chave
É inevitável que os requisitos mudam, visto que ao longo do desenvolvimento do sistema:– os clientes desenvolvem um maior conhecimento sobre as
suas necessidades reais– o meio organizacional e técnico no qual o sistema será
instalado evolui
Os requisitos relacionados com a essência do sistema tendem a ser mais estáveis do que os requisitos relacionados com a forma de implementação do sistema Requisitos voláteis incluem os requisitos emergentes, de consequência e de compatibilidade
ACSI/Gestão, Adaptado de Kotonya&Sommerville
Resumo dos pontos-chave
As politicas de gestão de mudança devem definir:– Os processos usados na gestão de mudança– A informação a associar a cada pedido de mudança– As responsabilidades individuais no processo de gestão de
mudançaA informação de rastreabilidade regista:– Dependências entre requisitos– A origem dos requisitos– Dependências entre requisitos e a implementação do sistema
Matrizes de rastreabilidade podem ser usadas para registar a informação de rastreabilidade Colectar e manter informação de rastreabilidade tem um custo elevado. – Para controlar os custos as organizações devem definir politicas de
rastreabilidade que determinam a informação a ser colectada e a forma de manutenção dessa informação
Recommended