Baixe o app para aproveitar ainda mais
Prévia do material em texto
Análise e Negociação de Requisitos Processo da Engenharia de Requisitos identificação , descoberta de requisitos análise e negociação de requisitos documentaçã o de requisitos validação de requisitos documento de requisitos necessidades dos usuários, sistemas legados, informação do domínio, normas organizacionais, etc. Processo de Engenharia de Requisitos: modelo em espiral (Kotonya e Sommerville, 1998; SWEBOK) Análise e negociação de requisitos • Objetivos – Atividades que visam descobrir problemas com os requisitos e chegar a acordos para a sua resolução de forma a satisfazer todos os interessados no sistema – na realidade, desde a fase de identificação de requisitos já se desenrolam atividades de análise e negociação. – análise e negociação de requisitos são atividades que incidem sobre conjuntos incompletos de requisitos Análise e negociação de requisitos • Características – A análise e negociação de requisitos é normalmente um processo complexo • requer pessoas com competências específicas • baseia-se muito no julgamento e experiência dos participantes • não é possível transformar este processo numa abordagem estruturada e sistemática • é custoso e moroso Processo de análise e negociação Kotonya, 1998 Análise de Requisitos • Análise (verificação) de requisitos – no conjunto de requisitos identificados pode • haver requisitos que se sobrepõem • haver requisitos que estão em conflito ou que são contraditórios • faltar requisitos... Instrumentos de Análise de Requisitos • Listas de checagem – listas de questões que um analista usa para avaliar os requisitos – são um "lembrete" do que é importante considerar na análise – não devem ter muitos itens – evoluem com a experiência ganha no processo de análise • Exemplo de listas de checagem – o requisito inclui aspectos de desenho ou implementação? – o requisito poderia ser decomposto em sub-requisitos? – o requisito é mesmo necessário?... – o requisito implica a utilização de software não padronizado? – o requisito está de acordo com os objetivos do negócio? – o requisito é ambíguo? – o requisito é realista? – o requisito é "testável"? Instrumentos de Análise de Requisitos Critérios de qualidade em listas de checagem de requisitos O requisito pode ser testado? Há informação suficiente para que testes possam ser criados para verificá-lo?Testável A especificação trata da definição do produto e não com questões de desenho, arquitetura e código? Independência de código O requisito pode ser implementado com os recursos disponíveis?Viabilidade O requisito é realmente necessário? Há alguma necessidade de interessados que o sustentam?Relevância A descrição é feita de forma que não haja inconsistências na própria descrição ou com outros itens da especificação?Consistência A descrição do requisito não é vaga, inexata? Tem uma única interpretação? É facil de ler e entender? Precisão e clareza O requisito define apropriadamente seu objetivo? Não há erros na sua especificação?Acurácia Há algum requisito ausente ou esquecido?Completeza O que deve ser consideradoAtributo Análise de escopo definir as fronteiras do sistema analisar e decidir se o requisito está dentro ou fora diagramas de contexto diagramas de casos de uso Análise de dependências requisito r1 r2 r3 r4 r1 x x x x r2 conflito x x x r3 x x r4 sobreposição sobreposição x • matriz de dependências Análise de risco • Riscos nos requisitos tem a ver com – dificuldades no desenvolvimento – dificuldades na análise • Tipos de risco – técnico – desempenho – segurança – integridade de base de dados – processo de desenvolvimento – político – legal – volatilidade Análise de prioridades • definir prioridades na análise e implementação dos requisitos • classificação – alta, média, baixa, não sabe – essencial, útil, pouco interesse, a ser decidido Organização dos requisitos • classificação – agrupamento de requisitos para melhor manipulação – ex: atendimento, pesquisa, fluxo de trabalho, etc. • atribuição de identificadores – número sequencial (1, 1, 3, ...) – número hierárquico (1, 1.1, 1.2, 2, ...) – número sequencial dentro de uma categoria (A1, A2, ..., B1, B2, ...) Organização dos requisitos • hierarquização – relações de composição ou "pai → filhos" ou "requisito→ sub-requisito" – os requisitos são definidos em vários níveis de abstração • a organização em hierarquias é adequada a uma abordagem iterativa do processo de engenharia de requisitos Organização dos requisitos Exemplo • 1. "o sistema deve escalonar a próxima chamada para um cliente após a solicitação do operador de telemarketing" – 1.1 "o sistema deve ativar o botão 'próxima chamada' depois de entrar no formulário de 'controlo de telemarketing' ou assim que a última chamada terminar" – 1.2 "o sistema deve remover a chamada do topo da fila de chamadas escalonadas e estabelecer a chamada seguinte" – 1.3 etc. Outro exemplo 1. O sistema deve permitir a marcação de consultas (caso de uso) – 1.1 a consulta pode ser marcada pelo médico ou pela assistente – 1.2 um médico pode marcar uma consulta para outro médico – 1.3 não se podem marcar duas consultas para a mesma data, hora e médico (restrição) – 1.4 o sistema deve alertar o usuário no caso do doente ter outras consultas marcadas (alerta) – 1.5 o sistema deve ajudar o usuário a encontrar vagas (ajuda) – (...) Organização dos requisitos Modelagem de requisitos • Construção de modelos semi-formais (UML) ou formais (matemáticos) é uma técnica útil não só para documentar e organizar requisitos, como também para descobrir problemas nos requisitos (ambiguidades, conflitos e omissões) e ajudar à descoberta de novos requisitos (colocar questões) – Principais vantagens dos modelos: síntese, rigor – Modelos UML mais importantes: modelos de casos de uso, modelos de (objetos de) domínio, modelos de processos de negócio Negociação de requisitos • Objetivos – chegar a acordo em relação a opções mais adequadas aos interesses dos stakeholders – definir as prioridades a dar aos requisitos para novas iterações de identificação e análise e para o desenvolvimento – chegar a acordo em relação a compromissos entre requisitos que entram em conflito Tarefas na negociação estruturar opções e escolhas estabelecer critérios de avaliação explicar opções disponíveis e a escolha a fazer chegar a um acordo diagnosticar causas de desacordo Participantes na negociação • stakeholders primários – os que operam o sistema – preocupam-se com os requisitos funcionais e questões de usabilidade – pretendem sistemas fáceis de usar e aprender • stakeholders secundários – não operam o sistema mas consomem o que este produz – o sucesso das suas atividades depende da qualdade do sistema – são tipicamente gestores que usam a informação do sistema para controlar, monitorar e ajustar processos organizacionais Participantes na negociação • stakeholders terciários – gestores de topo que raramente consomem as saídas do sistema (diretamente) – usam-nas indiretamente para planear e controlar estrategicamente o negócio – interessam-se pelo papel que o sistema desempenha no realização dos objetivos estratégicos do negócio tais como aumentar a vantagem competitiva ou melhorar o serviço ao cliente Participantes na negociação • problemas num processo de negociação – conflitos entre grupos • choque de pontos de vista entre grupos – exemplos: qualidade vs. prazos, custos vs. desenvolvimento, segurança vs. acesso, complexidadefuncional vs. usabilidade, etc. – falta de entendimento partilhado e de pontos de vista pessoais – atitudes interpessoais • Comportamentos indesejados • Ataques pessoais Dificuldades na negociação
Compartilhar