ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS
Análise e Modelação de Sistemas 2006

Engenharia de Requisitos
A engenharia de requisitos (no contexto da engenharia de software) É um processo que engloba todas as actividades Que contribuem para a produção de um documento de requisitos E sua manutenção ao longo do tempo.

Engenharia de Requisitos
Este processo deve ser precedido de estudos de viabilidade Que a partir das restrições do projecto, determinam se este é ou não viável E se se deve prosseguir para a identificação dos requisitos.

Conceito de Requisitos
O que são requisitos de um sistema? descrições de como o sistema se deve comportar descrições de propriedades do sistema descrições de restrições do sistema ou condicionantes no seu desenvolvimento Início aula 6 de Outubro de 2004

mais definições... uma capacidade de um sistema de software que um utilizador necessita para resolver um problema ou atingir um objectivo uma capacidade que um sistema de software deve possuir para satisfazer um contracto, especificação, norma, ou qualquer outra documentação imposta

requisitos funcionais descrevem o que o sistema deve fazer exemplos "o sistema deve possibilitar armazenar os pedidos de orçamento" "o sistema deve possibilitar a paragem de emergência do motor requisitos não-funcionais descrevem as restrições na implementação dos requisitos funcionais "o sistema deve permitir armazenar pelo menos 500 pedidos de orçamento por ano" "o sistema operativo a usar deve ser linux" "a paragem de emergência deve ser realizada em menos de 3 segundos"

Onde terminam os requisitos?
"Os requisitos terminam onde começa a liberdade do implementador" Idealmente, todas as decisões que têm de ser validadas pelo cliente (que o implementador não pode tomar isoladamente), devem estar contidas no documento de requisitos Na prática, não é possível ou economicamente viável prever tudo à partida, e é necessário manter um diálogo constante com o cliente O nível de detalhe desejável varia de situação para situação

níveis de requisitos alto nível: missões, objectivos, regras do negócio baixo nível: necessidades dos utilizadores, funcionalidades, restrições

O processo de Engenharia de Requisitos
É constituído por quatro actividades de alto nível (Soares, 2005): Identificação. Análise e negociação. Especificação e documentação. Validação.

O processo de engenharia de requisitos: modelo de actividades de alto nível
documento de requisitos identificação, descoberta de requisitos análise e negociação de requisitos documentação, especificação de requisitos validação de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc.

O processo de engenharia de requisitos: entradas e saídas
sistemas legados necessidades dos utilizadores processo de engenharia de requisitos especificação do sistema requisitos (acordados) normas da organização regulamentos informação do domínio (Kotonya e Sommerville, 1998)

O processo de engenharia de requisitos *qualidade do processo de ER
modelo de maturidade nível 3. definido PER baseado em melhores práticas; melhoria contínua saltei nível 2. repetível PER obedecendo a normas nível 1. inicial PER adhoc

O processo de engenharia de requisitos actores no processo
especialista do domínio utilizador final engenheiro de software responsável de projecto engenheiro de requisitos / analista processo de engenharia de requisitos Falta o cliente. Fazia sentido actores = stakeholders (interessados no sistema) + analistas / eng. requisitos (independentes de stakeholders) + outros

Quem são os "interessados no sistema" (stakeholders)?
O processo de engenharia de requisitos actores no processo: stakeholders Quem são os "interessados no sistema" (stakeholders)? São as pessoas que serão afectadas pelo sistema E que têm uma influência directa ou indirecta na elaboração dos requisitos: Explicar que os donos da empresa podem ter interesse legítimo no lucro.

Quem são os "interessados no sistema" (stakeholders)
O processo de engenharia de requisitos actores no processo: stakeholders Quem são os "interessados no sistema" (stakeholders) Utilizadores finais, gestores e outros envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistema Clientes da organização que possam vir a usar o sistema, organismos de regulação e certificação, etc. Explicar que os donos da empresa podem ter interesse legítimo no lucro.

Processo de descoberta de requisitos "orientado ao problema"
análise de problemas - processo de compreender um problema e propor soluções para resolver esse problema identificar os stakeholders entender as causas do problema definir as fronteiras da solução acordar na definição do problema identificar as restrições da solução

identificar os stakeholders
compreender as necessidades dos interessados no sistema é um factor decisivo no desenvolvimento de uma solução efectiva para um problema quem são os utilizadores do sistema? quem é o cliente (comprador) do sistema? quem será afectado pelas saídas que o sistema produz? quem fará a manutenção do sistema?

Definir as fronteiras da solução
quem fornece, utiliza, remove informação do sistema? quem opera o sistema? quem faz manutenção do sistema? onde é que o sistema é usado? como obtém o sistema a sua informação? que outros sistema interactuam com o sistema? fronteira do sistema solução utilizadores outros sistemas

identificar as restrições da solução
restrições no grau de liberdade que temos para desenvolver o sistema económicas políticas tecnológicas sistemas existentes ambiente recursos

Acordar na definição do problema
exemplo de formulação do problema "o problema de se passar demasiado tempo a produzir a documentação do projecto afecta os parceiros do projecto e resulta em atrasos significativos no cumprimento dos prazos; os benefícios do sistema que gerisse a documentação à medida que é produzida residiriam numa menor percentagem de incumprimento de prazos e numa melhor relação com os parceiros"

O processo de engenharia de requisitos boas práticas
algumas boas práticas definir uma estrutura normalizada para o documento de requisitos identificar univocamente cada requisito definir políticas de gestão de requisitos usar checklists de problemas para a análise de requisitos usar cenários para identificar os requisitos especificar os requisitos quantitativamente usar prototipagem para animar os requisitos reutilizar requisitos especificar sistemas formalmente etc., Referir que o conhecimento resultante da experiência em Eng.Soft. está normalmente (semi)estruturado em práticas e padrões.

IDENTIFICACÃO DOS REQUISITOS

Processo de engenharia de requisitos: modelo de actividades de alto nível
documento de Requisitos identificação, descoberta de requisitos análise e negociação de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc. especificação, documentação de requisitos validação de requisitos

Processo de engenharia de requisitos: modelo em espiral
(Kotonya e Sommerville, 1998; SWEBOK)

Dimensões da descoberta de requisitos
conhecimento geral do domínio estende e especializa conhecimento geral do domínio compreender o domínio de aplicação compreender o problema a ser resolvido compreender as necessidades e restrições dos interessados compreender o contexto de negócio que actividades devem ser suportadas pelo sistema? qual o papel de sistemas existentes? etc. como é que o sistema contribui para os objectivos do negócio? etc. Kotonya, 1998

Estágios do Processo Estabelecimento de objectivos
Objectivos gerais do negócio, descrição genérica do problema a resolver, necessidade do sistema e restrições sobre o sistema. Aquisição de conhecimento de background informação sobre a organização em que o sistema vai ser instalado, o domínio de aplicação do sistema e informação sobre sistemas existentes Organização do conhecimento Organizar a grande quantidade de conhecimento (informação?) recolhida no estágio anterior. Recolher requisitos dos stakeholders Consultar os interessados no sistema para descobrir os seus requisitos.

Fontes de requisitos (1)
(fonte: SWEBOK) objectivos gerais de alto nível do sistema objectivos gerais de alto nível do sistema, problema que o sistema deve resolver, motivação para a implementação do sistema, factores críticos de sucesso, interesse para o negócio, ... necessário avaliar custos e benefícios de atingir os objectivos, por exemplo com estudo de viabilidade conhecimento do domínio de aplicação necessário para inferir conhecimento tácito que os stakeholders não explicitam, avaliar trade-offs entre requisitos conflituosos, etc. pode ser obtido junto de especialistas do domínio, documentos, etc. stakeholders do sistema fundamental identificar, representar e gerir os pontos de vista, interesses e necessidades de todos os interessados no sistema (utilizadores, clientes, etc.)

Fontes de requisitos (2)
(fonte: SWEBOK) ambiente operacional o ambiente operacional em que o sistema vai executar pode impor diversos requisitos aproveitamento de infra-estruturas físicas e lógicas existentes interoperabilidade com sistemas existentes (internos ou externos) etc. ambiente organizacional muitos sistemas destinam-se a suportar processos de negócio, devendo-se adequar à estrutura, cultura, políticas, regras e normas internas da organização (intra/inter) ambiente externo normas, regulamentos, legislação, etc. podem impor requisitos exemplos: lei de protecção de dados pessoais, normas de acessibilidade, POC, ...

Técnicas de descoberta de requisitos
análise de documentação análise de sistemas existentes entrevistas encontros facilitados (workshops, brainstorming) cenários protótipos observação e análise social, estudos etnográficos soft systems methods reutilização de requisitos

ENTREVISTAS

Entrevistas entrevistar os futuros utilizadores e outros stakeholders é a técnica mais vulgar e simples de obter informação para identificar requisitos

Entrevistas a entrevista é uma técnica simples, mas não é fácil de aplicar

Entrevistas Enviesamento de quem conduz a entrevista:
Relação pessoal entre os intervenientes na entrevista: predisposição do entrevistado: Capacidade de seguir um "plano" para a entrevista:

Entrevistas tipos de entrevistas estruturadas vs. não estruturadas
descontextualizadas vs. contextualizadas pela solução

Entrevistas Entrevistas e Questionários: esta é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns factores: Enviesamento de quem conduz a entrevista: convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida). Relação pessoal entre os intervenientes na entrevista.

Entrevistas Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afectado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação. Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).

Elaboração das perguntas Perguntas de contexto livre
Como exemplo de perguntas deste género, podemos ter: Quem são os utilizadores? Quem é o cliente? Têm necessidades diferentes? Onde podem ser encontradas outras soluções para este problema?

Elaboração das perguntas Perguntas centradas na solução
Após terem sido feitas as perguntas de contexto livre, pode começar-se a explorar as soluções propostas com estas perguntas mais direccionadas: (Apresentar as capacidade gerais de uma solução) E se pudesse fazer ... e ...? Como classificaria a importância de cada uma das funcionalidades apresentadas?

Aqui ficam algumas dicas para uma entrevista de sucesso:
Prepare uma entrevista de contexto livre apropriada, e tome nota para que isso sirva como referência no decorrer da entrevista. Faça uma revisão às questões a colocar nos momentos que antecedem a entrevista. Antes da entrevista faça uma pesquisa ao background do stakeholder e da empresa a serem entrevistados. Não mace a pessoa a ser entrevistada com perguntas que poderia facilmente saber a resposta à priori. Ainda assim, pode confirmar brevemente essas respostas dando a mostrar o seu interesse e conhecimento da pessoa e empresa em questão.

Aqui ficam algumas dicas para uma entrevista de sucesso:
Anote as respostas no seu bloco de notas durante a entrevista. (Não tente capturar a informação de forma electrónica nesta fase!) Consulte as notas da estrutura da entrevista no decorrer da mesma. Desta forma tem a certeza que está a fazer as perguntas correctas e que não se está a desviar dos objectivos definidos. Discuta os problemas com o utilizador. Esclareça situações que possa observar no ambiente. Faça sugestões e observações baseadas em conhecimento teórico e familiarização com outros sistemas.

Entrevista e Compilação
O guião da entrevista não deve ser demasiado restritivo. Depois de estabelecida uma ligação positiva com o entrevistado, é normal que a entrevista acabe por entrar numa dinâmica própria. Após a realização das entrevistas, o analista já deve ter ficado com um leque de necessidades identificadas. Para compilar o conjunto de necessidades gerais dos utilizadores entrevistados deve ser usado um método que pode ser denominado de "Resumo do Analista".

Vantagens É a forma mais fácil de descobrir as necessidades de um sistema, pois passa por perguntar directamente aos stakeholders. Permite uma melhor compreensão do problema e seu domínio. Pode ser utilizada em praticamente qualquer situação. É uma solução de baixo custo. Uma vez bem definidas as perguntas e estrutura da entrevista, é possível encontrar requisitos reais, e não apenas necessidades de alto nível. É um método que aproxima as entidades envolvidas no projecto.

Desvantagens Consome bastante tempo.
Utilizadores diferentes podem ter necessidades contraditórias. Pode originar grandes discrepâncias entre o funcionamento actual do processo de negócio, e o plano para o futuro.

Workshops de Requisitos

Workshops uma workshop de requisitos é uma técnica de grupo para o debate e acordo das questões asociadas à identificação dos requisitos levada a cabo através da formação de um grupo de representantes dos stakeholders facilitada por alguém com competência para conduzir o processo de identificação e análise de requisitos

Workshops preparação "vender" o conceito
assegurar a participação dos stakeholders adequados garantir os aspectos logísticos fornecer materiais para discussão antecipadamente escolher o facilitador estabelecer uma agenda

Note-se que uma workshop, apesar de se assemelhar a uma reunião, difere em alguns pontos:
Reuniões são lideradas por um gestor (líder, que geralmente, faz pouca preparação). As workshops são lideradas por um facilitador neutro que se prepara intensivamente; As reuniões não requerem trabalho prévio por parte da assistência. As workshops requerem muito trabalho prévio, incluíndo a criação de produtos que servem de candidatos a inputs do workshop; As decisões numa reunião são tomadas pelo gestor, e podem não ser tópico de discussão. Numa workshop cada decisão está associada a uma regra. Existe um processo de decisão e a tomada de decisão pode estar associada a uma ou mais pessoas (mas não ao facilitador); As reuniões prendem-se com troca de informação. Já ás workshops prendem-se com a descoberta e criação da informação;

Note-se que uma workshop, apesar de se assemelhar a uma reunião, difere em alguns pontos:
Numa reunião existe pouca interacção entre os presentes. Nas workshops a participação é intensa e variada e os participantes realizam actividades individualmente, como membros de sub-grupos, ou colectivamente; Reuniões não permitem quase nenhuns momentos de descontracção. Já as workshops encorajam a descontracção como forma de promoção da inovação e do trabalho de equipa. As reuniões normalmente não envolvem a prodção de documentação. Já nas workshops os participantes criam e verificam documentos como p.ex diagramas de casos de uso; As reuniões usam raramente meios visuais. Nas workshops sao fortemente utilizados meios visuais como posters, post-it, cartões diagramas.

Planear uma workshop Planear o horário da sessão: em que altura do dia se realizará, quanto tempo durará, ... Planear o local: a sessão deve decorrer num local arejado, com boa luz; as cadeiras devem estar dispostas de forma que todos os participantes se vejam Planear as regras básicas: Todos os membros devem participar o máximo possível Como a sessão é só uma, é importante que seja estabelecido um conjunto de regras básicas que regulem a participação. Ex: nunca se deve desviar do objectivo da sessão, nunca se deve desviar da questão base do momento, não se deve ultrapassar a vez dos outros, ...

Planear uma workshop Planear a agenda a seguir:
Dar as boas-vindas Rever a agenda Rever o objectivo da sessão Rever as regras básicas de participação Fazer uma introdução ao projecto Lançar as questões e conduzir as respostas Terminar agradecendo a participação Escolher os participantes (ver quadro abaixo) Planear a gravação da sessão Deve estar presente um ajudante (co-facilitador) que vá tirando notas ao longo da workshop Para além disso, pode ser útil gravar a sessão em suporte áudio ou video

Conduzir uma workshop De seguida será descrita uma possível abordagem ao modo como o mediador deverá conduzir a sessão:

Conduzir uma workshop Forming - Fase de orientação do grupo e introdução dos objectivos da sessão. Nesta fase o facilitador deve: Apresentar-se e apresentar o co-facilitador Agradecer a disponibilidade das pessoas Explicar os modos de gravação da sessão (só papel, gravador audio ou video) Apresentar/relembrar a agenda Storming - divulgação de todas as ideias que os intervenientes possam ter, mesmo que estas sejam incompatíveis com outras áreas de negócio ou mesmo com o sistema que foi inicialmente idealizado. O facilitador deve: Introduzir todas as questões antes de se iniciar o debate. Dar algum tempo aos participantes para pensarem sobre cada uma (e registarem as suas respostas). De seguida conduzir a discussão à volta das respostas a cada questão, sendo tratada uma de cada vez Quando terminada uma questão, o facilitador deve fazer um breve resumo sobre as respostas dadas e a conclusão a que se chegou (pode ser o co-facilitador a fazer isto)

Conduzir uma workshop Norming - Promover a harmonia, a compreensão e o apoio das ideias uns dos outros, aumentando a coesão dos grupos intervenientes. O facilitador deve: Garantir que as regras básicas de participação são respeitadas, dando voz a todos os participantes O facilitador não deve participar no debate/discussão (nunca justificar a sua posição)... O seu papel fundamental é ouvir e coleccionar informação Assegurar a participação uniforme - se 1/2 pessoas estão a liderar a discussão, o facilitador deve promover e incentivar os outros intervenientes, chamando-os a responder. Uma boa abordagem é usar uma mesa redonda, seguindo uma direcção, dando a cada participante 1 min para transmitir a sua opinião. Performing - Nesta fase já deverá estar interiorizado no pensamento dos stakeholders uma actuação como equipa. Aqui já deverão emergir soluções. Os requisitos já deverão ser tratados com mais detalhe e ser prioritizados.

Conduzir uma workshop Adjourning - Deverá ser feita uma retrospectiva do projecto, e das soluções encontradas. Esta fase não deverá ser descurada, já que é essencial para que os intervenientes percebam que o papel que desempenharam foi tomado em conta e é essencial para este e futuros projectos. O facilitador deve: Notificar os participantes da breve recepção de uma cópia do relatório resultante da sessão (contendo as principais propostas e conclusões) Agradecer aos participantes a sua presença e participação Terminar a sessão

Como tirar mais proveito dos Workshops?
As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming como forma de gerar um elevado número de ideias numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentação que reflicta os requisitos e decisões tomadas sobre o sistema a implementar.

Brainstorming brainstorming é uma técnica para a geração de novas ideias por um conjuto de pessoas encoraja a participação de todos permite o aproveitamento e refinamento de outras ideias pode ser bastante produtiva (nº de ideias/hora) o resultado pode ser um conjunto de soluções encoraja o pensamento livre... (maluquices...)

Brainstorming: reduzir ideias
"podar" ideias agrupar ideias definir as características de cada ideia estabelecer prioridades

Brainstorming regras do brainstorming não permitir críticas ou debate
deixar a imaginação voar... gerar tantas ideias quanto for possível mutar e combinar ideias Atraso do julgamento Criatividade em quantidade e qualidade

Há 3 principais partes no brainstorming:
Encontrar os factos, Geração da ideia, Encontrar a solução.

Da busca dos factos na resolução de um problema existem duas sub partes: Definição do problema, Preparação.

Inicialmente, define-se o problema. Poderá ser necessário subdividir o problema em várias partes. A técnica de Brainstorming funciona para problemas que têm muitas soluções possíveis tal como a geração de ideias para o seu desenho. Depois é necessário colher toda a informação que pode relacionar-se com o problema. Geração de idéias por brainstorming. Busca da solução. Avaliar e seleccionar as melhores idéias.

Brainstorming na educação
A técnica de brainstorming não é uma actividade exclusiva de um ambiente empresarial: pelo contrário, na escola esta, pode ser uma técnica muito importante na educação dos estudantes. Este grande ou pequeno grupo de actividade encoraja os estudantes a manterem-se focados num tópico e contribuir para uma fluidez de ideias em liberdade. O professor pode começar por propôr uma questão ou problema, ou introduzindo um tópico. Os estudantes, depois expressam e divulgam as possíevis respostas e soluções, palavras, expressões ou ideias relevantes.

CENÁRIOS

cenários abordagem para colocar os interessados num sistema perante uma situação realista em que simulam ou apenas antevêem a sua interacção com o sistema materializam-se em histórias que explicam como é que o sistema poderá ser usado

Cenários uma forma de levar as pessoas a imaginar o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento e da interacção que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos:

Cenários Estado do sistema no início do cenário.
Sequência de eventos esperada (na ausência de erros) no cenário. Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados.

Cenários Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados. Outras actividades que podem estar a ser executadas ao mesmo tempo que as deste cenário. Estado do sistema depois de o cenário terminar.

Cenários: conteúdo descrição do sistema antes de se entrar no cenário
outras actividades que ocorrem ao mesmo tempo informação sobre fluxo normal de eventos excepções ao fluxo normal de eventos descrição do estado do sistema depois de completado o cenário

Cenários: definição mais definições
uma história ou exemplo de eventos retirados da experiência do mundo real; incluem detalhes do contexto do sistema (cenas) um caminho ou instância de um modelo (normalmente de casos de utilização) a visão futura de um sistema a ser desenhado, com sequências de comportamento e descrições contextuais Sutcliffe, 2002

Cenários: objectivos identificar e clarificar requisitos
adicionar detalhe a requisitos mais gerais compreender a relação entre requisitos validar requisitos compreender um requisito no seu contexto de utilização verificar se a sua relação com outros requisitos faz sentido

Principais vantagens do uso de cenários em Engenharia de Requisitos
Tem em conta o ponto de vista do utilizador Especificações parciais Fácil de compreender Ciclos de feedback curtos Servir de base para os testes do sistema

CENÁRIOS: conclusão Engenharia de requisitos baseada em cenários é definitavamente um passo na direcção certa. Em particular, cenários são uma chave que permite um novo estilo de engenharia de requisitos evolucionário e incremental.

CENÁRIOS: conclusão Os cenários focam-se nos utilizadores, em descrições concretas e instâncias específicas. O desenho de sistemas baseado em cenários atribui um grande ênfase aos utilizadores; articula qual o seu papel, o que fazem, como fazem, e sobre que circunstâncias o fazem. Um cenário é uma descrição concreta do trabalho e actividades, descrevendo assim uma instância específica e um caso de uso.

Cenários versus casos de uso
Existem diferentes opiniões sobre a relação existente entre casos de uso e cenários: Há quem os considere sinónimos Há quem considere que um cenário corresponde a um conjunto de casos de uso (fluxo normal de eventos, e cada fluxo excepcional seriam casos de uso separados) Há quem considere que um caso de uso corresponde a um conjunto de cenários Em UML, um caso de uso admite variantes, podendo-se considerar cada variante como um cenário Cada cenário pode ser representado por um diagrama de interacção (normalmente um diagrama de sequência)

cenários: exemplo – reservar livro através do site da biblioteca
Entrar no sistema (log on) Procurar o livro pretendido por autor, título ou ISBN Seleccionar um dos exemplares disponíveis Dar ordem para reservar esse exemplar Seleccionar o modo de entrega: levantamento na biblioteca, ou envio por funcionário Sair do sistema (logout)

PROTOTIPAGEM

Prototipagem um protótipo é uma versão inicial de um sistema usado para apoiar essencialmente as fases de identificação, análise e validação de requisitos

Prototipagem características desenvolvimento rápido
funcionalidades limitadas requisitos não funcionais pouco considerados várias tecnologias pode ir desde maquetas a protótipos evolutivos

Prototipagem: custos a decisão de usar a prototipagem deve ser tomada com recurso a uma análise custo-benefício custos envolvidos na prototipagem formação, desenvolvimento, prazos mais alargados, protótipos incompletos

Prototipagem: benefícios
benefício principal os clientes e utilizadores finais têm contacto com um sistema realista cedo o que lhes permite compreender melhor os requisitos que pretendem identificar e analisar outros benefícios ajuda a estabelecer a viabilidade e utilidade do sistema é a única forma efectiva de desenvolver IPC pode ser usado na validação o estudo cuidadoso dos requisitos ajuda a revelar inconsistências e lacunas

Prototipagem: tipos Existem 3 tipos de protótipos (Sommerville, Sawyer, 1997): Protótipo em papel: é desenvolvido um conjunto de interfaces associadas a cenários de utilização que são apresentados aos utilizadores. Este tipo de prototipagem é barata e eficiente (Rogers, Sharp, Preece, 2002)(Kotonya, Sommerville 1998). È mais indicada quando o sistema a desenvolver é software. Não é necessário desenvolver software executável. Os analistas e utilizadores percorrem estes cenários, simulando a utilização do sistema, sendo analisado as reacções dos utilizadores, a informação requerida e a forma de interacção com o sistema. Este método é muito eficiente para sistemas interactivos. Este tipo de protótipo é de baixa fidelidade (Rogers, Sharp, Preece, 2002).

Prototipagem: tipos Protótipo “wizard of Oz”: uma pessoa simula as respostas dos sistemas em resposta as acções dos utilizadores. Este tipo de prototipagem é relativamente barata visto apenas a interface do sistema ter de ser desenvolvida (Kotonya, Sommerville 1998). Os utilizadores interagem com o que parece ser o sistema em que as suas acções são analisadas por um pessoa que simula a resposta do sistema. É particularmente útil quando o sistema a desenvolver tem por base numa interface existente. Este tipo de protótipo é de baixa fidelidade (Rogers, Sharp, Preece, 2002).

Prototipagem: tipos Protótipo automático: é utilizado linguagens 4GL ou outras linguagens que permitem um rápido desenvolvimento de protótipos executáveis. Este tipo de prototipagem é a mais cara (Kotonya, Sommerville 1998). Envolve o desenvolvimento de software, recorrendo a linguagens de programação de alto nível, que simule as funcionalidades do sistema. O problema principal do desenvolvimento de protótipos executáveis é de os Stakeholders não simularem a real utilização do sistema final devido ao facto de muitos dos requisitos não funcionais do sistema não estarem provavelmente implementados em conjunção com falta de treino. Um outro problema poderá surgir se o desenvolvimento do sistema estiver atrasado. Nesta situação pode ocorrer a tentação de prosseguir o desenvolvimento do protótipo com todas as nefastas consequências anteriormente referidas.

Prototipagem: tipos prototipagem evolutiva
o objectivo é proporcionar um sistema "produtivo" o mais rápido possível ao cliente os requisitos objecto dos protótipos iniciais deverão ser aqueles mais facilmente compreendidos e que podem dar rapidamente um valor acrescentado útil ao utilizador

ESTUDOS ETNOGRÁFICOS

Etnografia Técnica onde o sociólogo gasta um tempo considerável no ambiente de trabalho a observar e a anotar como os participantes envolvidos trabalham Interacções implícitas são reveladas. As pessoas não têm que explicar o seu trabalho

Estudos Etnográficos:
Este tipo de estudos são uma análise da componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo.

Estudos Etnográficos:
Através de uma observação directa das actividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de registos áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o stakeholder observado desempenha as suas funções "correctamente", pelo que convém ter algum cuidado na escolha do(s) stakeholder(s) a observar.

Observação e Análise Social
estudos etnográficos e identificação de requisitos há requisitos que não se conseguem identificar através das técnicas convencionais os estudos etnográficos ajudam a fazer emergir requisitos derivados de formas rotineiras e tácitas de trabalhar

Observação e Análise Social
grande parte dos sistemas que desenvolvemos visam apoiar o trabalho das pessoas o trabalho é uma actividade social que envolve grupos de pessoas que cooperam para levar a cabo diferentes tarefas Kotonya, 1998

observação e análise social
as pessoas encontram frequentemente dificuldade em tornar explícita a forma como realizam tarefas e como trabalham em conjunto com outros quando as tarefas se tornam rotina e as pessoas tendem a não pensar nelas conscientemente, torna-se difícil que articulem como é que o trabalho é realizado as pessoas usam artefactos (ferramentas, documentos, etc.) de uma forma intuitiva

Estudos Etnográficos algumas directrizes
assumir que as pessoas que se estão a estudar são boas a realizar o seu trabalho estabelecer relações de confiança com as pessoas envolvidas no estudo; os analistas devem ser externos à organização escrever notas detalhadas e regulares das práticas de trabalho estudadas realizar entrevistas abertas não recorrer demasiado às gravações vídeo e áudio, porque são difíceis de tratar em tempo útil realizar sessões de crítica por parte de elementos externos ao projecto

observação e análise social
estudos etnográficos observação detalhada das práticas sociais de uma sociedade uma compreensao total destas práticas só é possível pela observação do detalhe e a partir do interior da comunidade um grupo de funcionários numa biblioteca, num banco, num laboratório têm características dos elementos de uma sociedade

Estudos Etnográficos reuniões de análise crítica etnográfica
etnografia focada prototipagem protótipo experiências dos utilizadores

ANÁLISE E NEGOCIAÇÃO

O processo de engenharia de requisitos modelo de actividades de alto nível
documento de requisitos identificação, descoberta de requisitos análise e negociação de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc. documentação de requisitos validação de requisitos

Análise e Negociação de Requisitos objectivos
actividades 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, na fase de identificação de requisitos já se desenrolam actividades de análise e negociação análise e negociação de requisitos são actividades 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

Análise de Requisitos necessidade, consistência e completude
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...

Análise de Requisitos técnicas: check-lists
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 mais do que 10 items evoluem com a experiência ganha no processo de análise

Análise de Requisitos técnicas: check-lists
exemplo 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 standard? o requisito está de acordo com os objectivos do negócio? o requisito é ambíguo? o requisito é realista? o requisito é "testável"? Sutcliffe, 2002

Análise de Requisitos análise quanto ao âmbito
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 Requisitos 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

Análise de Requisitos organização dos requisitos
hierarquização relações de composição ou "pai-> filhos" ou "requisito-> sub-requisito" os requisitos são definidos a vários níveis de abstracção a organização em hierarquias é adequada a uma abordagem iterativa (espiral) ao processo de engenharia de requisitos

Análise de Requisitos hierarquia de requisitos e casos de uso
marcação de consulta (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 utilizador no caso do doente ter outras consultas marcadas (alerta) 1.5 o sistema deve ajudar o utilizador a encontrar vagas (ajuda) (...) Explicar vantagem de organizar requisitos em casos de uso, para facilitar a ponte com o implementador Agrupar casos de uso em módulos (gestão de consultas, ...) Passos de um caso de uso não são normalmente adequados como sub-requisitos

Negociação de Requisitos aspectos gerais
negociação para quê? 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

Negociação de Requisitos 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

Negociação de Requisitos intervenientes 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 actividades depende da qualdade do sistema são tipicamente gestores que usam a informação do sistema para controlar, monitorar e ajustar processos organizacionais

stakeholders terciários gestores de topo que raramente consomem as saídas do sistema (directamente) usam-nas indirectamente para planear e controlar estrategicamente o negócio interessam-se pelo papel que o sistema desempenha na prossecução dos objectivos estratégicos do negócio tais como aumentar a vantagem competitiva ou melhorar o serviço ao cliente

Negociação de Requisitos gerir a negociação
problemas num processo de negociação separar os aspectos a debater das questões pessoais falta de entendimento partilhado e de pontos de vista pessoais atitudes interpessoais

Negociação de Requisitos técnicas para gerir a negociação
lidar com os ataques pessoais evitá-los... se acontecerem: mudar de assunto, fazer um intervalo... resolver o problema fora da reunião

bloqueio reacções negativas sem justificação: "isso não resulta", "não se pode fazer", "dá muito trabalho“. desafiar os participantes a justificarem a sua posição negativa

conflitos entre grupos choque de pontos de vista entre grupos exemplos: qualidade vs. prazos, custos vs. desenvolvimento, segurança vs. acesso, complexidade funcional vs. usabilidade, etc. deferir decisões, os ânimos arrefecem...

outras técnicas testar e provar assunções (pressupostos) relaxar restrições tentar encontrar potenciais benefícios para todos evitar tomar partidos

ESPECIFICAÇÃO E DOCUMENTAÇÃO

+ protótipo documento de requisitos identificação, descoberta de requisitos + modelo análise e negociação de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc. documentação de requisitos validação de requisitos

Documento de Requisitos
O que é um Documento de Requisitos? é uma descrição oficial dos requisitos de um sistema para os clientes, utilizadores e desenvolvedores outras designações: especificação funcional, definição de requisitos, especificação de requisitos, caderno de encargos

como se escreve um Documento de Requisitos? depende de quem o escreve, para quem, onde, ... normalmente é escrito em linguagem natural e pode ser complementado com diagramas, tabelas, fotografias, imagens, etc. existem directrizes e recomendações para a escrita de documentos de requisitos o grau de detalhe depende de quem o escreve, da organização em que está inserido, do seu propósito,

Documento de Requisitos é usado para comunicar o que se pretende que um determinado sistema faça destina-se aos clientes, utilizadores, gestores e desenvolvedores do eventual sistema especifica que serviços o sistema deve prestar, as propriedades do sistema (fiabilidade, eficiência, etc.) e restrições impostas à operação e desenvolvimento do sistema tanto pode ser um documento muito sucinto e genérico como um documento extenso e muito detalhado.

O que é que normalmente se encontra num documento de requisitos? uma visão geral do sistema e dos benefícios decorrentes do desenvolvimento do sistema um glossário explicando os termos técnicos usados uma definição dos serviços ou requisitos funcionais do sistema uma definição das propriedades do sistema (requisitos não-funcionais) tais como fiabilidade, segurança, etc.

O que é que normalmente se encontra num documento de requisitos? as restrições à operação do sistema e ao processo de desenvolvimento uma definição do ambiente em que o sistema vai operar e as mudanças previstas para esse ambiente especificações detalhadas recorrendo a modelos e outras ferramentas

Estrutura sugerida por IEEE/ANSI ( ) 1. Introdução 1.1 Propósito do documento 1.2 Âmbito do sistema 1.3 Definições, acrónimos e abreviaturas 1.4 Referências 1.5 Resenha do resto do documento

Estrutura sugerida por IEEE/ANSI ( ) (cont.) 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos utilizadores 2.4 Restrições gerais 2.5 Assunções e dependências

Estrutura sugerida por IEEE/ANSI ( ) (cont.) 3. Requisitos específicos requisitos funcionais, requisitos não funcionais, requisitos da interface com o utilizador: funcionalidade, interfaces externas, requisitos de desempenho, restrições de concepção, atributos do sistema, características de qualidade, ... Apêndices Índice

Orientações explicar como se usa o documento descrever um ou mais cenários de utilização definir claramente os termos especializados formatar o documento para uma boa legibilidade ajudar os leitores a encontrar informação fazer o documento fácil de alterar

Manual do Utilizador como Documento de Requisitos
Steve McConnel, no seu livro "Software Project Survival Guide", defende que, na maioria dos situações, é mais vantajoso documentar os requisitos através de um manual do utilizador e um protótipo da interface com o utilizador, facilmente percebidos por todos, do que através de um documento formal de requisitos (documento formal deve ser apenas um complemento)

VALIDAÇÃO DE REQUISITOS

documento de requisitos identificação, descoberta de requisitos análise e negociação de requisitos necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc. documentação de requisitos validação de requisitos

Validação de Requisitos
Consiste em demonstrar que os requisitos definem o sistema que o cliente realmente quer.

Revisões de Requisitos
Revisões regulares devem ser realizadas enquanto a definição dos requisitos está sendo formulada Ambos o cliente e o analista devem estar envolvidos nas revisões

O processo de Engenharia de Requisitos validação de Requisitos
validação de requisitos diz respeito à verificação dos requisitos quanto à sua consistência, completude e precisão envolve revisão de requisitos prototipagem validação de modelos teste de requisitos

Validação de Requisitos análise vs. validação
análise e negociação de requisitos assegurar que os requisitos vão ao encontro das necessidades dos stakeholders requisitos em "bruto", informais e pouco estruturados, escritos numa mistura de notações stakeholders validação de requisitos draft final do documento de requisitos, isento de inconsistência e incompletude, segue normas de qualidade, assegurar que os requisitos estão correctamente descritos temos os requisitos certos? temos os requisitos correctamente?

Validação de Requisitos análise vs. validação
exemplos de problemas que aparecem na fase de validação não conformidade com normas de qualidade requisitos mal descritos, ambíguos erros na modelação do sistema ou problema conflictos entre requisitos que não foram detectados no processo de análise

Validação de Requisitos processo de validação
documento de requisitos lista de problemas validação de requisitos normas da organização conhecimento organizacional acções acordadas Kotonya, 1998

Validação de Requisitos Revisão de requisitos
planear revisão distribuir documentos preparar para a revisão reunião de revisão acções de continuidade rever o documento Kotonya, 1998

Validação de Requisitos revisão de requisitos
reunião de revisão de requisitos a reunião de revisão é uma reunião formal deve ser conduzida por alguém que não esteve envolvido na produção dos requisitos cada requisito deve ser apresentado à vez para discussão pelo grupo os problemas identificados são registados para posterior discussão

Validação de Requisitos revisão de requisitos
acções problemas clarificação, reescrita dos requisitos requisitos mal escritos descobrir a informação que falta no documento falta de informação conflictos os stakeholders devem negociar para resolver o conflicto requisitos não realistas o requisito deve ser modificado ou removido

Validação de Requisitos revisão de requisitos: equipa
especialista do domínio utilizador-final ou representante equipa de revisão de requisitos representante do cliente engenheiro de requisitos responsáveis pelo desenho do sistema

Validação de Requisitos revisão de requisitos: checklists
checklists de revisão devem ser genéricas não devem incidir sobre requisitos individualmente mas com as propriedades de qualidade do documento como um todo e com as relações entre requisitos

atributos de qualidade dos requisitos compreensibilidade redundância completude ambiguidade consistência organização conformidade com as normas rastreabilidade

Validação de Requisitos prototipagem
se num projecto já foram usados protótipos para a identificação de requisitos, então faz sentido que o sejam também na validação

seleccionar os testadores do protótipo desenvolver cenários de teste executar cenários documentar problemas documentar e estender os protótipos Kotonya, 1998

a reescrita dos requisitos noutro formato pode ajudar a validá-los é necessário compreendê-los bem o que pode revelar conflictos, omissões e inconsistências os manuais de utilização podem começar a ser produzidos na fase de validação (manual do protótipo) descrição das funcionalidades implementadas e da forma de as aceder (interfaces) menção às partes do sistema não implementadas como recuperar de dificuldades como instalar o protótipo

Validação de Requisitos validação de modelos
parte da especificação de requisitos de um sistema pode ser constituída por vários modelos a validação de modelos tem como objectivos 1. avaliar individualmente a consistência de cada modelo 2. avaliar a consistência externa (entre modelos) 3. mostrar que os modelos reflectem os requisitos reais dos stakeholders

Validação de Requisitos teste de requisitos
um requisito "testável" significa que se pode definir um ou mais testes a realizar no sistema final de forma a poder ser verificado se o sistema cumpre o requisito cada requisito funcional no documento de requisitos deve ser analisado e um teste ser definido de forma a ser verificado objectivamente se o sistema satisfaz o requisito

Validação de Requisitos teste de requisitos
registo de teste 1. identificador do requisito 2. requisitos relacionados 3. descrição do teste 4. problemas na realização do teste 5. comentários e recomendações

Verificação Automatizada de Consistência
Requisitos em uma linguagem formal Relatório dos problemas com os Requisitos Processador de requisitos Analisador de requisitos Bases de dados de requisitos

Erros nos requisitos custam caro, portanto a sua validação é importante corrigir um erro de requisitos = 100 x corrigir erro de implementação

“Checar” requisitos Consistência. Há conflitos de requisitos? Validade. O sistema provê as funções que atendem as necessidades do cliente? Completude. Todas as funções requeridas pelo cliente estão incluídas? Realismo. Os requisitos podem ser implementados com o orçamento e tecnologia disponíveis? Verificabilidade. Os requisitos podem ser verificados?

Técnicas de Validação de Requisitos
Revisões de requisitos Análise manual sistemática dos requisitos Prototipação Utilização de um modelo executável do sistema

Técnicas de Validação de Requisitos
Geração de casos de teste Desenvolver testes para verificar os requisitos Análise automatizada da consistência Verificar a consistência de uma descrição de requisitos estruturada

Revisões de Requisitos
Revisões devem se preocupar com: Verificabilidade. O requisito é realisticamente testável? Compreensibilidade. O requisito está bem compreendido? Traço. A origem do requisito está claramente identificada? Adaptabilidade. O requisito pode ser mudado sem grande impacto noutros requisitos?

Requisitos Voláteis e Permanentes
Mudança provável durante ou depois do desenvolvimento Ex: Requisitos dos serviços bancários Tipos de requisitos voláteis: Mutáveis: mudanças no ambiente Emergentes: durante o desenvolvimento Consequentes: resulta da introdução do sistema de computador Compatibilidade: depende de sistemas ou processos particulares dentro da organização

GESTÃO DE REQUISITOS

Gestão de Requisitos É o processo de gerir as mudanças nos requisitos durante o processo de engenharia de requisitos e o processo de desenvolvimento de sistemas

Gestão de Requisitos Requisitos são inevitavelmente incompletos e inconsistentes Novos requisitos emergem durante o processo, pois as necessidades do negócio mudam e a compreensão dos requisitos melhora Pode haver contradição no requisitos de viewpoints diferentes

Gestão de Requisitos Mudança de requisitos
A prioridade dos requisitos de viewpoints diferentes pode mudar durante o processo de desenvolvimento O negócio pode sofrer alterações durante o desenvolvimento

Evolução de Requisitos
Compreensão inicial do problema modificada do Requisitos iniciais modificados Tempo

Plano de Gestão de Requisitos
Durante o processo de engenharia de requisitos deve-se planear: A identificação dos requisitos Um processo de gestão de mudança Políticas de traço Suporte de ferramentas CASE

referências e informação adicional
Gerald Kotonya, Ian Sommerville, Requirements Engineering – Processes and Techniques, Wiley, 1998 (capítulo 3) User Centerd Requirements Engineering: Theory and Practice. Alistair Stutcliffe. Springer Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares

ENGENHARIA DE REQUISITOS

Apresentações semelhantes

Apresentação em tema: "ENGENHARIA DE REQUISITOS"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

ENGENHARIA DE REQUISITOS

Apresentações semelhantes

Apresentação em tema: "ENGENHARIA DE REQUISITOS"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback