Baixe o app para aproveitar ainda mais
Prévia do material em texto
Engenharia de Software I Flávio Ferro Engenharia de Software I Flávio Ferro FACITEC - Faculdade de Ciências Sociais e Tecnológicas Bacharelado em Sistemas de Informação Engenharia de Software I Flávio Ferro Engenharia de Requisitos 1 Identificar os conceitos que permitem levantar requisitos de sistema e especificá-los. 2 Identificar os elementos da análise e da negociação de requisitos. 3 Identificar as principais características da especificação de requisitos. 4 Descrever o processo de validação e gestão de requisitos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Importância dos Requisitos Requisitos são descrições das necessidades ou dos desejos para um produto. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Importância dos Requisitos Engenharia de Software I Flávio Ferro Engenharia de Requisitos Engenharia de Software I Flávio Ferro Engenharia de Requisitos A Engenharia de Requisitos tem sido reconhecida como uma das mais importantes disciplinas em Engenharia de Software devido a maior parte dos problemas de desenvolvimento de software são originados por definições equivocadas de requisitos. As atividades de Engenharia de Requisitos são executadas de forma mais intensa nas etapas iniciais do desenvolvimento de software e direcionam fortemente o uso dos recursos ao longo de todo o desenvolvimento e, depois, ao longo de todo o ciclo de vida do produto. Por isso, problemas de correção mais dispendiosa e de maior impacto negativo no projeto freqüentemente são decorrência de falhas em Engenharia de Requisitos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Conforme pode ser observado abaixo, as atividades que compõem o Processo de Engenharia de Requisitos são um conjunto de boas práticas que apóiam a sua execução: elicitação; análise e negociação; especificação e documentação; validação. Normalmente, falhas na realização destas atividades resultam em documentos de requisitos inconsistentes, incompletos e conseqüentemente produtos de software de baixa qualidade. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 1 - Elicitação de Requisitos 1.1 - Conceitos Os requisitos de um projeto de software formam a base para o planejamento, o acompanhamento do desenvolvimento, e a aceitação dos resultados do projeto de software. Portanto, é muito importante que esses requisitos estejam bem definidos e acordados entre os envolvidos. Se os requisitos são especificados de forma incompleta ou inconsistente, os artefatos resultantes das próximas etapas do processo de software (por exemplo, projeto, implementação e testes) não terão a qualidade desejada. Quanto mais tarde os problemas na especificação de requisitos forem detectados no processo de desenvolvimento, maior será o custo de correção do software. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Com um processo bem definido pode-se obter (elicitar), entender e validar as necessidades e expectativas do cliente e, posteriormente, documentá- las no Documento de Requisitos de Sistema (DRS). O documento de requisitos descreve os serviços e funções que o sistema deve prover, as limitações sobre as quais o sistema deve operar, as propriedades gerais do sistema, isto é, limitações nas propriedades emergentes, as definições de outros sistemas com os quais o sistema deve integrar, as limitações no processo usado para desenvolver o sistema e as descrições sobre o hardware no qual o sistema irá executar. Engenharia de Software I Flávio Ferro Engenharia de Requisitos O DRS constitui a base para as estimativas de tamanho, de esforço, de cronograma, e de custo. Assim, quando as estimativas de tamanho, prazo e custo são gerados a partir de requisitos incompletos, ambíguos, omissos ou inconsistentes, as estimativas não serão precisas resultando em prejuízo e descumprimento dos prazos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Os requisitos descrevem ‘o que o sistema deve fazer’ - e também ‘o que ele não deve fazer’ - sem dizer (ou detalhar) ‘o como fazer’ e devem ter as seguintes características: Verificáveis: se podemos ou não verificar o atendimento de um dado requisito. A verificação ocorre mediante procedimentos de teste, experimentos e provas ou por meio de acordos de aceitação previamente definidos; Precisos: requisitos devem ser expressos precisamente, de outro modo não se pode garantir que irão ser interpretados da mesma forma por todas as pessoas envolvidas; Engenharia de Software I Flávio Ferro Engenharia de Requisitos Corretos: requisitos devem expressar corretamente o que é requerido; Consistentes: requisitos não devem conter conflitos; Completos: tudo que é requerido deve ser expresso; Compreensíveis: todas as pessoas envolvidas devem entender, no seu nível de participação, o que está expresso em um requisito; Manuteníveis: podemos alterar com facilidade um requisito quando este muda ou evolui. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Quando a organização não dispõe deste processo formalmente definido e amplamente divulgado, os desenvolvedores elaboram as especificações de requisitos de uma forma empírica, executando atividades não padronizadas e definidas individualmente. Se isto ocorre, a qualidade da especificação dependerá exclusivamente da experiência e formação das pessoas, havendo assim uma elevada probabilidade de ocorrerem conflitos, incoerências e re-trabalho. Engenharia de Software I Flávio Ferro Engenharia de Requisitos A etapa de elicitação de requisitos corresponde à fase de entendimento do problema. Elicitação é o processo responsável por descobrir informações, compreender os fatos descobertos e adquirir conhecimentos. Para tanto, são utilizadas diversas técnicas que serão vistas posteriormente, como a análise dos fluxos de trabalho dos usuários, a definição dos atributos de qualidade do sistema e o desenvolvimento de mecanismos que possibilitem o reuso de requisitos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Na elicitação de requisitos, a redação de uma declaração de visão e escopo do sistema, a definição dos procedimentos para desenvolvimento dos requisitos, a identificação das classes de usuários e dos diferentes grupos de interesse no sistema, a identificação dos casos de uso constituem boas práticas. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Algumas das atividades envolvidas na análise de requisitos incluem: classificação: agrupamento de requisitos em "módulos"para facilitar a visão global do funcionamento pretendido para o sistema; resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível; priorização: consiste na atribuição de uma "prioridade"a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um fator gerador de conflitos; confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema). Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir para as demais fases. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Na fase de especificação e documentação se dá a produção propriamente dita do documento de especificação de requisitos. Em todos os tipos de especificação há 2 tipos de requisitos a considerar: Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, deuma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido. Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Na fase de validação pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.Corresponde à confirmação dos conhecimentos adquiridos junto aos clientes/usuários. Tudo isso é feito sob uma gerência responsável pelo acompanhamento das fases por meio de avaliação contínua dos resultados obtidos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos São participantes do processo de engenharia de requisitos: 1 Clientes (Usuários) do Sistema: definem os requisitos e verificam se eles satisfazem suas necessidades; 2 Líderes de Projeto: definem e usam os requisitos para planejarem uma proposta e o processo de desenvolvimento do sistema; 3 Analistas e Analistas Desenvolvedores: usam os requisitos para entender e especificar o sistema em construção; 4 Analistas de teste do sistema: usam os requisitos para desenvolver testes de validação do sistema; Engenharia de Software I Flávio Ferro Engenharia de Requisitos 5 Analistas de manutenção do sistema: usam os requisitos para entender o sistema. 6 Representantes da Área de Infra-estrutura: usam requisitos não funcionais para a concepção do sistema. 7 Representantes da Área de Operação de Sistemas: usam requisitos não funcionais para a implantação do sistema. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 1.2 - Atividades da elicitação de requisitos Conforme pode ser visto na Figura 2, os componentes da elicitação de requisitos são: entendimento do domínio da aplicação, entendimento do problema a ser resolvido, entendimento do contexto do negócio e entendimento das necessidades das partes interessadas (stakeholders). Engenharia de Software I Flávio Ferro Engenharia de Requisitos Entender o domínio da aplicação é o ponto inicial de todo o processo de análise. Os usuários e desenvolvedores possuem visões diferentes e fazem suposições diferentes sobre a natureza da solução. Uma mesma linguagem compartilhada tanto por desenvolvedor como por usuário melhora a comunicação e o entendimento entre ambos. Em outras palavras, a análise do domínio consiste em estudá-lo de forma a identificar, formalizar e classificar as características elementares (objeto, regras e limitações). Engenharia de Software I Flávio Ferro Engenharia de Requisitos O entendimento do problema corresponde a compreensão detalhada da situação/problema existente que demanda uma solução que seja a mais apropriada e otimizada possível. O entendimento do contexto do negócio corresponde a compreensão de como os sistemas envolvidos interagem entre si e contribuem de forma direta ou indireta com os objetivos do negócio em questão. Por último, é imprescindível entender detalhadamente as necessidades específicas dos usuários e demais pessoas que requerem suporte do sistema em seu trabalho. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 1.3 - Dificuldades da elicitação As principais dificuldades na atividade de elicitação de requisitos, em geral, estão relacionadas à postura dos usuários diante da situação atual e do sistema proposto, são elas: Os usuários podem não ter uma idéia exata do sistema por eles requerido ou mesmo das soluções possíveis a serem oferecidas pelo sistema. Em geral, os usuários têm dificuldades para descrever seus conhecimentos sobre o domínio do problema. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Usuários e analistas têm pontos de vista diferentes referente ao problema e a possíveis soluções devido às diferentes formações profissionais. Os usuários podem ter restrições de uso em relação ao novo sistema e, com isso, se recusarem a participar da elicitação de requisitos, ou mesmo fornecer informações erradas. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 1.4 - Técnicas de elicitação As Técnicas de Elicitação correspondem às técnicas que podem ser utilizadas para coletar conhecimento sobre os requisitos dos usuários. O conhecimento deve ser estruturado segundo as técnicas de particionamento (agregação dos conhecimentos relacionados), abstração (expressões de alto nível de comportamento de sistema que permitem identificar generalidades) e projeção (organização das informações de acordo com futuras perspectivas). Engenharia de Software I Flávio Ferro Engenharia de Requisitos Alguns problemas, no entanto, devem ser superados como, por exemplo, o tempo reduzido dedicado para a etapa de elicitação, a falta de preparo dos engenheiros quanto às técnicas de elicitação e a própria postura dos stakeholders que nem sempre se encontram totalmente convencidos da necessidade de um novo sistema. De forma prática, o processo de elicitação de requisitos deve começar pelas perguntas óbvias do tipo: ‘o que?’, ‘por quê?’, ‘por quem?’, ‘como?’, porém existem técnicas que podem ser seguidas para obter as informações necessárias de forma precisa e completa. Engenharia de Software I Flávio Ferro Engenharia de Requisitos As principais técnicas de elicitação são: Técnicas tradicionais - inclui o uso de questionários, de entrevistas e de análise de documentação existente. 1 Questionários - questões pré-estabelecidas são distribuídas para uma amostragem significante e representativa de stakeholders e, por fim, os resultados são avaliados. São extremamente úteis quando a quantidade de stakeholders é grande. 2 Entrevistas - o engenheiro de requisitos ou analista levanta questões relacionadas aos stakeholders e/ou suas necessidades referente ao problema a ser resolvido. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 3 Análise de documentação existente - requer abstração e conhecimento do vocabulário da aplicação para extrair as informações relevantes. A maior vantagem é a facilidade de acesso à grande quantidade de informações. Por outro lado, tem-se grande dispersão das informações e volume de trabalho. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Técnicas de elicitação de grupo - são técnicas de dinâmica de grupo cujo objetivo é entender de forma mais detalhada as necessidades dos usuários, dentre elas, o brainstorming. No brainstorming, os stakeholders são reunidos em ambiente apropriado, onde a participação é encorajada de forma que todas as idéias possam ser declaradas em voz alta (para que os demais sejam influenciados) e escritas (para que não sejam perdidas). Esta técnica é mais eficaz quando cada stakeholder possui uma parte do conhecimento de algum aspecto do problema. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Prototipação - corresponde à implementação parcial e rápida de um sistema enfatizando principalmente a interface visual de forma a coletar informações para o processo de requisitos. O protótipo pode ser descartado ou evoluir para o produto final. Tal técnica é usada para elicitar requisitos quando há um alto grau de incerteza ou quando é necessário um rápido feedback dos usuários. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Técnicas de modelagem - técnica que visa representar os requisitos em modelos conceituais que descrevem as necessidades encontradas na elicitação, ou seja, fornece um modelo específico das informações que serão adquiridas, e usa o modelo para orientar o processo de elicitação. Uma técnica bastante utilizada é o usode cenários para representar as tarefas que os usuários executam normalmente e aquelas que eles desejam executar. Inclui métodos baseados em metas e métodos baseados em cenários. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Etnografia - técnica que prima pela observação dos potenciais usuários em seu ambiente natural. Resulta em uma percepção mais precisa do problema do que simplesmente perguntar aos usuários o que eles fazem. Essa técnica é bastante útil para suporte à automação de uma função pouco ou não automatizada, particularmente quando são disponíveis a observadores treinados sem noções pré-concebidas do problema e de sua solução. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 1.5 - Processos para a elicitação de requisitos Os processos para a Elicitação de Requisitos podem ser observados na Figura 3. Em geral, o processo de Elicitação de requisitos de software recebe novos requisitos por meio de uma Solicitação de serviço ou Solicitação de alteração de requisitos entre outras fontes e, uma vez documentados e analisados, são elaboradas as Matrizes de rastreabilidade e o Documento de requisitos de software (DRS) que, por sua vez, entram em um processo para negociação de prioridades, conforme detalhado a seguir. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Engenharia de Software I Flávio Ferro Engenharia de Requisitos Efetuar a reunião inicial com o cliente - participam da reunião inicial com o cliente todas as partes interessadas (stakeholders). Nessa reunião devem ser obtidos os principais assuntos que deverão estar presentes no Documento de Visão. Entender o domínio da aplicação - a reunião inicial com o cliente fornecerá a base para determinar os principais domínios para proceder o desenvolvimento do sistema. Uma das principais dificuldades enfrentadas pelo desenvolvedor de software é a complexidade do domínio do problema, ou seja, estabelecer um entendimento do domínio da aplicação procurando descobrir o máximo de informações sobre o ambiente onde o sistema atuará; Engenharia de Software I Flávio Ferro Engenharia de Requisitos Identificar as partes interessadas (stakeholders) - ou seja, identificar as pessoas interessadas pelo produto, ou que participarão do seu desenvolvimento. Para cada stakeholder é importante identificar nome e função; Escolher a técnica de elicitação - ao escolher a técnica de elicitação, devem ser consideradas quais as fontes dos requisitos, a disponibilidade e nível de cooperação das pessoas, além dos tipos de requisitos a serem elicitados. A escolha da técnica apropriada para elicitar requisitos depende do tempo e dos recursos disponíveis, assim como do tipo de informação necessária. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Elaborar a lista de Requisitos Candidatos - o objetivo desta atividade é descrever os requisitos relevantes do sistema, ou seja, aqueles que contribuem para atender os objetivos do projeto, de forma a representar as principais necessidades e funcionalidades do sistema, devendo ser incluídos no Documento de Visão. Estudar os Requisitos candidatos, os sistemas similares e os documentos coletados com o cliente - documentos, arquivos e sistemas similares devem ser inspecionados e abstraídos para melhor compreender o contexto do sistema, além de permitir uma avaliação da possibilidade de re-usabilidade de requisitos e de soluções. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Elaborar o glossário - a definição de um glossário é necessária para evitar ambigüidades e facilitar a leitura de documentos do sistema onde os principais termos utilizados no domínio da aplicação e pelos desenvolvedores e usuários devem ser definidos. Elaborar o documento de Visão - deve-se avaliar o conjunto de requisitos essenciais para a definição do Documento de visão do software e este deve incluir o escopo do projeto e suas limitações, bem como as principais características do software a ser desenvolvido. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 2 - Análise e Negociação de Requisitos O objetivo da análise é descobrir problemas, incompletude e inconsistência nos requisitos elicitados. Neste caso, os requisitos normalmente são retornados aos stakeholders para resolução por meio de um processo de negociação. Outro importante objetivo da análise de requisitos é descobrir as interações entre requisitos e informar os conflitos e sobreposições de requisitos. As atividades da análise de requisitos começam com o reconhecimento do problema, a avaliação do problema e síntese da solução (modelagem), a especificação dos requisitos do software e por fim a revisão. Engenharia de Software I Flávio Ferro Engenharia de Requisitos A análise é intercalada com elicitação, pois os problemas são levantados quando os requisitos são elicitados. Além disso, uma lista de verificação de problemas poderá ser utilizada para auxiliar o processo de análise onde cada requisito poderá ser avaliado em contrapartida a esta lista. A lista de verificação da análise consta de basicamente oito itens que conduzem às perguntas que devem ser respondidas na análise dos requisitos. Os itens são: Engenharia de Software I Flávio Ferro Engenharia de Requisitos Projeto prematuro - Os requisitos incluem informação prematura de projeto ou de implementação? Requisitos combinados - A descrição dos requisitos especifica um requisito único ou pode ser desmembrada em vários requisitos diferentes? Requisitos desnecessários - O requisito é realmente imprescindível ou será que é uma mera adição supérflua ao sistema? Engenharia de Software I Flávio Ferro Engenharia de Requisitos Uso de hardware não padronizado - Os requisitos implicam uso de uma plataforma de hardware não padronizada? Para tomar esta decisão, é necessário conhecer os requisitos de plataforma do computador. Está de acordo com os objetivos de negócio - O requisito é consistente com os objetivos de negócio definidos na introdução do documento de requisitos? Engenharia de Software I Flávio Ferro Engenharia de Requisitos Ambigüidade de requisitos - O requisito é ambíguo, ou seja, poderá ser interpretado de forma diferente por pessoas diferentes? Quais são as possibilidades de interpretação dos requisitos? Realismo dos requisitos - O requisito é real no que se refere à tecnologia usada para a implementação do sistema? Teste dos requisitos - Há possibilidade de teste para comprovar se o sistema satisfaz os requisitos? Engenharia de Software I Flávio Ferro Engenharia de Requisitos Durante a negociação e priorização de requisitos (Figura 4), as seguintes atividades são realizadas: Engenharia de Software I Flávio Ferro Engenharia de Requisitos Escolher a técnica de negociação - o processo de negociação de requisitos tenta solucionar conflitos entre usuários sem comprometer a satisfação dos objetivos de cada um. Em geral, os modelos de negociação identificam as principais necessidades de cada usuário, ou seja, atribuem prioridades aos requisitos, em seguida analisam esses resultados para tentar garantir que os requisitos mais críticos sejam atendidos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Priorizar os requisitos - uma vez escolhida a técnica de negociação, a mesma deve ser utilizada não apenas para resolver conflitos, mas também para priorizar os requisitos. Na definição de prioridades para os requisitos, é importante que os riscos e a complexidade dos requisitos sejam observados de forma a minimizar possíveis atrasos nos milestones estabelecidos. Milestones correspondem aos pontos de controle em um cronograma os quais representam a conclusão de um conjunto de tarefas oufase, passiva de aprovação e de formalização por parte do cliente. Os requisitos podem ter três níveis de prioridade: alta, média e baixa. Engenharia de Software I Flávio Ferro Engenharia de Requisitos - Alta: requisitos obrigatórios, ou seja, requisitos que deixam o desenvolvedor sob força de contrato perante o cliente ou entidades externas à equipe de desenvolvimento. - Média: requisitos que possuem importância significativa para o cliente, mas que podem ser negociados com a gerência para serem retirados do escopo, caso não seja viável sua implementação. - Baixa: requisitos de menor importância para a realização dos objetivos do software. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Definir os milestones e os pontos de revisão - de acordo com a priorização, os requisitos são agrupados para estabelecer linhas de base de implementação, facilitando a definição dos milestones e de pontos de revisão. Atualizar o Documento de Requisitos de Software - o resultado obtido a partir da técnica de priorização deve ser incorporado ao Documento de Requisitos de Software (DRS), enriquecendo a documentação sobre os atributos dos requisitos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 2.1 - Solicitações x necessidades O grupo de pessoas ou representantes de uma organização que tem interesse ou influência no projeto são chamados de interessados (na literatura em inglês, é utilizado o termo "stakeholder"). O interessado mais óbvio é o usuário final, mas devem ser levados em consideração outros interessados importantes: um comprador, um contratante, um desenvolvedor, um gerente de projeto ou qualquer outro que se preocupe bastante ou que apresente necessidades que devem ser satisfeitas pelo projeto. Engenharia de Software I Flávio Ferro Engenharia de Requisitos É importante que sejam agrupados todos os tipos de solicitações de interessados ao longo do ciclo de vida do desenvolvimento. As solicitações correspondem aos dados brutos de entrada usados para levantar as necessidades. No início do projeto, são usadas técnicas de entrevistas, questionários e seminários. Em um estágio mais adiantado do desenvolvimento, são feitas a coleta das solicitações de mudanças, relatórios de defeito e solicitações de melhoria. É comum que as solicitações sejam vagas e ambíguas, declaradas até mesmo como necessidades. Engenharia de Software I Flávio Ferro Engenharia de Requisitos A partir das solicitações, são realizadas algumas verificações referentes aos requisitos levantados (Figura 5): Engenharia de Software I Flávio Ferro Engenharia de Requisitos Verificação da necessidade - a necessidade dos requisitos é analisada. Em alguns casos, alguns requisitos propostos podem não ser relevantes, pois não contribuem para os objetivos de negócio da organização ou para o problema específico tratado pelo sistema. Verificação de consistência e completude - os requisitos são verificados entre si para determinar consistência e completude. Consistência significa que nenhum requisito deve ser contraditório e completude significa que nenhum serviço (ou limitação) necessário seja esquecido. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Verificação de viabilidade - Os requisitos são verificados para garantir que são viáveis dentro do orçamento e do prazo estabelecido para o desenvolvimento do sistema. Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feito um estudo de viabilidade. Pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e organizacional, o projeto é viável. Algumas questões precisam ser levantadas, por exemplo: 1 Será que o sistema contribui para os objetivos da organização? 2 Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado? 3 Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível? Engenharia de Software I Flávio Ferro Engenharia de Requisitos 2.2 - Encontros de negociação Problemas nos requisitos são inevitáveis quando um sistema possui muitos stakeholders. Os conflitos não são necessariamente falhas, mas refletem necessidades e prioridades diferentes entre as partes interessadas. A negociação de requisitos é o processo de discussão dos conflitos de requisitos e a busca de um compromisso no qual, por meio de um consenso, todas as partes interessadas concordem com as soluções sugeridas. Sendo assim, no planejamento do processo de engenharia de requisitos, é desejável deixar um tempo considerável reservado para a negociação. Alcançar o consenso aceitável por todas as partes pode tomar um tempo considerável. Engenharia de Software I Flávio Ferro Engenharia de Requisitos Os encontros de negociação correspondem ao estágio de informação no qual a natureza dos problemas associados com os requisitos é explicada. A partir daí, as partes interessadas discutem como o problema poderá ser resolvido. Todas as partes interessadas no requisito devem ter a oportunidade de participar com comentários e opiniões, devendo ser atribuídas prioridades aos requisitos. Como resultado deste processo, soluções para os problemas dos requisitos são identificadas e um conjunto de requisitos é acordado. Geralmente, isso envolve mudanças, eliminação ou elicitação para obter mais informações sobre alguns dos requisitos. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 3 - Especificação de Requisitos Os requisitos podem ser classificados como: Requisitos funcionais; Requisitos não-funcionais. A diferença entre requisitos funcionais e não-funcionais está no fato de os primeiros descreverem ‘o quê’ o sistema deve fazer, enquanto que os outros fixam restrições sobre ‘como’ os requisitos funcionais devem ser implementados. Os requisitos funcionais têm efeito localizado, isto é, afetam apenas a parte do sistema onde as funcionalidades foram implementadas. Os requisitos não-funcionais têm efeito global, pois a satisfação afeta vários componentes do sistema. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 3.1 - Atividades da elicitação de requisitos Requisitos funcionais expressam o comportamento de um sistema especificando a contribuição e as condições esperadas de saída, ou seja, correspondem à descrição das diversas operações que clientes e usuários solicitam para que possam ser implementadas e oferecidas pelo sistema. Engenharia de Software I Flávio Ferro Engenharia de Requisitos 3.2 - Requisitos não-funcionais Requisitos não-funcionais correspondem aos atributos que não são especificamente descritos pelos requisitos funcionais do sistema, mas são imprescindíveis para atingir a qualidade necessária do software. Requisitos não-funcionais são difíceis de descrever, porém, tratá-los durante o processo de desenvolvimento pode ser vital para o sucesso dos sistemas. Além disso, os requisitos não-funcionais são críticos para o sucesso de sistemas de software e estão diretamente relacionados com a satisfação dos usuários. Devido a essa importância, alguns requisitos funcionais podem ser sacrificados para atender às restrições impostas pelos requisitos não-funcionais. Engenharia de Software I Flávio Ferro Engenharia de Requisitos
Compartilhar