Home

TX-EngSoft-01-Requisitos-IEEE830

1. a velocidade disponibilidade tempo de resposta tempo de recupera o das v rias fun es do software etc o d Atributos Quais as considera es relativas portabilidade correc o mantenabilidade seguran a etc Restri es de desenho impostas numa implementa o Existem exig ncias padr o linguagem de implementa o pol ticas para integridade da base de dados limites de recursos ambientes operacionais etc O Quem escreve um documento de EES deve evitar introduzir exig ncias de desenho ou de projecto no documento de EES Para conte dos recomendados consulte o Cap tulo 5 4 2 Ambiente do documento de EES importante ter em conta o papel que o documento de EES possui no plano de todo o projecto que definido no documento IEEE Std 610 12 1990 O software pode conter essencialmente toda a funcionalidade do projecto ou pode ser parte integrante de um sistema maior Neste ltimo caso tipicamente existe um documento de EES que Cap tulo 4 Considera es para a produ o de um bom documento de EES documenta as interfaces entre o sistema e esta parte do software impondo assim exig ncias externas de performance e funcionalidade do software Claro que o documento de EES deve estar em concord ncia e expandir estas exig ncias de sistema O documento IEEE Std 1074 1997 descreve os passos do ciclo da vida de um software e as entradas que cada passo comporta Outros padr es tais como os listados no
2. j Criticalidade da aplica o k Considera es de seguran a 5 2 5 Assun es e depend ncias Sec o 2 5 do documento de EES Esta sub sec o do documento de FES deve listar cada um dos factores que afectam as exig ncias ditadas no documento de EES Estes factores n o s o restri es de desenho do software mas sim factores que ao mudarem afectam as exig ncias presentes no documento de EES Por exemplo pode ser assumido que um determinado sistema operativo estar dispon vel no hardware designado para o produto de software Se mais tarde se verificasse que tal sistema operativo n o est de facto dispon vel o documento de EES teria ent o de ser alterado 19 Cap tulo 5 As partes de um documento de EES 5 2 6 Divis o e atribui o das exig ncias Sec o 2 6 do documento de EES Esta sub sec o do documento de EES deve identificar as exig ncias que podem ser adiadas para vers es futuras do sistema 5 3 Exig ncias espec ficas Sec o 3 do documento de EES Esta sec o do documento de EES deve conter todas as exig ncias de software a um n vel de detalhe suficiente para permitir que seja feito o desenho de um sistema que satisfaz as exig ncias e que sejam feitos testes que mostrem que o sistema satisfaz essas mesmas exig ncias Ao longo desta sec o cada exig ncia que ditada deve ser externamente percept vel por utilizadores operadores ou outros sistemas externos Estas exig ncias devem i
3. por exemplo opera es iniciadas pelos utilizadores b Per odos de opera o interactiva e per odos de opera o n o supervisionada c Fun es de suporte a processamento de dados d Opera es de c pia de seguran a e restauro Nota Isto por vezes especificado como parte da sec o Interface com o Utilizador 5 2 1 8 Exig ncias de adapta o ao local Aqui deve se a Definir as exig ncias para quaisquer dados ou sequ ncias de inicializa o que sejam espec ficos a um local de instala o miss o ou modo de opera o por exemplo limites de seguran a etc b Especificar as caracter sticas relacionadas com um local de instala o ou miss o que devem ser modificadas para adaptar o sofware a uma instala o em particular 5 2 2 Fun es do produto Sec o 2 2 do documento de EES Esta sub sec o do documento de EES deve fornecer um resumo das principais fun es que o software vai desempenhar Por exemplo um documento de EES para um programa de contabilidade pode usar esta sec o para referir manuten o de contas de cliente balan os e prepara o de recibos sem mencionar as vastas quantidades de detalhe que cada uma dessas fun es necessita 18 Cap tulo 5 As partes de um documento de EES Por vezes o resumo de fun es que necess rio para esta sec o pode ser retirado directamente da sec o de especifica o de alto n vel caso exista que atribui fun es particular
4. Al Il Al 1 1 TAR 1 1 RR 3 1 1 2n Requisito Funcional n 3 1 1 E Performance 3 1 2 Modo 2 3 1 m Modo m 3 2 Restri es de Desenho 3 3 Atributos do Sistema de Software 3 4 Outros Requisitos Ap ndice A Modelos de EES A 3 Modelo de Sec o 3 do EES organizada por classe de utilizador 3 Requisitos Espec ficos 3 1 Requisitos de Interface Externos 3 1 1 Interfaces de Utilizador 3 1 2 Interfaces de Hardware 1 3 interfaces de Software 4 Interfaces de Comunica o Requisitos Funcionais 1 2 2 1 Classe de Utilizador 1 2 3 3 3 3 2 3 2 1 1 Requisito Funcional 1 1 32 1n Requisito Funcional 1 n 3 2 2 Classe de Utilizador 2 3 2 m Classe de Utilizador m 3 2 m 1 Requisito Funcional m 1 32mn Requisito Funcional m n 3 3 Requisitos de Performance 3 4 Restri es de Desenho 3 5 Atributos do Sistema de Software 3 6 Outros requisitos A 4 Modelo de Sec o 3 do EES organizada por objecto 3 Requisitos Espec ficos 3 1 Requisitos de Interface Externos 3 1 1 Interfaces de Utilizador 3 1 2 Interfaces de Hardware 3 1 3 Interfaces de Software 3 1 4 Interfaces de Comunica o 3 2 Classes Objectos 3 2 1 Classe Objecto 1 3 2 1 1 Atributos directos ou herdados 3 2 1 1 1 Atributo 1 3 2 1 1 n Atributo n 3 2 1 2 Fun es servi os m todos directos ou herdados 3 2 1 2 1 Requisito Funcional 1 1 3 2 1 2m Requisito Funcional 1 m 3 2 1 3 Mensagens Comunica es enviadas ou recebidas 3
5. Cap tulo 2 est o relacionados com outras partes do ciclo de vida do software e podem complementar as exig ncias Como o documento de EES tem um papel espec fico no processo de desenvolvimento de software quem escreve o documento de EES deve ter cuidado para n o passar os limites desse papel Isto quer dizer que a O documento de EES deve definir correctamente todas as exig ncias do software Uma exig ncia do software pode existir devido natureza da tarefa a ser resolvida ou devido a uma caracter stica particular do projecto b O documento de EES n o deve descrever nenhum detalhe de desenho ou implementa o Estes devem ser descritos na fase de desenho do projecto c O documento de EES n o deve impor restri es adicionais ao software Estas est o devidamente especificadas noutros documentos tais como o plano de garantia de qualidade do software Por isso um documento de EES correctamente escrito limita a fronteira de desenhos v lidos mas n o vincula nenhum desenho particular 4 3 Caracter sticas de um bom documento de EES Um documento de EES deve ser a Correcto b N o amb guo c Completo d Consistente e Classific vel por import ncia e ou estabilidade f Verific vel g Modific vel h Rastre vel 4 3 1 Correcto Um documento de EES est correcto se e s se todas as exig ncias expressas nele ser o correspondidas pelo software N o existe nenhuma ferramenta ou procedimento q
6. Caracter sticas do utilizador d Restri es e Assun es e depend ncias f Divis o e atribui o das exig ncias 5 2 1 Perspectiva do produto Sec o 2 1 do documento de EES Esta sub sec o do documento de EES deve colocar o produto em perspectiva relativamente a outros produtos relacionados Se o produto independente e totalmente auto contido isso deve ser explicitado aqui Se o documento de EES define um produto que forma parte de um sistema maior como frequentemente o caso ent o esta sub sec o deve relacionar as exig ncias do sistema envolvente com a funcionalidade do software e deve identificar interfaces entre o sistema e o software Um diagrama de blocos mostrando os componentes principais do sistema envolvente interliga es e interfaces externas poder ser til Esta sub sec o deve tamb m descrever a opera o do software dentro de v rias restri es Por exemplo estas restri es podem incluir a Interfaces de sistema b Interfaces com o utilizador c Interfaces de hardware d Interfaces de software e Interfaces de comunica o f Mem ria g Opera es 16 Cap tulo 5 As partes de um documento de EES h Adapta es ao local de instala o 5 2 1 1 Interfaces de sistema Aqui deve ser listada cada interface de sistema e identificada a funcionalidade do software que cumpre a exig ncia do sistema 5 2 1 2 Interfaces com o utilizador Aqui deve ser espe
7. Desenho 3 5 Atributos do Sistema de Software 3 6 Outros Requisitos Ap ndice A Modelos de EES A 7 Modelo de Sec o 3 do EES organizada por hierarquia funcional 3 Requisitos Espec ficos 3 1 Requisitos de Interface Externos 3 1 1 Interfaces de Utilizador 3 1 2 Interfaces de Hardware 3 1 3 Interfaces de Software 3 1 4 Interfaces de Comunica o 3 2 Requisitos Funcionais 3 2 1 Fluxos de Informa o 3 2 1 1 Diagrama de fluxo de dados 1 3 2 1 1 1 Entidades de Dados 3 2 1 1 2 Processos Pertinentes 3 2 1 1 3 Topologia 3 2 1 2 Diagrama de fluxo de dados 2 3 2 1 2 1 Entidades de Dados 1 2 2 Processos Pertinentes 3 2 3 2 1 2 3 Topologia 32 1n Diagrama de fluxo de dados n 3 2 1 n 1 Entidades de Dados 3 2 1 n 2 Processos Pertinentes 3 2 1 n 3 Topologia 3 2 2 Descri o de Processos 3 2 2 1 Processo 1 1 1 Entidades de dados de entrada 1 2 Algoritmo ou f rmula do processo 1 3 Entidades de dados afectadas 2 Processo 2 2 1 Entidades de dados de entrada 2 2 Algoritmo ou f rmula do processo Da 322 3 2 2 322 3 2 2 3 22 3 2 2 3 2 2 2 3 Entidades de dados afectadas 2 m Processo m 2 m 1 Entidades de dados de entrada 2 m 2 Algoritmo ou f rmula do processo 3 2 2 m 3 Entidades de dados afectadas 3 2 3 Especifica o de constru es de dados 3 2 3 1 Constru o 1 3 2 3 1 1 Tipo de registo 3 2 3 1 2 Campos constituintes 3 2 3 2 Constru o 2 3 2 3 2 1 Tipo de registo 3 2 3 2 2 Campos consti
8. Um documento de EES internamente consistente se e s se nenhum sub conjunto individual de exig ncias descrito nele entra em conflito Existem tr s tipos de conflitos poss veis num documento de EES como se segue a As caracter sticas dos objectos do mundo real podem entrar em conflito Por exemplo 1 O formato de um relat rio de sa da pode ser descrito numa exig ncia como tabular mas noutra como textual 2 Uma exig ncia pode afirmar que todos os leds s o verdes enquanto outra pode afirmar que todos os leds devem ser vermelhos b Podem existir conflitos entre duas ac es especificadas Por exemplo Cap tulo 4 Considera es para a produ o de um bom documento de EES 1 Uma exig ncia pode especificar que um programa deve adicionar dois valores enquanto outra pode especificar que devem ser multiplicados 2 Uma exig ncia pode afirmar que A deve sempre seguir B enquanto outra pode exigir que A e B ocorram simultaneamente c Duas ou mais exig ncias podem descrever o mesmo objecto do mundo real mas usam diferentes termos para esse objecto Por exemplo um pedido de entrada por parte do utilizador num programa pode chamar se prompt numa exig ncia enquanto noutro pode chamar se indicador A utiliza o de terminologia standard e defini es assentes em gloss rios promove a consist ncia 4 3 5 Classifica o por import ncia e ou estabilidade Um documento de EES encontra se classificado por impo
9. do IEEE Espera se a sua publica o em Dezembro de 1998 Contacte o IEEE Standards Department atrav s do telefone 1 732 562 3800 para mais informa es data desta publica o os standards IEEE Std 828 1998 IEEE Std 1012a 1998 IEEE Std 1016 1998 e IEEE Std 1233 Edi o de 1998 est o aprovados mas ainda n o foram publicados No entanto as vers es preliminares est o dispon veis no IEEE As publica es est o previstas para o Outono de 1998 Contacte o IEEE Standards Department atrav s do telefone 1 732 562 3800 para mais informa o Cap tulo 3 Defini es Em geral os termos usados nesta pr tica recomendada est o conformes com as defini es disponibilizadas no documento IEEE Std 610 12 1990 As defini es abaixo s o os termos chave usados nesta pr tica recomendada 3 1 Contracto Um documento legal de obriga es com o qual o cliente e o fornecedor concordam Isto inclui as exig ncias t cnicas e organizacionais o custo e o calend rio para um produto Um contracto pode ainda conter informa o informal mas til tal como os compromissos ou expectativas das partes envolvidas 3 2 Cliente A pessoa ou pessoas que pagam o produto e normalmente mas n o obrigatoriamente decidem as exig ncias No contexto de uma pr tica recomendada o cliente e o fornecedor podem ser membros de uma mesma organiza o 3 3 Fornecedor A pessoa ou pessoas que produzem um produto para um cliente No contexto des
10. e para quem O documento de EES deve focar se em servi os a desempenhar O documento de EES n o deve normalmente especificar os seguintes itens de desenho a Subdivis o do software por m dulos b Aloca o de fun es a m dulos c Descrever o fluxo de informa o ou controlo entre m dulos d Escolha de estruturas de dados 2 Cap tulo 4 Considera es para a produ o de um bom documento de EES 4 7 1 Exig ncias de desenho necess rias Existem casos especiais em que as exig ncias podem restringir severamente o desenho Por exemplo exig ncias de seguran a ou salvaguarda podem reflectir se directamente no desenho despoletando a necessidade de a Manter certas funcionalidades em m dulos separados b Limitar a comunica o entre algumas reas do programa c Verificar a integridade de vari veis cr ticas Exemplos de restri es de desenho v lidas s o restri es f sicas restri es de desempenho standards de desenvolvimento de software standards de certifica o de qualidade de software Assim sendo as exig ncias devem ser sempre especificadas de um ponto de vista puramente externo Quando forem utilizados modelos para ilustrar as exig ncias deve ser lembrado que o modelo apenas indica o comportamento externo e n o especifica o desenho 4 8 Incorpora o de exig ncias do projecto no documento de EES O documento de EES deve focar se no produto de software e n o no processo de produ o d
11. forma a permitir a cria o de um prot tipo que exiba algumas caracter sticas do sistema de forma r pida e f cil Consulte tamb m a norma ASTM E1340 96 Um prot tipo til pelas seguintes raz es a O cliente tem maior probabilidade de reagir ao olhar para o prot tipo do que ao ler o documento de exig ncias Assim um prot tipo permite respostas r pidas b O prot tipo exibe aspectos do comportamento do sistema que ainda n o haviam sido previstos Assim produzem se n o apenas novas respostas mas novas perguntas Isto acelera a converg ncia do documento de EES c Um documento de EES desenvolvido com base em prototipagem tende a sofrer menos modifica es durante o seu desenvolvimento encurtando desta forma o tempo de desenvolvimento 4 7 Incorpora o do desenho no documento de EES Uma exig ncia especifica uma fun o externamente vis vel ou um atributo de um sistema O desenho descreve um sub componente particular do sistema e ou as suas interfaces com outros sub componentes Quem escreve documentos de FES deve distinguir claramente entre a defini o de restri es de desenho e o v nculo a um desenho espec fico Note se que cada exig ncia de um documento de FES limita as alternativas de desenho Isto n o significa no entanto que qualquer exig ncia seja desenho O documento de EES deve especificar quais as fun es que devem ser levadas a cabo em que dados de forma a produzir que resultados em que local
12. ncias 35 Ap ndice B Modelo de EES ndice Gen rico da norma IEEE EIA 12207 1 1997 Cl usulas correspondentes da norma IEEE Std 830 1998 Adi es s exig ncias da norma IEEE Std 830 1998 e Contexto Sec o 1 1 Escopo f Nota o para a descri o Sec o 4 3 Caracter sticas de um bom documento de EES g Corpo Cap tulo 5 As partes de um documento de EES h Sum rio Sec o 5 1 1 Prop sito 1 Gloss rio Sec o 5 1 3 Defini es j Hist rico Hist rico de um SRD dever ser providenciado ou referenciado B 3 3 Conformidade com as exig ncias espec ficas da norma IEEE EIA 12207 1 1997 As exig ncias espec ficas para um SRD na norma IEEF EIA 12207 1 1997 s o prescritas por 6 22 da norma IEEE EIA 12207 1 1997 Um SRD concordante conseguir a finalidade indicada em 6 22 1 da norma IEEE EIA 12207 1 1997 A finalidade do SRD IEEE EIA 12207 1 1997 cl usula secund ria 6 22 1 Finalidade Especifique as exig ncias para um artigo do software e os m todos ser usado assegurar se de que cada exig ncia esteja atingida Usado como a base para o projecto e testar da qualifica o de um artigo do software Um documento de EES concordante com esta norma encontra se com as exig ncias adicionais da tabela B 3 desta norma conseguiria a finalidade indicada Um SRD que obedece com a norma IEEE EIA 12207 1 1997 satisfar as exig n
13. pessoas n o possuem o mesmo background e por essa raz o tendem a n o descrever as exig ncias de software da mesma forma Representa es que melhorem a especifica o de exig ncias para a equipa de desenvolvimento tendem a ser contra productivos porque diminuem a compreens o do documento pelos utilizadores e vice versa Da Sec o 4 3 2 1 at Sec o 4 3 2 3 encontra se as recomenda es para evitar ambiguidades 4 3 2 1 Problemas da l ngua natural As exig ncias s o normalmente escritas em l ngua natural por exemplo Portugu s ou Ingl s A l ngua natural prop cia a ambiguidades Uma l ngua natural de um documento de EES deve ser revista por algu m independente para identificar o uso de ambiguidades da linguagem que devem ser corrigidas 4 3 2 2 Linguagens de especifica o de exig ncias Um modo de contornar a ambiguidade inerente da linguagem natural consiste em escrever um documento de EES numa linguagem especial orientada para especifica o de exig ncias O processador desta linguagem tem a capacidade de detectar automaticamanente muitos erros lexicais sint cticos e sem nticos Uma desvantagem destas linguagens o tempo necess rio para as aprender Acresce ainda que os utilizadores n o t cnicos acham estas linguagens incompreens veis Estas linguagens t m tend ncia a servir para especificar certos tipos de exig ncias e exig ncias de dom nios espec ficos que s o utilizadas para certos tipos de
14. que possa ajudar os leitores do documento de EES 3 Uma descri o dos problemas a serem resolvidos pelo software 4 Instru es de empacotamento especiais para o c digo e para os suportes de distribui o por forma a satizfazer exig ncias de seguran a exporta o carregamento inicial ou outras Quando s o inclu dos ap ndices o documento de EES deve explicitamente referir se estes devem ser considerados parte integrante das exig ncias 26 Ap ndice A Modelos de EES Informativo A 1 Modelo de Sec o 3 do EES organizada por modo Vers o 1 3 Requisitos Espec ficos 3 1 Requisitos de Interface Externos 3 1 1 Interfaces de Utilizador 3 1 2 Interfaces de Hardware 1 3 Interfaces de Software 4 Interfaces de Comunica o Requisitos Funcionais 1 2 2 1 Modo 1 2 3 3 3 3 3 2 1 1 Requisito Funcional 1 1 32 1n Requisito Funcional 1 n 3 2 2 Modo 2 3 2 m Modo m 3 2 m 1 Requisito Funcional m 1 32mn Requisito Funcional m n 3 3 Requisitos de Performance 3 4 Restri es de Desenho 3 5 Atributos do Sistema de Software 3 6 Outros requisitos A 2 Modelo de Sec o 3 do EES organizada por modo Vers o 2 3 Requisitos Espec ficos 3 1 Requisitos Funcionais Modo 1 1 Interfaces Externas 1 1 Interfaces de Utilizador 1 2 Interfaces de Hardware 1 3 Interfaces de Software 1 4 Interfaces de Comunica o 2 Requisitos Funcionais 2 1 Requisitos Funcional 1 LO LD US USD US US WD LO Il
15. reservados Este documento est protegido pelas leis internacionais e pelos acordos de autoria Todos os produtos mencionados aqui s o apenas usados para fins de identifica o e s o marcas registadas dos seus legais detentores ndice 1 01 5 64 A OU DOE RES DE RR E RAARSEAREM SS robs TS SEO RARAS sao SP SRD ERC A ESSES CRS RS ANE E SP RES DS 1 1 1 Escopo esse aire e ie eE ie aussi REE T E ENE KNE E E SEEE EEEE auto fas eus EEE S 1 2 Refer ncias 3 Defini es E E E E E A E ENE A E N A E aa antas asa a atada 3 1 Contrat fOe eei a a E EEEa AE E E E E EE E EE EE E A EER R 4 PAE ME E EEEE E ETE E EEEE 4 3 3 Fornecedor soseo ereet eo a E AEE aE E E E E ERE EEE EEE O E EERE A EEROR ES 4 JA UAA OT a ERRO RR DE CRER RR ET RR ORE E E A AE t 4 4 Considera es para a produ o de um bom documento de EES esesssssesseseseecosssoseseececososeseseeeosososeseocecososeseseeeeee 5 4 1 Natureza do documento de EES niinen enie re eae eaaeo Eeo Se tore Se Eker tE eike ror VURSA i o 5 4 2 Ambiente do documento de EES seses Pesser eieae E E E EESE ERERKEN REI E 5 4 3 Caracter sticas de um bom documento de EES s ssssseesseeeeesesesrestrrssteresresertssentestntertnseetsrentetesrerrsreeesresreres 6 4 4 Prepara o conjunta do documento de EES erre eerererrereaa ae aerae era enranannaa 11 4 5 Evolu o do documento de EES sessesssssseeseseeseersresssreresresreresterestssertesentesterestnttssentetesttetstentetrsrerrsr
16. sistemas Por isso estas linguagens podem influenciar as exig ncias de formas por vezes subtis 4 3 2 3 Ferramentas de representa o De uma forma geral os m todos e linguagens de exig ncias bem como as respectivas ferramentas que as suportam podem ser agrupadas em tr s categorias Objectos processos e comportamentais As aproxima es orientadas aos objectos organizam as exig ncias em termos de objectos do mundo real dos seus atributos e dos servi os que oferecem As aproxima es baseadas em processos organizam as exig ncias em hierarquias de fun es que comunicam atrav s de fluxo de dados Finalmente as aproxima es comportamentais descrevem o comportamento externo do sistema em termos de no es abstractas por exemplo atrav s do c lculo de predicados atrav s de fun es matem ticas ou atrav s de m quinas de estados O grau at ao qual estas ferramentas e m todos se constituem teis na prepara o de um documento de EES depende do tamanho e da complexidade do programa Este standard n o pretende descrever ou sugerir nenhuma ferramenta em particular Cap tulo 4 Considera es para a produ o de um bom documento de EES Ao utilizar qualquer uma destas aproxima es recomenda se que se conserve a utiliza o da linguagem natural Desta forma os clientes que n o estejam familiarizados com nota es podem tamb m compreender o documento de EES 4 3 3 Completo Um documento de EES considera se
17. 2 1 m 1 Introdu o Objectivo da caracter stica 3 2 1 m 2 Est mulo Segqu ncia de resposta 3 2 1 m 3 Exig ncias Funcionais Associadas 3 2 2 Classe de utilizador 2 31 Ap ndice A Modelos de EES 3 2 n Classe de utilizador n 3 3 Exig ncias de desempenho 3 4 Restri es de Desenho 3 5 Atributos do Sistema de Software 3 6 Outros Requisitos 32 Ap ndice B Modelo de EES Informativo B 1 Vista geral O comit de padr es da tecnologia de programa o Software Engineering Standards Committee SESC da IEEE Computer Society endossou a pol tica de adoptar padr es internacionais Em 1995 o padr o internacional ISO IEC 12207 processos do ciclo de vida da tecnologia de Software de Informa o foi terminado O padr o estabelece uma estrutura comum para processos do ciclo de vida do software com terminologia bem definida que pode referenciada pela ind stria do software Em 1995 o SESC avaliou o ISO IEC 12207 e decidiu que esse padr o deveria ser adoptado e usado como base para processos de ciclo de vida dentro da JEEE Software Engineering Collection A adapta o do ISO IEC 12207 pela IEEE o IEEE EIA 12207 0 1996 Este cont m a norma ISO IEC 12207 e as seguintes adi es melhoramento da abordagem de conformidade objectivos do processo do ciclo de vida objectivos dos dados do ciclo de vida e erratas A implementa o da norma ISO IEC 12207 dentro da IEEE inclui tamb m o seguinte IEEE EIA 12207 1 1997 gu
18. 2 2 Classe Objecto 2 28 32 p Classe Objecto p 3 3 Requisitos de Performance 3 4 Restri es de Desenho 3 5 Atributos do Sistema de Software 3 6 Outros Requisitos Ap ndice A Modelos de EES A 5 Modelo de Sec o 3 do EES organizada por caracter stica 3 Requisitos Espec ficos 3 1 Requisitos de Interface Externos 3 1 1 Interfaces de Utilizador 3 1 2 Interfaces de Hardware 3 1 3 Interfaces de Software 3 1 4 Interfaces de Comunica o 3 2 Caracter sticas de sistema 3 2 1 Caracter stica de sistema 1 3 2 1 1 Introdu o Objectivo da caracter stica 3 2 1 2 Est mulo Sequ ncia de resposta 3 2 1 3 Requisitos Funcionais Associados 3 2 1 3 1 Requisito Funcional 1 32 13n Requisito Funcional n 3 2 2 Caracter stica de sistema 2 3 2 m Caracter stica de sistema m 3 3 Requisitos de Performance 3 4 Restri es de Desenho 3 5 Atributos do Sistema de Software 3 6 Outros Requisitos A 6 Modelo de Sec o 3 do EES organizada por est mulos 3 Requisitos Espec ficos 3 1 Requisitos de Interface Externos 3 1 1 Interfaces de Utilizador 3 1 2 Interfaces de Hardware 1 3 Interfaces de Software 1 4 Interfaces de Comunica o 2 Requisitos Funcionais 2 1 Est mulo 1 2 3 3 3 3 3 2 1 1 Requisito Funcional 1 1 32 1n Requisito Funcional 1 n 3 2 2 Est mulo 2 3 2 m Est mulo m 3 2 m 1 Requisito Funcional m 1 29 32mn Requisito Funcional m n 3 3 Requisitos de Performance 3 4 Restri es de
19. Condicionais Implicam que as exig ncias constituem melhorias ao produto de software mas a sua aus ncia n o o torna inaceit vel c Opcionais Implica que estas exig ncias se refiram a funcionalidades que podem n o ser necess rias Estas exig ncias d o ao fornecedor a oportunidade de propor algo que exceda o documento de EES Cap tulo 4 Considera es para a produ o de um bom documento de EES 4 3 6 Verific vel Um documento de EES diz se verific vel se e s se cada exig ncia especificada verific vel Uma exig ncia verific vel se e s se existe um processo finito e de custo aceit vel atrav s do qual uma pessoa ou uma m quina pode verificar que o produto de software cumpre essa exig ncia Em geral uma exig ncia amb gua n o verific vel Exig ncias n o verific veis incluem por norma frases tais como trabalha bem boa interface ou ir acontecer normalmente Estas exig ncias n o podem ser verificados pois n o poss vel definir os termos bom normalmente A exig ncia O programa nunca entrar num ciclo infinito embora esteja definida objectivamente bem ou n o verific vel pois testar esta qualidade teoricamente imposs vel Exemplo 4 1 Exemplo de uma exig ncia verific vel O resultado do programa produzido em menos de 20 segundos a partir do momento da recep o do evento arranque Esta exig ncia verific vel porque utiliza termos e quantidades mensur
20. IEEE Std 830 Pr tica Recomendada Para Especifica es de Exig ncias de Software Standard Internacional Andr Gon alves IST Universidade T cnica de Lisboa Fernando Martins Paulo Carreira FCUL Universidade de Lisboa Pedro Lopes S rgio Nunes IEEE Std 830 Pr tica Recomendada Para Especifica es de Exig ncias de Software Standard In ternacional por Andr Gon alves Fernando Martins Paulo Carreira Pedro Lopes e S rgio Nunes Publicado Abril 2004 Norma IEEE Std 830 1998 Este documento foi elaborado sobre a norma IEEE Std 830 1998 IEEE Recommended Practice for Software Requirements Specifications Este documento descreve o conte do e a qualidade de uma boa especifica o de exig ncias de software EES e apresenta exemplos de poss veis tipos de estruturas de documentos EES Esta pr tica recomendada orientada especifica o de exig ncias de software a serem desenvolvidas mas tamb m pode ser aplicado na assist ncia de selec o de produtos comerciais ou desenvolvidos pela pr pria empresa Linhas de orienta o gerais para conformidade com a norma IEEE EIA 12207 1 1997 tamb m s o disponibilizadas Este documento assim uma recomenda o pr tica da implementa o da norma em quest o e tem a finalidade de definir o standard para defini o de exig ncias Avisos legais Este documento uma tradu o do standard IEEE STD 830 e n o tem sobre o mesmo qualquer direito Todos os direitos
21. Produce Reliable Software IEEE Std 982 2 1988 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software IEEE Std 1002 1987 Reaff 1992 IEEE Standard Taxonomy for Software Engineering Standards IEEE Std 1012 1998 IEEE Standard for Software Verification and Validation IEEE Std 1012a 1998 IEEE Standard for Software Verification and Validation Content Map to IEEE EIA 12207 1 1997 IEEE Std 1016 1998 IEEE Recommended Practice for Software Design Descriptions IEEE Std 1028 1997 IEEE Standard for Software Reviews IEEE Std 1042 1987 Reaff 1993 IEEE Guide to Software Configuration Management IEEE P1058 D2 1 Draft Standard for Software Project Management Plans dated 5 August 1998 IEEE Std 1058a 1998 IEEE Standard for Software Project Management Plans Content Map to IEEE EIA 12207 1 1997 7 IEEE Std 1074 1997 IEEE Standard for Developing Software Life Cycle Processes IEEE Std 1233 1998 Edition IEEE Guide for Developing System Requirements Specifications Notas 1 As publica es ASTM est o dispon veis na American Society for Testing and Materials 100 Barr Harbor Drive West Conshohocken PA 19428 2959 USA 2 As publica es IEEE est o dispon veis no Institute of Electrical and Electronics Engineers 445 Hoes Lane P O Box 1331 Piscataway NJ 08855 1331 USA 3 data desta publica o os standards IEEE Std 828 1998 IEEE Std 1012a 1998 IEEE Std 1016 1998 e IEEE S
22. a o de ecr i Formato organiza o de janela j Formatos de dados k Formatos de comandos 1 Mensagens finais 20 Cap tulo 5 As partes de um documento de EES 5 3 2 Fun es As exig ncias funcionais devem definir as ac es fundamentais que devem ter lugar no software ao aceitar e processar as entradas e ao processar e gerar as sa das Estes s o geralmente listados usando frases na forma O sistema deve Estas incluem a Valida es da entrada b Segu ncias exactas de opera o c Reac es a situa es anormais incluindo 1 Overflow 2 Falhas de comunica o 3 Tratamento e recupera o de erros d Efeitos dos par metros e Rela o de entradas com sa das incluindo 1 Segu ncias de entrada sa da 2 Formulas de convers o da entrada para a sa da Pode ser apropriado dividir as exig ncias funcionais em sub fun es ou sub processos Isto n o implica que o desenho do software tamb m venha a ser dividido da mesma forma 5 3 3 Exig ncias de desempenho Esta sub sec o deve especificar exig ncias num ricas est ticas e exig ncias num ricas din micas impostas ao software ou interac o humana com o software como um todo Exig ncias num ricas est ticas podem incluir os seguintes pontos a O n mero de terminais a suportar b O n mero de utilizadores simult neos a suportar c Quantidades e tipos de informa o a processar As exig ncias num ricas est tic
23. as s o por vezes identificadas sob uma sec o separada intitulada Capacidade As exig ncias num ricas din micas podem incluir por exemplo o n mero de transac es e tarefas e a quantidade de dados a processar num determinado per odo de tempo em condi es de carga normal e carga m xima Todas estas exig ncias devem ser definidas em termos quantific veis Por exemplo 95 das transac es devem ser processadas em menos de 1 segundo em vez de O operador n o deve ter de esperar que a transac o complete Nota Limites num ricos aplic veis a uma fun o espec fica s o normalmente especificados como parte de um sub par grafo de descri o do processamento dessa fun o 21 Cap tulo 5 As partes de um documento de EES 5 3 4 Exig ncias l gicas da base de dados Aqui devem ser especificadas as exig ncias l gicas sobre qualquer informa o que deva ser colocada numa base de dados Isto pode incluir o seguinte a Tipos de informa o usados pelas v rias fun es b Frequ ncia de uso c Capacidades de acesso d Entidades e rela es e Restri es de integridade f Exig ncias de reten o dos dados 5 3 5 Restri es de desenho Aqui devem ser especificadas restri es ao desenho que possam ser impostas por outras normas limita es de hardware etc 5 3 5 1 Obedi ncia a normas Esta sub sec o deve especificar as exig ncias derivadas de normas ou regulamentos existentes Pod
24. cias espec ficas fornecidas em 6 22 3 e em 6 22 4 daquela norma Tabela B 3 desta norma recomendada lista os artigos especificos e onde apropriado refer ncias a cl usulas desta norma recomendada que requer a mesma informa o Um SRD especificou concordar as exig ncias indicadas ou referidas na tabela B 3 desta pr tica recomendada ser avaliado considerando os crit rios fornecidos em 5 3 4 2 de IEEE EIA 12207 0 1996 Tabela B 3 Cobertura de exig ncias espec ficas da descri o da norma IEEE Std 830 1998 ndice Gen rico da norma IEEE EIA 12207 1 1997 Cl usulas correspondentes da norma IEEE Std 830 1998 Adi es s exig ncias da norma IEEE Std 830 1998 a Informa o gen rica da descri o Veja a tabela B 2 b Identifica o e vista geral do sistema Sec o 5 1 1 Prop sito 36 Ap ndice B Modelo de EES ndice Gen rico da norma IEEE EIA 12207 1 1997 Cl usulas correspondentes da norma IEEE Std 830 1998 Adi es s exig ncias da norma IEEE Std 830 1998 c Funcionalidade do artigo do software incluindo e Exig ncias de desempenho e Caracter sticas f sicas e Circunst ncias ambientais Sec o 5 3 2 Fun es Sec o 5 3 3 Exig ncias de desempenho As caracter sticas f sicas e as circunst ncias ambientais devem ser fornecidas d Exig ncias para as interfaces externas ao item do software Sec o 5 3 1 Interfaces externa
25. cificado o seguinte a As caracter sticas l gicas de cada interface entre o produto de software e os seus utilizadores Isto inclui as caracter sticas de configura o por exemplo formatos de ecr necess rios disposi o de p gina ou janela conte do de quaisquer relat rios ou menus ou disponibilidade de teclas de fun o program veis necess rias para cumprir as exig ncias de software b Todos os aspectos de optimiza o da interface com a pessoa que deve usar o sistema Isto pode consistir simplesmente de uma lista do que se deve ou n o fazer no modo como o sistema aparece ao utilizador Um exemplo pode ser a exig ncia para uma op o de mensagens de erro longas ou curtas Tal como todas as outras estas exig ncias devem ser verific veis por exemplo um funcion rio dactil grafo de grau 4 consegue fazer a fun o X em Z minutos ap s 1 hora de treino em vez de um dactil grafo pode fazer a fun o X Isto pode tamb m ser especificado na sec o de Atributos do sistema de software ver Sec o 5 3 6 sob uma sub sec o intitulada Facilidade de Utiliza o 5 2 1 3 Interfaces de hardware Aqui devem ser especificadas as caracter sticas l gicas de cada interface entre o produto de software e os componentes de hardware do sistema Isto inclui caracter sticas de configura o n mero de portos conjuntos de instru es etc Cobre tamb m assuntos como os dispositivos a suportar como estes devem ser suporta
26. completo se e s se inclui os seguintes elementos a Todas as exig ncias significantes quer se prendam com a funcionalidade o desempenho restri es de desenho atributos ou interfaces externas em particular quaisquer exig ncias externas impostas por especifica es de sistemas est o reconhecidas e tratadas b Est o definidas as respostas do software a todas as classes realiz veis de entradas de dados em todas as classes de situa es c Legendas e refer ncias completas para todas as figuras tabelas e diagramas do documento de EES bem como a defini o de todos os termos e unidades de medida 4 3 3 1 Utiliza o de TDBs Qualquer documento de EES que utilize a frase a determinar ou to be determined TBD n o est completo O acr nimo TBD no entanto necess rio ocasionalmente e deve ser acompanhado por a Uma descri o das condi es que causam o TBD por exemplo explica o de porque n o conhecida a resposta de forma a que a situa o possa ser resolvida b Uma descri o do que deve ser feito para eliminar o TBD quem respons vel pela sua elimina o e at quando deve ser eliminado 4 3 4 Consist ncia Consist ncia refere se consist ncia interna Se um documento de EES n o est de acordo com um documento de mais alto n vel tal como seja uma especifica o de exig ncias de sistema ent o ele n o est correcto veja a Sec o 4 3 1 4 3 4 1 Consist ncia interna
27. da uma das suas exig ncias clara e facilitadora da identifica o da mesma exig ncia em vers es futuras do desenvolvimento ou da documenta o S o recomendados os seguintes dois tipos de rastreio 10 Cap tulo 4 Considera es para a produ o de um bom documento de EES a Rastreio para tr s i e para est dios anteriores do desenvolvimento Isto depende do facto de cada exig ncia explicitamente referir a sua fonte em outros documentos que d o origem ao requisito b Rastreio para a frente i e para todos os documentos que emanam do documento de FES sejam eles c digo ou documenta o propriamente dita Isto depende do facto de cada exig ncia no documento de EES ter um nome ou um n mero de refer ncia nicos O rastreio para a frente num documento de EES especialmente importante quando o produto de software entra na fase de opera o e manuten o A medida que o c digo e o desenho v o sendo modificados torna se essencial possuir meios para aferir acerca do conjunto completo de exig ncias que podem ser afectados por essas modifica es 4 4 Prepara o conjunta do documento de EES O processo de desenvolvimento de software deve come ar com o acordo por parte do cliente e do fornecedor acerca daquilo que o software uma vez completo deve fazer Este acordo sob a forma de um documento de EES deve ser preparado de forma conjunta Isto importante pois usualmente nem o cliente nem o fornecedor est o compl
28. dem ser organizadas em sec es de acordo com fun es associadas com a gera o de cheques de pagamento de listas de empregados etc Deve ser utilizado o esbo o da Sec o A 6 com todas as ocorr ncias de est mulos substitu das por respostas 24 Cap tulo 5 As partes de um documento de EES 5 3 7 7 Hierarquia funcional Quando nenhum dos esquemas organizacionais anteriores provam ser teis a funcionalidade total pode ser organizada numa hierarquia de fun es organizadas por entradas comuns sa das comuns ou dados internos comuns Diagramas de fluxo de dados e dicion rios de dados podem ser usados para mostrar relacionamentos entre as fun es e os dados Quando se organiza esta sec o pela hierarquia funcional deve ser usado o esbo o da Sec o A 7 5 3 8 Coment rios adicionais Sempre que contemplado um documento de EES novo v rias das t cnicas organizacionais dadas na Sec o 5 3 7 7 podem ser empregues Nestes casos organizam se as exig ncias espec ficas para as m ltiplas hierarquias ligadas s necessidades espec ficas do sistema que est a ser especificado Por exemplo ver a Sec o A 8 para uma organiza o que combina classes de utilizador e caracter sticas Quaisquer exig ncias adicionais podem ser postas numa sec o separada no fim do documento de EES Existem muitas nota es m todos e ferramentas de apoio automatizado dispon veis para ajudar na documenta o de exig ncias Na maior par
29. do como exig ncias de software Divide se em cinco cap tulos A Sec o 1 1 explica o escopo desta pr tica recomendada O Cap tulo 2 lista as refer ncias feitas a outros standards O Cap tulo 3 disponibiliza defini es de termos usados O Cap tulo 4 d um enquadramento informativo para escrever uma boa Especifica o de Exig ncias de Software EES Software Requirements Specification SRS no original O Cap tulo 5 disserta sobre cada uma das partes essenciais de um documento de EES Esta pr tica recomendada tamb m possui dois anexos um disponibilizando formatos alternativos e outro disponibilizando linhas de orienta o para conformidade com IEEE EIA 12207 1 1997 1 1 Escopo Esta uma recomenda o pr tica para escrever especifica es de requisitos de software Este documento descreve o conte do e as qualidades de um bom documento de EES e apresenta diversos exemplos Esta pr tica recomendada tem como objectivo a especifica o de exig ncias de software a ser desenvolvido mas tamb m pode ser usada na selec o de produtos comerciais de software No entanto a sua aplica o a software j desenvolvido pode ser contra producente Quando o software est embebido em sistemas de grande escala como sejam equipamentos m dicos ent o tudo o que est fora do mbito deste documento deve ser visto em particular Esta recomenda o pr tica descreve o processo da cria o de um produto e o conte do desse mesmo
30. dos e protocolos 5 2 1 4 Interfaces de software Aqui deve ser especificado o uso de outros produtos de software necess rios por exemplo um sistema de gest o de base de dados um sistema operativo ou um pacote matem tico e interfaces com outros sistemas aplicacionais por exemplo a liga o entre um sistema de vendas e o sistema de contabilidade Para cada produto de software necess rio deve ser fornecido o seguinte Nome Mnem nica N mero de especifica o e N mero de vers o e Fonte Para cada interface o seguinte deve ser fornecido 17 Cap tulo 5 As partes de um documento de EES e Uma discuss o sobre a fun o do software com que feita a interface e a sua rela o com este produto de software e Defini o da interface em termos de conte do e formato de mensagens N o necess rio detalhar interfaces que estejam bem documentadas mas deve existir uma refer ncia para o documento que define a interface 5 2 1 5 Interfaces de comunica o Aqui devem ser especificadas as v rias interfaces de comunica o tais como protocolos de rede etc 5 2 1 6 Mem ria Aqui devem ser especificados os limites e quaisquer outras caracter sticas aplic veis da mem ria prim ria e secund ria 5 2 1 7 Opera es Aqui devem ser especificadas as opera es normais e especiais requeridas pelo utilizador tais como a Os v rios modos de opera o na organiza o que utiliza o software
31. eersreee 11 4 6 Pr t tpagem aene e ae RR NR REDE RP E PRO a PO RO 12 4 7 Incorpora o do desenho no documento de EES ssssseseessssrerrsssstssrsrsesrsresrsseeresenrrresseersrentetrsrerrsreersresee 12 4 8 Incorpora o de exig ncias do projecto no documento de FES aa 13 5 As partes de um documento de EES crecerneeernecernerernenerecresecneseonesesnesesnesesnesesnesescen escore se cne cerne cosas eras esc snasasa 14 5 1 Introdu o Sec o 1 do documento de EES eee re enteada 14 5 2 Descri o geral Sec o 2 do documento de EES een 16 5 3 Exig ncias espec ficas Sec o 3 do documento de EES erra 20 54 Informa o de su porte isestem E E in e iene saio Toca EE E da EL CREED EE E cnah adido da has hip a San ca o 25 A Modelos de EES nnair aiiin aE atas esa asas as aa dente asa ta actas caca casas ca ata datada 27 A 1 Modelo de Sec o 3 do EES organizada por modo Vers o 1 27 A 2 Modelo de Sec o 3 do EES organizada por modo Vers o 2 27 A 3 Modelo de Sec o 3 do EES organizada por classe de utilizador 28 A 4 Modelo de Sec o 3 do EES organizada por objecto erre 28 A 5 Modelo de Sec o 3 do EES organizada por caracter stica eee 29 A 6 Modelo de Sec o 3 do EES organizada por est mulos eee 29 A 7 Modelo de Sec o 3 do EES organizada por hie
32. eja ISO IEC 5806 12207 1 1997 5807 6593 8631 8790 e 11411 para orienta o no uso de nota es 34 Ap ndice B Modelo de EES As exig ncias para a conformidade do original s o discutidas nas seguintes cl usulas secund rias Sec o B 3 1 discute a conformidade com as exig ncias de informa o not veis na coluna 2 da tabela B 1 como prescrito por 5 1 1 4 por 5 3 4 1 e por 5 3 4 2 da norma IEEE EIA 12207 0 1996 Sec o B 3 2 discute a conformidade com as linhas gerais do conte do gen rico o tipo de documento vis vel na coluna 3 da tabela B 1 como uma descri o O conte do gen rico das linhas gerais para uma descri o aparecem em 5 1 da norma IEEE EIA 12207 1 1997 Sec o B 3 3 discute a conformidade com as exig ncias espec ficas para uma descri o das exig ncias do software not vel na coluna 4 da tabela B 1 como prescrito por 6 22 da norma IEEE EIA 12207 1 1997 Sec o B 3 4 discute a conformidade com os objectivos dos dados do ciclo de vida do Anexo H da norma IEEE EIA 12207 0 1996 como descritos em 4 2 da norma IEEE EIA 12207 1 1997 B 3 1 Conformidade com exig ncias de informa o da norma IEEE EIA 12207 0 1996 As exig ncias de informa o para um SRD s o aquelas prescritas por 5 1 1 4 por 5 3 4 1 e por 5 3 4 2 de IEEE EIA 12207 0 1996 As exig ncias s o substantivamente id nticas quelas consideradas em B 3 3 desta pr tica recomendada B 3 2 Conformidade com as linhas g
33. em incluir os seguintes a Formato de relat rios b Nomea o de dados c Procedimentos contabil sticos d Rastreio e auditoria Por exemplo pode se especificar aqui a exig ncia de que o software fa a o rastreio da actividade de processamento Tal rastreio pode ser necess rio em algumas aplica es para estar em conformidade com normas reguladoras ou financeiras Uma exig ncia de rastreio e auditoria pode por exemplo ditar que todas as altera es a uma base de dados de pagamentos sejam gravadas num ficheiro de rastreio com os valores antes e depois da transac o 5 3 6 Atributos do sistema de software Existe um n mero de atributos do software que podem servir de exig ncias importante que os atributos requeridos sejam especificados de modo a que o seu cumprimento possa ser objectivamente verificado Da Sec o 5 3 6 1 at Sec o 5 3 6 5 fornecida uma lista parcial de exemplos 5 3 6 1 Fiabilidade Deve especificar os factores necess rios para estabelecer a fiabilidade exigida ao sistema de software no acto da entrega 22 Cap tulo 5 As partes de um documento de EES 5 3 6 2 Disponibilidade Deve especificar os factores necess rios para garantir um n vel definido de disponibilidade para todo o sistema tais como o ponto de verifica o recupera o e rein cio 5 3 6 3 Seguran a Deve especificar os factores que protejam o software do acesso do uso da modifica o da destrui o o
34. en ricas da norma IEEE EIA 12207 1 1997 De acordo com a norma IEEF EIA 12207 1 1997 as linhas gen ricas para um SRD geralmente uma descri o como prescrito por 5 1 de TEEF EIA 12207 1 1997 Uma descri o concordante conseguir a finalidade indicada em 5 1 1 e incluir a informa o listada em 5 1 2 da norma IEEF EIA 12207 1 1997 A finalidade de uma descri o IEEE EIA 12207 1 1997 sub cl usula 5 1 1 Finalidade Descrever uma fun o um projecto um desempenho ou um processo de planeamento ou real Um SRD concordante com esta pr tica recomendada conseguiria a finalidade indicada Toda a descri o ou especifica o concordante com a norma IEEF EIA 12207 1 1997 satisfar as exig ncias gen ricas fornecidas em 5 1 2 daquela norma A tabela B 2 de lista gen rica de pr ticas recomendadas contento os artigos e onde apropriado as refer ncias gen ricas da cl usula desta pr tica recomendada que requer a mesma informa o Tabela B 2 Cobertura de exig ncias gen ricas da descri o da norma IEEE Std 830 1998 ndice Gen rico da norma Cl usulas correspondentes da Adi es s exig ncias da IEEE EIA 12207 1 1997 norma IEEE Std 830 1998 norma IEEE Std 830 1998 a Data de edi o e de status A data de edi o e o estado ser fornecida b Escopo Sec o 5 1 1 Prop sito c Relativo organiza o A organiza o ser identificada d Refer ncias Sec o 5 1 4 Refer
35. es ao produto de software Note se que para bem da clareza a As fun es devem ser organizadas de um modo que torne a lista de fun es compreens vel para o cliente ou quem quer que esteja a ler o documento pela primeira vez b M todos textuais ou gr ficos podem ser usados para mostrar as diferentes fun es e as suas inter rela es Tais diagramas n o se destinam a mostrar o desenho t cnico do produto mas simplesmente a mostrar as rela es l gicas entre vari veis 5 2 3 Caracter sticas do utilizador Sec o 2 3 do documento de EES Esta sub sec o do documento de EES deve descrever as caracter sticas gerais dos utilizadores alvo do produto incluindo n vel de forma o experi ncia e profici ncia t cnica N o deve ser usada para ditar exig ncias espec ficas mas sim para fornecer as raz es pelas quais certas exig ncias espec ficas s o mais tarde determinados na Sec o 3 do documento de EES ver a Sec o 5 3 5 2 4 Restri es Sec o 2 4 do documento de EES Esta sub sec o do documento de EES deve fornecer uma descri o geral de quaisquer outros itens que limitem as op es de desenvolvimento Estes incluem a Regulamentos b Limita es de hardware c Interfaces com outras aplica es d Opera o em paralelo e Fun es de auditoria f Fun es de controlo g Exig ncias de alto n vel da linguagem h Protocolos de signal handshake i Exig ncias de fiabilidade
36. estri es q Exig ncias de recursos do computador Sec o 5 3 3 Exig ncias de desempenho Exig ncias de recursos do computador r Exig ncias de empacotamento Exig ncias de empacotamento s Preced ncia e criticalidade das exig ncias Sec o 5 2 6 Divis o e atribui o das exig ncias t Rastreio de exig ncias Sec o 4 3 8 Rastre vel 37 Ap ndice B Modelo de EES ndice Gen rico da norma IEEE EIA 12207 1 1997 Cl usulas correspondentes da norma IEEE Std 830 1998 Adi es s exig ncias da norma IEEE Std 830 1998 u Racionaliza o Sec o 5 2 5 Assun es e depend ncias Os artigos a a f abaixo s o de 6 22 4 dos objectivos dos dados do Anexo H da norma IEEF EIA 12207 0 1996 a Suporte ao ciclo de vida Suporte ao ciclo de vida dos objectivos dos dados do Anexo H da norma IEEE EIA 12207 0 1996 b Descreva todas as fun es usando nota o bem definida Sec o 4 3 Caracter sticas de um bom documento de EES c N o definir nenhuma exig ncia que esteja em conflito Sec o 4 3 Caracter sticas de um bom documento de EES d Terminologia e defini es padr o do utilizador Sec o 5 1 3 Defini es acr nimos e abreviaturas e Defina cada exig ncia de modo a prevenir inconsist ncias Sec o 4 3 Caracter sticas de um bom documento de EES f Identificar cada exig ncia univ
37. etamente qualificados para escrever um bom documento de EES de uma forma unilateral a Os clientes normalmente n o compreendem o suficiente dos processos de desenho e desenvolvimento de software para escrever este documento b Os fornecedores normalmente n o compreendem os problemas e os neg cios dos clientes o suficiente para escreverem o documento de exig ncias de forma satisfat ria Assim sendo o cliente e o fornecedor devem trabalhar de forma conjunta para produzir um documento de exig ncias bem escrito e completo O caso em que o software e o sistema onde se enquadra est o a ser elaborados simultaneamente constituiu uma situa o especial Neste caso a funcionalidade as interfaces o desempenho outros atributos e restri es do software n o s o predefinidos mas sim definidos de forma conjunta ficando sujeitos negocia o e mudan a Isto torna mais dif cil mas n o menos importante o alcance das caracter sticas expressas na Sec o 4 3 Em particular se um documento de EES n o est de acordo com a especifica o do seu sistema de acolhimento est incorrecto A presente recomenda o de pr tica este standard n o discute um estilo espec fico uso de linguagem ou t cnicas de boa escrita Reveste se da maior import ncia no entanto que um documento de EES esteja bem escrito Livros sobre escrita t cnica devem ser utilizados para melhorar as capacidades de escrita de exig ncias 4 5 Evolu o do docume
38. ganizar as exig ncias de uma forma simples de compreender N o existe uma organiza o ptima para todos os sistemas Diferentes classes de sistemas inclinam se para diferentes organiza es de exig ncias na Sec o 3 de um documento de EES Algumas dessas organiza es s o descritas da Sec o 5 3 7 1 at Sec o 5 3 7 7 23 Cap tulo 5 As partes de um documento de EES 5 3 7 1 Modo de sistema Alguns sistemas comportam se de maneiras diferentes dependendo do modo de opera o Por exemplo um sistema de controlo pode ter um conjunto de diferentes fun es dependendo do seu modo treino normal ou emerg ncia Quando se organiza esta sec o pelo modo devem ser usados os esbo os da Sec o A 1 ou da Sec o A 2 do presente documento A escolha depende de as interfaces e a performance serem ou n o dependentes do modo de opera o 5 3 7 2 Classe do utilizador Alguns sistemas providenciam diferentes conjuntos de fun es para diferentes classes de utilizadores Por exemplo um sistema de controlo de um elevador apresenta diferentes capacidades para os passageiros para os trabalhadores de manuten o e para os bombeiros Quando se organiza esta sec o pela classe do utilizador deve ser usado o esbo o da Sec o A 3 5 3 7 3 Objectos Objectos s o entidades reais que tem correspond ncia no sistema Por exemplo num sistema de monitoriza o de pacientes os objectos incluem pacientes sensores enfermeiras quart
39. ia da IEEE EIA para processos do ciclo de vida do Tecnologia de Software de informa o dados do ciclo de vida IEEE EIA 12207 2 1997 guia da IEEE EIA para processos do ciclo de vida do Tecnologia de Software de informa o considera es da execu o e As adi es a 11 padr es de SESC isto IEEE Stds 730 828 829 830 1012 1016 1058 1062 1219 1233 1362 para definir a correla o entre os dados produzidos por padr es existentes de SESC e pelos dados produzidos pela aplica o da norma IEEF EIA 12207 1 1997 Nota Embora a norma IEEF EIA 12207 1 1997 seja apenas um guia cont m indica es para a sua aplica o como sendo um padr o com conformidade de exig ncias espec ficas Este ap ndice trata a norma 12207 1 1997 como um padr o B 1 1 Escopo e finalidade A norma IEEE Std 830 1998 e a norma IEEE EIA 12207 1 1997 colocam exig ncias no Documento Descritivo de Exig ncias de Software A finalidade deste ap ndice explicar o relacionamento entre as duas normas das exig ncias de modo que os utilizadores possam produzir os originais pretendidos que respeitam as ambas as normas o possam fazer B 2 Correla o Esta cl usula explica o relacionamento entre a norma IEEE Std 830 1998 a norma IEEE EIA 12207 0 1996 e a norma IEEE EIA 12207 1 1997 nas seguintes reas terminologia processo e dados do ciclo de vida 33 Ap ndice B Modelo de EES B 2 1 Correla o de terminologia Tanto esta norma rec
40. ncluir no m nimo uma descri o de cada entrada est mulo ao sistema cada sa da resposta do sistema e todas as fun es levadas a cabo pelo sistema em resposta a uma entrada ou em suporte de uma sa da Uma vez que esta frequentemente a parte maior e mais importante do documento de EES aplicam se os seguintes princ pios a Exig ncias espec ficas devem ser ditadas de acordo com todas as caracter sticas descritas na Sec o 4 3 b Exig ncias espec ficas devem fazer refer ncia a documentos anteriores que estejam relacionados c Todas as exig ncias devem ser unicamente identific veis d Deve ser dada aten o cuidada organiza o das exig ncias de forma a maximizar a legibilidade Antes de examinar formas espec ficas de organizar as exig ncias til entender os v rios itens em que consiste a exig ncia como descrito da Sec o 5 3 1 at Sec o 5 3 7 5 3 1 Interfaces externas Esta deve ser uma descri o detalhada de todas as entradas e sa das do sistema de software Deve complementar as descri es de interfaces da Sec o 5 2 e n o deve repetir informa o l detalhada Deve cobrir quer conte do quer formato da seguinte maneira a Nome do item og Descri o do objectivo c Fonte da entrada ou destino da sa da d Intervalo de validade precis o e ou toler ncia e Unidades de medida f Temporiza es g Rela o com outras entradas sa das h Formato organiz
41. nto de EES O documento de EES pode necessitar de evoluir medida que o desenvolvimento do produto de software avan a Pode ser imposs vel especificar todos os detalhes na altura em que o projecto iniciado por exemplo pode ser imposs vel definir todos os formatos de ecr de uma aplica o interactiva durante a fase de requisitos Mudan as subsequentes do documento podem ser encaradas como defici ncias ou imprecis es descobertas no documento de EES As duas principais considera es a ter neste processo s o 11 Cap tulo 4 Considera es para a produ o de um bom documento de EES a As exig ncias devem ser especificadas da forma mais completa e aprofundada poss vel a partir do conhecimento dispon vel num determinado momento pode implicar pesquisa ainda que revis es evolutivas se prevejam inevit veis O facto de que a descri o est incompleta deve ser anotado b Um processo formal de modifica es deve ser iniciado para identificar controlar rastrear e reportar as modifica es projectadas As modifica es aprovadas nas exig ncias devem ser incorporadas no documento de EES de forma a 1 Providenciar um historial de modifica es audit vel preciso e completo 2 Permitir a revis o de por es correntes ou j substitu das do documento de EES 4 6 Prototipagem A prototipagem utilizada frequentemente durante a fase de desenvolvimento de exig ncias V rias ferramentas podem ser utilizadas de
42. o produto de software As exig ncias do projecto representam um entendimento entre o cliente e o fornecedor sobre quest es contratuais relacionadas com o processo de software e assim n o podem ser inclu das nas exig ncias Nestes itens incluem se refer ncias a a Custo b Datas de entrega c Procedimentos de reporte d M todos de desenvolvimento de software e Certifica o de qualidade f Crit rios de verifica o e valida o g Procedimentos de aceita o Exig ncias do projecto s o especificados em outros documentos tipicamente num plano de desenvolvimento de software e num plano de certifica o de qualidade de software 13 Cap tulo 5 As partes de um documento de EES Esta cl usula discute cada um dos componentes essenciais de um documento de EES Estas partes s o apresentadas na Tabela 1 delineando uma estrutura que pode servir de exemplo para a escrita de documentos de EES Se bem que um documento de EES n o tenha de seguir esta estrutura ou utilizar os nomes aqui sugeridos para os seus componentes um bom documento de exig ncias deve incluir toda a informa o aqui descrita Tabela 5 1 Prot tipo da estrutura de um documento de EES 1 Introdu o 1 1 Prop sito 1 2 mbito 1 3 Defini es acr nimos e abreviaturas 1 4 Refer ncias 1 5 Organiza o 2 Descri o geral 2 1 Perspectiva do produto 2 2 Funcionalidades do produto 2 3 Caracter sticas do utilizador 2 4 Rest
43. ocamente Sec o 4 3 Caracter sticas de um bom documento de EES B 3 4 Conformidade com objectivos dos dados do ciclo de vida Al m s exig ncias satisfeitas os dados do ciclo de vida ser o controlados de acordo com os objectivos fornecidos no Anexo H da norma IEEE EIA 12207 0 1996 B 4 Conclus o A an lise sugere que todo o documento de EES que obedece a esta norma e as adi es mostradas na tabela B 2 e na tabela B 3 obedece tamb m s exig ncias de um SRD na norma IEEE EIA 12207 1 1997 Em adi o para obedecer norma IEEE EIA 12207 1 1997 um documento de EES suportar os objectivos dos dados do ciclo de vida do Anexo H da norma IEEE EIA 12207 0 1996 38
44. omendada como a norma IEEE EIA 12207 0 1996 t m uma sem ntica similar para os termos chave do software das exig ncias da especifica o do fornecedor do colaborador e de quem faz a manuten o Esta norma recomendada usa o termo cliente onde a norma IEEE EIA 12207 0 1996 usa o comprador e esta norma recomendada usa o utilizador onde a norma IEEF EIA 12207 0 1996 usa o operador B 2 2 Correla o de processo IEEF EIA 12207 0 1996 usa uma aproxima o orientada ao processo de modo a definir a descri o de um conjunto de exig ncias para o software Esta pr tica recomendada usa uma aproxima o orientada ao produto onde o produto uma descri o das exig ncias do software SRD Existem etapas naturais de processo nomeadamente as etapas de cria o de cada parcela do SRD Estas podem ser correlacionadas com as exig ncias no processo da norma IEEE EIA 12207 0 1996 A diferen a que esta pr tica est focalizada no desenvolvimento de exig ncias do software visto que a norma IEEE EIA 12207 0 1996 fornece uma vista global do ciclo de vida e menciona a an lise de exig ncias do software como a parte de seu processo do desenvolvimento Esta pr tica fornece um n vel mais elevado no detalhe em o que envolvido na prepara o de um SRD B 2 3 Correla o do ciclo de vida dos dados IEEE EIA 12207 0 1996 parte do ponto de vista que as exig ncias do software s o derivados das exig ncias do sistema Consequentemente
45. os medicamentos etc Associado a cada objecto est um conjunto de atributos desse objecto e fun es efectuadas por esse objecto Essas fun es s o tamb m designadas por servi os m todos ou processos Quando se organiza esta sec o por objecto deve ser usado o esbo o da Sec o A 4 Note que conjuntos de objectos podem partilhar atributos e servi os Estes s o agrupados em classes 5 3 7 4 Caracter stica Uma caracter stica um servi o do sistema desejado externamente que pode necessitar de uma sequ ncia de entradas para efectuar o resultado desejado Por exemplo num sistema telef nico as caracter sticas incluem a chamada local o reencaminhamento da chamada e a chamada de confer ncia Cada caracter stica descrita geralmente numa sequ ncia de pares de resposta est mulo Ao organizar esta sec o por caracter stica deve ser usado o esbo o da Sec o A 5 5 3 7 5 Est mulos Alguns sistemas podem ser melhor organizados descrevendo as suas fun es em termos de est mulos Por exemplo um sistema de aterragem autom tico pode ser organizado em sec es por perda de energia mudan a repentina de rolamento velocidade vertical excessiva etc Ao organizar esta sec o por est mulo deve ser usado o esbo o da Sec o A 6 5 3 7 6 Resposta Alguns sistemas podem ser melhor organizados descrevendo todas as fun es que sustentam a gera o de uma resposta Por exemplo as fun es de um sistema de pessoal po
46. produto O produto um documento de EES Estas recomenda es pr ticas podem ser usadas para criar um documento de EES ou podem ser usadas como modelo para um standard mais espec fico Esta recomenda o pr tica n o identifica nenhum m todo nomenclatura ou ferramenta espec fica para a prepara o de um documento de EES Notas 1 Nota de Tradu o Neste documento a palavra requirement foi traduzida por exig ncia transmitindo o car cter de obrigatoriedade que a palavra assume na l ngua inglesa e libertando se de qualquer ambiguidade que a palavra requisito comummente usada em portugu s pudesse adquirir neste documento 2 Nota de Tradu o Neste documento Software Requirements Specification foi traduzido por Especifica es de Exig ncias de Software e consequentemente a sigla SRS foi traduzida por EES Assim a sigla EES ir ser usada ao longo deste documento Cap tulo 2 Refer ncias Este documento deve ser usado em conjunto com as seguintes publica es ASTM E1340 96 Standard Guide for Rapid Prototyping of Computerized Systems IEEE Std 610 12 1990 IEEE Standard Glossary of Software Engineering Terminology IEEE Std 730 1998 IEEE Standard for Software Quality Assurance Plans IEEE Std 730 1 1995 IEEE Guide for Software Quality Assurance Planning IEEE Std 828 1998 IEEE Standard for Software Configuration Management Plans IEEE Std 982 1 1988 IEEE Standard Dictionary of Measures to
47. rarquia funcional 30 A 8 Modelo de Sec o 3 do EES mostrando multiplas eee 31 B Modelo de EES ccereeernecernererneresecreseeneseenesesneses neces nes E N ses ne se E A cerne eras cs nen asc cn ana 33 Bl Vista geral itasssa srs si E ab ita asso Pos ia La pan UICaR DRE E dada baia onda SR TRR LADA SEO TEE 33 B 2 Correla o sisitasas sis sora oeei oriee E E SUS EEE E oa Rca fadada E EEE diana eliana do asia tea ds 33 B 3 Mapeamento de conte do s msssessiaerseseme aaen sena Da pede Stan aE EE ria tania E Serer i atadas 34 B 4 Conclus o nno siso KE E EE E eso as lion E GOL E Gp bLs Slap demo Guaianases E ratio Tanto s 38 iii Lista de Tabelas 5 1 Prot tipo da estrutura de um documento de EES e erereeeeeeeaeeae ent eeeenerraaraannada 14 B 1 Resumo das exig ncias para um SRD Retirado da Tabela 1 da norma IEEE EIA 12207 1 1997 34 B 2 Cobertura de exig ncias gen ricas da descri o da norma IEEE Std 830 1998 35 B 3 Cobertura de exig ncias espec ficas da descri o da norma IEEE Std 830 1998 36 10 4 1 Exemplo de uma exig ncia verific vel rr ereee erre eearareenace encarna ana ne encara aeee cen ncara nana nnenn Cap tulo 1 Objectivo Este documento descreve as abordagens recomendadas para a especifica o de requisitos de software daqui para a frente referi
48. ri es 2 5 Assun es e depend ncias 3 Exig ncias espec ficas Ver da Sec o 5 3 1 at Sec o 5 3 8 para explica es acerca das exig ncias espec ficas Nos ap ndices ver tamb m o Ap ndice A onde se encontram diferentes formas de organizar esta sec o do documento de exig ncias 4 Ap ndices 5 Indice remissivo 5 1 Introdu o Sec o 1 do documento de EES A introdu o do documento de EES deve providenciar uma vis o geral sobre o documento inteiro Deve por isso 14 Cap tulo 5 As partes de um documento de EES conter as seguintes sub sec es a Prop sito b mbito c Defini es acr nimos e abreviaturas d Refer ncias e Organiza o 5 1 1 Prop sito Sec o 1 1 do documento de EES Esta sec o deve a Delinear o prop sito do documento de EES b Especificar a audi ncia alvo do documento de EES 5 1 2 mbito Sec o 1 2 do documento de EES Esta sec o deve a Identificar o produto de software a desenvolver pelo seu nome b Explicar o que o produto ir fazer e se necess rio o que n o ir fazer c Descrever a aplica o do software incluindo benef cios relevantes e objectivos d Ser consistente com outros documentos similares ou de mais alto n vel por exemplo a especifica o das exig ncias do sistema caso existam 5 1 3 Defini es acr nimos e abreviaturas Sec o 1 3 do documento de EES Esta sub sec o deve fo
49. rnecer as defini es de todos os termos acr nimos e abreviaturas necess rios interpreta o do documento de EES Esta informa o pode ser fornecida por refer ncia a um ou mais ap ndices do documento de EES ou por refer ncia a outros documentos 5 1 4 Refer ncias Sec o 1 4 do documento de EES Esta sec o deve a Fornecer uma lista completa de todos os outros documentos referenciados pelo documento de EES b Identificar cada documento pelo seu t tulo n mero de relat rio quando aplic vel data e organiza o que o publica c Especificar as fontes de onde as refer ncias podem ser obtidas Esta informa o pode ser fornecida por refer ncia a um ap ndice ou a outro documento 15 Cap tulo 5 As partes de um documento de EES 5 1 5 Organiza o Sec o 1 5 do documento de EES Esta sec o deve a Descrever o conte do do documento de EES b Explicar a organiza o do documento de EES 5 2 Descri o geral Sec o 2 do documento de EES Esta sec o do documento de EES deve descrever os factores gerais que afectam o produto e as suas exig ncias Esta sec o n o enumera exig ncias espec ficas Ao inv s fornece um contexto para essas exig ncias que s o definidas em detalhe na Sec o 3 do documento de EES e facilita a sua compreens o ver a Sec o 5 3 Esta sec o consiste habitualmente em 6 sub sec es a Perspectiva do produto b Fun es do produto c
50. rt ncia e ou estabilidade se cada exig ncia nele contido tem associada um identificador de estabilidade e ou import ncia Tipicamente as exig ncias de um produto de software n o s o da mesma import ncia Algumas exig ncias podem ser essenciais especialmente para aplica es cr ticas enquanto que outras podem ser apenas desej veis Cada exig ncia de um documento de EES deve conter identifica es que tornem estas diferen as claras e expl citas Esta identifica o ajuda a a Fazer com que os clientes olhem para cada exig ncia com maior aten o Como resultado algumas assun es escondidas que o possa fazer s o clarificadas b Fazer com que as equipas de desenvolvimento possam tomar decis es de desenho mais correctas e empregar n veis de esfor o distintos nas diferentes partes do projecto 4 3 5 1 Grau de estabilidade Um m todo para classifica o das exig ncias utiliza a dimens o da estabilidade A estabilidade pode ser expressa em termos do n mero de modifica es esperadas a uma exig ncia baseado na experi ncia ou em conhecimento de eventos futuros que afectem a organiza o as fun es ou as pessoas apoiadas pelo software 4 3 5 2 Grau de necessidade Uma outra forma de classificar as exig ncias consiste em distingui las como essenciais condicionais e opcionais a Essenciais Implicam que o software n o ser aceite a n o ser que essas exig ncias sejam implementadas da forma acordada b
51. s e Exig ncias de qualifica o As exig ncias a serem usadas para testar a qualifica o devem ser fornecidas ou referenciadas f Especifica es de seguran a Sec o 5 2 4 Restri es g Especifica es da seguran a e da privacidade Sec o 5 3 6 3 Seguran a h Factores humanos que projectam exig ncias Sec o 5 2 3 Caracter sticas do utilizador Sec o 5 2 1 2 Interfaces com o utilizador i Defini o de dados e exig ncias da base de dados Sec o 5 3 4 Exig ncias l gicas da base de dados j Exig ncias de instala o e aceita o no local de opera o Sec o 5 2 1 8 Exig ncias de adapta o ao local Exig ncias de instala o e aceita o no local da opera o k Exig ncias de instala o e aceita o no local de manuten o Exig ncias de instala o e aceita o no local de manuten o 1 Exig ncias da documenta o do utilizador Exig ncias da documenta o do utilizador m Exig ncias das opera es e execu es por parte do utilizador Sec o 5 2 1 7 Opera es Exig ncias das execu es por parte do utilizador n Exig ncias da manuten o por parte do utilizador Sec o 5 3 6 4 Capacidade de manuten o o Caracter sticas da qualidade do software Sec o 5 3 6 Atributos do sistema de software p Restri es de desenho e implementa o Sec o 5 2 4 R
52. ta pr tica recomendada o cliente e o fornecedor podem ser membros de uma mesma organiza o 3 4 Utilizador A pessoa ou pessoas que v o operar ou interagir com o produto Os utilizadores e os clientes s o comummente as mesmas pessoas Cap tulo 4 Considera es para a produ o de um bom documento de EES Este ponto disponibiliza alguma informa o base que deve ser considerada aquando da escrita de um documento de EES Isto inclui o seguinte a Natureza do documento de EES b Ambiente do documento de EES c Caracter sticas de um bom documento de EES d Prepara o conjunta do documento de EES e Evolu o do documento de EES f Prototipagem g Incorpora o do desenho no documento de EES h Incorpora o das exig ncias do projecto no documento de EES 4 1 Natureza do documento de EES O documento de EES uma especifica o particular de um software produto programa ou conjunto de programas que executam certas fun es num ambiente espec fico O documento de EES pode ser escrito por um ou mais representantes do fornecedor um ou mais representantes do cliente ou por ambos A Sec o 4 2 recomenda ambos Quem escreve um documento de EES deve sempre ter em conta os seguintes pontos base e Funcionalidade O que deve fazer o software b Interfaces externas Como interage o software com as pessoas com o hardware do sistema com outro hardware e com outro software Performance Qual
53. td 1233 Edi o de 1998 est o aprovados mas ainda n o foram publicados No entanto as vers es preliminares est o dispon veis no IEEE As publica es est o previstas para o Outono de 1998 Contacte o IEEE Standards Department at 1 732 562 3800 para mais informa o 4 data desta publica o os standards IEEE Std 828 1998 IEEE Std 1012a 1998 IEEE Std 1016 1998 e IEEE Std 1233 Edi o de 1998 est o aprovados mas ainda n o foram publicados No entanto as vers es preliminares est o dispon veis no IEEE As publica es est o previstas para o Outono de 1998 Contacte o IEEE Standards Department at 1 732 562 3800 para mais informa o Cap tulo 2 Refer ncias data desta publica o os standards IEEE Std 828 1998 IEEE Std 1012a 1998 IEEE Std 1016 1998 e IEEE Std 1233 Edi o de 1998 est o aprovados mas ainda n o foram publicados No entanto as vers es preliminares est o dispon veis no IEEE As publica es est o previstas para o Outono de 1998 Contacte o IEEE Standards Department at 1 732 562 3800 para mais informa o At aprova o do IEEE P1058 pelo IEEE SA Standards Board este standard ir ser integrado com o IEEE Std 1058a 1998 e publicado como IEEE Std 1058 Edi o de 1998 esperada a sua aprova o a 8 de Dezembro de 1998 data de edi o deste standard o IEEE Std 1058a 1998 est aprovado mas ainda n o foi publicado A vers o preliminar deste est dispon vel atrav s
54. te a sua utilidade uma fun o da organiza o Por exemplo ao organizar por modo m quinas de estados finitas e tabelas de estados podem ser teis ao organizar por objecto an lise orientada a objectos por ser til ao organizar por caracter stica sequ ncias de resposta de est mulos podem ser teis e ao organizar por hierarquia funcional diagramas de fluxo de dados e dicion rios de dados podem ser teis Em todos os esbo os que v o da Sec o A 1 at Sec o A 8 as sec es chamadas Exig ncia funcional i podem ser descritas na l ngua natural em pseudoc digo numa linguagem de defini o do sistema ou em quatro sub sec es chamadas Introdu o Entradas Processamento e Sa das 5 4 Informa o de suporte A informa o de suporte torna o documento de EES mais simples de usar Ela inclui o seguinte 1 Tabela de conte dos 2 ndice remissivo 3 Ap ndices 5 4 1 Tabela de conte dos e ndice remissivo A tabela de conte dos e o ndice remissivo s o deveras importantes de devem seguir pr ticas de composi o gerais 5 4 2 Ap ndices Os ap ndices nem sempre s o considerados parte do documento de EES pr priamente dito e n o s o sempre necess rios Eles podem incluir 1 Uma amostra de formatos de entrada sa da descri es de estudos de an lise de custos ou resultados de question rios 25 Cap tulo 5 As partes de um documento de EES 2 Informa o de suporte ou de fundo
55. tuintes 3 2 3 2 3 2 30 Ap ndice A Modelos de EES 3 2 3 p Constru o p 3 2 3 p 1 Tipo de registo 3 2 3 p 2 Campos constituintes 3 2 4 Dicion rio dos dados 3 2 4 1 Elemento de dados 1 3 2 4 1 1 Nome 3 2 4 1 2 Representa o 3 2 4 1 3 Unidades Formato 3 2 4 1 4 Precis o Exactid o 3 2 4 1 5 Intervalo de valores 3 2 4 2 Elemento de dados 2 3 2 4 2 1 Nome 3 2 4 2 2 Representa o 3 2 4 2 3 Unidades Formato 3 2 4 2 4 Precis o Exactid o 3 2 4 2 5 Intervalo de valores 3 2 4 9 Elemento de dados q 3 2 4 9 1 Nome 3 2 4 9 2 Representa o 3 2 4 9 3 Unidades Formato 3 2 4 9 4 Precis o Exactid o 3 2 4 9 5 Intervalo de valores 3 3 Exig ncias de desempenho 3 4 Restri es de Desenho 3 5 Atributos do Sistema de Software 3 6 Outros Requisitos A 8 Modelo de Sec o 3 do EES mostrando multiplas 3 Exig ncias Espec ficas 3 1 Requisitos de Interface Externos 3 1 1 Interfaces de Utilizador 3 1 2 Interfaces de Hardware 3 1 3 Interfaces de Software 3 1 4 Interfaces de Comunica o 3 2 Exig ncias Funcionais 3 2 1 Classe de utilizador 1 3 2 1 1 Caracter stica 1 1 3 2 1 1 1 Introdu o Objectivo da caracter stica 3 2 1 1 2 Est mulo Sequ ncia de resposta 3 2 1 1 3 Exig ncias Funcionais Associadas 3 2 1 2 Caracter stica 1 2 3 2 1 2 1 Introdu o Objectivo da caracter stica 3 2 1 2 2 Est mulo Sequ ncia de resposta 3 2 1 2 3 Exig ncias Funcionais Associadas 3 2 1 m Caracter stica 1 m 3
56. u da divulga o acidental ou maliciosa As exig ncias espec ficas nesta rea podem incluir a necessidade de a Utilizar determinadas t cnicas de codifica o usando uma determinada cifra b Manter um hist rico ou registo de dados especifico c Atribuir determinadas fun es a m dulos diferentes d Restringir comunica es entre algumas reas do programa e Verificar a integridade de dados e vari veis cr ticas 5 3 6 4 Capacidade de manuten o Deve especificar os atributos do software que se relacionam com a facilidade de manuten o do mesmo Pode haver determinadas exig ncias para a modularidade rela es complexidade etc As exig ncias n o devem ser colocadas aqui apenas porque s o geralmente consideradas boas pr ticas de desenho 5 3 6 5 Portabilidade Deve especificar os atributos do software que se relacionam com a facilidade de mover o software para outras m quinas e ou sistemas operativos Pode incluir o seguinte a Percentagem de componentes com c digo dependente da m quina b Percentagem de c digo dependente da m quina c Usar uma linguagem provadamente portavel d Usar um compilador ou um subconjunto espec fico da linguagem e Usar um sistema operativo espec fico 5 3 7 Organiza o das exig ncias especificas As exig ncias detalhadas tendem a ser extensivas quando se trata de um sistema n o trivial Por esta raz o recomenda se uma considera o cuidadosa por forma a or
57. ue assegure a correc o O documento de EES deve ser comparado com outras especifica o aplic veis tais como as exig ncias de especifica es do sistema com outra documenta o do projecto e com outros standards aplic veis para garantir que est em concord ncia Alternativamente o cliente pode determinar se o documento de EES reflecte correctamente as suas necessidades actuais O rastreio facilita este procedimento e torna o menos permissivo a erros Ver a Sec o 4 3 8 Cap tulo 4 Considera es para a produ o de um bom documento de EES 4 3 2 N o amb guo Um documento de EES n o amb guo se e s se todas as exig ncias expressas nele t m apenas uma nica interpreta o Como m nimo isto requer que cada caracter stica do produto final seja descrita usando termos simples e nicos Nas situa es em que um termo ao ser utilizado em determinado contexto possa adquirir m ltiplos significados esse termo deve ser inclu do num gloss rio onde o seu significado tornado mais espec fico Um documento de EES uma parte importante do processo de exig ncias do ciclo de vida do software sendo tamb m utilizado nas fases de desenho implementa o monitoriza o do projecto verifica o e valida o e na fase de treino tal como descrito no standard IEEE std 1074 1997 O documento de EES n o pode conter ambiguidades quer para quem o cria quer para quem o utiliza No entanto frequentemente estes dois grupos de
58. usa o termo descri o em vez de especifica o para descrever as exig ncias do software Num sistema em que o software um componente cada componente requer a sua pr pria especifica o haveria uma especifica o de exig ncias do sistema documento de EES e um ou mais SRDs Se o termo especifica o de exig ncias do software fosse usado haveria confus o entre um documento de EES que se refere a um sistema ou a um componente No caso onde h um sistema de software aut nomo a norma IEEE EIA 12207 1 1997 indica se o software for um sistema aut nomo ent o este documento deve ser uma especifica o B 3 Mapeamento de conte do Esta cl usula fornece os detalhes que indicam uma reivindica o de que um documento de EES que obedece a esta pr tica recomendada atinja tamb m concord ncia com o documento SRD descrito na norma IEEE EIA 12207 1 1997 As exig ncias para concord ncia com o documento s o resumidas numa nica linha da Tabela 1 da norma IEEE EIA 12207 1 1997 Essa linha reproduzida na tabela B 1 Tabela B 1 Resumo das exig ncias para um SRD Retirado da Tabela 1 da norma IEEE EIA 12207 1 1997 Artigo da Cl usula Tipo Cl usula Refer ncias Informa o IEEE EIA IEEE EIA 12207 0 1996 12207 1 1997 Descri o Das 5 1 1 4 Descri o Veja 6 22 IEEE Std 830 1998 Exig ncias Do 5 3 4 1 5 3 4 2 nota 6 22 1 da EIA IEEEJ STD 016 F 2 3 F 2 4 Software norma IEEE EIA MIL STD 961D V
59. veis Se n o poss vel descrever um processo para determinar se o software implementa uma exig ncia ent o essa exig ncia deve ser removida ou revista 4 3 7 Modific vel Um documento de EES diz se modific vel se e s se a sua estrutura e estilo s o tais que mudan as a exig ncias podem ser efectuadas de forma f cil completa e consistente preservando simultaneamente estrutura e estilo Para ser modific vel um documento de EES geralmente requer as seguintes caracter sticas a Uma estrutura coerente uma organiza o que o torne de f cil utiliza o com um ndice tabela de conte dos um ndice remissivo e refer ncias cruzadas b N o contenha redund ncias isto a mesma exig ncia n o deve estar definida em mais do que um local do documento c Expresse cada exig ncia de forma separada A defini o de uma exig ncia n o deve estar misturada ou dispersa em outras exig ncias A redund ncia em si mesma n o um erro mas leva ocorr ncia de erros A redund ncia pode ocasionalmente ajudar a tornar um documento de EES mais leg vel mas o problema surge quando o documento actualizado Por exemplo uma exig ncia pode ser alterada em apenas um dos locais onde aparece O documento de EES fica ent o inconsistente Quando a redund ncia for mesmo necess ria devem utilizar se refer ncias cruzadas para tornar o documento modific vel 4 3 8 Rastre vel Um documento de EES diz se rastre vel se ca

TX-EngSoft-01-Requisitos-IEEE830

Contents

Download Pdf Manuals

Related Search

Related Contents