Engenharia de Software Introducao

Anlise de RequisitosMETODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS

Prof. Dr. rer. nat. Daniel D. Abdalae-mail: abdala@das.ufsc.br1ObjetivosIntroduzir os conceitos de requisitos do usurio e do sistema;Definir requisitos funcionais e no-funcionais;Explicar duas tcnicas para descrio de requisitos do sistema;2PlanoRequisitos Funcionais e No-FuncionaisRequisitos do UsurioRequisitos do SistemaDocumento de Requisitos34

Engenharia de RequisitosProcesso sistemtico para:Identificao e registro das necessidades especficas dos stackholders;Refinamento dos requisitos levantados;Resoluo de conflitos entre requisitos;Identificao de interdependncias entre requisitos;5O que so Requisitos?Descrio de servios e restries do sistema;Devem refletir a necessidade dos usurios do sistema;Existem diferentes nveis:Alto nvel usados por exemplo em propostas de contrato;Detalhados usados na redao de contratos. Definem precisamente o que deve estar presente no software6Abstrao de RequisitosIf a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisations needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.

7SommervilleTipos de RequisitosRequisitos do Usurio (Usurio)afirmaes em linguagem natural enriquecidos por diagramas descrevendo os servios e funcionalidades que um sistema deve prover, assim como restries na presena das quais ele deve operar.Requisitos do Sistema (Eng. de Requisitos)estabelece as funes do sistema, servios e restries em detalhes. O documento de requisitos do sistema (tambm chamado especificao funcional) deve ser preciso e detalhado. Ele deve definir exatamente o que deve ser implementado. Ele ainda pode ser usado como parte do contrato entre o comprador do sistema e os desenvolvedores.Especificao do Software (Desenvolvedores)Uma descrio detalhada do software que serve como base para o projeto e implementao8Definio e EspecificaoEspecificao de Requisitos9O Software deve prover funcionalidade para impresso de todos os relatrios gerados .Definio de RequisitosO software deve ser capaz de escolher uma dentre as vrias impressoras disponveis para impresso;A impresso de um relatrio deve ser permitida em diferentes nveis de qualidade;Os nveis de qualidade so: (rascunho, normal e alta qualidade);Deve ser possvel imprimir relatrios para arquivos .pdf.Requisitos do UsurioRequisitos funcionais e no-funcionais devem ser descritos de tal forma que eles possam ser entendidos por usurios que no possuem conhecimento; Requisitos do Usurio so definidos usando Linguagem Natural (LN), tabelas e diagramas.Problemas com Linguagem NaturalFalta de claridadeAlcanar preciso difcil sem tornar o documento muito complexoConfuso entre os RequisitosRequisitos funcionais e no-funcionais tendem a se misturarCombinao de RequisitosVrios requisitos distintos podem vir a ser expressos conjuntamenteDatabase requirement4.A.5 O banco de dados deve permitir a gerao e controle de objetos de configurao, isto , objetos que so compostos pela combinao de outros objetos. As ferramentas de controle de configurao devem permitir acesso aos objetos em um grupo de verso por meio do uso de nomes incompletos.Requisitos do Editor Grid2.6 Grid facilities Para auxiliar o posicionamento de entidades no diagrama, o usurio poder habilitar a visualizao do grid tanto em centmetros quanto em milmetros utilizando para tal um painel de controle. Inicialmente, o grid no deve estar habilitado. O grid pode ser habilitado e desabilitado a qualquer momento durante uma sesso de edio assim como poder ser alterado entre cm e mm. Uma outra opo chamada reduce-to-fit , no entanto o nmero de linhas mostradas ser reduzido de modo a evitar que diagramas pequenos sejam rearranjados para se ajustarem as linha do grid.Problemas com os RequisitosOs requisitos do database incluem tanto informaes conceituais quanto detalhes de implementaoDescrevem o conceito de opes de controle de configuraoIncluem detalhes a respeito de como os objetos devem ser acessados (usando nomes incompletos) Os requisitos do grid incluem trs tipos de requisitosConceitual (a necessidade de um grid)No-Funcional (unidades de medida do grid)No Funcional IU (troca de tamanho do grid)Quem l os diferentes nveis de Requisitos?15

Requisitos Funcionais e No-FuncionaisRequisitos Funcionaisdefinies dos servios que o sistema de prover;define como o sistema deve reagir a diferentes tipos de entrada;como o sistema deve se comportar em situaes particulares.definir explicitamente o que o sistema NO deve fazer;Requisitos No-FuncionaisDefine restries dos servios oferecidos pelo sistema;Restries de tempo;Restries do processo de desenvolvimento;Restries (concordncia) de padronizao;Geralmente so aplicveis a todo o sistema.16Exemplos de Requisitos FucionaisO usurio deve ser capaz de pesquisar tanto um conjunto inicial de bancos de dados como um sub grupo selecionado dos mesmos.O sistema deve prover mtodos de visualizao adequados de modo que o usurio possa ler os documentos disponveis na loja de documentos.Deve ser atribudo um identificador nico (ORDER_ID) a todos os documentos. 17Tipos de Requisitos No-Funcionais

Exemplos de Requisitos No FuncionaisRequisitos do Produto4.C.8 Deve ser possvel representar toda a comunicao entre o APSE e o usurio usando o conjunto de caracteres Ada.Requisitos de organizao9.3.2 O processo de desenvolvimento do sistema assim como todos os documentos entregveis devem estar em concordncia com o padro definido em XYZCo-SP-STAN-95Requisitos Externos7.6.5 O sistema no deve publicar nenhuma informao pessoal dos clientes com exceo do nome e nmero de referncia para o operador do sistema19Objetivos dos RequisitosRequisitos no-funcionais podem ser difceis de serem definidos claramente, e requisitos imprecisos podem ser difceis de verificar. ObjetivosSo uma inteno geral do usurio, tal como facilidade de utilizaoRequisitos funcionais verificveisUma especificao de funcionalidade usando alguma forma de medida que pode ser testada objetivamenteObjetivos podem ser teis aos desenvolvedores uma vez que estes representam as intenes dos usurios do sistema20ExemplosUm objetivo do sistemaO sistema deve ser fcil de usar por controladores experientes e deve ser organizado de forma que os erros de utilizao sejam minimizadosUm requisito no-funcional verificvelControladores experientes dever ser capazes de usar todas as funes do sistema aps um treinamento de duas horas. Uma vez que o treinamento tenha sido feito, o nmero mdio de erros de utilizao no dever ultrapassar duas ocorrncias por dia.O documento de requisitosO documento de requisitos uma especificao formal do que requerido dos desenvolvedores do sistemaEle deve incluir tanto uma definio quanto a especificao de cada requisitoEle NO um documento de projeto. Tanto quanto possvel ele deve definir o que o sistema deve fazer ao invs de COMO ele deve fazer23

Requisitos do SistemaEspecificao detalhada dos requisitos do usurio;Serve como base para o projeto do sistema.Projeto de RequisitosComo princpio, requisitos devem informar o que o sistema deve fazer e projeto como deve ser feito Na prtica, requisitos e projeto so inseparveisUma arquitetura do sistema deve ser projetada para estruturar os requisitosProblemas com a especificaso usando LNAmbigidadeOs leitores e escritores dos requisitos podem vir a interpretar as mesmas palavras de maneiras diversas. LN naturalmente ambiguaMuita FlexibilidadeA mesma idia pode ser expressa de maneiras diferentesFalta de ModularizaoLN inadequada para estruturao de requisitos do sistema27

Alternativas a LN

Lingugem EstruturadaUma forma limitada de LN pode ser usada para expressar requisitosSana alguns dos problemas resultantes da ambiguidade e flexibilidade e impoe um certo grau de uniformidade para a especificaoEspecificao Baseada em FormulriosDefinio de funo ou entidadeDescrio das entradas e de sua procednciaDescrio das sadas e seu destinoIndicao de dependncia de outras entidadesPre-condies e ps-condies Especificao Baseada em Formulrios

Especificao de InterfacesMuitos sistemas operam em conjunto com outros sistemas. Interfaces entre tais sistemas devem ser especificadas como parte dos requisitos Trs tipos de interfaces podem ser definidas:Interfaces de ProcedimentosEstruturas de dados que sero intercambiadasRepresentao de dadosNotaes formais so uma tcnica efetiva para especificao de interfacesPontos ChaveRequisitos especificam o que o sistema deve fazer e definem restries quanto a sua operao e implementao;Requisitos funcionais especificam servios que o sistema deve prover;Requisitos no-funcionais restringem o sistema sendo desenvolvido e/ou o processo de desenvolvimento;Requisitos do usurio so especificaes de alto nvel a respeito do que o sistema deve fazer;33Pontos ChaveRequisitos do usurio devem ser escritos em linguagem natural, tabelas e diagramas;Requisitos do sistema tem como tarefa comunicar as funcionalidades que o sistema deve prover;Requisitos do sistema devem ser escritos em linguagem natural estruturada ou uma linguagem formal.34RefernciasR. S. Pressman, Engenharia de Software, McGraw Hill, 6a Ed., 2002. Chap. 7.I. Sommerville. Software Engineering. 7th Ed. Addison-Wesley, 2004. Chap. 5.35NotationDescription

Structured natural language This approach depends on defining standard forms or templates to express the requirements specification.

Design description languagesThis approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system.

Graphical notationsA graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT (Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) have been used.

Mathematical specifications These are notations based on mathematical concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers dont understand formal specifications and are reluctant to accept it as a system contract.