Engenharia de Requisitos 1 Introdução António Lucas Soares

Engenharia de Requisitos 1. Introdução António Lucas Soares, João Pascoal Faria 1 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Índice Importância da engenharia de requisitos Conceitos básicos O processo de engenharia de requisitos A engenharia de requisitos e os processos de planeamento e desenvolvimento de sistemas de informação 2 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Importância da Engenharia de Requisitos (fonte: "Software Testing", Ron Patton) 3 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Importância da Engenharia de Requisitos (fonte: "Software Project Survival Guide", Steve Mc. Connell) 4 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos Software Engineering Body of Knowledge (SWEBOK), Trial Version 1. 0, 2001 (. . . ) 5 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos Software Engineering Body of Knowledge (SWEBOK), Trial Version 1. 0, 2001 6 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos CMMI-SW, Version 1. 1 – processos por níveis de maturidade e áreas Level 2) Managed Level 3) Defined Engineering Project Managem. Process Managem. Level 1) Initial Organizational Process Focus Organizational Process Definition Organizational Process Performance Level 5) Optimizing Organizational Innovation and Deployment Organizational Training Project Planning Integrated Project Management Project Monitoring and Control for Integrated Product and Process Development (IPPD) Supplier Agreement Management Requirements Management (REQM) Quantitative Project Management Risk Management Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Configuration Management (CM) Support Level 4) Quantitatively Managed Decision Analysis and Resolution (DAR) Measurement and Analysis (MA) Causal Analysis and Resolution (CAR) Process and Product Quality Assurance (PPQA) 7 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos CMMI-SW - interacções entre processos na área de engenharia REQM Requirements Product and product component requirements Alternative solutions RD TS Product components PI Product Customer Requirements Product components, verification and work products, validation reports VER VAL Customer needs 8 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos Rational Unified Process (RUP) or a simpler domain modeling instead solução ideal, independente de plataforma e tecnologia 9 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos Rational Unified Process (RUP) 10 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos Rational Unified Process (RUP) or a simpler domain model instead (with entities, but not workers or actors) 11 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos Rational Unified Process (RUP) 12 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Enquadramento da Engenharia de Requisitos Rational Unified Process (RUP) 13 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Da modelação do negócio à modelação dos sistemas de software Identificação de actores externos e processos de negócio primários (contexto do negócio) cliente/actor externo processo de negócio primário (caso de uso do negócio): conjunto organizado de actividades para produzir um resultado com valor para um cliente ou actor externo faltam processos de negócio secundários, que suportam ou controlam processos primários 14 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Da modelação do negócio à modelação dos sistemas de software Especificação dos processos de negócio e associação a sistemas que os suportam Consulta externa: do pedido até à efectivação Médico Funcionário Administrativo Manual SGH actor interno Marcar Consulta Observar Doente Admitir Doente EPR Prescrever Terapêutica Cobrar Taxa Moderadora Prescrição Carimbar Prescrição Aplicações / sistemas de software / sistemas de informação: SGH – Sistema de Gestão Hospital (dados administrativos) EPR – Electronic Patient Record (dados clínicos) Apoiam a execução das actividades e fazem circular informação ao longo do processo! 15 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Da modelação do negócio à modelação dos sistemas de software Identificação de utilizadores e funcionalidades EPR Registar Dados Clínicos SGH Médico Marcar Consulta Identificar Utente Prescrever Terapêutica Admitir Doente Funcionário Administrativo Ø Derivado mais ou menos directamente da especificação de processos de negócio Ø Falta analisar os requisitos de informação (estruturas e fluxos de informação) Ø Modelação do negócio é um passo importante quando se desenvolve software para automatizar processos numa organização (business software, sistemas de informação), mas não quando se desenvolve software embutido em dispositivos (embedded software) 16 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

algumas considerações. . . 17 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Porque é que se fala em "desenvolvimento" e não em "levantamento" de requisitos? Porque os requisitos não "estão lá" para serem levantados Normalmente, existe uma necessidade algo vaga que tem de ser aprofundada e analisada (com o apoio do engenheiro de requisitos ou analista), até se chegar a uma definição de requisitos suficientemente detalhada e precisa 18 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

captura (levantamento) vs elaboração (desenvolvimento) de requisitos utilizadores finais captura de requisitos gestão analistas/ produtores informação, conhecimento, experiência documento de requisitos informação, conhecimento, experiência clientes 19 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

captura (levantamento) vs elaboração (desenvolvimento) de requisitos identificação, elaboração de requisitos utilizadores finais gestão analistas/ produtores negociação, aprendizagem documento de requisitos clientes 20 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

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 21 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

É possível "congelar" o documento de requisitos? Na prática, não! O documento de requisitos serve como "contracto" (na variável âmbito) entre o cliente (que paga e decide a aceitação do sistema) e o implementador Um contracto completo incide também sobre as variáveis custo e duração Mas alterações posteriores são inevitáveis, o que é importante é que essas alterações sejam geridas e negociadas (em termos das 3 variáveis do projecto: âmbito, duração e custo), se possível de acordo com regras fixadas inicialmente Daí a importância da gestão (de alterações) de requisitos Princípio da incerteza na gestão de projectos de software: não é possível fixar simultaneamente o âmbito, custo e duração de um projecto 22 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Posso confiar em que os requisitos documentados (e aprovados pelo cliente) traduzem realmente as necessidades do cliente? Não totalmente. . . o que representa um risco que tem de ser gerido! O cliente pode não perceber claramente o documento de requisitos não tem erros ou omissões evidentes -> MAU evidentemente, não tem erros ou omissões -> BOM A confiança aumenta se usarmos protótipos de interface com o utilizador, storyboards e até um manual do utilizador para capturar e validar os requisitos, em complemento (ou até em substituição) de documentos formais de requisitos É fundamental manter diálogo constante com o cliente O objecto último deve ser satisfazer o cliente e não cumprir requisitos. . . Não basta conduzir actividades de verificação (garantir que o produto está conforme os requisitos documentados), é necessário também conduzir actividades de validação (garantir que o produto satisfaz as necessidades do cliente) 23 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Posso confiar em que o cliente vai aceitar o sistema que cumpre os requisitos documentados? Evitar ambiguidades no documento de requisitos Quantificar requisitos não funcionais Testabilidade dos requisitos: dada a descrição de um requisito, deve ser possível conceber testes de verificação e aceitação (incluindo critério para decidir se o sistema passa ou falha no teste – oráculo do teste) Acordar à partida os critérios e testes de aceitação Se os requisitos documentados e os testes de aceitação acordados não traduzirem realmente as necessidades do cliente, pouco há a fazer. . . 24 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

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 25 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

conceito de requisitos 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 26 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

engenharia de requisitos requisito: um longo caminho a percorrer… questões tecnológicas como alertar os vendedores se não estiverem nas instalações da empresa? é possível que as BD das lojas estejam sempre consistentes? . . . ● ● ● . . . o cliente pode escolher entre encomendar o computador online ou então solicitar o contacto de um vendedor para lhe explicar os pormenores da encomenda, negociar o preço, etc. antes da encomenda ser confirmada questões organizacionais o que é necessário mudar no processo de satisfação de encomendas? qual o impacto da mudança de funções dos vendedores? interessa "induzir" o cliente a usar sempre a internet para colocar a encomenda? . . . ● ● 27 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

engenharia de requisitos conceito de requisitos exemplos ↳ funcionalidades ao nível do utilizador ↳ ↳ "cada disciplina tem um professor responsável, embora outros professores possam leccioná-la também; em cada semestre pode haver um professor responsável diferente e os professores que a leccionam também" propriedades gerais do sistema ↳ ↳ ↳ "o sistema deverá ter uma disponibilidade superior a 99%" "as respostas do sistema nunca deverão ser percepcionadas como 'lentas'" restrições do sistema ou do seu desenvolvimento ↳ "os dados colaboradores deverão ser obtidos por consulta à base de dados de recursos humanos; não é desejável que se façam cópias das tabelas desta base de dados" ↳ "o sistema deve respeitar as normas de acessibilidade da W 3 C" 28 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

conceito de requisitos os requisitos de um sistema devem focar-se no "o quê? " ↳ o que é que o sistema deve fazer? ↳ o "como? " deve ser relegado para segundo plano no entanto a separação do "o quê? " e do "como? " é difícil de conseguir na prática ↳ os requisitos de um sistema incluem na prática uma mistura de dados sobre o problema, descrições do comportamento do sistema e propriedades e restrições da construção do sistema. 29 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

conceito de 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 ↳ exemplos ↳ "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" 30 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

conceito de requisitos atributos principais dos requisitos ↳ prioridade ↳ esforço ↳ risco 31 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

conceito de requisitos níveis de requisitos ↳ alto nível: missões, objectivos, regras do negócio ↳ baixo nível: necessidades dos utilizadores, funcionalidades, restrições 32 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

engenharia de requisitos o que é a engenharia de requisitos? ↳ designa todas as actividades envolvidas em ↳ ↳ especificar, documentar ↳ ↳ descobrir, obter, analisar verificar, gerir, manter os requisitos de um sistema implica a utilização de um conjunto de técnicas e modelos que tornam sistemática e repetitiva a execução destas tarefas 33 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos 34 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos: entradas e saídas sistemas legados necessidades dos utilizadores normas da organização processo de engenharia de requisitos (acordados) especificação do sistema regulamentos informação do domínio (Kotonya e Sommerville, 1998) 35 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

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. 36 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos: modelo em espiral (Kotonya e Sommerville, 1998; SWEBOK) 37 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos outro modelo. . . Sutcliffe, 2002 38 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos: interacção com processo de aquisição de produto do mercado Sutcliffe, 2002 39 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos: caso de desenvolvimento de produto para um mercado E quando uma empresa pretende desenvolver um produto para um mercado, e não um produto à medida para um cliente específico? Análise do domínio e de pontos de variabilidade no domínio é fundamental (engenharia do domínio) Normalmente começa-se com clientes concretos e depois generaliza-se para um mercado Pode-se desenvolver um produto genérico, altamente configurável, ou uma família de produtos, com base em componentes comuns 40 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos factores de variabilidade no processo maturidade técnica envolvimento disciplinar cultura organizacional domínio de aplicação porque é que não faz sentido falar no "processo de ER ideal"? 41 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos actores no processo engenheiro de requisitos / analista especialista do domínio responsável de projecto processo de engenharia de requisitos utilizador final engenheiro de software 42 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

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: ↳ 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. 43 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos actores no processo: stakeholders exemplo: num sistema automático de sinalização ferroviária os stakeholders são: ↳ operadores responsáveis por trabalhar com o sistema, condutores dos comboios, gestores, passageiros, engenheiros de instalação e manutenção, autoridades de certificação e segurança porque é importante compreender as funções e papéis das pessoas envolvidas num processo de ER? 44 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos *actores no processo: outros factores humanos, sociais e organizacionais ↳ os stakeholders têm diferentes "backgrounds" e diferentes objectivos individuais e organizacionais ↳ os interesses individuais e de grupo das pessoas envolvidas influenciam o processo de ER ↳ devem ser considerados como factores intrínsecos ao processo de ER como considerar estes factores num processo de ER? 45 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

o processo de engenharia de requisitos actores no processo Customer - the party (individual, project, or organization) responsible for accepting the product or for authorizing payment ↳ The customer is external to the project, but not necessarily external to the organization ↳ The customer may be a higher level project ↳ Customers are a subset of stakeholders Stakeholder - a group or individual that is affected by or in some way accountable for the outcome of an undertaking ↳ Stakeholders may include project members, suppliers, customers, end users, and others Project manager - the person responsible for planning, directing, controlling, structuring, and motivating the project and satisfying the customer (fonte: CMMI) 46 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

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 nível 2. repetível PER obedecendo a normas nível 1. inicial PER adhoc 47 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

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. , 48 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

a engenharia de requisitos e os processos de planeamento e desenvolvimento de sistemas de informação 49 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Conceito de Sistema de Informação (SI) "Sistema de Informação é um sistema que reúne, guarda, processa e faculta informação relevante para a organização (. . . ), de modo que a informação é acessível e útil para aqueles que a querem utilizar, incluindo gestores, funcionários, clientes, (. . . ). Um Sistema de Informação é um sistema de actividade humana (social) que pode envolver ou não a utilização de computadores. " (Buckingham et al 1987 citado em Amaral 2000) Aceitando a presença de computadores e tecnologias de informação (TI) em geral como participantes nos SI, pode-se redefinir, numa perspectiva mais organizacional: "Sistema de Informação é uma combinação de procedimentos, informação, pessoas e tecnologias de informação, organizadas para o alcance de objectivos de uma organização" (Alter 1992, citado em Amaral 2000) Pode-se falar em um ou mais (sub)sistemas de informação numa organização 50 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Conceito de Sistema de Informação (SI) The term information system has the following meanings: 1. A system, whether automated or manual, that comprises people, machines, and/or methods organized to collect, process, transmit, and disseminate data that represent user information. 2. Any telecommunications and/or computer related equipment or interconnected system or subsystems of equipment that is used in the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of voice and/or data, and includes software, firmware, and hardware Source: from Federal Standard 1037 C and from MIL-STD-188 and from the National Information Systems Security Glossary (. . . ) (www. wikipedia. org) 51 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Conceito de Tecnologias de Informação (TI) "Tecnologias de Informação são o conjunto de equipamentos (hardware) e suportes lógicos (software) que permitem executar tarefas como aquisição, transmissão, armazenamento, recuperação e exposição de dados" (Alter, 1992) "Information technology (IT) or information and communication technology (ICT) is the technology required for information processing. In particular the use of electronic computers and computer software to convert, store, process, transmit, and retrieve information from anywhere, anytime". (www. wikipedia. org) 52 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Tipos de Sistemas de Informação (1/2) Sistemas de produtividade pessoal ↳ Permitem aumentar a produtividade pessoal ↳ Sistemas de automação de escritório, CAD, etc. ↳ Tipicamente podem correr de forma autónoma (no PC) ↳ Tipicamente dados são armazenados em ficheiros Sistemas operacionais ↳ Apoiam a operação diária da organização, automatizam processos, fazem circular a informação ↳ Sistemas transaccionais (OLTP), . . . ↳ Tipicamente dados são armazenados em bases de dados relacionais, suportando muitos utilizadores em simultâneo e muitas transacções (e consultas) por segundo 53 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Tipos de Sistemas de Informação (2/2) Sistemas de apoio à decisão (táctica e estratégica) ↳ Sistemas de processamento analítico (OLAP), . . . ↳ Apoiam a decisão táctica e estratégica ↳ Dados históricos de múltiplas fontes podem ser canalizados para um armazém de dados (data warehouse), suportando interrogações e análises de dados complexas Sistemas colaborativos ↳ Apoiam a comunicação, colaboração e coordenação numa comunidade de forma pouco estruturada (groupware) Não é uma lista exaustiva, nem a única classificação possível! 54 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Arquitectura de Sistemas de Informação Arquitectura = estrutura de alto nível (visão estática) Pode ser definida segundo diferentes perspectivas Arquitectura da Informação ↳ Que informação (grupos de dados), quando e aonde ↳ Circuitos de informação ↳ Relação com processos e unidades organizacionais ↳ Mais ou menos independente do suporte em TI Arquitectura das Tecnologias de Informação ↳ Arquitectura física ↳ ↳ sítios, computadores, redes, . . . Arquitectura lógica ↳ aplicações e comunicação entre aplicações Arquitectura de Serviços? 55 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Ciclo de Vida dos Sistemas de Informação (fonte: L. Amaral, 2000) Estratégico plano director informático arquitectura do negócio (objectivos, estratégias, processos, recursos, . . . ) arquitectura actual e futura dos SI estratégia de outsourcing prioridades, custos e benefícios carteira de projectos garantir alinhamento com o negócio pode englobar a análise e modelação do negócio / empresa / organização - identificar necessidades e oportunidades - especificar requisitos funcionais e não funcionais para a solução (com a ajuda de modelos do sistema pretendido) produto standard ou à medida? arquitectura? tecnologias? e mudança organizacional. . . design 56 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Planeamento de Sistemas de Informação Beynon-Davies, 2002 planeamento informático organizar o planeamento análise organizacional análise do ambiente avaliar a infraestrutura informática estabelecer uma visão desenvolver a estratégia informática gestão informática análise da tecnologia desenvolver planos operacionais 57 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Desenvolvimento de Sistemas de Informação Beynon-Davies, 2002 planeamento de sistemas de informação concepção do sistema construir uma justificação do SI para o negócio análise organizacional análise do sistema de informação desenho do sistema análise do sistema de actividades humanas avaliar os riscos análise do sistema sócio-técnico estudar a viabilidade 58 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Análise do sistema de informação Beynon-Davies, 2002 análise do sistema de informação obtenção dos requisitos interessados especificação dos requisitos 59 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

*Abordagens de Planeamento Estratégico de SI Análise SWOT – Strenghts, Weaknesses, Opportunities, Threats ↳ permite identificar, classificar, prioritizar e seleccionar projectos de desenvolvimento de SI de uma forma alinhada com as forças, fraquezas, oportunidades e ameaças da organização Abordagem VCM – Value Chain Model (Porter 1985) ↳ analisa a cadeia completa de actividades numa organização – desde a entrada de matérias primas até à venda e envio de produtos finais a clientes, por exemplo ↳ ajuda a compreender que configuração da cadeia de valor traz a maior vantagem competitiva para a organização ↳ os projectos de desenvolvimento de SI são dirigidos aos segmentos, operações, canais de distribuição, abordagens de marketing, etc. , que trazem a maior vantagem competitiva (continua) 60 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

*Abordagens de Planeamento Estratégico de SI (continuação) Abordagem BPR – Business Process Reengineering ↳ baseia-se no princípio que as organizações se devem focar nos seus processos de negócio (que normalmente atravessam várias unidades organizacionais), em vez de se focarem nas funções das pessoas ou das unidades organizacionais ↳ a mudança de foco nota-se com a existência de donos de processos ↳ os projectos de desenvolvimento de SI destinam-se a automatizar e melhorar os processos Abordagem ISA – Information Systems Architecture (Zachman 1987) ↳ a arquitectura do SI é definida de forma bottom-up com base na análise e descrição das perspectivas de diferentes players (planner, owner, designer, builder, subcontractor) sobre diferentes aspectos do SI (what, how, where, who, when, why) ↳ não fica tão explícita a ligação a uma estratégia de negócio, mas também não fica tão dependente da estratégia de negócio (fonte: Maciaszek, 2001) 61 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Exemplo de análise SWOT e definição de estratégia (fonte: Erikson & Penker) 62 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Abordagens de Análise e Modelação de Sistemas de Informação Análise estruturada ↳ Diagramas de fluxos de dados (DFD) ↳ ↳ Mostram processos (transformam dados, podendo ser decompostos hierarquicamente), depósitos de dados, entidades (são fonte ou destino de dados), e fluxos de dados entre os elementos anteriores Diagramas entidade-associação (ER) ↳ Mostram entidades, atributos e associações Análise orientada por objectos ↳ Actualmente com base na notação UML – Unified Modeling Language ↳ Diagramas de casos de utilização ↳ ↳ ↳ Mostram actores (tipos de utilizadores) e casos de utilização (serviços ou funcionalidades) Detalhados através de vários tipos de "diagramas dinâmicos" Diagramas de classes (de objectos) ↳ Classes são semelhantes a entidades ↳ ER + herança (generalização/especialização) Normalmente usam-se abordagens integradas de análise e desenho (design), usando técnicas de modelação em ambos as fases 63 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Abordagens de Análise e Modelação do Negócio Abordagens baseadas em UML (linguagem de modelação orientada por objectos, de uso genérico) ↳ Jacobson 1995 (pre-UML), Rational Unified Process (pos-UML) ↳ ↳ ↳ Modelo de casos de utilização do negócio – visão externa; mostra processos de negócio primários e actores externos Modelo de objectos do negócio – visão interna Eriksson, Penker, 2000 (UML) ↳ ↳ Vista de processos do negócio – modelação de processos e "linhas de montagem" ↳ Vista de estrutura do negócio – modelação de recursos (estrutura de unidades organizacionais, estrutura de informação, estrutura de produtos, etc. ) ↳ ↳ Vista de visão do negócio – modelação de objectivos e problemas, modelação conceptual Vista de comportamento do negócio – ciclos de vida de recursos São abordagens complementares e não antagónicas Abordagens baseadas em linguagens específicas para modelação de processos de negócio ↳ BPML – Business Process Modeling Language ↳ IDEF – ver comparação com UML em http: //www. cit. gu. edu. au/~noran/Docs/UMLvs. IDEF. pdf ↳ (. . . ) 64 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria

Referências ↳ "Software Testing", Ron Patton, SAMS, 2001 ↳ "Software Project Survival Guide", Steve Mc. Connell, Microsoft Press, 1998 ↳ Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society , chapter 2 (Peter Sawyer, Gerald Kotonya), http: //www. swebok. org/ ↳ Capability Maturity Model Integration for Software Engineering (CMMI-SW), Software Engineering Institute (SEI), Carnegie Mellon University (CMU), http: //www. sei. cmu. edu/cmmi/ ↳ Gerald Kotonya, Ian Sommerville, Requirements Engineering – Processes and Techniques, Wiley, 1998 ↳ P. Beynon-Davies, Information Systems: An introduction to informatics in organizations. Palgrave, 2002 ↳ Luís Amaral, João Varajão, Planeamento de Sistemas de Informação, FCA Editora, 2000 ↳ R. A. Buckingham, R. A. Hirschheim, F. F. Land e C. J. Tully, Information Systems Curriculum: A basis for course design, in Buckingham, R. A. Hirschheim, F. F. Land e C. J. Tully (Eds. ), Information Systems Education: Recommendations and Implementation, Cambridge University Press, 1987. ↳ S. Alter, Information Systems: A Management Perspective, Addison-Wesley, 1992. ↳ M. Porter, Competitive Advantage: Creating and Sustaining Superior Performance, Free Press, 1985 ↳ L. A. Maciaszek, Requirements Analysis and System Design: Devloping Information Systems with UML, Addison. Wesley, 2001 ↳ J. A. Zachman, A Framework for Information Systems Architecture, IBM Systems Journal, 1987, 1999 ↳ Ivar Jacobson, M. E. A. Jacobson, The Object Advantage: Business Process Reengineering with Object Tecnology, Addison-Wesley, 1995 ↳ Hans-Eriksson, Magnus Penker, Business Modeling with UML: Business Patterns at Work, John Willey & Sons, 2000 ↳ www. wikipedia. org ↳ www. uml. org 65 Engenharia de Requisitos António Lucas Soares, João Pascoal Faria