análise e concepção de sistemas de informação · rastreabilidade requisito-design –...

14
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 requisito Porque é que o requisito existe Que 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

Upload: doankien

Post on 25-Dec-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

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