Requisitos Como Definir

Especificação de
Requisitos de Software
Sumário da Lição
Provas públicas de avaliação da competência

pedagógica e técnico-científica
Fernando Paulo dos Santos Rodrigues Belfo

Instituto Superior de Contabilidade e Administração de Coimbra
Instituto Politécnico de Coimbra
Portugal
22 de Outubro, 2012
Índice
Índice ........................................................................................................................ i
Índice de Figuras ..................................................................................................... iii
Índice de Tabelas ..................................................................................................... iv
Preâmbulo ............................................................................................................... v
I. Introdução......................................................................................................... 1
A. As causas nas falhas dos projetos de tecnologias de informação ................................. 1
B. A complexidade da gestão dos requisitos ..................................................................... 2
C. Da noção de requisitos à especificação de requisitos de software ............................... 3
II. Fundamentos sobre requisitos de software........................................................ 7
A. Requisitos de sistema versus requisitos de software .................................................... 7
B. Requisitos de negócio, de utilizador e de software ....................................................... 7
C. Dos requisitos de negócio aos requisitos de software .................................................. 9
1. A elaboração dos requisitos de negócio .............................................................. 10
2. Dos requisitos de negócio aos requisitos de utilizador........................................ 16
D. Os intervenientes no processo de especificação de requisitos ................................... 17
E. A elicitação de requisitos ............................................................................................. 20
F. Análise de Requisitos ................................................................................................... 21
III. Elaboração do documento de especificação de requisitos de software ............. 23
A. Alguns princípios na elaboração dum documento de SRS .......................................... 23
1. O que o SRS deverá ser ou não ser ...................................................................... 24
2. Componentes da especificação de requisitos de software ................................. 24
B. Um modelo de SRS....................................................................................................... 25
1. Introdução ............................................................................................................ 25
2. Descrição geral ..................................................................................................... 27
3. Características do sistema.................................................................................... 32
4. Requisitos de interface externo ........................................................................... 36
5. Requisitos não funcionais .................................................................................... 37
6. Outros tipos de requisitos .................................................................................... 43
7. Apêndices ............................................................................................................. 43
Especificação de Requisitos de Software
C. Outros aspetos relacionados com a especificação de requisitos ................................ 44

1. A organização dos requisitos ............................................................................... 44
2. Qualidades dos requisitos de software ................................................................ 45
3. Boas práticas e dicas para escrever bons requisitos ............................................ 47
4. Qualidades do documento SRS ............................................................................ 51
5. A priorização dos requisitos de software............................................................. 52
6. A dimensão humana, organizacional e tecnológica da especificação
de requisitos de software .................................................................................... 55
IV. Para além da especificação de requisitos ......................................................... 58
A. A traçabilidade dos requisitos ..................................................................................... 58
B. Validação dos requisitos .............................................................................................. 60
C. Pedido de proposta de fornecimento (RFP) ................................................................ 61
D. Ferramentas de gestão de requisitos .......................................................................... 64
V. Referências...................................................................................................... 65
Anexo 1: Lista de acrónimos e siglas .................................................................. 68
Anexo 2: Glossário ............................................................................................ 69
Anexo 3: Métodos de ensino planeados ............................................................ 70
Anexo 4: Projeto Prático.................................................................................... 72
ii
Índice de Figuras
Figura 1. Resolução de projetos em 2000 e 2008 (Standish Group, 2009)................................ 1
Figura 2. O ciclo de desenvolvimento da arquitetura empresarial (The Open Group, 2009).... 2
Figura 3. Alguns aspetos a considerar numa política de gestão de requisitos. ......................... 3
Figura 4. Sete subáreas relativas aos requisitos de software. Adaptado de Abran et al.
(2004). ......................................................................................................................... 4
Figura 5. Processo iterativo no desenvolvimento de requisitos. Adaptado de Wiegers
(2009). ......................................................................................................................... 5
Figura 6. A pirâmide de requisitos. Adaptado de Leffingwell and Widrig (2003). ..................... 8
Figura 7. Os três níveis de requisitos: requisitos de negócio, de utilizador e de software........ 8
Figura 8. Etapas na especificação dos requisitos do software. Adaptado de Wiegers
(2000). ....................................................................................................................... 10
Figura 9. Possível modelo do documento "Visão e Âmbito do Sistema" (Wiegers, 2009). ..... 11
Figura 10. Estratégia do produto SAP para Utilities (Guerra et al., 2006). ................................ 13
Figura 11. Estratégia das versões SAP com pacotes melhorados . Adaptado de Tobola
(2009). ....................................................................................................................... 14
Figura 12. Diagrama parcial de caso de uso relativo ao SRQ (Wiegers, 2009). ......................... 17
Figura 13. Contexto do desenvolvimento de um SyRS (IEEE, 1998b). ....................................... 18
Figura 14. Partes interessadas num processo de gestão dos requisitos de software ............... 18
Figura 15. Utilizadores e o documento de requisitos. Adaptado de Sommerville (2007). ........ 19
Figura 16: Categorias de métodos de análise de requisitos ...................................................... 21
Figura 17. Possível modelo do documento "Especificação de Requisitos de Software". .......... 25
Figura 18. Árvore genealógica do sistema operativo Microsoft Windows (Wikipedia, 2012). . 27
Figura 19. Diagrama de contexto do sistema MEDIGest. Adaptado de Ferreira et al. (2005)... 28
Figura 20. Diagrama de 1º nível do sistema MEDIGest. Adaptado de Ferreira et al. (2005)..... 29
Figura 21. Diagrama de 2º nível do grupo funcional 4 - Gestão de Utentes do sistema
MEDIGest. Adaptado de Ferreira et al. (2005). ......................................................... 34
Figura 22. Ícones da interface de utilizador do Windows XP..................................................... 36
Figura 23. As dimensões Pessoas, Organização e Tecnologia e as suas relações. Adaptado
do modelo da tecnologia (Orlikowski, 1992). ........................................................... 56
Figura 24. Quatro tipos de traçabilidade de requisitos. Adaptado de Wiegers (2009). ............ 58
Figura 25. Exemplo de modelo de pedido de proposta de cotação (TEC, 2012). ...................... 62
iii
Índice de Tabelas
Tabela 1. Exemplos de objetivos de negócio. Adaptado de Wiegers (2009)............................ 11

Tabela 2. Exemplo de prioridades dum projeto. Adaptado de Leffingwell e Widrig (2003). ... 16
Tabela 3. Técnicas e abordagens para atividades de elicitação (Zowghi and Coulin, 2005). ... 21
Tabela 4. Relacionando a voz do cliente com componentes de modelação da análise. .......... 22
Tabela 5. Atributos de qualidade do software. Adaptado de Wiegers (2009). ........................ 40
Tabela 6. Lista de potenciais problemas dos requisitos a controlar......................................... 49
Tabela 7. Exemplo de conferência da qualidade numa amostra de requisitos de software. .. 51
Tabela 8. Sumário de técnicas na priorização. Adaptado de Berander and Andrews (2005). . 55
Tabela 9. Questões nas dimensões pessoas, organização e tecnologia quanto à precisão
(Belfo, 2012). ............................................................................................................. 56
Tabela 10. Graus de disponibilidade do fornecedor na entrega dum requisito (TEC, 2012). .... 63
iv
Preâmbulo
Este documento escrito é o suporte à lição a apresentar pelo seu autor, no âmbito das
suas provas públicas para professor adjunto no Instituto Superior de Contabilidade e
Administração de Coimbra, unidade orgânica do Instituto Politécnico de Coimbra,
conforme previsto na Lei nº 7/2010 de 13 de Maio e regulado por Despacho nº
4476/2011, Diário da República, 2ª Série, nº 50, de 11 de Março e ainda pelo respetivo
Regulamento de Provas Públicas do Instituto Politécnico de Coimbra aprovado em 1
de Março de 2011.
O docente tem desempenhado funções letivas no Instituto Superior de Contabilidade e

Administração de Coimbra há aproximadamente 20 anos nas áreas da Informática. No
últimos anos tem lecionado e sido responsável por unidades curriculares na área dos
sistemas de informação da licenciatura em Informática de Gestão deste Instituto. Uma
das unidades curriculares que tem lecionado com frequência nos últimos anos é a
unidade curricular de Sistemas de Informação II, estando, por esse motivo, a lição
escolhida associada a um dos objetivos curriculares desta unidade. Entre os principais
objetivos da unidade curricular de Sistemas de Informação II encontra-se a aquisição
de competências pelo aluno relativas à especificação de requisitos de software. É esse
o tema escolhido para esta lição.
Como será melhor explicado nesta lição, a especificação de requisitos de software,

encontra-se muito relacionada com as fases de elicitação, análise e validação de
requisitos. Embora estas três fases da gestão dos requisitos estejam levemente
apresentadas nesta lição, estas não fazem parte do seu objetivo de aprendizagem.
Assim, existe o pressuposto de que os alunos que assistirão a esta lição detenham um
conjunto de conhecimentos prévio. De entre os conhecimentos preliminares desejáveis
para uma melhor compreensão desta lição, destacam-se os seguintes:
Nomeadamente o conceito de sistema, as caraterísticas

Conceitos básicos sobre básicas de um sistema, a automação de um sistema, o
sistemas de informação conceito de sistema de informação, os tipos de sistemas
de informação e a sua evolução.
Nomeadamente algumas competências relativas às

principais técnicas de elicitação de requisitos, tais como
entrevistas, sessões de reflexão (brainstorming) sessões
Elicitação de requisitos "problema- resolução", inquéritos / questionários,
observação de padrões de trabalho, revisão da
documentação técnica, prototipagem ou processos e
sistemas de avaliação comparativa (benchmarking).
Nomeadamente algumas competências relativas à

análise de sistemas de informação, nomeadamente
Análise de sistemas de
técnicas de modelação com diagramas de fluxos de
informação
dados, casos de uso e as mais usuais técnicas de
modelação com UML.
v
O documento começa por apresentar uma introdução ao tema e á sua pertinência,

nomeadamente as usuais causas nas falhas dos projetos de tecnologias de
informação, a complexidade da gestão dos requisitos e um breve percurso que vai da
noção de requisitos à especificação de requisitos de software .
Em seguida, apresenta um capítulo com os fundamentos sobre requisitos de software,

onde abordará tópicos como os requisitos de sistema versus os requisitos de software,
ou o percurso a percorrer desde os requisitos de negócio, passando pelos requisitos
de utilizador até aos requisitos de software. Este capítulo abordará ainda os
intervenientes no processo de especificação de requisitos, a elicitação e a análise de
requisitos.
O terceiro capítulo mostra propriamente aspetos práticos associados à elaboração do

documento de especificação de requisitos de software. Evidencia alguns princípios na
elaboração desse documento e propõe um modelo para essa especificação. Alguns
outros aspetos relacionados com a especificação de requisitos são ainda referidos,
tais como questões associadas à organização dos requisitos, à qualidade dos
requisitos de software, às boas práticas e dicas para escrever bons requisitos, às
qualidades que um documento SRS deve ter, à priorização dos requisitos de software.
Uma perspetiva multidimensional, composta pela dimensão humana, organizacional e
tecnológica é ainda proposta como complemento à análise e à especificação de
requisitos de software.
O último capítulo deste documento escrito apresenta questões para além da

especificação de requisitos propriamente dita, nomeadamente a traçabilidade dos
requisitos, a validação dos requisitos, a utilização dos requisitos de software em
pedidos de proposta de fornecimento (RFP) e as ferramentas de gestão de requisitos.
No final do documento encontram-se ainda as referências usadas e alguns anexos,

designadamente, uma lista de acrónimos e siglas, um glossário, a metodologia de
ensino planeada e um projeto prático proposto que consiste na especificação de um
documento de requisitos de software relativo ao desenvolvimento de um sistema de
informação para uma determinada organização que atua numa determinada área de
atividade e que, de acordo com a metodologia de ensino proposta, pretende ser uma
forma de aprendizagem complementar às aulas.
Fernando Paulo Belfo
Coimbra, Outubro de 2012
vi
I. Introdução
A. As causas nas falhas dos projetos de tecnologias de informação
Os relatórios Chaos do Standish Group (The Standish Group, 1995, Standish Group, 2009)
demonstram claramente que as coisas não têm mudado significativamente no que se refere ao
sucesso de projetos de Tecnologia
ecnologias da Informação (TI). Apesar da diversidade de livros,
formação, consultoria e ferramentas que apontam caminhos para uma melhor prática, a
maioria dos projetos ainda falha. Segundo o inquérito de 2009 do Standish Group,
Group em 2008
cerca de um terço dos projetos de tecnologia da informação tiveram sucesso, cerca de um
quarto são cancelados antes da sua conclusão e os restantes 44 por cento têm problemas
significativos, designadamente
ente um atraso sério, orçamento ultrapassado ou redução de
características
as ou funcionalidades previstas (ver a Figura 1). Segundo
egundo os inquéritos do Chaos, a
evolução de 2000 para 2008 evidencia uma ligeira melhoria da percentagem de projetos bem
sucedidos, aumentando essa proporção de 28% % para 32%. Em contrapartida, os projetos
colocados de alguma forma em causa reduziram ligeiramente de 49% para 44%. 44
Figura 1. Resolução de projetos em 2000 e 2008 (Standish Group, 2009)
Segundo este relatório, um dos problemas usuais com os projetos de TI está relacionado com
os requisitos de software, destacando que apenas parte dos requisitos especificados são
implementados.
dos. Relativamente ao ano de 2008, o inquérito Chaos revelou que apenas 67%
dos requisitos especificados eram efetivamente desenvolvidos. É também realçado
realça que se
deve ter cuidado na análise deste número, já que outros estudos do Standish Group revelaram
que
ue apenas 20% das características e funcionalidades do software são usadas. O Chaos
apresenta um conjunto de dez leis, sendo uma delas a "lei do monstro de cauda longa", que
afirma que existe uma tendência em, por um lado, se construir demasiado do que não se
precisa e, por outro, pouco do que se precisa (The Standish Group, 1995, Standish Group,
2009). Na realidade, esta é uma das causas mais importantes que explicam
explicam o insucesso no
desenvolvimento de significativo número de projetos de TI.
Estes relatórios apresentam ainda oss três fatores mais apontados para colocar em causa os
projetos, nomeadamente a falta de contribuição dos utilizadores com 12,8% das respostas, a
especificação ou requisitos incompletos com 12,3% e a alteração da especificação ou de
requisitos com 11,8% dos respondentes (The Standish Group, 1995). Mais, o facto do software
não satisfazer os requisitos pretendidos
preten é apontado como um dos motivos principais para
considerar um projeto falhado ou com problemas. Por estas razões, uma boa gestão de
requisitos de software é muito importante e poderá representar a diferença essencial entre o
falhanço de um projeto ou o seu sucesso.
B. A complexidade da gestão dos requisitos
A gestão de requisitos pode ser definida como "o conjunto de disciplinas e atividades
relacionadas com a captura, formulação, organização, controle das versões, edição,
rastreamento, análise e mudança de requisitos" (IBM, 2009).
O processo de gestão de requisitos está preocupado em saber como as atividades de

elicitação, análise, especificação e validação de requisitos se configuram nos diferentes tipos
de projetos e restrições (Abran et al., 2004).
A gestão de requisitos tem como princípio não ser apenas um processo inicial no ciclo de vida
do projeto de software. Ele acontece no início do projeto, mas continua a ser refinado ao
longo do desenvolvimento do mesmo. A gestão dos requisitos baseia-se na necessidade de
adaptar os requisitos à organização e ao projeto.
A
Visão da
Arquitetura
H
B
Gestão da
Arquitetura de
Mudança
Negócio
Arquitetural
C
G
Governação da
Gestão de Arquiteturas de
Sistemas de
Implementação requisitos Informação
F D
Plano de Arquitetura
Migração Tecnológica
E
Oportunidades
e Soluções
Figura 2. O ciclo de desenvolvimento da arquitetura empresarial (The Open Group, 2009).
Algumas das principais referências de enquadramento na área do governo das tecnologias de

informação, como o TOGAF (The Open Group Architecture Framework), centram precisamente
o desenvolvimento duma arquitetura empresarial na gestão dos requisitos (The Open Group,
2009). A Figura 2 apresenta o ciclo de desenvolvimento da arquitetura empresarial proposto
pelo referencial TOGAF.
2
A gestão de requisitos é obviamente importante e também complexa. Exige da parte da

organização opções e linhas orientadoras. É de todo conveniente que se especifique uma
política de gestão de requisitos que deverá incluir os princípios e orientações estratégicas
respeitantes aos principais aspetos a ter em atenção na gestão de requisitos.
Figura 3. Alguns aspetos a considerar numa política de gestão de requisitos.
A Figura 3 representa a complexidade que a definição duma política de gestão de requisitos

pode ter, traçando alguns dos principais aspetos a incluir nessa definição, nomeadamente, o
envolvimento das partes interessadas, a rastreabilidade, a verificação e validação, a
documentação, a análise, a (re)definição da base de dados, o grau de parametrização e
configuração a aprovação ou alteração dos requisitos, os custos de manutenção e de
desenvolvimento, o tempo de desenvolvimento, a gestão do risco ou a definição de
prioridades.
C. Da noção de requisitos à especificação de requisitos de software
Existem diversas definições de requisito. Um requisito pode ser visto como uma "asserção que
tem de ser satisfeita por um produto ou processo" (IBM, 2009), ou pode, por exemplo,
igualmente ser definido como uma propriedade que tem de existir para que um determinado
problema do mundo real possa ser resolvido (Abran et al., 2004). Consequentemente, os
requisitos de software expressam as necessidades e restrições colocadas sobre um produto de
software que contribuem para a solução de alguns problemas do mundo real (Kotonya and
Sommerville). A área de conhecimento dos requisitos de software preocupa-se sobretudo com
as atividades de elicitação, análise, especificação e validação de requisitos de software
(Wiegers, 2009). É amplamente reconhecido na indústria de software que os projetos de
software são extremamente vulneráveis quando estas atividades são mal executadas.
Segundo Abran et al. (2004), a "especificação de requisitos de software" refere-se tipicamente

à produção de um documento, ou o seu equivalente eletrónico, que compile os requisitos de
3
software e que possa ser sistematicamente revisto, avaliado e aprovado (Abran et al., 2004). A
importância desta temática justificou mesmo o aparecimento dum ramo da engenharia
designado por engenharia de requisitos de sistemas de software. A utilidade deste ramo do
conhecimento prende-se, em primeiro lugar, com a necessidade de medir o sucesso dum
software, ou seja, o grau com que ele suporta o objetivo para o qual foi desenvolvido
(Nuseibeh and Easterbrook, 2000). De uma forma geral, a engenharia de requisitos de sistemas
de software (ER) é o processo de descoberta do propósito do sistema, através da identificação
das partes interessadas e das suas necessidades, documentando-as de uma forma que seja
consentânea à sua análise, comunicação e implementação.
Fundamentos
dos requisitos
Questões Processo dos

práticas requisitos
Requisitos
de
Validação
dos Software Elicitação de
requisitos
requisitos
Especificação
Análise de
dos
requisitos
requisitos
Figura 4. Sete subáreas relativas aos requisitos de software. Adaptado de Abran et al. (2004).
A área de conhecimento relativa aos requisitos de software pode dividir-se em sete subáreas
(ver Figura 4). A primeira subárea considera os fundamentos dos requisitos de software,
incluindo a própria definição de requisito de software, e também a definição dos principais
tipos de requisitos, como requisito de produto versus requisito de processo, requisito
funcional versus não funcional ou ainda propriedades emergentes. A segunda subárea
considera os processos de requisitos de software, enquadrando as cinco subáreas restantes.
Descreve ainda os modelos para processos, os atores dos processos, o suporte e a gestão dos
processos, a qualidade dos processos e a sua melhoria. A elicitação de requisitos é a terceira
subárea e preocupa-se com a proveniência dos requisitos e a sua forma de recolha junto das
partes interessadas no produto (stakeholders). A análise de requisitos é a quarta subárea,
estando interessada com o processo de análise para detetar e resolver conflitos entre os
requisitos, para descobrir os limites do software e para entender como o software deve
interagir com o seu meio ambiente e por fim, como elaborar os requisitos de software a partir
4
dos requisitos de sistema. Esta subárea também inclui a classificação dos requisitos, a sua
modelação conceptual, o desenho da arquitetura, a alocação e a negociação de requisitos. A
quinta subárea denomina-se especificação de requisitos. Esta subárea normalmente refere-se
à produção de um documento (normalmente também com uma versão eletrónica), que pode
ser sistematicamente revisto, avaliado e aprovado. Em sistemas complexos, sistemas que
muitas vezes envolvem importantes componentes que não são software, três diferentes tipos
de documento são produzidos: um documento de definição do sistema, outro de especificação
de requisitos do sistema e ainda um outro com a especificação dos requisitos de software. A
sexta subárea trata da validação dos requisitos e o seu principal objetivo é a recolha de
eventuais problemas antes de existir uma afetação de recursos à implementação dos
requisitos. Esta subárea preocupa-se com o estudo de cada requisito no sentido de garantir
que este está a servir o sistema pretendido. A sétima e última subárea consiste em
considerações práticas e descreve questões que têm de ser entendidas na prática, tais como, a
natureza iterativa dos processos de requisitos, a gestão da mudança ou a gestão dos requisitos
(Abran et al., 2004).
Esta lição expõe sobretudo o conhecimento relativo à especificação de requisitos, embora se

reconheça a existência de relações importantes com todas as outras subáreas de
conhecimento apresentadas, em especial com as duas subáreas que a precedem (a elicitação e
a análise de requisitos) e a que a sucede (a validação dos requisitos). Este caráter não linear,
inerente ao processo de desenvolvimento dos requisitos que conjuga as atividades de
elicitação, de análise, de especificação e de validação dos requisitos está patente na Figura 5.
Figura 5. Processo iterativo no desenvolvimento de requisitos. Adaptado de Wiegers (2009).
Esta lição inclui breves secções relativas às atividades de elicitação, de análise e de validação
dos requisitos, justificadas na complementaridade existente entre elas e a atividade de
especificação de requisitos, apenas com o objetivo de a melhor enquadrar.
Relativamente à especificação de requisitos, Abran et al. (2004) propõem ainda uma divisão
em três subtópicos. O primeiro aborda a questão associada à elaboração do documento de
definição de sistema. O segundo deverá preocupar-se com a especificação dos requisitos de
sistema e o terceiro e último com a especificação dos requisitos de software. Ainda, de acordo
com a norma internacional ISO/IEC 12207, o software é tratado como uma parte integral do
sistema completo e desempenha algumas das funções nesse sistema. Do ponto de vista da
especificação de requisitos, os requisitos de software são extraídos dos requisitos de sistema,
sendo que, posteriormente à produção do software, este deverá ser integrado nesse mesmo
5
sistema. Em rigor, um produto ou serviço de software é sempre considerado um item do

sistema, mesmo que o sistema consista apenas num processador e no software que nele será
executado (ISO and IEC, 2008).
Esta lição, embora se centre particularmente nos aspetos associados à especificação dos
requisitos de software, não pretende esgotar-se nisso. Como se referiu anteriormente, a
relação entre sistema e software é tão significativa que será difícil dissociá-los. Esta lição
procura interligar as prévias definições de sistema e da especificação dos requisitos de sistema
com a especificação de requisitos de software. Efetivamente, quando se está perante sistemas
complexos que envolvem consideráveis componentes de não-software, dever-se-ão produzir
os três tipos de documentos: definição de sistema, requisitos de sistema e requisitos de
software. No entanto, quando se está perante simples produtos de software, apenas os
requisitos de software são necessários (Abran et al., 2004).
A lição guiar-se-á especialmente pela abordagem de Wiegers (2009) e pela norma

internacional IEEE 830-1998. Esta norma descreve o conteúdo e as qualidades de uma boa
especificação de requisitos de software, usualmente conhecida pela sigla SRS (Software
Requirements Specification), apresentando vários exemplos de modelos deste documento.
Esta norma internacional visa a especificação de requisitos de software a desenvolver, mas
também pode ser aplicada para ajudar na seleção de produtos de software desenvolvidos
internamente na organização ou de propostas comerciais exteriores (IEEE, 1998a).
6
II. Fundamentos sobre requisitos de software

A. Requisitos de sistema versus requisitos de software
A especificação dos requisitos de software está intrinsecamente relacionada com a

especificação dos requisitos de sistema (SyRS) e, muitas vezes, até quase que se confundem.
Para entender a diferença entre ambas as especificações é fundamental perceber a importante

noção de que um sistema de informação pode ter várias componentes, não sendo
necessariamente todas apenas constituídas por software. Assim, muitas vezes justifica-se a
necessidade de se separar completamente a especificação das componentes de software das
da restante parte do sistema, resultando dessa separação dois documentos distintos. Outras
vezes, não será necessário a autonomização dos requisitos de sistema face aos requisitos de
software. No caso do software representar apenas uma parte do sistema, então deverá ser no
SRS que se especificarão as interfaces entre o sistema e a parte do software. Como é evidente,
nesse caso, o SRS resultará duma expansão dos requisitos do sistema (IEEE, 1998a).
A reputada associação internacional Institute of Electrical and Electronics Engineers (IEEE)

apresenta uma norma internacional para cada uma destas duas especificações. Enquanto que
a norma IEEE 1233 apresenta um guia para o desenvolvimento da especificação do conjunto
dos requisitos de sistema (IEEE, 1998b), a norma IEEE 830 apresenta um conjunto das
melhores práticas relativas à especificação dos requisitos de software (IEEE, 1998a).
B. Requisitos de negócio, de utilizador e de software
Os requisitos apenas são requisitos se estão formalmente escritos. É frequente a escrita dos
requisitos em três documentos distintos: as necessidades dos stakeholders, as caraterísticas do
sistema (ou do software) e a especificação dos requisitos do software (McEwen, 2004).
No sentido de tentar esclarecer alguma terminologia acerca da especificação das caraterísticas

pretendidas para um software, Dean Leffingwell propôs uma pirâmide de requisitos que
separa o domínio do problema face ao domínio da solução no que diz respeito à especificação
(ver a Figura 6). Nessa pirâmide, as caraterísticas pretendidas para um software são
estruturadas segundo uma pirâmide de requisitos com três níveis. Um nível de abstração mais
elevado representará as necessidades dos vários stakeholders do projeto. Trata-se de um
trabalho resultante do entendimento das necessidades dos utilizadores e dos outros
interessados no sistema. Este nível pretende especificar o domínio do problema. O segundo e
o terceiro nível representarão o nível da solução. O segundo nível apresentará o conjunto das
caraterísticas do sistema e corresponderá ao primeiro nível na proposta de solução para o
sistema, apresentando uma resposta direta aos problemas levantados no primeiro nível. O
terceiro nível, o nível mais baixo de especificação, corresponderá ao detalhe dessas mesmas
soluções, correspondendo a soluções ao nível dos implementadores, suficientemente
detalhados para a sua respetiva programação e testes (Leffingwell and Widrig, 2003,
Leffingwell, 2001).
7
Domínio
do
problema
necessidades
caraterísticas
do
sistema Domínio
da
solução
requisitos
de
software
Figura 6. A pirâmide de requisitos. Adaptado de Leffingwell and Widrig (2003).
A pirâmide anteriormente apresentada conduz-nos a uma outra pirâmide com três níveis de
requisitos, resultantes do processo de desenvolvimento de um projeto de software (Wiegers,
2000).
el
nív
ixo
ba
ais
em
sd
i to
ui s
req
Figura 7. Os três níveis de requisitos: requisitos de negócio, de utilizador e de software.
A Figura 7 pretende ilustrar estes três níveis de requisitos, as principais motivações para o seu
desenvolvimento e a sua relação. Em certa medida, poderíamos dizer que estes três níveis de
requisitos tentam responder a duas perguntas chave: "Porquê?" e "O que fazer?". No que diz
8
respeito ao que fazer, esta subdivide-se em duas questões, uma questão feita aos utilizadores
e outra, dependente da anterior, feita aos implementadores.
Mais concretamente, o primeiro nível apresenta os requisitos de mais alto nível, designados
por requisitos de negócio, pretendendo explorar e explanar as razões para as quais esse
determinado sistema pretende ser realizado. O segundo nível, associado ao primeiro,
apresenta os requisitos de utilizador que correspondem ao que os utilizadores vão poder fazer
com o produto (sistema). O terceiro e último nível corresponde propriamente aos requisitos de
software. Estes requisitos pretendem explicar o que os implementadores irão ter de construir.
Nesta pirâmide das caraterísticas a implementar no sistema, o primeiro nível pode ser visto
como o nível das necessidades da organização e o segundo e terceiro níveis como os níveis do
domínio da solução (Leffingwell and Widrig, 2003).
Devido à grande interligação e dependência entre estes três níveis de requisitos, diversas
metodologias propostas para a especificação de requisitos de software relevam, numa fase
anterior aos aspetos associados aos requisitos de software, os requisitos de negócio e os
requisitos de utilizador (Wiegers, 2009, IEEE, 1998a, Davis, 1993, Leffingwell and Widrig, 2003).
C. Dos requisitos de negócio aos requisitos de software
Existe um percurso que deve ser percorrido para a especificação dos requisitos de software.
Efetivamente, os requisitos de software não aparecem por si só, estando muito ligados e
dependentes dos requisitos de negócio e de utilizador. Em primeiro lugar, devem-se
considerar os requisitos do negócio, representando estes os objetivos de alto nível da
organização e que devem ser considerados num documento com a visão e o âmbito do
sistema. Em seguida, encontram-se os requisitos dos utilizadores e que correspondem à
descrição das tarefas que é suposto os utilizadores efetuarem com a utilização do novo
produto. Normalmente, estas histórias ou cenários modelam-se através da utilização de casos
de uso. A partir da elaboração destes casos de uso é possível derivar uma terceira e, última
etapa, onde se especificam os requisitos funcionais do software (Wiegers, 2000). A Figura 8
apresenta as etapas e os principais documentos produzidos aquando da especificação dos
requisitos do software.
Os requisitos de software são normalmente constituídos por requisitos funcionais e requisitos

não funcionais. Os requisitos funcionais de software pormenorizam os comportamentos
específicos que o software deverá ter. Os requisitos não funcionais incluem objetivos para os
atributos de qualidade, objetivos de desempenho, regras de negócio, restrições de desenho e
implementação e os requisitos de interfaces externos. Os atributos de qualidade, que podem
ser de diversos tipos, como por exemplo a usabilidade, a eficiência, a portabilidade ou a
facilidade de manutenção, devem derivar igualmente das necessidades manifestadas pelos
utilizadores, juntamente com os casos de uso.
9
Especificação Especificação dos Especificação

dos requisitos requisitos de dos requisitos
de negócio utilizador de software
Outros
Visão e Casos Requisitos
Requisitos Requisitos
Âmbito do de de
Funcionais Não
Sistema Uso Qualidade
Funcionais
Figura 8. Etapas na especificação dos requisitos do software. Adaptado de Wiegers (2000).
A principal vantagem de começar sempre pelos requisitos de negócio, passando pelos

requisitos de utilizador e por fim definindo os requisitos de software é o facto de assim se
garantir o alinhamento dos requisitos de software e utilizador com os requisitos de negócio
estabelecidos (Wiegers, 2009). Esta abordagem facilita a ligação dos três níveis de requisitos
entre si. Requisitos que não ajudem o projeto a atingir os objetivos de negócio deverão ser
excluídos.
1. A elaboração dos requisitos de negócio

O lançamento dum projeto de um novo ou renovado sistema de informação tem a esperança
de que de alguma forma esse produto permita "tornar o mundo um mundo melhor" (Wiegers,
2009). Os requisitos de negócio descrevem os principais benefícios que esse sistema possa
trazer aos patrocinadores, aos compradores ou aos utilizadores desse sistema. O documento
resultante desta fase deve enquadrar os requisitos de negócio com a visão da solução, o
âmbito e as limitações do projeto e ainda o contexto do negócio. Usualmente, designa-se este
documento por "Requisitos de Negócio" ou "Visão e Âmbito do Sistema".
a) Requisitos de negócio
Segundo Wiegers (2009), a especificação dos requisitos de negócio deve contemplar os
antecedentes da criação do novo produto, as oportunidades de negócio que lhe estão
subjacentes, os respetivos objetivos de negócio e os critérios de sucesso associados, as
necessidades de clientes ou as necessidades do mercado e os riscos de negócio (ver Figura 9).
Os antecedentes da criação do novo produto consistem na explicação das razões e no contexto

do novo sistema, devendo apresentar inclusive uma descrição geral da história ou da situação
que levou à decisão de avançar com o projeto.
Um outro aspeto a considerar no documento "Visão e Âmbito do Sistema" deverá contemplar

as oportunidades de negócio a explorar através deste produto. A perspetiva poderá variar em
função do tipo de produto a desenvolver. Por exemplo, no caso de se tratar dum software
comercial, será importante apresentar o mercado onde o produto operará. Aí, um
levantamento dos diversos produtos existentes no mercado poderá ser feito, de forma a
evidenciar as lacunas ou fragilidades existentes nesses produtos e consequentemente mostrar
as oportunidades de mercado. Já por exemplo, no caso dum sistema de informação
corporativo, será importante evidenciar o problema de negócio que se pretende resolver ou o
10
processo de negócio que se pretende melhorar. Neste caso, vários produtos e soluções devem
ser procurados, ilustrando-se num mapa uma avaliação comparativa estre as várias
possibilidades e evidenciando que a solução ou o produto proposto apresenta-se atrativo e
vantajoso face às outras possibilidades.
Figura 9. Possível modelo do documento "Visão e Âmbito do Sistema" (Wiegers, 2009).
Este documento deverá igualmente conter os objetivos de negócio, ligando-os a critérios de

sucesso mensuráveis e perfeitamente quantificados. Wiegers (2009) divide estes objetivos em
financeiros e não financeiros. A Tabela 1 apresenta alguns exemplos.
Objetivos Financeiros Objetivos Não Financeiros

• Atingir um volume de vendas de 10.000 • Atingir uma satisfação média dos clientes
unidades ou um volume de vendas de de 8.5 (num máximo de 10) em 24 meses
1.500.000,00 euros. • Ser classificado como o produto mais
• Aumentar a margem de lucro bruta de fiável na revista da especialidade na
50% para 60% primeira edição num prazo de 36 meses
• Reduzir os custos administrativos em 20% • cumprir com os regulamentos nacionais
nos próximos 18 meses relativos a esta área de negócio
Tabela 1. Exemplos de objetivos de negócio. Adaptado de Wiegers (2009).
As necessidades dos clientes ou do mercado deverão ser tidas em conta e, para isso, deverão
ser considerados os clientes típicos ou o segmento de mercado de destino. Deverá ser feito um
exercício que descreva os problemas que esses clientes normalmente encontram e de que
forma o novo produto irá tentar resolver ou minorar esses mesmos problemas. Sem incluir
qualquer definição de desenho ou de detalhes de implementação, deverá ser apresentado, a
um nível muito alto, as interfaces críticas ou os requisitos de desempenho.
Os requisitos de negócio deverão ainda sumarizar os principais riscos do negócio, associados
11
ao desenvolvimento, ou ao não desenvolvimento, do produto. Algumas categorias de risco

poderão ser as seguintes:
• concorrência de mercado
• questões de tempo
• aceitação dos utilizadores
• questões de implementação
• possíveis impactos negativos no negócio
b) Visão da solução
A secção seguinte do documento, deverá apresentar a visão estratégica da solução. Esta
secção deverá contextualizar as decisões a tomar ao longo da vida do produto. A visão da
solução deverá incluir uma declaração de visão, as principais características do produto e
eventuais assunções e dependências (Wiegers, 2009).
A declaração de visão deverá consistir numa exposição resumida do desígnio de longo prazo
do novo produto, considerando a satisfação das necessidades das diversas partes interessadas
(stakeholders). O produto a desenvolver deverá apresentar uma proposta de valor atrativa
composta por (Moore, 2002):
• Para ... [clientes-alvo do segmento a alcançar]

• O ... [nome do produto]
• É ... [categoria de produto com a sua diferenciação principal e respetivas vantagens]
• Que... [todas as principais características deste tipos de produtos na aplicação
específica, benefícios principais, razão convincente para usar ou comprar]
• Ao contrário ... [do produto alternativo, do sistema atual ou processo de negócio
atualmente presente]
Vejamos o seguinte exemplo do designado "Sistema de Rastreamento de Químicos".
Exemplo prático
"PARA os cientistas que precisam de pedir contentores de produtos químicos, O Sistema de
Rastreamento de Químicos É um sistema de informação QUE irá fornecer um único ponto de
acesso ao armazém químico e aos fornecedores. O sistema irá guardar a localização de cada
contentor químico na empresa, a quantidade de material remanescente no mesmo e a história
completa da localização de cada contentor e da sua utilização.
Este sistema irá poupar à empresa 25% nos custos de químico no primeiro ano de utilização,
permitindo à empresa explorar plenamente os produtos químicos que já tem disponíveis,
dispor de menos contentores parcialmente utilizados ou expirados e utilizar um processo de
compra química único e normalizado. AO CONTRÁRIO dos processos manuais atuais de
ordenação, o nosso produto vai gerar todos os relatórios necessários para cumprir com as
regulamentações governamentais que exigem a notificação de uso de produtos químicos, o
seu armazenamento e disposição."
12
Em seguida, deverão ser enunciadas cada uma das principais características ou funcionalidades
do produto. Deverá ser usada uma abordagem única e organizada, atribuindo a cada um
destes aspetos, não uma marca, mas sim uma etiqueta única e que, por si só, os diferencie dos
outros aspetos.
As assunções ou pressupostos apresentados por qualquer uma das partes interessadas

deverão igualmente ser registados. Por vezes, as assunções ou pressupostos apresentados por
uma das partes interessadas podem não ser partilhados por outra parte interessada. O seu
registo e posterior revisão permitirá facilitar o entendimento e uma visão mais partilhada
sobre o produto entre as partes interessadas neste (Wiegers, 2009). Por exemplo, no caso do
"Sistema de Rastreamento de Químicos", o responsável executivo assumiu que este sistema
substituiria o atual sistema de inventário do armazém químico e que faria interface com o
sistema de compras "Contoso". Deverão ainda ser registadas as principais dependências a
fatores externos que estejam fora do controlo deste projeto.
c) Âmbito e as limitações do projeto

O documento deverá ainda contemplar uma secção com o âmbito da versão inicial, o âmbito
das seguintes versões e as limitações e exclusões do projeto (Wiegers, 2009).
O âmbito deverá definir o que é suposto o software fazer, mas também o que não é suposto
fazer. Poderão ser equacionadas, logo à partida, mais do que uma versão do produto. O
planeamento do projeto poderá ser comprometido se não se resistir à tentação de incluir na
versão 1.0 todas as características que alguns potenciais clientes considerem vir um dia a
precisar no produto. Nesse caso, deverá ser planeada resumidamente uma primeira versão do
produto com as principais caraterísticas. Essa primeira versão deverá contemplar as
características que tragam mais valor à solução num futuro próximo (Wiegers, 2009).
Figura 10. Estratégia do produto SAP para Utilities (Guerra et al., 2006).
13
O planeamento de um produto que possa evoluir através de diversas fases deverá contemplar
a indicação das características que esse produto deve ter na primeira versão e quais as que
deverá ter nas restantes versões. Deverá ainda indicar os prazos respeitantes a cada uma das
versões planeadas.
A Figura 10 apresenta um resumo esquemático da estratégia do produto SAP para a área das
Utilities (Guerra et al., 2006), indicando um período de desenvolvimento (com a linha limite a
tracejado) e apontando as datas de entrada em operação e respetiva manutenção, com o
período de manutenção corrente (à esquerda do ponto 1), de manutenção estendida (entre o
ponto 1 e o ponto 2) e um eventual período de manutenção personalizado de acordo com as
necessidades do cliente (entre o ponto 2 e o ponto 3). Este exemplo ilustra claramente a
existência de um plano para as várias versões de um determinado produto e ainda os períodos
subjacentes a cada um dos seus ciclos de vida.
Requisitos do Negócio /
Requisitos do Sistema
Figura 11. Estratégia das versões SAP com pacotes melhorados . Adaptado de Tobola (2009).
A estratégia associada às várias versões tem normalmente subjacente o princípio de que a

cada nova versão está associado um acréscimo de características funcionais e não funcionais
significativo face à versão anterior. A Figura 11 apresenta visualmente a relação que existe
entre os requisitos de negócio e as respetivas funcionalidades da versão padrão 6.0 do
produto ERP (Enterprise Resource Planning) da SAP e os pacotes funcionais designados por
EHP (ENhancement Package) que melhoram as características do sistema ERP base (Tobola,
2009). Mais detalhes sobre o conceito de pacote de melhoria da SAP poderão ser consultados
no seu sítio oficial na internet (Schwandt, 2008).
Um aspeto igualmente importante é a definição clara do que o sistema fará e do que não é
suposto vir a fazer. Essa definição cuidada permitirá gerir melhor o planeamento do projeto,
da sua equipa e ainda as expetativas do cliente. Aconselha-se a elaboração duma lista com as
características ou funcionalidade que o cliente deseja, mas que não fazem parte do projeto, ou
aquelas que ainda não manifestou intenção, mas que se espera que poderão vir a pretender
no futuro (Wiegers, 2009).
14
d) Contexto do negócio
O contexto do negócio pretende caracterizar os vários stakeholders, as prioridades genéricas
definidas do projeto e os principais aspetos ao nível do ambiente operacional (Wiegers, 2009).
Um stakeholder é uma parte interessada no produto. Pode ser um indivíduo ou uma

organização que tenha um direito, uma participação, uma reclamação ou um interesse num
sistema ou de que este disponha de características que atendam às suas necessidades e
expectativas (ISO and IEC, 2008). A caracterização dos perfis dos mais importantes
stakeholders deverá focar os diferentes tipos de clientes, segmentos-alvo de mercado e
diferentes tipos de classes de utilizadores dentro desses segmentos. O perfil de cada
stakeholder deverá incluir (Wiegers, 2009):
• O maior valor acrescentado ou benefício que o stakeholder usufruirá do produto e que

proporcione uma elevada satisfação ao cliente
• A sua interação mais provável do stakeholder com o produto
• As funcionalidades e características mais valorizadas no produto pelo stakeholder
• Quaisquer restrições específicas do stakeholder que devam ser consideradas
Por outro lado, os benefícios que cada stakeholder poderá usufruir poderão contemplar:
• o aumento de produtividade,
• o aumento do "fazer bem à primeira" (reduzindo o número de ações corretivas),
• a poupança de custos,
• a simplificação dos processos de negócio,
• a automatização de tarefas manuais, disponibilizando a possibilidade de executar
tarefas completamente novas, cumprindo com a legislação ou outro tipo de
obrigações ou aumento de usabilidade comparativamente a outros produtos.
Outro aspeto importante na contextualização do projeto face ao negócio resulta na definição

das prioridades genéricas que deverão ficar associadas ao projeto. A priorização pode ser
abordada segundo as cinco dimensões de um projeto de software (Wiegers, 2009):
• o âmbito
• a qualidade
• o planeamento
• o custo
• a equipa
As diversas prioridades definidas deverão ter em devida conta estes fatores e o seu respetivo
equilíbrio. O conjunto das diversas características que o sistema virá a conter deverá ser
enquadrado no âmbito do sistema pretendido e tendo em atenção as respetivas necessidades
dos utilizadores. Estas características deverão balancear igualmente a qualidade pretendida na
solução por um lado, e as restrições de recursos existentes para a elaboração do planeamento
do projeto, nomeadamente os custos envolvidos e a equipa disponível para o implementar. A
importância da definição destas prioridades será maior num cenário em que no período
pretendido, não venha a ser possível o desenvolvimento de todas as caraterísticas pretendidas
15
para o sistema. Nesse caso, a existência duma ordenação de características por prioridades
será uma ferramenta fundamental na gestão do projeto.
A Tabela 2 apresenta um exemplo do que poderia ser uma definição das prioridades para as
principais características do sistema. É feita uma classificação de cada caraterística com uma
prioridade crítica, importante ou útil e em seguida é feita uma ordenação por prioridade.
Caraterística Prioridade Risco

1 Suporte a base de dados relacional externa Crítica Baixo
4 Porta para a nova versão do sistema operativo Crítica Médio
6 Importação de dados externos Crítica Alto
3 Capacidade de clonar um projeto Importante Médio
2 Segurança multiutilizador Importante Alto
5 Guia para auxílio na criação de um novo projeto Importante Baixo
7 Dicas para ferramenta de implementação Útil Alto
8 Integração com o subsistema de gestão de versões Útil Baixo
Tabela 2. Exemplo de prioridades dum projeto. Adaptado de Leffingwell e Widrig (2003).
A priorização inicial deverá ser feita essencialmente pelos clientes, utilizadores, gestores de
produto ou outros representantes do negócio. A interferência da comunidade técnica deverá
ser mínima nesta fase, pois, caso contrário, as possíveis dificuldades técnicas no
desenvolvimento do sistema poderão contribuir para uma desadequada definição dessas
prioridades por parte do lado do negócio (Leffingwell and Widrig, 2003).
No sentido de uma melhor gestão do âmbito do projeto, pode-se igualmente associar o

elemento risco a cada característica do sistema. Cada avaliação de risco estará ligada à
probabilidade e ao impacto negativo da implementação de determinada característica do
sistema no que diz respeito ao planeamento e ao orçamento do projeto (Leffingwell and
Widrig, 2003).
A questão da priorização e de outros atributos de classificação será novamente abordada mais

à frente nesta lição, não no contexto das caraterísticas gerais do sistema como agora se expôs,
mas no âmbito dos requisitos de software em particular.
2. Dos requisitos de negócio aos requisitos de utilizador

O documento que compila os requisitos de utilizador descreve os requisitos de mais alto nível
que o sistema deverá ter e, por essa razão, é por vezes designado de documento de definição
de sistema (Abran et al., 2004). Nele são definidos os requisitos de sistema de alto nível a
partir da perspetiva de domínio.
Os casos de uso podem ser identificados de várias formas (Wiegers, 2009):
• Em primeiro lugar, através da identificação dos seus atores e, em seguida, através da

identificação dos processos onde estes participam
• Identificando os eventos externos aos quais o sistemas deverá responder e, em
seguida, relatar estes eventos, os seus atores e casos de uso específicos
16
• Expressando processos de negócio em termos de cenários específicos, generalizando

os cenários em casos de uso e identificando os atores envolvidos em cada caso de uso
• Derivando casos de uso de requisitos funcionais já existentes
Vejamos o exemplo associado ao já apresentado "Sistema de Rastreamento de Químicos".
Exemplo prático
A Figura 12 representa um diagrama parcial de caso de uso relativo ao "Sistema de
Rastreamento de Químicos" (SRQ), no qual estão identificados cinco atores e sete processos
em que estes atores participam.
Figura 12. Diagrama parcial de caso de uso relativo ao SRQ (Wiegers, 2009).
A cada caso de uso deverá ser associado o chamado cenário principal, podendo ainda ser
apresentados cenários secundários, especificando casos especiais a tratar. no entanto, não é
objetivo desta lição aprofundar este tema.
D. Os intervenientes no processo de especificação de requisitos
No caso do desenvolvimento de um software, um requisito de software descreve o que as

várias partes interessadas, nomeadamente designers ou outros interessados, pretendem que o
sistema faça (Gilb, 2005). As várias partes interessadas colaboram tradicionalmente na gestão
dos requisitos de software, podendo fazê-lo com maior ou menor grau de participação, com
maior incidência nalgumas fases do projeto ou assumindo algumas funções especificas nessa
mesma gestão. As partes interessadas podem-se agrupar em dois grandes grupos: os clientes e
a comunidade técnica. Para além destes dois grupos, o meio ambiente também interfere no
processo de desenvolvimento de requisitos. A Figura 13 realça as principais relações existentes
17
entre os clientes, a comunidade técnica e o meio ambiente no desenvolvimento da coleção de

requisitos do sistema (SyRS).
Figura 13. Contexto do desenvolvimento de um SyRS (IEEE, 1998b).
A Figura 14 apresenta mais detalhadamente algumas das partes interessadas (stakeholders) no

processo de gestão dos requisitos de software e que poderão estar envolvidas neste processo.
CIO CEO
arquiteto de utilizador
negócio
analista utilizadora
designer utilizador
Gestão de
administradora de
base de dados
Requisitos utilizador
utilizadora
programador
cliente
testador
fornecedor
consultor
gestor de
projeto
Figura 14. Partes interessadas num processo de gestão dos requisitos de software
Do lado direito da figura apresentam-se as partes (utilizadores) mais ligadas ao negócio,

reportando direta ou indiretamente ao CEO (Chief Executive Officer) ou a outros diretores
executivos. Representam-se ainda, como possível parte interessada, um cliente e um
fornecedor (parceiros exteriores). Do lado esquerdo, figuram elementos da equipa das TI
(Tecnologias e Informação) dependentes do CIO (Chief Information Officer), tais como, uma
18
administradora de base de dados ou um programador. Como suporte ao projeto temos a

importante figura do gestor de projeto (ao centro e em baixo). Poderá ainda haver alguns
parceiros exteriores mais ligados às TSI, aqui representados pelos consultores (de TI) e por
eventuais fornecedores (de TI).
Como é espectável, o ambiente da organização influenciará e contribuirá com restrições na

especificação dos requisitos. Para além disso, cada uma das diferentes partes interessadas tem
uma participação e interesses específicos relativos à utilização deste documento. A Figura 15
apresenta alguns dos mais importantes utilizadores dum documento deste tipo e as suas
principais motivações na sua utilização (Sommerville, 2007, IEEE, 1998b).
cliente do
sistema
{ Especifica os requisitos e lê-os para verificar que
estes vão de encontro às suas necessidades.
Especificam alterações aos requisitos.
gestor
{ Usa o documento dos requisitos para planear uma
proposta para o sistema
Usa o documento para planear o processo de
desenvolvimento do sistema
implementador
{ Usa o documento dos requisitos para entender
qual o sistema que deverá ser desenvolvido
testador
{ Usa os requisitos para desenvolver testes de
validação dos diversos componentes do sistema
Usa os requisitos para efetuar a validação do
sistema como um todo
manutenção
{ Usa os requisitos para entender o sistema e a
relação entre as suas partes
Usa os requisitos para entender o impacto das
alterações a efetuar
Figura 15. Utilizadores e o documento de requisitos. Adaptado de Sommerville (2007).
A participação dos utilizadores, nomeadamente na fase de especificação de requisitos, está

intimamente relacionada com o sucesso ou o insucesso dum projeto. Segundo um inquérito
efetuado, os três fatores mais significativos no sucesso dum projeto são o envolvimento dos
utilizadores (15,9% das respostas), o apoio dos gestores executivos (13,9%) e a descrição clara
dos requisitos com 13,0% dos respondentes (The Standish Group, 1995).
19
E. A elicitação de requisitos
A elicitação de requisitos é normalmente a atividade associada ao primeiro passo do processo

de engenharia de requisitos (Nuseibeh and Easterbrook, 2000). O termo elicitação é preferível
ao termo recolha ou captura de requisitos. Estas últimas expressões indiciam que os requisitos
existem algures, de certa forma prontos para ser colhidos, o que não corresponde ao que na
realidade acontece.
O processo de procurar, descobrir, adquirir e elaborar requisitos para sistemas baseados em

computador é designado de elicitação de requisitos. É comummente aceite que os requisitos
são elicitados em vez de capturados ou recolhidos. Isso implica que existe um processo de
descoberta que possibilitará o emergir dos requisitos (Zowghi and Coulin, 2005).
Há um número significativo de técnicas para a identificação de requisitos, das quais

destacamos as seguintes (IEEE, 1998b):
• Oficinas estruturadas;
• Sessões de reflexão (brainstorming) ou sessões "problema- resolução";
• Entrevistas;
• Inquéritos / questionários;
• Observação de padrões de trabalho (por exemplo, estudos de tempo e movimento);
• Observação do ambiente de sistemas organizacionais e políticos (por exemplo,
sociograma);
• Revisão da documentação técnica;
• Análise de Mercado;
• Avaliação do sistema competitivo;
• Engenharia reversa;
• Simulações;
• Protótipos;
• Processos e sistemas de avaliação comparativa (benchmarking).
No que diz respeito à elicitação de requisitos, existe um conjunto de diferentes técnicas e

abordagens que podem ser utilizadas para cada atividade de elicitação de requisitos. Por outro
lado, as técnicas e abordagens usadas no levantamento de requisitos são frequentemente
utilizadas em cooperação com outras.
A Tabela 3 apresenta um conjunto de oito técnicas e abordagens que se acredita fornecer

cobertura adequada em todo o espectro de técnicas e abordagens disponíveis usadas em
atividades de elicitação (Zowghi and Coulin, 2005).
20
Trabalho em grupo
Pontos de vista
Prototipagem
Cenarização
Entrevistas
Técnicas e Abordagens
Etnografia
Objetivos
Domínio
Entendendo o domínio X X X X X X X
Identificando as fontes dos requisitos X X X X X X
Analisando os stakeholders X X X X X X X X
Selecionando técnicas e abordagens X X X
Elicitação dos requisitos X X X X X X X X
Tabela 3. Técnicas e abordagens para atividades de elicitação (Zowghi and Coulin, 2005).
Tal como foi referido anteriormente, apesar desta lição não ter como objetivo o tema da
elicitação de requisitos, há uma clara inter-relação entre estas atividades. Existe a consciência
de que uma má elicitação de requisitos irá condicionar claramente as atividades que se lhe
seguem, nomeadamente a análise, a especificação e a validação de requisitos. A Figura 5
realça que após a fase de validação de requisitos, por vezes será necessário voltar à fase
anterior da análise, reescrevendo os requisitos, ou voltar mesmo á fase inicial da elicitação de
requisitos, corrigindo e fechando lacunas neles existentes.
F. Análise de Requisitos
Segundo a Figura 5, a análise de requisitos é a atividade que antecede imediatamente a

especificação de requisitos. Por outro lado, a análise de requisitos sucede e interage com a
atividade de elicitação.
orientadas aos
processos
orientadas aos orientadas aos

requisitos do
objetos dados
sistema
orientadas ao
controle
Figura 16: Categorias de métodos de análise de requisitos
Os métodos de análise de requisitos podem ser divididos em quatro categorias. Esta proposta
de categorização não deve ser considerada como absoluta, porque a maioria dos métodos tem
21
algumas das características destas várias categorias, embora, geralmente tenham um ponto de
vista principal (Dorfman, 1990). A Figura 16 apresenta as 4 categorias, respetivamente
orientadas a processos (e.g. DFD), orientadas a dados (e.g. ERD), orientadas a controle (e.g.
diagramas de estados) e orientadas a objetos (e.g. diagramas de classes).
Da interação com os clientes e as várias partes interessadas, a análise de requisitos coleciona

um conjunto de palavras-chave que serão usadas em elementos específicos de modelação. A
Tabela 4, adaptada de Wiegers (2009) apresenta um conjunto de possíveis nomes e verbos
oriundos do cliente mapeados em componentes de modelação posteriormente analisados.
Tipo de Componentes de Modelos da

Exemplos
Palavra Análise de Requisitos
• entidades externas/terminadores (DFD)
• pessoas
• depósitos de dados (DFD)
• organizações
• atores (diagramas de casos de uso)
• sistemas de software
Nome • entidades ou os seus atributos (ERD)
• itens de dados
• classes ou seus atributos (diagramas de
• objetos que existem
classes)
• estados
• estados de objetos (STD)
• fluxos de dados (DFD)
• casos de uso (diagramas de casos de uso)
• ações • relações entre casos de uso (diagramas
• processos de casos de uso)
• atividades • cenários principais e secundários
Verbo
• coisas que os utilizadores fazem (diagramas de casos de uso)
• eventos que podem acontecer • relações entre entidades (ERD)
• cenários • transições entre estados (STD)
• processos, atividades (diagramas de
atividades)
Tabela 4. Relacionando a voz do cliente com componentes de modelação da análise.
Da voz do cliente recolher-se-ão as informações necessárias que permitirão a construção dos

modelos de análise e a especificação dos requisitos. Deverá ser possível assegurar a ligação de
cada modelo de análise com requisitos de utilizador específicos (Wiegers, 2009).
Posteriormente, também deverá ser possível a ligação de cada requisito de software a um
requisito de utilizador específico, preferencialmente via modelos de análise efetuados.
São vários os tipos de modelação da análise disponíveis, estando os mais conhecidos listados
na tabela anterior. No entanto, esta lição, que pretende focar-se na especificação dos
requisitos, apenas usará a modelação da análise como suporte á especificação dos requisitos
de mais alto nível. Assim, optará por usar apenas um destes tipos de modelação da análise,
sendo essa abordagem, a dos diagramas de fluxos de dados (DFD). Esta opção não pretende de
forma alguma, desvalorizar os restantes tipos de modelação. Pelo contrário, é comummente
aceite que estas diferentes abordagens são usadas complementarmente entre si como forma
de evidenciar diferentes perspetivas das questões a resolver.
22
III. Elaboração do documento de especificação de

requisitos de software
Um documento de requisitos de software explica um problema de negócio e os requisitos de
uma solução de software numa perspetiva do utilizador e do negócio (Rinzler, 2009). Deverá
ser preciso e detalhado o suficiente de forma a que os engenheiros possam entender o que
construir e ainda uma forma de avaliar o que produzem. Algumas das características de um
documento de requisitos bem redigido são as seguintes:
• Deverá conter o que é pedido ao sistema duma forma precisa, mensurável e testável
• Detalha a forma como o sistema interage com os elementos que o rodeiam
• Deverá utilizar uma linguagem entendível para os utilizadores do software e para os
seus desenvolvedores
Este último aspeto, a utilização duma linguagem entendível para vários destinatários do
documento, é importante e facilita o desempenho duma missão especial por parte deste
documento que é o de se tornar numa ferramenta facilitadora da comunicação entre todos os
elementos da equipa de projeto, quaisquer que eles sejam. No entanto, a visão de Rinzler
(2009), ao não distinguir os requisitos de software dos requisitos de negócio, pode não ser
unânime. Outros autores, como por exemplo Wiegers (2009), sem deixarem de apostar numa
linguagem o mais entendível possível, defendem que um documento de especificação de
requisitos possa ter capítulos mais destinados a certos interessados e outros capítulos mais
destinados a outros.
A. Alguns princípios na elaboração dum documento de SRS
O documento de requisitos de software (normalmente designado de especificação de

requisitos de software ou SRS) é a declaração oficial do que os desenvolvedores do sistema
devem implementar. Este documento deve incluir não só os requisitos de utilizador para um
sistema, mas também uma especificação detalhada dos requisitos do sistema (Sommerville,
2007).
O conjunto de recomendações práticas que se apresentam em seguida está integrado num

processo de especificação de requisitos de software (SRS) cujo resultado pretendido é a
elaboração dum SRS inequívoco e completo. Este documento deverá ajudar (IEEE, 1998a):
• Os clientes do software a descreverem duma forma precisa o que pretendem obter;

• Os fornecedores do software a entenderem inequivocamente o que os clientes
pretendem;
• Os elementos da equipa de projeto a atingirem objetivos como o desenvolvimento
duma especificação de requisitos de software normalizada para a sua organização; a
definição do formato e os conteúdos da sua especificação de requisitos de software
específica ou o desenvolvimento de itens adicionais de suporte local, tais como, uma
lista de verificação para a qualidade do SRS ou um manual de escrita de SRS.
23
Um bom SRS deverá ser um instrumento que permita a clientes, a fornecedores e a outros
elementos (IEEE, 1998a):
• Estabelecer as bases para um acordo entre os clientes e os fornecedores sobre o que é

que o produto de software deverá fazer
• Reduzir o esforço de desenvolvimento
• Proporcionar uma base que permita a orçamentação e o planeamento
• Permitir uma linha orientadora para validação e verificação
• Facilitar a transferência do novo software para os utilizadores ou equipamento
• Servir como veículo de melhoria
1. O que o SRS deverá ser ou não ser

Os aspetos básicos que um bom SRS deverá abranger e as questões principais a que deverá
responder são os seguintes (IEEE, 1998a):
• Funcionalidade. O que é que o sistema deverá fazer?

• Interfaces Externas. Como é que o software interage com as pessoas, o hardware do
sistema, outro hardware ou outro software?
• Desempenho. Qual é a velocidade, disponibilidade, tempo de resposta, tempo de
recuperação para várias funções do software, etc.?
• Atributos. Que considerações sobre portabilidade, correção, manutenibilidade,
segurança, etc.?
• Restrições de desenho. Existem algumas normas, linguagens de implementação,
políticas de integridade de bases de dados, limitações de recursos, ambientes
operativos imperativos?
Por outro lado, embora o escritor do SRS possa colocar normas ou regras relativas ao desenho
do sistema, deverá evitar colocar requisitos específicos de desenho, de projeto ou de
implementação neste documento.
A especificação dos requisitos resulta da sua análise e é geralmente definida como o "quê" de
um problema, liberto da implementação, contendo objetivos e não os métodos a usar. O
desenho é o "como", a implementação que irá cumprir os requisitos. Embora, obviamente, a
viabilidade dum requisito deva ser sempre considerada, estes dois aspetos devem ser
mantidos em separado. No entanto, olhando de perto o processo de criação do desenho
arquitetural, observa-se que quer a análise/especificação de requisitos, quer o desenho estão
nele envolvidos (Dorfman, 1990).
2. Componentes da especificação de requisitos de software

Propõe-se que um documento de especificação de requisitos de software tenha uma
introdução, uma secção com uma descrição geral e uma secção de requisitos específicos. A
introdução do SRS deverá mostrar uma visão geral de todo o documento, contendo o seu
objetivo, o seu âmbito, as definições, siglas e abreviaturas utilizadas, as referências e uma
visão global do software. A descrição geral deverá apresentar a perspetiva do produto, as
características do produto, as classes e características de utilizador, as restrições de desenho e
24
implementação e as assunções e dependências. A secção de requisitos específicos deve conter

todos os requisitos de software com um nível de detalhe suficiente que permita aos designers
projetar um sistema que satisfaça esses requisitos e aos testadores que verifiquem se o
sistema satisfaz esses requisitos. Cada requisito especificado deve ser entendido
externamente pelos utilizadores, operadores ou por outros sistemas externos que sejam
intervenientes (IEEE, 1998a).
Uma organização deverá adotar (pelo menos) um modelo que normalize a especificação de
requisitos de software nos seus projetos. Existem alguns modelos e abordagens disponíveis
para este efeito (Vie, 2009, IEEE, 1998a, Wiegers, 2009, Leffingwell and Widrig, 2003, Davis,
1993, Gilb, 2005). Propõe-se a utilização da estrutura que se apresenta na Figura 17 (Wiegers,
2009).
Figura 17. Possível modelo do documento "Especificação de Requisitos de Software".
A secção seguinte apresentará cada um dos tópicos propostos neste modelo para este
documento.
B. Um modelo de SRS
1. Introdução
O objetivo da introdução é apresentar o documento, indicando a forma como está organizado
e ainda a forma de o usar. Sugere-se que seja composto pelos tópicos objetivo, convenções do
documento, audiência pretendida e sugestões de leitura, âmbito do projeto e por referências
(Wiegers, 2009). Em seguida desenvolvem-se estes tópicos.
a) Objetivo
Neste tópico deve-se identificar o produto cujos requisitos de software estão especificados no
documento, incluindo o número de revisão ou versão. Deve descrever-se o âmbito do produto
que está coberto pelo SRS, em particular se o SRS descreve apenas uma parte do sistema ou
um único subsistema (Wiegers, 2009).
25
b) Convenções do documento
Este tópico deverá descrever as normas ou convenções tipográficas que devem ser seguidas
aquando da escrita deste SRS, tais como fontes de letra ou qualquer outro tipo de formatação
com significado especial. Por exemplo, definir se as prioridades dos requisitos de alto nível são
assumidamente herdadas dos requisitos detalhados, ou se cada requisito deve ter a sua
própria prioridade. Este tópico também deverá definir o tipo de etiquetagem a usar. Este
assunto será melhor abordado noutro ponto desta lição (Wiegers, 2009).
De entre as convenções que algumas organizações têm, destacam-se ainda as seguintes

(Herrington, 2007):
• Interfaces gráficos de utilizador, chamadas de GUI (Graphical User Interface)

• Formatos para relatórios
• Desenho de base de dados
• Normas de segurança e privacidade
c) Audiência pretendida e sugestões de leitura

Este tópico deverá descrever os diferentes tipos de leitores para os quais foi feito o
documento, tais como; programadores, gestores de projeto, equipa de marketing, utilizadores,
equipa de testes ou documentação. Deve ainda ser descrito o que o resto do SRS contem e
como está organizado. Pode ser sugerida uma sequência de leitura para o documento,
começando com um resumo das diversas sessões e indicando quais as mais relevantes para
cada tipo de utilizador (Wiegers, 2009).
d) Âmbito do projeto
Aconselha-se a fazer uma pequena descrição do software e o seu propósito, com a indicação
dos seus benefícios, dos seus objetivos e das suas metas. Neste tópico deverá ser relacionado
o software com o negócio, nomeadamente com as metas aí incorporadas ou com as
estratégias definidas para o negócio.
Deverão ser identificados os FCS (Fatores Críticos de Sucesso) do negócio e estes enquadrados
com o projeto. Se está disponível um documento separado de visão e alcance ou âmbito
(matéria apresentada anteriormente no tópico "A elaboração dos requisitos de negócio", na
página 10), dever-se-á referir a ele em vez de duplicar o seu conteúdo.
Um SRS que especifique uma versão posterior, numa perspetiva dum produto mais
envolvente, deverá conter uma declaração do alcance deste como um subconjunto duma visão
estratégica de longo prazo do produto (Wiegers, 2009).
e) Referências
Deverá ser listado qualquer outro documento ou endereço da Internet ao qual o SRS se refere.
Poderão ser incluídas guias de estilo para interfaces com utilizadores, contratos, normas,
especificação de requisitos de sistema, documentos com casos de uso, documento de visão e
alcance. Poderá ainda ser incluída alguma legislação relevante para o desenvolvimento do
sistema (Wiegers, 2009).
26
Deverá ser disponibilizada informação suficiente de forma a que o leitor possa ter acesso a
uma cópia de cada referência, nomeadamente:
• título
• autor
• número da versão
• data
• fonte e localização
Uma referência a uma fonte publicada ou não publicada é designada normalmente por
citação. Existem diversos sistemas de citação, sendo os mais populares os seguintes: Oxford,
Harvard, MLA, American Sociological Association (ASA) e a American Psychological Association
(APA).
2. Descrição geral
O objetivo deste capítulo é apresentar uma visão de alto nível do produto e do ambiente em
que este será usado, dos utilizadores que provavelmente o irão utilizar, das restrições,
assunções e dependências existentes. Assim, sugere-se que este capítulo do SRS seja
composto pelos tópicos: perspetiva do produto, caraterísticas do produto, classes e
características de utilizador, ambiente operativo, restrições de desenho e implementação,
documentação de utilizador e por assunções e dependências (Wiegers, 2009). Em seguida
desenvolvem-se estes tópicos.
a) Perspetiva do produto
Este tópico deverá descrever o contexto e a origem do produto que está a ser especificado no
SRS. Por exemplo, estabelecer se o produto é um membro de continuidade duma família de
produtos, uma substituição de um determinado sistema existente ou um produto
completamente novo. A Figura 18 ilustra uma árvore genealógica de produtos, neste caso a
relação das várias versões do sistema operativo Microsoft Windows desde a sua versão inicial,
a versão 1.0, até à mais recente versão 7 ou Server 2008 R2.
Figura 18. Árvore genealógica do sistema operativo Microsoft Windows (Wikipedia, 2012).
27
Se o SRS está a definir uma componente dum sistema mais abrangente, deverão ser
especificados os requisitos desse sistema global para a funcionalidade deste software e
identificadas as interfaces entre os dois sistemas (Wiegers, 2009).
Poderá ainda ser mostrado, através duma simples modelação, uma perspetiva do sistema
como um todo, com as principais interações com os utilizadores e as suas interligações com
subsistemas e interfaces externos. Uma das técnicas de modelação mais usadas para este
efeito é o DFD (diagrama de fluxos de dados).
Exemplo prático
Imagine que pretendia desenvolver um sistema de informação que suportasse a gestão duma
clínica médica, permitindo gerir horários de médicos, gerir consultas (marcação de consultas e
desmarcação de consultas), consultar históricos de consultas de um paciente, funcionando
todo ele como um histórico de todo o consultório. Este sistema não pretende disponibilizar
funções financeiras, nem de gestão de recursos humanos (nomeadamente a sua contratação,
despedimento ou avaliação de pessoal).
O sistema deve ser desenvolvido em ambiente WEB, de forma a ser acedido pela Internet
através de um browser, simplificando o acesso a utilizadores que utilizem este meio de acesso
Figura 19. Diagrama de contexto do sistema MEDIGest. Adaptado de Ferreira et al. (2005).
A Figura 19 apresenta uma proposta de modelação de alto nível para o sistema a desenvolver,
que se denominou de MEDIGest (Ferreira et al., 2005), utilizando como técnica de modelação
um diagrama de fluxos de dados (neste caso, o diagrama de contexto do sistema).
Uma modelação alternativa ao diagrama de fluxo de dados de contexto para este nível de
especificação será a modelação através de caso de uso de contexto.
b) Características do produto
Neste tópico deverão ser resumidas as principais características que o produto contem ou as
principais funções que este executa ou permite ao utilizador executar. Os detalhes destas
características ou funcionalidades deverão ser desenvolvidos no capítulo 3 do SRS e que se
explica mais à frente, pelo que, apenas um sumário de nível mais alto deverá ser mostrado
nesta fase.
28
As diversas funcionalidades deverão ser organizadas de forma a torná-las percetíveis a

qualquer leitor do SRS. De forma a complementar esta apresentação deverá ser usado uma
modelação, do tipo diagrama de fluxo de dados de 1º nível ou então um diagrama de caso de
uso, com as respetivas funcionalidades do sistema e a forma como estas se relacionam
(Wiegers, 2009).
Exemplo prático
A Figura 20 apresenta uma modelação de primeiro nível para o sistema denominado
MEDIGest, apresentado anteriormente duma forma resumida e cujo respetivo diagrama de
contexto tinha sido proposto na Figura 19 (Ferreira et al., 2005).
Pedido de acesso
Pedido de acesso
Administrador Confirmação / Secretaria
Negação
Confirmação / Negação de acesso
de acesso
Novos utilizadores Novo Utente
Consulta nova / alterada
Listagem de utilizadores
1. 3.
1
Gestão de Gestão de Consulta a desmarcar
2
acessos consultas
Horários dos médicos
Pedido de acesso
Confirmação
Negação de acesso
Utilizador Utente
Consultas
Horários Livres
Marcadas
Utente
Agenda Horário clínica Novo ou
alterado
2. 4.
Horário Pretendido Gestão de Gestão de
Horário Concedido horários Dados Clinicos utentes
Histórico de consultas
Consultas marcadas
Dados clínicos
Médico Consulta (dados clínicos) Utente
1 Pedido de acesso
2 Confirmação / Negação de acesso
Figura 20. Diagrama de 1º nível do sistema MEDIGest. Adaptado de Ferreira et al. (2005).
Esta modelação ilustra quatro grandes grupos funcionais, respetivamente:

• Gestão de acessos
• Gestão de horários
• Gestão de consultas
• Gestão de utentes
Deverá ser ainda apresentado um pequeno texto a explicar o que cada grupo funcional
pretende abarcar em termos de funcionalidade.
29
Cada um dos grupos funcionais apresentados neste capítulo deverão ser detalhados em
secções distintas no capítulo 3 do SRS.
c) Classes e características de utilizador

Esta secção deverá identificar as várias classes de utilizador que se antecipam e que vão usar o
software. A diferenciação nas classes de utilizador poderá ser feita através da frequência de
utilização, subconjunto de funcionalidades utilizadas, experiência técnica, nível de segurança
ou privilégios, nível educacional ou experiência.
Para cada uma das classes de utilizador deverão ser descritas as características mais
pertinentes. Alguns requisitos poderão estar associados apenas a algumas classes de
utilizador. Deverão ser distintas as classes de utilizador que são mais importantes para
satisfazer e as que o são em menor grau (Wiegers, 2009).
Exemplo prático
Relativamente ao caso do sistema MEDIGest, deverá ser permitido o acesso a vários tipos de
utilizadores, sendo o administrador responsável por todos os utilizadores. Em resumo, deverão
ser considerados quatro classes de utilizador, cujas caraterísticas principais se apresentam:
Administrador Deverá ser permitido aos administradores da clínica adicionar, editar e

remover funcionários (médicos ou funcionário de secretaria), consultar
horários dos médicos. As credenciais para acesso ao sistema serão fornecidos
pelo administrador.
Médico Deverá ser permitido a cada médico consultar e atualizar os dados clínicos
dos seus utentes, disponibilizar horários de consultas.
Secretaria Deverá ser permitido ao funcionário marcar e desmarcar consultas, adicionar

e editar utentes. No caso de utentes, a sua ficha tem de estar previamente
criada no sistema pelos serviços administrativos.
Utentes Deverá ser permitido a cada utente visualizar as suas consultas marcadas
(data, hora, médico, etc.), bem como todo o histórico de consultas já
realizadas por si.
d) Ambiente operativo
Esta secção deverá identificar o ambiente no qual o software irá operar, incluindo (Wiegers,
2009):
• a plataforma de hardware,
• os sistemas operativos e as respetivas versões,
• as localizações geográficas dos utilizadores,
• servidores,
• bases de dados,
30
• qualquer outro componente de software com o qual o produto terá de coabitar

pacificamente.
e) Restrições de desenho e implementação

Esta secção deverá descrever qualquer item que limite as opções disponíveis para os
programadores, bem como o racional inerente a cada restrição. A lista destas restrições
poderá incluir (Wiegers, 2009):
• tecnologias, ferramentas, linguagens de programação ou bases de dados específicas a
utilizar ou a evitar,
• restrições derivadas do ambiente operativo do produto (tais como as versões do
navegador da Web que irá ser usado),
• políticas cooperativas ou regulamentares (como por exemplo, no caso da organização
do cliente ser responsável pela manutenção do software a entregar, poderá definir
notações ou normas de codificação que o fornecedor deverá seguir),
• compatibilidade com produtos anteriores,
• limitações impostas por regras de negócio (a documentar noutro local),
• limitações de hardware (tais como requisitos de tempo, de memória, de processador,
de custo, de tamanho ou peso),
• interfaces com outras aplicações a seguir,
• protocolos de comunicação (tal como a utilização dum formato XML),
• considerações de segurança,
• convenções de desenho
f) Documentação de utilizador
A secção relativa à documentação de utilizador deverá contemplar uma listagem das
componentes de documentação que serão entregues mais tarde juntamente com o software,
tais como:
• os manuais de utilizador,
• ajuda “on-line”
• tutoriais
Deverá ainda ser identificado qualquer formato ou norma de documentação de utilizador a
entregar.
g) Assunções e dependências
Para terminar este capítulo do SRS, propõe-se uma secção com assunções e dependências.
Aqui deverá ser listado qualquer fator assumido (em contraposição com factos já confirmados)
que poderá afetar os requisitos estabelecidos no SRS.
Isto poderá incluir terceiras pessoas ou uma componente comercial que se pensa usar,
questões acerca do desenvolvimento ou do ambiente operativo ou ainda restrições doutra
ordem.
O projeto poderá vir a ser afetado se estas assunções forem incorretas, não forem partilhadas
ou forem alteradas.
31
Também deverá ser ainda identificada qualquer dependência que o projeto tenha de fatores
externos, tal como, componentes de software que pretende reutilizar doutro projeto, a não
ser que estes já estejam devidamente documentados noutro local (por exemplo, na parte da
visão ou do plano de projeto).
3. Características do sistema
Este modelo de SRS ilustra a organização dos requisitos funcionais do produto, estruturada por
características do sistema, ou seja, pelos principais serviços disponibilizados pelo produto.
Existem diversas formas de organizar este capítulo dum SRS.
A escolha da forma de organização do capítulo dependerá do formato que for mais adequado
ao produto. No caso de se optar por uma organização por caraterísticas funcionais, cada
secção do capítulo deverá corresponder a um dos grupos funcionais identificados. Cada uma
das características do produto pode ser especificada segundo os seguintes pontos (Wiegers,
2009):
• Descrição e prioridade
• Sequência de resposta
• Requisitos funcionais
Cada caraterística deverá ser acompanhada de uma pequena descrição. Deverá também ser
indicada igualmente a prioridade de cada funcionalidade (por exemplo, com uma classificação
de baixa, média ou alta prioridade, ou outro tipo de classificação de prioridade definido).
Poderão ainda ser incluídos outros atributos com classificação específicos, tais como o
benefício, o custo ou o risco (cada um classificado segundo uma escala pré-definida).
Exemplo prático
No caso do sistema MEDIGest, optou-se por uma hierarquia funcional. A característica de cada
função foi definida em poucas palavras. Respetivamente: “1-Gestão de acessos”, “2-Gestão de
horários", "3-Gestão de Consultas” e "4 - Gestão de utentes".
A palavra “Gestão” indicia que terá que existir um desdobramento em cada uma das
funcionalidades em várias subfunções. A etiquetagem numérica permitirá um desdobramento
hierárquico que se apresentará posteriormente nesta lição. Por exemplo, o módulo 4, relativo
à gestão de utentes, será desenvolvido no subponto 4 do ponto 3 do documento SRS, ou seja,
no seu ponto 3.4.
32
Exemplo prático (continuação)

Este módulo poderá ser descrito da seguinte forma:
O módulo de Gestão de Utentes permite a criação de novos utentes da clínica por parte do
pessoal da secretaria. Estes utilizadores poderão ainda alterar alguns dados da ficha de
cada utente, nomeadamente a morada ou o estado civil. O módulo permite também
verificar os dados clínicos dos utentes pelos seus respetivos médicos aquando duma
consulta e introduzir novos dados clínicos do utente ou alterar alguns desses dados nas
suas fichas. Este módulo contempla ainda a possibilidade do utente visualizar o histórico
de consultas que teve na clínica, inclusive os seus respetivos dados clínicos e ainda a
informação acerca dos horários livres dos médicos para posteriormente poder solicitar a
marcação de consultas no futuro.
Prioridade: Alta
A análise essencial pressupõe que a cada estímulo do mundo exterior, o sistema deva reagir
produzindo uma resposta predeterminada. Estas sequências podem-se designar por
sequências "estímulo-resposta". Normalmente, um estímulo é um ativador de uma função ou
uma forma de como o evento atua sobre o sistema. A resposta, é o efeito originado pelo
sistema devido à ocorrência de um evento. Para além da linguagem natural, usam-se
frequentemente alguns tipos de modelação para ilustrar melhor estas sequências como os
cenários associados aos casos de uso, diagramas de transição de estados ou diagramas de
atividades.
Exemplo prático
No caso do MEDIGest, vejamos os seguintes exemplos de sequências "estímulo-resposta" que
ilustram o comportamento definido nesta característica:
Estímulo: O médico pede a ficha de dados clínicos de um determinado utente ao sistema.

Resposta: O MEDIGest apresenta ao médico a ficha dos dados clínicos armazenada
referente a esse utente, caso este seja seu paciente.
Estímulo: O médico adiciona novos dados à ficha clínica do utente.

Resposta: O MEDIGest acrescenta os novos dados à ficha clínica do utente e armazena-a
posteriormente.
Segue-se a apresentação dos requisitos funcionais. Os requisitos deverão ser itemizados e cada
um deverá ter uma etiqueta única. Deverá ser elaborada uma lista das capacidades do
software a disponibilizar ao utilizador segundo a análise previamente feita. Deverá ainda
contemplar-se as respostas do sistema a condições de erro, a incorretas ações ou entradas de
dados.
A especificação dos requisitos funcionais está intimamente ligada à análise que foi feita aos
requisitos. A modelação que suporta a análise proposta para o capítulo 2 do SRS, apresentado
anteriormente, previa a utilização de um DFD de primeiro nível, mostrando as principais
33
funcionalidades do sistema e a sua interligação. Para este capítulo 3, propõem-se níveis de

especificação mais detalhados, com uma modelação adequadamente de mais baixo nível. Essa
modelação será conseguida com DFD´s de 2º nível (ou de nível ainda mais baixo),
respetivamente ligados a cada uma das características do produto.
Por outro lado, cada característica pode ser imediatamente subdividida nos seus requisitos, ou
então, pode ser dividida noutras características até chegar a uma unidade mono funcional e,
apenas nesse momento, ser dividida em requisitos. Cada característica do produto é apenas
passível de ser convertida em pseudocódigo no nível mais baixo de especificação.
Exemplo prático
No caso do sistema MEDIGest, a proposta de modulação para a gestão dos utentes é a que se
apresenta na Figura 21. Esta modelação torna evidente a não interferência da classe de
utilizador administrador nesta funcionalidade. Neste caso, não foi definido um terceiro nível
para este grupo funcional. O uso da etiquetagem do tipo hierárquica facilita uma associação
com o módulo 4, mostrando um grupo de quatro características que este módulo deverá ter.
Figura 21. Diagrama de 2º nível do grupo funcional 4 - Gestão de Utentes do sistema

MEDIGest. Adaptado de Ferreira et al. (2005).
A cada uma destas quatro características deverão ser associados os requisitos pretendidos:
4.3.1: "O sistema permitirá que cada utente liste as consultas que teve no passado,
indicando a data, a especialidade e o médico respetivo de cada consulta"
4.3.2: "O sistema permitirá que cada utente visualize, na forma de agenda, as consultas que
teve no passado e as que tem agendadas para o futuro "
4.3.3: "O sistema permitirá que qualquer utente selecione uma qualquer sua consulta
passada, apresentando os seus detalhes (a data, a hora, o médico, a sintomatologia,
o diagnóstico, os exames, a medicação ou o tratamento prescrito)"
34
O capítulo 3 do SRS é normalmente o capítulo mais extenso do documento. A complexidade da

especificação de requisitos pode obrigar à definição de vários níveis funcionais. Por exemplo,
os pedidos de cotação a fornecedores, internacionalmente designados por RFI (Request For
Information) ou RFP (Request For Proposal), propostos pelo centro de avaliação de software da
TEC (Technology Evaluation Center), contemplam normalmente milhares de requisitos para
cada tipo de sistema pretendido, divididos por várias caraterísticas ou componentes.
Exemplo prático
O modelo de RFI/RFP da TEC para um sistema de grande dimensão, como um sistema do tipo
ERP Mixed-Mode lista 3.872 características/funções/requisitos, encontrados a partir da base
de dados de soluções que este centro de avaliação tem para este tipo de produto (TEC, 2012).
Os requisitos contemplados neste modelo de ERP Mixed-Mode estão estruturados segundo os
seguintes grupos funcionais:
1. Financeira
2. Recursos Humanos
3. Gestão da Produção Discreta
4. Gestão do Processo de Fabricação
5. Gestão de Inventário
6. Gestão de Compras
7. Gestão da Qualidade
8. Gestão de Vendas
9. Tecnologia de Produtos
No caso deste modelo de RFI/RFP da TEC para um ERP Mixed-Mode, o segundo nível de
detalhe do grupo de requisitos número 5, relativos à Gestão de Inventário tem um conjunto de
subgrupos, nomeadamente aquele respeitante aos requisitos de "Gestão de Inventário On-
line" (subgrupo 5.1). Este subgrupo contem inúmeros requisitos, onde a título de mero
exemplo, se apresenta o seguinte requisito:
5.1.2 Providenciar capacidade de consulta e elaboração de relatórios para as transações de

inventário por número de item, por localização e por tipo de transação.
Finalmente, para cada característica deverão ser listados os requisitos funcionais detalhados
que lhe estão associados. Estas são as capacidades do software que deverão estar disponíveis
de forma a que o utilizador possa desempenhar os serviços disponibilizados, ou para executar
o “caso de uso”.
Deverá ser incluído como o produto deverá responder antecipadamente a condições de erro
ou inputs errados. Por outro lado, os requisitos deverão ter um conjunto de qualidades,
nomeadamente serem concisos, completos, não ambíguos, verificáveis e necessários. As
qualidades que os requisitos deverão evidenciar serão melhor desenvolvidas à frente.
35
4. Requisitos de interface externo

O capítulo relativamente a requisitos de interfaces externo deverá contemplar as interfaces de
utilizador, de hardware, de software e de comunicação. Em seguida, desenvolve-se um pouco
cada um destes tipos de interfaces a especificar.
a) Interfaces de utilizador
Esta secção descreverá as características lógicas de cada interface entre o software e os
utilizadores. Embora o SRS não seja um documento de desenho, poderá incluir alguns
exemplos de ecrãs e alguns princípios de desenho a seguir, como por exemplo:
• normas GUI (Graphical User Interface),

• estilos de famílias de produtos a ser seguidos,
• restrições de layout,
• tipos de botões a usar (por exemplo o botão para a ajuda),
• atalhos de teclado,
• normas para mensagens de erro,
• assistentes,
• controlos comuns,
• janelas e caixas de diálogo
Schaffer propõe uma estratégia para a definição de uma normalização GUI, assim como um
conjunto de simples princípios de desenho que deverão ser seguidos e de armadilhas a evitar
(Schaffer, 2004).
Figura 22. Ícones da interface de utilizador do Windows XP.
A título de exemplo, a Figura 22 apresenta um conjunto de ícones relativos à interface de

utilizador do sistema operativo Windows XP (Microsoft, 2006).
Deverão ser definidos os componentes do software para os quais é necessário a definição de
interface de utilizador. A seguir ao SRS deverá ser elaborado um documento específico que
especifique e detalhe o desenho do sistema.
b) Interfaces de hardware
Esta secção deverá descrever as características lógicas de cada interface entre o software e
cada componente de hardware do sistema. Poderá incluir:
• dispositivos de armazenamento ou outros

• natureza dos dados e interação de controle entre o software e o hardware
• protocolos de comunicação
36
c) Interfaces de software
Aqui deverão ser descritas as características lógicas e físicas de cada interface entre o software
e outros componentes de software. Poderá incluir:
• Bases de dados a partilhar

• Sistemas operativos
• Ferramentas
• Bibliotecas
• Componentes comerciais integrados
d) Interfaces de comunicação
Propõe-se nesta secção a descrição dos requisitos com qualquer função de comunicação
necessária ao sistema. Apresentam-se os seguintes exemplos:
• E-mail
• Web browser
• Protocolos de comunicação de servidor de rede
• Formulários eletrónicos
Deverão ser identificadas as normas de comunicação a usar, tais como FTP ou HTTP. Deverão
ainda ser identificadas as opções de segurança ao nível da comunicação ou encriptação. Por
exemplo, ao nível da encriptação é popular a utilização do MD5 (Message-Digest algorithm 5)
como algoritmo a usar para verificação de integridade e logins.
5. Requisitos não funcionais

O capítulo relativamente a requisitos não funcionais deverá contemplar os requisitos de
desempenho, de proteção, de segurança e acessos e os atributos de qualidade de software.
Em seguida, apresentam-se cada um destes tipos de requisitos não funcionais a especificar.
a) Requisitos de desempenho
Esta secção deverá estabelecer os requisitos de desempenho a serem considerados no
desenho. Deverão ser estabelecidas as relações temporais a considerar no sistema em tempo
real. Poderá ser necessário estabelecer requisitos de desempenho para requisitos funcionais
individuais. Cada um destes requisitos deverá ser tão específico quanto possível.
É um facto evidente de que se os requisitos do sistema não incluem o desempenho como um
critério enunciado, então, os projetistas de sistemas em geral não considerarão as questões de
desempenho. A fim de avaliar o desempenho de um sistema deverão ser claramente
especificados os seguintes aspetos (Lee, 2012):
• Tempo de Resposta
• Carga de trabalho
• Escalabilidade
• Plataforma
37
No que toca a estes quatro aspetos, que obrigatoriamente se inter-relacionam, o tempo de

resposta é provavelmente a variável mais marcante nos requisitos de desempenho. Eis alguns
limites no que diz respeito a tempos de resposta (Nielsen, 1994):
• 0,1 segundo é o limite para o utilizador ter a sensação de que o sistema está a reagir
instantaneamente, o que significa que nenhum feedback especial é necessário, exceto
a exibição do resultado.
• 1,0 segundo é o limite para o fluxo do pensamento do utilizador não ser interrompido,
mesmo que este venha a notar o atraso. Normalmente, não é necessário nenhum
feedback especial para atrasos superiores a 0,1 mas inferiores a 1,0 segundo, embora
o utilizador deixe de ter a sensação de operar diretamente sobre os dados.
• 10 segundos é o limite para manter a atenção do utilizador focada no diálogo. Para
atrasos maiores, os utilizadores vão querer executar outras tarefas enquanto esperam
que o computador conclua, de modo que deve ser dado feedback indicando quando o
computador espera terminar a tarefa. Alguns comentários durante o atraso são bem
vindos especialmente se o tempo de resposta for suscetível de ser altamente variável,
já que os utilizadores não saberão com que contar.
Exemplo prático
No caso do sistema MEDIGest, apresentam-se alguns exemplos de requisitos de desempenho:
"No suporte a um máximo de 10.000 utentes e à exceção das páginas que dizem respeito
aos dados clínicos, deve-se assegurar que qualquer página deva responder em 90% das
ocasiões em menos de 8 segundos."
"O sistema deve ter menos de 1 hora de inatividade em cada trimestre."
"O sistema deve ser capaz de responder a mais de 100 transações por segundo."
De entre os fatores que influenciam o desempenho, destacam-se os seguintes:

• Hardware (nomeadamente o processador, as memórias, outros dispositivos)
o Servidor
o Cliente
• Comunicação
o Características de bastidores
o Largura de banda na rede local e no acesso à Internet
• Nº de utilizadores em simultâneo
• Algoritmos usados
• Base de dados
• Desenho da interface
A definição dos requisitos de desempenho e o planeamento de uma respetiva solução
adequada, necessitará do envolvimento e da colaboração de distintos "stakeholders" no
projeto, nomeadamente o analista de negócio, o implementador, o gestor da infraestrutura e
o administrador da base de dados.
38
b) Requisitos de segurança contra incidentes aleatórios (Safety)

Esta secção e a seguinte pretendem definir os requisitos de segurança. Ao contrário da língua
portuguesa, a língua inglesa apresenta dois conceitos associados à segurança: safety e security.
Ambos estes conceitos estão associados à proteção dos ativos de riscos ou ameaças, criando
condições de segurança (Albrechtsen, 2003). Por isso, por vezes é difícil distingui-los. No
entanto, existem algumas diferenças assinaláveis entre eles. No essencial, a safety está
associada à segurança contra incidentes aleatórios, enquanto a security está associada à
segurança contra incidentes intencionais. O foco principal do conceito safety está associado
aos incidentes não intencionais. Alguns exemplos clássicos passam por riscos inerentes a
possíveis explosões em indústrias nucleares, explorações petrolíferas ou de gás.
No caso dos requisitos safety para o software dever-se-ão estabelecer os requisitos
relacionados com a possível perda ou danos provocados pelo uso do sistema. Deverão ser
definidas medidas de proteção ou ações a prevenir. Deverão ser referidas políticas externas e
possíveis certificações relacionadas com esta área.
Exemplo prático
Apresenta-se um exemplo de requisito contra incidente aleatório (Safety) para o caso do
sistema MEDIGest:
"SA-1 - O sistema deverá terminar qualquer operação em 5 minutos, avisando os

utilizadores nesse sentido, no caso de ser detetada a falha de abastecimento de energia
elétrica ao servidor proveniente da rede pública."
c) Requisitos de segurança contra incidentes intencionais (Security)

Pode-se definir security como a condição de ser protegido contra incidentes planeados,
maliciosos e criminais numa ampla gama de ameaças, onde o que se pretende proteger são
todos os tipos de valores duma organização ou indivíduo e onde os incidentes acontecem
devido ao desejo de uma consequência para o atacante (Albrechtsen, 2003).
Esta secção deverá estabelecer os requisitos relacionados com segurança ou privacidade dos
dados. Deverá definir os requisitos de autenticação de utilizador e deverá referir as políticas
externas relacionadas com esta área. Igualmente deverão ser indicadas as certificações desta
área.
Exemplo prático
Apresentam-se alguns exemplos de requisitos do MEDIGest contra incidentes intencionais:
"SE-1 Cada utilizador deverá mudar a sua senha de acesso imediatamente a seguir a ter feito
o seu primeiro login bem sucedido."
"SE-2 O sistema deverá desligar um acesso após ocorrerem 5 minutos de inatividade no

sistema por parte dum utilizador."
"SE-3 O sistema não deverá permitir dois nomes de utilizador iguais."
39
d) Atributos de qualidade do software

Esta secção deverá estabelecer os requisitos adicionais relacionados com qualidade
eventualmente importantes para clientes ou implementadores. Não se deverá confundir os
atributos de qualidade do software que se pretendem abordar nesta secção com a qualidade
dos requisitos de software que é uma questão diferente.
Alguns atributos de qualidade do software são mais relevantes para os utilizadores, enquanto
outros são mais importantes para os implementadores. A Tabela 5 apresenta um conjunto de
atributos de qualidade do software com esta separação (Wiegers, 1999).
Atributo mais relevante Atributo mais relevante
para os utilizadores para os implementadores
disponibilidade manutenibilidade
eficiência portabilidade
flexibilidade reusabilidade
integridade testabilidade
interoperabilidade
fiabilidade
robustez
usabilidade
Tabela 5. Atributos de qualidade do software. Adaptado de Wiegers (2009).
Apresentam-se em seguida alguns conceitos e aspetos importantes relativos a cada um destes

atributos.
A disponibilidade é a medida do tempo previsível durante o qual o sistema está disponível para
utilização e completamente operacional (Wiegers, 1999). Os requisitos de disponibilidade
poderão especificar os fatores que garantam o nível de disponibilidade pretendido para todo o
sistema, referindo aspetos como por exemplo os pontos de inspeção (checkpoint),
recuperação ou reinício.
Um requisito de disponibilidade poderá ser o seguinte:
"DS-1 O sistema deverá estar disponível pelo menos 99.5% do tempo em todos os dias úteis,
de 2ª a 6ªFeira, das 8h00 às 18h00."
A eficiência é a medida do quão bem o sistema usa a capacidade do processador, a capacidade

do disco, de memória ou de largura de banda (Davis, 1993). A eficiência está relacionada com
o desempenho. Muitas vezes, em momentos de pico de utilização, o desempenho do sistema
degrada-se e por exemplo, os utilizadores poderão demorar muito tempo para fazer uma
determinada consulta à base de dados. A especificação de caraterísticas mínimas de hardware
permitirá obviar situações como estas (Wiegers, 1999).
Um requisito de eficiência poderá ser o seguinte:
"EF-1 O processador deverá estar no máximo a ser utilizado a 75% nos momentos de maior
pico de utilização."
40
A flexibilidade é um atributo que é muitas vezes associada à extensibilidade, à escalabilidade

ou à expansibilidade (Wiegers, 1999). Mede a facilidade com que se poderão adicionar novas
capacidades ao produto. Este atributo é muito pertinente, em especial para os casos de
projetos desenvolvidos incremental ou iterativamente, onde existem um conjunto de diversas
versões do produto.
Um requisito de flexibilidade poderá ser o seguinte:
"FL-1 - Um programador de manutenção, com pelo menos 6 meses de experiência no suporte

ao produto, deverá ser capaz de lhe disponibilizar uma nova impressora, incluindo as
modificações ao código e os respetivos testes, em menos de uma hora de trabalho."
A integridade está associada com a prevenção de perda de informação e com a privacidade

dos dados. Relaciona-se com o atributo segurança contra incidentes intencionais (Security).
Algumas das grandes preocupações a este nível são as de que o sistema está protegido contra
acessos indevidos e contra infeções provocadas por vírus. Por exemplo, num sistema acessível
via Web é fundamental que existam garantias de que os dados associados aos cartões de
crédito estão devidamente protegidos (Wiegers, 1999).
Um requisito de integridade poderá ser o seguinte:
"IN-1 - Para além do próprio utente, apenas os utilizadores com o perfil de médico desse
utente poderão consultar o seu respetivo historial clínico."
O atributo interoperabilidade indica o quanto o sistema consegue trocar dados ou serviços

com outros sistemas. De forma a medir a interoperabilidade de um sistema é preciso saber
quais os sistemas com os quais será expectável que ele venha a interagir (Wiegers, 1999).
Um requisito de interoperabilidade poderá ser o seguinte:
"IO-1 - O sistema deverá ser capaz de importar os horários dos médicos que estejam
carregados no sistema de gestão de acessos da clínica."
A fiabilidade pode ser definida como a probabilidade que o software tem de trabalhar sem
falhas durante um determinado período específico (Musa et al., 1987). Duas formas de medir a
fiabilidade dum software são a percentagem de operações completas bem sucedidas e o
tempo médio que o software dura sem que ocorra uma falha (Wiegers, 1999).
Um requisito de fiabilidade poderá ser o seguinte:
"FI-1 - Em média, o sistema deverá ser capaz de trabalhar 24 horas sem que ocorra uma
falha."
A robustez é um conceito que está intimamente ligado com a tolerância a falhas. Pode ser
definido como a capacidade que um sistema tem de continuar a trabalhar bem no caso de
inputs, ligações defeituosas de componentes de software ou hardware, ou condições de
operação inesperadas (Wiegers, 1999). Softwares robustos recuperam elegantemente de
situações problemáticas, sendo muito tolerantes a erros de utilização.
41
Um requisito de robustez poderá ser o seguinte:
"RO-1 - No caso de uma falha de energia, o sistema deverá ser capaz de recuperar os dados
que não foram previamente gravados, até 5 minutos antes da falha, da próxima vez
que o utilizador reinicie o programa."
A usabilidade pode ser definida como a medida na qual um produto pode ser usado por
utilizadores específicos para alcançar objetivos específicos com eficácia, eficiência e satisfação
num contexto específico de uso (ISO, 1998). A complexidade deste conceito liga-o a outros
conceitos como a capacidade de aprendizagem, a eficiência, a capacidade de memorização, a
fiabilidade ou a satisfação do utilizador (Nielsen, 1994).
Um requisito de usabilidade poderá ser o seguinte:
"US-1 - Em média, um médico experiente no sistema deverá ser capaz de introduzir os dados
clínicos relativos a uma consulta num máximo de 5 minutos."
A manutenibilidade indica a facilidade com que se corrige um problema ou se faz uma

modificação ao software (Wiegers, 1999). Relaciona-se com a facilidade com que o software é
entendido, mudado e testado. É um conceito intimamente relacionado com a testabilidade e a
flexibilidade. Métricas frequentemente usadas para a manutibilidade passam por medir o
tempo médio necessário para corrigir um problema ou a percentagem de correções feitas
adequadamente.
Alguns requisitos de manutenibilidade poderão ser os seguintes:
"MA-1 Em média, um programador deverá ser capaz de modificar um relatório para ser
conforme com novas necessidades, com um máximo de 20 horas de trabalho de
desenvolvimento."
"MA-2 Em cada módulo do software, o rácio de linhas de comentário face às linhas de código
deverá ser, no mínimo, de 50%."
A portabilidade é o esforço necessário para migrar uma parte do software de um ambiente

operativo para outro diferente (Wiegers, 1999). Algumas das questões associadas à
portabilidade estão ao nível do desenho da aplicação. Por exemplo, requisitos que digam
respeito à portabilidade, devem especificar atributos de software que se relacionam com a
facilidade de portar o software para outras máquinas anfitriãs ou outros sistemas operativos
(IEEE, 1998a). Isto pode incluir o seguinte:
• Percentagem de componentes com código dependente do computador anfitrião;
• Percentagem de dependente do computador anfitrião;
• Utilização de uma linguagem comprovadamente portátil;
• O uso de um compilador especial ou um subconjunto duma linguagem;
• O uso de um determinado sistema operativo.
A reusabilidade é o esforço relativo necessário para converter um componente do software de
forma a que possa ser usado noutra aplicação (Wiegers, 1999). A reusabilidade obriga a que o
42
respetivo componente de software seja modular, bem documentado, independente duma

aplicação específica ou de um ambiente operativo e de alguma forma genérico na sua
aplicação. Normalmente a reusabilidade é um atributo difícil de quantificar.
Um requisito de reusabilidade poderá ser o seguinte:
"RU-1 O módulo de gestão de acessos deverá ser desenhado de forma a ser reutilizável por
outras aplicações ao nível do objeto de código."
Por fim, a testabilidade refere à facilidade com que um determinado componente de software
ou o produto integrado pode ser testado contra defeitos (Wiegers, 1999). A testabilidade é
tanto mais crítica, quanto a complexidade dos algoritmos ou da lógica usada, ou ainda das
inter-relações funcionais existentes.
Um requisito de testabilidade poderá ser o seguinte:
"TE-1 As mensagens de log devem incluir timestamps e identificar o subsistema que os

produziu."
Embora existam muitos requisitos de qualidade, na maior parte dos softwares apenas alguns
destes atributos são usados para definir requisitos.
6. Outros tipos de requisitos

Existe um conjunto de outros requisitos importantes que deverão ser considerados. Um desses
exemplos são as restrições. As restrições são requisitos impostos sobre a solução, devido às
circunstâncias, uma obrigatoriedade, uma determinada imposição externa ou interna. As
restrições limitam as opções em aberto aos implementadores de uma solução através da
imposição de fronteiras e limites intransponíveis. As restrições são requisitos que se podem
situar na categoria dos requisitos funcionais ou dos não funcionais (IEEE, 1998b).
Outros importantes tipos de requisitos podem ainda ser destacados, nomeadamente os
seguintes (Wiegers, 1999):
• Requisitos internacionais do tipo formato de moeda, data, língua, regulamentos

internacionais, questões culturais ou políticas
• Requisitos de instalação ou configuração
• Requisitos de arranque ou de encerramento
• Tolerância a falhas
• Monitorização de operações
7. Apêndices
Aconselha-se a inclusão de alguns apêndices no SRS, nomeadamente:
• Glossário
• Modelos de análise
• Lista de questões
43
O glossário deverá definir um conjunto de termos especializados que são fundamentais para
que o leitor entenda o SRS. No entanto, cada SRS apenas deverá conter os termos específicos
absolutamente necessários a esse documento. Poderá também ser definida uma secção com
abreviações e acrónimos.
Aconselha-se o uso de um apêndice para apresentação de alguns modelos de análise de
requisitos. Embora possa ser oportuno a modelação com diagramas de fluxos de dados ou
casos de uso ao longo do SRS, outros modelos poderão ser anexados no final, tais como,
modelos complementares do tipo DFD ou de casos de uso, dicionário de dados, dicionário de
processos, diagramas de classes, diagramas de transição de estados, diagramas de relação de
entidades, tabelas de decisão, árvores de decisão ou mapas de diálogo. Contudo, como foi
anteriormente referido, esta lição não tem como objetivo o estudo aprofundado destas
técnicas de modelação.
Uma boa prática consiste na elaboração de um apêndice com uma lista de questões. Esse
anexo consistirá numa lista dinâmica de questões que ainda não foram decididas. Podem
catalogar-se como TBD (“To Be Determined”). O objetivo é o seu registo, de forma a que
oportunamente se tome uma decisão sobre cada uma dessas questões. Poderá também
incluir-se uma descrição da informação que ainda é necessária.
C. Outros aspetos relacionados com a especificação de requisitos
1. A organização dos requisitos

Um SRS é considerado organizado se e só se o seu conteúdo estiver disposto de forma a que os
seus leitores possam facilmente localizar a informação e ainda se as relações lógicas entre
secções adjacentes é óbvia (Davis et al., 1993). Uma das formas de o fazer é seguindo um dos
modelos de SRS propostos. O que se tem sugerido nesta lição é essencialmente o proposto no
capítulo anterior com base na sugestão de Wiegers (1999). As diferenças mais significativas
têm a ver com os requisitos funcionais detalhados A secção III.B.3 apresentada anteriormente
nesta lição, denominada por "Características do sistema", exemplificou uma abordagem por
grupos de caraterísticas funcionais. Tal como foi referido nessa secção, para além da divisão
por características funcionais, existem outras alternativas de organização deste capítulo,
nomeadamente as seguintes:
• classes de utilizador,
• classes de objeto,
• casos de uso,
• modo de operação,
• combinações destas várias alternativas,
Cada tipo de sistema a especificar terá provavelmente uma forma de organização mais
adequada.
Por exemplo, o caso de um sistema de controle de um elevador poderá dividir a secção III do
SRS com base nas classes de utilizador, com uma secção III.1 que especificará os requisitos
para todos os passageiros, uma secção III.2 para os bombeiros e uma secção III.3 para o
pessoal da manutenção (Davis et al., 1993).
44
No caso de um sistema para gerir reservas aéreas, provavelmente o mais adequado seria
dividir a secção III do SRS com base nas classes de objetos. Poderia ser dividido numa secção
III.1 com o conjunto de requisitos funcionais relativos aos lugares, numa secção III.2 com os
requisitos de segmentos de voos, numa secção III.3 com os requisitos para os agentes de
viagens, numa secção III.1 para os bilhetes, etc. (Davis et al., 1993).
Os casos de uso descrevem uma sequência de interações entre o sistema e um ator externo
(Wiegers, 2009). Normalmente existem cenários normais e outros eventuais cenários
alternativos (cenários secundários). Por exemplo, um sistema de pagamento de salários
poderia ter uma secção III.1 para os requisitos relacionados com a geração mensal de cheques
para pagamentos de salários, uma secção III.2 para a geração de um relatório geral com a
informação de todos os salários mensais pagos a cada funcionário, etc. (Davis et al., 1993).
Para além destes tipos de organização de um SRS, ainda é frequente usar a organização por
modo de operação ou seja, por tipo de estímulo. Imagine o caso de um sistema automático de
aterragem de um helicóptero. Neste caso, a secção III.1 poderia ter os requisitos para tipos de
ventos, a secção III.2 os requisitos relacionados com a falta de combustível, a secção III.3 os
requisitos relativos com a falha nas mudanças de aterragem, etc. (Davis et al., 1993).
A norma IEEE 830 (1998) propõe ainda alguns modelos específicos para cada uma destas
formas alternativas de organização.
2. Qualidades dos requisitos de software

Segundo Wiegers (1999), a qualidade dos requisitos de software depende se estes têm um
conjunto amplamente completo de características. De entre as caraterísticas que os requisitos
deverão ter, destacamos as seguintes:
• Corretos
• Viáveis, exequíveis ou alcançáveis
• Necessários
• Priorizados
• Precisos
• Verificáveis
• Consistentes
• Abstratos ou independentes do desenho
• Atomicidade
Cada requisito de software deverá descrever corretamente a funcionalidade a ser entregue.

Por outro lado, no caso de um requisito de software não estar coerente com os requisitos de
sistema ou com as necessidades dos utilizadores então não pode ser considerado correto. Uma
verdadeira avaliação da correção dos requisitos dos utilizadores apenas pode ser feita por
estes (Wiegers, 1999).
A viabilidade de um requisito depende da possibilidade deste ser implementado, tendo em

atenção as capacidades e limitações existentes. Consequentemente, para uma adequada
avaliação da viabilidade de cada requisito, deverão ser envolvidos os desenvolvedores, que
analisarão os requisitos não só do ponto de vista técnico, mas também quanto ao seu custo e
45
ao tempo envolvido (Wiegers, 1999). A viabilidade depende ainda se é possível implementar

um requisito quer em termos da fase de desenho do software, quer nas fases seguintes, como
a operação ou a manutenção (IEEE, 1998a). Quando se estabelecem metas inatingíveis, o
melhor resultado que se pode esperar é passar a ter uma equipa frustrada (Sehlhorst, 2006).
A necessidade de um requisito depende duma necessidade realmente manifestada pelos

utilizadores ou duma necessidade dum requisito externo, uma interface externa ou uma
norma obrigatória. A necessidade dum requisito poderá ser validada fazendo a sua
traçabilidade até à origem que a justifica, quer seja um caso de uso, um requisito de sistema,
um regulamento, ou qualquer outra entrada da parte do cliente. Se isso não conseguir ser feito
é sinal de que o requisito não é realmente necessário (Wiegers, 1999).
A priorização de cada requisito é essencial para indicar a importância que tem a sua inclusão
numa determinada versão do produto. O envolvimento dos clientes é importante para o
estabelecimento de cada prioridade. O objetivo passa por diferenciar as várias priorizações dos
requisitos. Para o estabelecimento de cada prioridade dever-se-á atender não só ao valor
acrescentado ao cliente, mas também ao custo da implementação e ao risco relativo associado
à implementação (Wiegers, 1999).
Um leitor de um requisito deverá ter apenas um entendimento sobre este. A precisão

dependerá ainda de outros leitores terem também a mesma interpretação do requisito. Os
requisitos de software são normalmente escritos em linguagem natural. Contudo, a linguagem
natural tem uma tendência para a ambiguidade. Dever-se-á evitar palavras como "amigável",
"fácil", "simples", "rápido", "eficiente", "estado da arte", "melhorado", "maximizado" ou
"minimizado". Para reduzir a possível ambiguidade da utilização da linguagem natural, a sua
especificação pode ser complementada por descrições formais ou semiformais. A seleção de
notações adequadas permite que requisitos específicos e certos aspetos da arquitetura do
software possam ser descritos de uma forma mais precisa e concisa do que através da
linguagem natural (Wiegers, 1999, IEEE, 1998a).
A verificabilidade de cada requisito depende se este pode ser posteriormente testado. Na

prática a verificabilidade dependerá de se poderem desenhar testes que comprovem
posteriormente se cada requisito foi adequadamente implementado. Requisitos que não são
consistentes, viáveis ou precisos também não são verificáveis (Wiegers, 1999).
A consistência de um requisito de software implica que este deva estar relacionado com
alguma das necessidades da aquisição (ISO and IEC, 2008). Deverá ser possível estabelecer
uma relação direta de cada requisito de software com cada requisito de negócio. Se tal não for
possível, então, provavelmente esse requisito não é necessário. Este conceito está também
relacionado com o conceito de rastreabilidade.
A abstração é um atributo realçado pela norma internacional IEEE 830, afirmando que cada
requisito deve ter a característica de ser independente da respetiva implementação (IEEE,
1998a). Genericamente, um requisito não deverá especificar nenhuma opção de desenho ou
de implementação. Cada requisito deverá ter o detalhe necessário, sem contudo condicionar a
equipa de desenvolvimento no seu trabalho (Sehlhorst, 2006).
46
O atributo atomicidade está associado à granularidade do requisito. Cada requisito que se

escreve representa uma necessidade única do mercado, que satisfaz ou não satisfaz. Um
requisito bem escrito é entregue independentemente de outros e representa um incremento
no valor do software. Escrever requisitos atómicos ajuda a organizar e a descrever porque se
está a pedir à equipa o que estão a implementar; como os interessados irão beneficiar do que
está a ser implementado; a compreender o valor atribuível a cada requisito, tornando mais
claro na árvore de dependências de requisitos as razões específicas porque cada requisito está
ali; a facilitar as discussões sobre inevitáveis alterações de requisitos numa lógica custo-
benefício; a classificar os testes como aprovado-reprovado e não como "X % a funcionar"
(Sehlhorst, 2006).
Exemplo prático
Um exemplo de requisito impreciso ou ambíguo que impedirá a sua verificabilidade poderá ser
o seguinte (Japenga, 2003):
"O sistema deverá responder rapidamente ao utilizador "
Em vez disso, dever-se-á especificar o requisito através duma abordagem quantitativa, de

forma a que possa ser posteriormente testado sem margem para diferentes interpretações.
Por exemplo, uma alternativa à anterior especificação de requisito poderá ser a seguinte:
"O sistema não deverá demorar mais de 100 milissegundos a responder a qualquer toque
em tecla ou no rato por parte do utilizador"
Ainda, relativamente à verificabilidade, um outro bom exemplo de requisito que não valerá a
pena especificar pelo seu elevado custo de teste é o seguinte (Davis et al., 1993):
"No caso do reator derreter, o sistema deverá reduzir o número de mortes no pessoal em
pelo menos 80% num raio de 20 milhas"
Existe também um conjunto de indicadores de qualidade que têm vindo a ser desenvolvidos e
que pode ser usado para relacionar a qualidade da especificação de requisitos de software
com outras variáveis do projeto, tal como custo, aceitação, desempenho, planeamento,
reprodutibilidade, etc. Os requisitos têm outros atributos para além das suas características
comportamentais. Por exemplo, para além da inclusão duma ordem de priorização poderá ser
avaliada se a etiquetagem é adequada.
3. Boas práticas e dicas para escrever bons requisitos

De acordo com norma IEEE 1233, um requisito bem especificado é uma declaração duma
funcionalidade do sistema (uma capacidade) que pode ser validada, que deve ser cumprida ou
possuída por um sistema para resolver um problema do cliente ou para alcançar um objetivo
do cliente, e que é qualificado por condições mensuráveis e limitada por restrições (IEEE,
1998b).
Embora a especificação de requisitos se auxilie de técnicas de modelação que a complementa

e valoriza, os requisitos são na sua maioria especificados usando a linguagem natural. No
47
entanto, a essência da linguagem natural exige um conjunto de cuidados aquando da

especificação de requisitos. Existe um conjunto de boas práticas e dicas para escrever
requisitos com qualidade, algumas com um enfoque especial num atributo específico, outras
pretendendo contribuir para a qualidade segundo diversos atributos: Em seguida, apresentam-
se algumas dessas sugestões:
• Mantenha as frases e os parágrafos curtos (Wiegers, 1999).

• Use o presente como tempo verbal (Wiegers, 1999).
• Use adequadamente a gramática, a expressão e a pontuação (Wiegers, 1999).
• Use uma linguagem específica e inequívoca (Herrington, 2007).
• Siga o mais rigorosamente possível as expressões exatas usadas pelo negócio.
• Organize os termos específicos num dicionário de dados ou num glossário e utilize-os
consistentemente (Wiegers, 1999).
• Tente sentir a perspetiva do desenvolvedor, acrescentando mentalmente a frase
"Chame-me quando terminar" no final do requisito. Verifique se essa questão o deixa
confortável ou se pelo contrário, lhe faz manifestar dúvidas e necessidade de novos
esclarecimentos e assim, de uma reelaboração (Wiegers, 1999).
• Na especificação duma obrigatoriedade por parte dum requisito do software use o
verbo "dever" e nas permissões use o verbo "poder" (ISO and IEC, 2008).
• Evite parágrafos com uma longa narrativa que provavelmente contêm vários requisitos
(Wiegers, 1999).
• Evite requisitos com restrições desnecessárias (IEEE, 1998b).
• Se conseguir pensar num número pequeno de testes para verificar a correta
implementação dum requisito, então, provavelmente o nível de detalhe está
adequado. Se pelo contrário, consegue imaginar diversos tipos de testes,
provavelmente vários requisitos foram agrupados num e deverão ser separados
(Wiegers, 1999).
• O uso de conjunções como "e" ou "ou" num requisito indicia que diversos requisitos
foram combinados. Nunca use estas conjunções (Wiegers, 1999).
• Decomponha um requisito vago de alto nível em detalhe suficiente de forma a
clarificá-lo e a retirar-lhe ambiguidade (Wiegers, 2009).
• Evite estabelecer requisitos redundantes no SRS (Wiegers, 1999).
• Apesar de a repetição de requisitos em locais distintos do SRS permitir uma leitura
mais fácil deste documento, também fará com que a sua manutenção seja mais difícil.
No caso de haver vários requisitos repetidos, a sua atualização tem de ser feita ao
mesmo tempo, aumentando a probabilidade de problemas a esse nível (Wiegers,
1999).
• Evite palavras abertas ou frases excessivamente gerais, tais como "algum", "qualquer",
"a maior parte", "usualmente" (Herrington, 2007), ou ainda "incluindo, mas não
limitado a..." (IEEE, 1998b).
• Não deixe para os programadores a definição do que é exequível. Por exemplo, não
use a expressão "tanto quanto possível". É preferível especificar um TBD (To Be
Determined) e estabelecer uma data limite para essa definição (Wiegers, 1999).
48
• Evite frases subjetivas ou vagas, tais como "aceitável" ou "adequado" (Wiegers, 1999)
ou ainda como "amigável", "tempo de resposta rápido" ou "rentável" (IEEE, 1998b).
• Evite requisitos baseados em assunções não documentadas (IEEE, 1998b).
• Pergunte-se continuamente se pode testar o cumprimento do requisito (Herrington,
2007).
• Pergunte-se como poderá depois fazer alguns testes ao requisito (Herrington, 2007).
• Assim que se aperceba que está a atrasar a especificação de parte dum requisito, isso
representará aviso claro de que o requisito não é atómico.
• Peça que alguém independente reveja o SRS de forma a poder identificar e corrigir o
eventual uso ambíguo da linguagem (IEEE, 1998a).
A qualidade de cada requisito poderá também ser procurada obviando diversos dos potenciais
problemas que poderão ocorrer.
Potencial problema Observações

Desenho prematuro do O requisito inclui informação prematura sobre o design ou a
sistema implementação).
Combinação de A descrição do requisito descreve um único requisito ou pode ser
requisitos dividida em diferentes requisitos.
Requisitos O requisito é apenas uma adição “cosmética” ao sistema.
desnecessários
Utilização de hardware Para esta decisão é necessário saber os requisitos da plataforma a
não-normalizado suportar.
Conformidade com os O requisito é consistente com os objetivos do negócio definidos na
objetivos de negócio introdução do documento de requisitos.
Requisitos ambíguos O requisito pode ser lido de formas diferentes por diferentes
pessoas. Quais as possíveis interpretações?
Requisitos realistas O requisito é realista tendo em conta a tecnologia a ser usada para
implementar o sistema.
Requisitos “testáveis” Os engenheiros de teste podem derivar um teste a partir da
descrição do requisito que mostre que o sistema satisfaz esse
requisito).
Tabela 6. Lista de potenciais problemas dos requisitos a controlar.
A Tabela 6 apresenta um conjunto de alguns desses potenciais problemas.
49
Exemplo prático
Vejamos o seguinte exemplo de especificação de um requisito de software (Wiegers, 1999):
"O produto deverá fornecer mensagens de estado em intervalos de tempo regulares não
inferiores a 60 segundos"
Este requisito pode-se considerar incompleto já que não se sabe quais são as mensagens de
estado a que se refere. Por outro lado, também se considera ambíguo, já que não se sabe
exatamente de que parte do produto se está a falar ou o intervalo de tempo adequado. Será
razoável apresentar uma mensagem de estado de 10 em 10 anos? Qual a duração de cada
mensagem? Como resultado destes problemas, o requisito também não é verificável.
De forma a obviar estes problemas, apresenta-se uma nova proposta de especificação deste
requisito:
"1. Mensagens de Estado.

1.1 O gestor de tarefas em segundo plano deverá mostrar mensagens de estado em área
designada da interface de utilizador em intervalos de 60, mais ou menos 10 segundos.
1.2 Se o processamento da tarefa de fundo está a progredir normalmente, deverá ser
mostrada a percentagem de conclusão da tarefa.
1.3 A mensagem deverá ser mostrada quando a tarefa de fundo está concluída.
1.4 Uma mensagem de erro deverá ser exibida se a tarefa de fundo encravou."
A proposta de "multiplicação" da versão inicial do requisito em vários requisitos justifica-se,
por um lado, com a necessidade de cada um dos novos requisitos precisar de testes distintos e,
por outro lado, pela necessidade de cada um deles ser autonomamente rastreáveis. Ainda, se
vários requisitos são acorrentados num único parágrafo, então não existe a granularidade
suficiente, sendo mais fácil esquecer um deles durante a fase de implementação ou de testes.
Com base na lista de potenciais problemas associados à qualidade dos requisitos poder-se-á
efetuar na prática um controle que usa uma tabela de dupla entrada para inspecionar se cada
requisito (colocado em coluna) cumpre cada atributo de qualidade (colocado em linha).
A Tabela 7 apresenta uma parte do conjunto de requisitos de software dum determinado

produto cuja qualidade se pretende controlar. As colunas dessa tabela indicam as etiquetas
associadas a cada requisito e as linhas apresentam os atributos segundo os quais esse controle
pretende ser feito. O conteúdo de cada célula que cruza cada requisito com cada atributo tem
o resultado da avaliação da qualidade desse requisito segundo esse atributo de qualidade.
Por exemplo, a abordagem para conferência apresentada neste exemplo mostra facilmente
que o requisito 01 oferece um conjunto de atributos de qualidade que cumpre
adequadamente, nomeadamente o facto da sua prioridade estar definida, do requisito não
corresponder a desenho prematuro, de ser necessário, de ser viável e deste ser testável.
50
Req 01
Req 02
Req 03
Req 04
Req 05
Req 06
Req 07
Req 08
Req 09
Atributo
Requisito com prioridade definida

Requisito sem desenho prematuro
Requisito único
Requisito necessário
Usa apenas hardware normalizado
De acordo com os objetivos do negócio
Requisito preciso
Requisito viável
Requisito testável
Tabela 7. Exemplo de conferência da qualidade numa amostra de requisitos de software.
No entanto, este controle detetou que o requisito deverá ser corrigido já que este tem alguns
problemas. Por um lado, deverá ser provavelmente desdobrado já que identifica não um, mas
vários requisitos em simultâneo. Por outro lado, foi detetada a necessidade de utilização de
hardware não normalizado e cujas implicações deverão ser adequadamente avaliadas.
Também aparenta não estar de acordo com os objetivos de negócio. Por fim, a sua redação e
pormenorização necessita de ser revista, pelo que o requisito é classificado como impreciso.
4. Qualidades do documento SRS

Tal como foi referido anteriormente, os requisitos podem ser de diferentes tipos podendo
corresponder não só a uma especificação funcional e de capacidade (incluindo desempenho,
características físicas, condições ambientais de funcionamento), mas também a uma
especificação de interfaces externos ao sistema, a especificação de requisitos de qualificação,
a especificações de segurança externa, a especificações de segurança interna, a especificações
ergonómicas, a definições de dados e requisitos de base de dados, a requisitos de instalação e
aceitação, a requisitos de documentação de utilizador, a requisitos de operação e execução ou
a requisitos de manutenção (ISO and IEC, 2008). Todos estes requisitos, em conjunto,
contribuem para um documento que denominamos de SRS. Em consequência, um documento
deste tipo deverá também ter um conjunto de atributos (alguns deles em consequência dos
conceitos anteriormente desenvolvidos relativos aos atributos dos requisitos), dos quais
destacamos os seguintes (Wiegers, 1999, IEEE, 1998b, IEEE, 1998a):
• Completude
• Consistência
• Modificabilidade
• Rastreabilidade ou traçabilidade
• Verificabilidade
Um SRS é completo se, e somente se, ele inclui todos os requisitos significativos, quer em
matéria de funcionalidade, desempenho, restrições de desenho, atributos ou interfaces
externas. Em particular, deverá ser reconhecida e tratada qualquer exigência externa imposta.
51
Ainda, deverá incluir a definição das respostas do software para todas as classes de dados de
entrada em todas as situações possíveis de acontecer. Por fim, a sua completude só será plena
se os rótulos e referências de todas as figuras, tabelas e diagramas no SRS estiverem
completos e se estiverem definidos todos os termos e unidades de medida usados (IEEE,
1998a).
Se um SRS não está de acordo com algum documento de nível superior, como uma
especificação de requisitos do sistema, então não é internamente consistente (IEEE, 1998a).
Pode-se ainda acrescentar que a consistência deverá igualmente acontecer dentro do próprio
SRS. Por exemplo, os diferentes níveis de especificação que vão sendo apresentados ao longo
do documento deverão ser coerentes entre si.
A modificabilidade de um SRS acontece se, e somente se, a sua estrutura e estilo são tais que
quaisquer mudanças nos requisitos possa ser feita facilmente, completamente e de forma
consistente, mantendo a estrutura e estilo. Geralmente requer-se que um SRS tenha uma
organização coerente e fácil de usar, com uma tabela de conteúdo, índice e referências
cruzadas explícitas, não seja redundante (ou seja, a mesma exigência não deve aparecer em
mais de um lugar no SRS) e que expresse cada requisito separadamente, em vez de misturá-los
com outros requisitos.
Um SRS é rastreável (ou traçável) se a origem de cada um dos seus requisitos é clara e se
facilita a referência de cada requisito no desenvolvimento futuro ou documentação acessória.
Recomendam-se dois tipos de rastreabilidade: para trás e para a frente. A rastreabilidade para
trás (ou seja, para estágios anteriores de desenvolvimento), depende de cada requisito
referenciar explicitamente a sua origem em documentos anteriores. A rastreabilidade para a
frente (ou seja, a todos os documentos derivados do SRS), depende de cada requisito no SRS
ter um único nome ou número de referência. Quando os documentos de implementação e de
desenho são modificados, é essencial ser-se capaz de determinar o conjunto completo de
requisitos que podem ser afetados por essas modificações. Mais, esta rastreabilidade é
particularmente importante quando o software entra na fase de operação e manutenção. Este
conceito é um pouco mais desenvolvido numa secção posterior.
Um SRS verificável deve ter técnicas disponíveis, com um custo aceitável, que podem ser
usadas para verificar que todas as necessidades especificadas serão satisfeitas pelo sistema
quando este estiver construído. A verificação de requisitos pode-se tornar difícil se os
requisitos forem ambíguos, pois interpretações diferentes poderão ocorrer. Além disso,
requisitos indecidíveis, como "o sistema nunca deve parar", não são verificáveis. Finalmente,
alguns requisitos não devem ser especificados porque eles não valem o custo dos seus testes
(Davis et al., 1993).
5. A priorização dos requisitos de software

Embora a questão da priorização já tenha sido abordada, quer ao nível das principais
caraterísticas estabelecidas na secção "Visão e Âmbito do Sistema" do SRS, quer ao nível mais
detalhado dos requisitos de software, a sua importância justifica uma abordagem mais
detalhada.
52
A qualidade dum produto de software é muitas vezes determinada pela capacidade em

satisfazer as necessidades dos clientes e dos utilizadores. Atendendo que a maioria dos
projetos de software tem mais requisitos candidatos do que aqueles que serão possíveis de
realizar no tempo e com as restrições de custos existentes, a priorização ajudará a identificar
os requisitos mais valiosos desse conjunto, distinguindo os mais críticos dos mais triviais
(Berander and Andrews, 2005).
Entre outros aspetos, o processo de priorização permitirá:
• às partes interessadas uma decisão sobre os requisitos essenciais para o sistema

• uma ordenação e a escolha do conjunto ótimo de requisitos para a implementação nas
sucessivas versões do produto
• a negociação do desejado âmbito do projeto face a restrições antagónicas como o
tempo de desenvolvimento, o orçamento, os recursos, o tempo para a comercialização
e a qualidade
• o balanceamento do benefício para o negócio de cada requisito face ao seu custo
As principais técnicas para a priorização de requisitos de software são as que se listam em

seguida (Berander and Andrews, 2005):
• Processo de hierarquização analítica

• Teste dos cem dólares
• Ranking
• Agrupamento
• Top 10
O processo de hierarquização analítica (do inglês Analytical Hierarchy Process, associado à sigla
AHP) é um método de tomada de decisão sistemática de priorização de requisitos de software
que resulta da comparação de todos os pares possíveis de requisitos classificados
hierarquicamente, de forma a determinar qual requisito num par tem a prioridade maior e
também qual a grandeza da diferença entre ambos os dois requisitos desse par. Para medir a
diferença da importância entre dois requisitos pode-se usar uma escala de 1 a 9, onde 1
representa prioridade igual e 9 representa extremamente mais importante. Considerando n o
número de requisitos num determinado nível hierárquico, o número total de comparações que
tem de se executar com o AHP é de: n x (n-1)/2 . Um número de requisitos muito grande
praticamente inviabiliza este método, dado o número de comparações que tem de se efetuar.
O resultado obtido com este método é uma lista ponderada numa escala do tipo rácio. No caso
de se usar uma escala de 1 a 9 para comparar cada par, o valor ponderado de prioridade para
cada requisito implicará também uma escala de 1 a 9.
O teste dos 100 dólares é uma técnica muito simples que resulta de se pedir às partes
interessadas que imaginem que cada um tem 100 dólares para distribuir pelos requisitos. O
resultado obtido com este método é igualmente uma lista ponderada numa escala do tipo
rácio. Por exemplo, se existirem 25 requisitos, existirá uma média de 4 dólares para distribuir
por cada requisito. No caso de haver muitos requisitos, poderá optar-se por aumentar o valor
fictício a usar por cada um dos participantes para, por exemplo, 1.000 ou 10.000 dólares.
53
Contudo, alguns participantes podem querer influenciar a priorização final dos requisitos,
valorizando excessivamente os requisitos que lhes são mais desejáveis. Para obviar estas
situações, poderá ser definido um limite de valor investido por cada participante num
requisito, de forma a não enviesar excessivamente a prioridade final.
A forma de priorização mais usual é a classificação numérica ou agrupamento, sendo

nomeadamente esta a técnica indicada na norma IEEE 830 (IEEE, 1998a). Esta abordagem
baseia-se no agrupamento dos requisitos em diferentes grupos de priorização. Embora, seja
possível conceber diversos grupos, é usual o uso de três grupos de priorização. Por exemplo,
aconselha-se o uso dos grupos crítico, normal e opcional. Em contraste, desaconselha-se o uso
dos grupos alto, médio e baixo, já que estes termos poderão confundir mais os participantes,
pelas possíveis diferentes interpretações que estes possam ter do que significa de alto, médio
e baixo. De forma a evitar uma tendência habitual dos participantes classificarem a grande
maioria dos requisitos como sendo de prioridade crítica ou mesmo normal, poder-se-á
estabelecer uma regra que limite uma proporção mínima de requisitos em cada um dos três
grupos (por exemplo de 25%).
A simples ordenação (do inglês ranking) é o método de priorização mais fácil de implementar.
Considerando n o número total de requisitos existentes, este método consiste em atribuir ao
requisito mais importante a classificação de 1 e ao requisito menos importante a classificação
de n. Comparativamente a outros métodos como o teste dos 100 dólares, o ranking não
permite ver a distância relativa entre os requisitos ordenados. Ainda, ao contrário do método
de agrupamento, no ranking cada requisito tem uma classificação única. Embora este método
se possa implementar combinando as perspetivas de várias partes interessadas, torna-se
efetivamente menos complexo e mais adequado usar este método quando existe apenas um
interlocutor a ouvir quanto à priorização dos requisitos.
No caso de se dever ouvir diversas partes interessadas (stakeholders) com igual importância,
um dos métodos mais adequados é o do Top 10. Este método consiste em pedir a cada parte
interessada que indique, segundo o seu ponto de vista e sem nenhuma ordem especial, os dez
requisitos mais importantes que devem ser implementados no sistema. Contabilizando as
preferências de todos os intervenientes, obtém-se uma priorização geral dos requisitos. Por
norma, os requisitos escolhidos por mais stakeholders, serão os mais importantes. Contudo,
uma simples média das escolhas dos requisitos poderá não acautelar que cada stakeholder
tenha garantido pelo menos os seus requisitos mais cruciais, pelo que esta questão deverá ser
vista caso a caso. O grande risco deste método é desagradar a todos os stakeholders, em vez
de agradar completamente à maioria.
A escolha da técnica a utilizar para a priorização dos requisitos de software dependerá das
características e condicionantes do projeto. A Tabela 8 apresenta um sumário das técnicas de
priorização apresentadas anteriormente.
54
Técnica Escala Granularidade Sofisticação

AHP Rácio Fina Muito complexo
Teste dos cem dólares Rácio Fina Complexo
Ordenação Ordinal Média Fácil
Classificação numérica Ordinal Grosseira Muito fácil
Top 10 - Extremamente grosseira Extremamente fácil
Tabela 8. Sumário de técnicas na priorização. Adaptado de Berander and Andrews (2005).
O conselho que se dá é de usar preferencialmente a técnica de priorização apropriada mais

simples e apenas usar uma técnica mais sofisticada no caso de ser necessário uma análise de
sensibilidade maior para dirimir desentendimentos ou para suportar decisões mais críticas
(Berander and Andrews, 2005).
6. A dimensão humana, organizacional e tecnológica da especificação

de requisitos de software
A complexidade da engenharia de requisitos é enorme. Tem-se vindo a aceitar a engenharia de
requisitos como um conjunto de processos que operam em diferentes níveis (Aurum and
Wohlin, 2005b). Uma das principais dificuldades da engenharia de requisitos é a
heterogeneidade dos temas que geralmente são considerados parte integrante dos requisitos.
Entre outros assuntos, podem-se considerar as tarefas que devem ser concluídas, os
problemas que devem ser resolvidos, as soluções para os problemas, as formas de contribuir
para o conhecimento ou os tipos de sistema a implementar. A definição de um esquema para a
estruturação da especificação dos requisitos não é fácil (Zave, 1997). As usuais abordagens
práticas para a especificação de requisitos focam sobretudo objetos, funções e estados
(Hochmüller, 1997). No entanto, isto não é suficiente. São necessárias perspetivas
complementares, considerando, entre outros, ângulos diferentes do problema, como a
economia, o tempo, o desempenho ou questões humanas. Várias são as evidências de estudos
da necessidade de utilização de abordagens alternativas para analisar os requisitos
(Hochmüller, 1997, Hochmuller, 2007, Paech and Kerkow, 2004, Zave, 1997). Uma perspetiva
complementar para a especificação de requisitos é a adoção da lente proveniente das
dimensões propostas do modelo de Orlikowski para esclarecer a complexidade da
especificação de requisitos (Belfo, 2012).
O modelo desenvolvido por Orlikowski sublinha a importância na análise de três componentes

distintas: as pessoas, a organização e a tecnologia (POT). A teoria de Orlikowski aborda as
influências dessas componentes e as suas interações recíprocas (Orlikowski, 1992). O modelo
da tecnologia de Orlikowski (ver a Figura 23) identifica quatro diferentes influências: a) a
tecnologia como uma criação da ação humana, b) a tecnologia como um instrumento da ação
humana, c) as condições organizacionais de interação com a tecnologia e d) as consequências
institucionais da interação com a tecnologia.
55
Pessoas
Organização Tecnologia
Figura 23. As dimensões Pessoas, Organização e Tecnologia e as suas relações. Adaptado do

modelo da tecnologia (Orlikowski, 1992).
Esta visão multifacetada já foi explorada por outras pesquisas interessantes, como o papel das
dimensões humana, organizacional e tecnológica no possibilitar da partilha de conhecimento
(Van den Brink, 2003) ou sobre o papel da tecnologia da informação (TI) como uma vantagem
competitiva (Powell and Dent-Micallef, 1997), entre outros (Fisher, 2004, Teletech, 2007).
Dimensão Dimensão Dimensão

Pessoas Organização Tecnologia
• As partes interessadas • O processo de • A equipe de TI entende o
têm o correto domínio do transformação da impacto tecnológico dos
conhecimento para informação é óbvio? requisitos (The Open
interpretar corretamente • As linguagens e as Group, 2004)?
a especificação de técnicas de modelação • Os requisitos têm uma
requisitos (Aurum and são adequadas para avaliação de necessidades
Wohlin, 2005a, Paech and entender os objetivos do claramente feita (Aurum
Kerkow, 2004, Paech and sistema (Aurum and and Wohlin, 2005a, Paech
Martell, 2008)? Wohlin, 2005a)? and Kerkow, 2004, Paech
• O tipo de discurso da and Martell, 2008)?
especificação de • Os requisitos estão
requisitos é adequado adequadamente
(Paech and Kerkow, elicitados (Pohl, 1994)?
2004)?
Tabela 9. Questões nas dimensões pessoas, organização e tecnologia quanto à precisão

(Belfo, 2012).
A proposta de Belfo (2012) consiste igualmente no uso destas três principais dimensões
(pessoas, organização e tecnologia) e na utilização da teoria de Orlikowski para apoiar o
processo de especificação de requisitos. Primeiro, a especificação de requisitos é
principalmente uma interação social entre as pessoas. Em segundo lugar, a organização é o
ambiente em que o processo de especificação acontece. Por último, a tecnologia da
56
informação é um importante facilitador para a especificação de requisitos e é o beneficiário

final do processo de especificação.
A Tabela 9 apresenta algumas questões quanto ao atributo precisão nas dimensões pessoas,
organização e tecnologia. Muitas outras questões deverão ser levantadas nestas três
dimensões, nomeadamente usando outros atributos de qualidade dos requisitos como a
integralidade, exatidão, compreensibilidade, verificabilidade, validade, consistência e
viabilidade.
57
IV. Para além da especificação de requisitos

A especificação dos requisitos de software está associada direta ou indiretamente a um
conjunto de questões que vai para além da construção do próprio documento. Apresentam-se
três desses tópicos: a traçabilidade dos requisitos, a validação dos requisitos e o pedido de
proposta de fornecimento (RFP). Porém, reconhece-se que existe ainda um vasto leque de
outros aspetos que também mereceriam ser abordados.
A. A traçabilidade dos requisitos
A norma IEEE 830 (1993) refere que um requisito é traçável (muitas vezes também designado
de rastreável) se a origem de cada requisito é clara e se existe um mecanismo que permita
referir-se a esse requisito em desenvolvimentos futuros ou em documentação melhorada. São
recomendados dois tipos de traçabilidade:
• Traçabilidade antecedente (backward traceability), que se refere a estágios anteriores

ao desenvolvimento. Esta traçabilidade depende da referência clara da fonte de cada
requisito em documentos anteriores.
• Traçabilidade subsequente (forward traceability), que resulta da difusão harmonizada
dos requisitos a todos os documentos pelo SRS. Isto implica que todos os requisitos
deverão ser identificados com números ou etiquetas únicas (Leffingwell and Widrig,
2000).
A Figura 24 ilustra quatro tipos de traçabilidade, sendo dois deles antecedentes e os outros
dois subsequentes.
Figura 24. Quatro tipos de traçabilidade de requisitos. Adaptado de Wiegers (2009).
A metade superior desta figura ilustra a traçabilidade antecedente. As necessidades dos

utilizadores (consubstanciadas em requisitos de negócio, regras de negócio, requisitos de
sistema, casos de uso, requisitos de interface externo ou atributo de qualidade) são seguidas
58
até aos requisitos de software, de forma a que se possa dizer sobre qualquer necessidade,
quais os requisitos que lhe estão associados. Estas ligações também permitirão que, caso
exista qualquer alteração duma dessas necessidades durante, ou mesmo depois do projeto
estar terminado, se possa saber quais os requisitos que serão afetados por essa alteração
(Wiegers, 1999). Estas ligações, também permitirão que se perceba para qualquer requisito,
qual a necessidade que lhe deu origem.
A metade inferior desta figura ilustra a traçabilidade subsequente. Os requisitos especificados

permitirão o desenvolvimento do produto, sendo que cada elemento a ser entregue ao longo
do processo do desenvolvimento deverá estar ligado a um ou a vários requisitos. Os elementos
específicos do desenvolvimento incluem elementos como a arquitetura definida, a interface de
utilizador, o desenho funcional, bem como o código desenvolvido e os seus respetivos testes
unitários, de integração para cada componente e de sistema. O estabelecimento e o destaque
destas ligações facilitará a garantia de que todos os requisitos foram satisfeitos. Por fim, o
último tipo de traçabilidade permitirá saber as razões porque cada elemento foi criado
(Wiegers, 1999).
Alguns benefícios potenciais da implementação da traçabilidade nos requisitos são:
• Certificação de que todos os requisitos foram implementados

• Análise melhorada do impacto de alterações
• Manutenção facilitada
• Melhor acompanhamento do projeto
• Reengenharia facilitada
• Reutilização potenciada
• Redução do risco (por exemplo da saída dum elemento chave da equipa de projeto)
• Simplificação dos testes
No que diz respeito à etiquetagem de requisitos, deve-se usar um critério que permita um fácil
e rápido acompanhamento e modificação. Todos os requisitos devem ser identificados duma
forma única e, por essa razão, não se deverá usar listas com marcas.
A etiquetagem de requisitos pode ser feita com base num dos seguintes tipos:
• Numeração sequencial
• Numeração hierárquica
• Etiqueta de texto hierárquica
A numeração sequencial é a abordagem mais simples. Fornece a cada requisito um número

único antecedido por um prefixo que indica o tipo de requisito em causa. No caso de um
requisito ser apagado, o seu número não deverá ser reusado. A principal vantagem desta
abordagem é a sua simplicidade e a maior desvantagem é o facto da etiqueta não indicar
nenhuma informação hierárquica, nem nenhuma pista sobre o tipo de requisito em causa.
A numeração hierárquica é normalmente usada em sistemas mais complexos. Esta

etiquetagem pressupõe que existem requisitos de mais alto nível e outros mais detalhados. O
método é simples e compacto: mais dígitos indicam maior detalhe do requisito. A cada novo
59
nível de detalhe é acrescentado um ponto que faz a separação entre níveis. A lógica de uso
deste método é também normalmente simples. No entanto, a numeração não indica o
propósito do requisito.
Na etiquetagem de texto hierárquica, usam-se etiquetas de texto resumidas que dão a

entender a função subjacente. Tal como na numeração hierárquica, a cada novo nível de
detalhe é acrescentado um ponto que faz a separação entre níveis. A grande vantagem é de
que é normalmente explícita a funcionalidade subjacente ao requisito. A principal
desvantagem é que estas etiquetas ocupam mais espaço que os outros dois tipos de
etiquetagem.
Exemplos práticos
A título de exemplo duma numeração sequencial temos a etiqueta RU-9. Neste caso RU
significará Requisito de Utilizador. Outra alternativa poderá ser SRS-43.
Como exemplo duma numeração hierárquica temos o conjunto de requisitos 3.2 que poderá
ser composto por vários, como por exemplo o 3.2.4.3 e o 3.2.4.4.
Como exemplo de etiquetagem de texto hierárquica, considere-se o requisito: “o sistema

deverá perguntar ao utilizador para confirmar qualquer pedido para imprimir mais do que 10
cópias”. Neste caso poderá ser definida a seguinte etiqueta para este requisito:
imprimir.confirmarcópias. Esta etiqueta indicará que se trata de um requisito relativo às
funcionalidades de impressão, relacionada com a parte de confirmação do número de cópias.
As questões pendentes de discussão futura poderão ser organizadas através do uso de

etiquetagem especial. Normalmente usa-se uma etiqueta do tipo PSD (Para Ser Discutido), ou
TBD (do inglês “To Be discussed”). Neste caso, poderá ser usada uma etiquetagem sequencial
numérica ou hierárquica. Por exemplo: "TBD1.01 – Será que o utilizador do tipo administrador
tem acesso a visualizar os dados de clientes?".
B. Validação dos requisitos
Tal como foi referido anteriormente, a atividade de validação e também a da verificação são
distintas da atividade de especificação de requisitos de software e, por essa razão, não fazem
parte dos objetivos específicos desta lição. No entanto, a verificação e validação são
complementares à especificação, tal como as atividades de elicitação e análise de requisitos
(ver a Figura 5). A interação entre estas atividades valoriza a qualidade final na elaboração do
documento SRS. Por essa razão, apresentam-se também aqui alguns aspetos importantes
sobre este tópico.
A validação de requisitos consiste na certificação de que os requisitos vão de encontro aos

objetivos das partes interessadas. Por outro lado, a verificação dos requisitos consiste em
determinar se o produto está conforme os requisitos estabelecidos (Hofmann and Lehner,
2001).
60
No final de contas, a validação de requisitos pretende responder às seguintes questões

(Boehm, 1984):
• Validação - "Estaremos a construir o produto correto?"

• Verificação - "Estaremos a construir corretamente o produto?"
As atividades de validação tentam garantir que (Wiegers, 2009):
• O SRS descreve corretamente as capacidades e caraterísticas desejadas para o sistema

que satisfarão as necessidades das diversas partes interessadas
• Os requisitos de software derivam corretamente dos requisitos de sistema, das regras
de negócio e de outras importantes fontes
• Os requisitos especificados estão completos e são de alta qualidade
• Todas as representações dos requisitos estão consistentes umas com as outras
• Os requisitos especificados fornecem uma base adequada para se poder proceder às
seguintes fases de desenho e de desenvolvimento
Existe um conjunto de técnicas que poderão ser usadas para avaliar da correção e qualidade
dos requisitos. Destacam-se as seguintes (Wiegers, 2009):
• Revisão por pares informal

• Inspeção (Fagan, 1976), um tipo formal de revisão por pares
Segundo a norma ISO/IEC 12207, o processo de validação de software deverá ter como
resultado (ISO and IEC, 2008):
• o desenvolvimento e implementação duma estratégia de validação

• a identificação dos critérios de validação para todos os produtos a desenvolver
• a execução das atividades de validação requeridas
• a identificação e o registo dos problemas
• as evidências de que os produtos de software a desenvolver estão de acordo com a
sua desejada utilização
• a disponibilização ao cliente e a outras partes interessadas dos resultados das
atividades de validação
A norma internacional para a verificação e validação do software (V&V), a IEEE 1012,

aprofunda estas e outras questões. Esta norma inclui aspetos relativos aos processos de
avaliação, análise, revisão, inspeção, apreciação e teste de produtos e processos de software.
Os processos de V&V avaliam o software no contexto do sistema, incluindo o ambiente
operacional, o hardware, o software de interface, os seus operadores e utilizadores (IEEE,
2012).
C. Pedido de proposta de fornecimento (RFP)
Um pedido de proposta de fornecimento (RFP) a vários fornecedores é uma prática habitual e

aconselhável em muitas situações. Consiste num convite enviado a um conjunto de
fornecedores para apresentarem propostas de fornecimento de um software que cubra as
61
necessidades do cliente. De entre os diversos benefícios na utilização dum RFP num processo
de aquisição de produto, destacamos os seguintes:
• várias propostas de fornecedores valorizam o processo de decisão;
• o poder de compra da empresa é aumentado;
• o processo de aquisição torna-se mais claro e transparente para os fornecedores e
para a empresa;
• o processo torna-se menos subjetivo, concentrando-se na racionalidade para
selecionar o fornecedor e a sua solução;
• facilita uma larga escala de distribuição de pedidos;
• estabelece um cronograma formal de entrega das informações
A elaboração duma cuidada especificação dos requisitos de software é uma componente
fundamental que deverá anteceder o pedido de proposta a fornecedores. A TEC propõe um
conjunto de modelos para RFP, que cada cliente poderá usar em função das suas necessidades.
Esta é uma boa prática que consiste no uso de uma folha de cálculo normalizada para recolha,
para cada potencial fornecedor, do seu grau de disponibilidade na entrega de cada requisito
pertencente a cada grupo funcional dos requisitos pretendidos (TEC, 2012).
Figura 25. Exemplo de modelo de pedido de proposta de cotação (TEC, 2012).
A Figura 25 apresenta um exemplo de um extrato duma folha de cálculo usada para resposta a
um pedido de proposta de cotação (RFP) com alguns possíveis requisitos, devidamente
etiquetados, utilizando uma coluna para a prioridade atribuída pelo cliente. Após o envio aos
potenciais fornecedores do pedido de proposta, estes, caso estejam interessados em
apresentar uma proposta formal, deverão preencher o grau de disponibilidade no
fornecimento para entrega de cada um dos requisitos solicitados.
62
Opção Descrição
O requisito é fornecido sem esforço especial de
SUP (supported)
desenvolvimento. Na gíria é normalmente designado como "out-
of-the-box" ou "off the shelf".
MOD (via modifications) O requisito é fornecido via algumas modificações (tais como
configurações de ecrãs, relatórios, GUI ou personalizações).
3RD (third party solution) O requisito é fornecido através duma solução existente dum
outro fornecedor.
CST (via customization) O requisito é fornecido através de customização (alterações do
código fonte).
FUT (future release) O requisito é apenas fornecido numa futura versão.
NS (not supported) O requisito não será fornecido.
Tabela 10. Graus de disponibilidade do fornecedor na entrega dum requisito (TEC, 2012).
A disponibilidade para entrega de cada requisito por parte de cada fornecedor tem seis
alternativas exclusivas entre si. A Figura 25 exemplifica igualmente, usando cruzes para o
efeito, uma possível resposta quanto ao grau de disponibilidade que um determinado
fornecedor tem para cada requisito. A Tabela 10 apresenta as várias opções quanto aos graus
de disponibilidade do fornecedor na entrega de cada requisito.
O modelo proposto propõe uma abordagem hierárquica para os requisitos que facilita ao
cliente numa primeira fase uma análise das suas necessidades. A TEC propõe um conjunto de
vários modelos, cada um deles com milhares de requisitos/critérios, orientados a cada setor de
atividade e tipo de necessidade. Na fase final da seleção dum fornecedor e da sua respetiva
solução, o cliente deverá analisar a compatibilidade entre as prioridades previamente
definidas por si e a disponibilidade de fornecimento mostrada para cada requisito por parte de
cada fornecedor.
Por vezes, a cada requisito ainda se associam outros atributos de classificação para além da
prioridade. Outros atributos de classificação poderão ser a criticidade, a fiabilidade, o risco, a
fonte e o tipo do requisito.
<identificação> = 2.1.3.6
<prioridade> = alta
<criticidade> = baixa
<fiabilidade> = alta
<risco> = médio
<fonte> = cliente
<tipo> = desempenho
O exemplo anterior apresenta um exemplo de instanciação de alguns destes atributos para um
requisito.
63
D. Ferramentas de gestão de requisitos
A utilização de uma ferramenta de gestão de requisitos pode representar uma ajuda

considerável ao processo de gestão de requisitos. Entre outras vantagens relativas à utilização
duma ferramenta deste género, normalmente são apontadas as seguintes:
• Os requisitos estão centralizados num único local

o Maior controlo do projeto
o Melhor comunicação entre a equipa
o Obviar o trabalho por suposição
• Maior facilidade na gestão da aprovação ou rejeição de requisitos
• Facilidade no estabelecimento de prioridades
• Criação de documentação instantânea (ex: ficheiros PDF)
• Facilidade na atribuição de requisitos aos membros da equipa
• Possibilidade de bloquear requisitos
• Maior integração com o acompanhamento de questões e casos de testes
Eis algumas das soluções existentes no mercado:
http://www.borland.com/products/caliber/
http://www.elementool.com
http://www.visual-paradigm.com/
http://www.seilevel.com/
http://www.i-nature.com/reqheap/ http://www.jamasoftware.com/
http://msdn.microsoft.com/
64
V. Referências
ABRAN, A., MOORE, J. W., DUPUIS, R., DUPUIS, R. & TRIPP, L. L. (eds.) 2004. Guide to the
Software Engineering Body of Knowledge (SWEBOK), Los Alamitos, California: IEEE, The
Institute of Electrical and Electronics Engineers, Inc.
ALBRECHTSEN, E. 2003. Security versus Safety. NTNU - Norwegian University of Science and
Technology.
AURUM, A. & WOHLIN, C. 2005a. Engineering and managing software requirements, Springer-
Verlag New York Inc.
AURUM, A. & WOHLIN, C. 2005b. Requirements Engineering: Setting the Context In: AURUM,
A. & WOHLIN, C. (eds.) Engineering and managing software requirements. Berlin,
Germany: Springer-Verlag.
AUSUBEL, D. P. 1960. The use of advance organizers in the learning and retention of
meaningful verbal material. Journal of educational psychology, 51, 267.
BELFO, F. 2012. People, Organizational and Technological Dimensions of Software
Requirements Specification. Procedia Technology, 5, 310-318.
BERANDER, P. & ANDREWS, A. 2005. Requirements Prioritization. In: AURUM, A. & WOHLIN, C.
(eds.) Engineering and managing software requirements. Berlin, Germany: Springer-
Verlag.
BOEHM, B. W. 1984. Verifying and validating software requirements and design specifications.
Software, IEEE, 1, 75-88.
CHEN, P. P. S. 1976. The entity-relationship model—toward a unified view of data. ACM
Transactions on Database Systems (TODS), 1, 9-36.
DAVIS, A., OVERMYER, S., JORDAN, K., CARUSO, J., DANDASHI, F., DINH, A., KINCAID, G.,
LEDEBOER, G., REYNOLDS, P. & SITARAM, P. Year. Identifying and measuring quality in
a software requirements specification. In, 1993. IEEE, 141-152.
DAVIS, A. M. 1993. Software requirements: objects, functions, and states, Prentice-Hall, Inc.
DORFMAN, M. Year. System and software requirements engineering. In, 1990. Citeseer.
FAGAN, M. E. 1976. Design and code inspections to reduce errors in program development.
IBM systems journal, 15, 182-211.
FERREIRA, I., LOBEIRO, M. & GOUVEIA, R. 2005. Especificação de Requisitos de software do
MEDIGest - Sistema de Gestão de uma Clínica Médica. Coimbra: Instituto Superior de
Contabilidade e Administração de Coimbra.
FISHER, D. M. 2004. The business process maturity model. A practical approach for identifying
opportunities for optimization. Business Process Trends.
GILB, T. 2005. Competitive engineering: a handbook for systems engineering, requirements
engineering, and software engineering using Planguage, A Butterworth-Heinemann
Title.
GUERRA, J., BURGER, B. & OPPENHEIMER, A. 14-16 de Março de 2006 2006. RE: Solução
Integrada para Gestão de Empresas de Utilities.
HERRINGTON, M. September 2007. RE: Defining Business Requirements.
HOCHMÜLLER, E. Year. Requirements classification as a first step to grasp quality
requirements. In, 1997.
HOCHMULLER, H. 2007. Towards the Proper Integration of Extra-Functional Requirements.
Australasian Journal of Information Systems, 6.
HOFMANN, H. F. & LEHNER, F. 2001. Requirements engineering as a success factor in software
projects. Software, IEEE, 18, 58-66.
65
IBM 2009. An Integrated Approach to Requirements and Quality Management: The principles
of requirements-driven testing. Requirements and quality management solutions.
Somers, New York, U.S.A.: IBM Corporation.
IEEE 1998a. IEEE Std 830-1998: Recommended Practice for Software Requirements
Specifications. New York, USA: IEEE, Institute of Electrical and Electronics Engineers,
Inc.
IEEE 1998b. IEEE Std 1233-1998: IEEE Guide for Developing System Requirements
Specifications. New York, USA: IEEE, Institute of Electrical and Electronics Engineers,
Inc.
IEEE 2012. IEEE Std 1012-2012: Standard for System and Software Verification and Validation.
IEEE Computer Society.
ISO 1998. ISO 9241 - Part 11: Ergonomic requirements for office work with visual display
terminals (VDTs) - Guidance on usability. ISO, International Organization for
Standardization.
ISO & IEC 2008. ISO/IEC 12207: Systems and software engineering - Software life cycle
processes. ISO, International Organization for Standardization
IEC, International Electrotechnical Commission.
JAPENGA, R. 2003. How to write a software requirements specification. Micro Tools, Inc.
KOTONYA, G. & SOMMERVILLE, I. 1998. Requirements Engineering: Processes and Techniques,
Chichester, England, John Wiley and Sons.
LEE, A. 2012. How to write Performance Requirements with Example. Available:
http://www.1202performance.com/atricles/how-to-write-performance-requirements-
with-example/ [Accessed 2012, Aug 03].
LEFFINGWELL, D. 2001. Features, use cases, requirements, oh my! The Rational Edge e-zine.
LEFFINGWELL, D. & WIDRIG, D. 2000. Managing Software Requirements: A Unified Approach,
ISBN 0-201-61593-2.
LEFFINGWELL, D. & WIDRIG, D. 2003. Management Software Requirements: A Use Case
Approach, Addison Wesley.
MCEWEN, S. 2004. Requirements: an introduction.
MICROSOFT 2006. Microsoft Office Visio. 2007 ed.: Microsoft Corporation.
MOORE, G. A. 2002. Crossing the chasm: Marketing and selling high-tech products to
mainstream customers, HarperBusiness.
MUSA, J. D., IANNINO, A. & OKUMOTO, K. 1987. Software reliability: measurement, prediction,
application, McGraw-Hill, Inc.
NIELSEN, J. 1994. Usability engineering, Morgan Kaufmann.
NUSEIBEH, B. & EASTERBROOK, S. Year. Requirements engineering: a roadmap. In, 2000. ACM,
35-46.
ORLIKOWSKI, W. J. 1992. The duality of technology: Rethinking the concept of technology in
organizations. Organization science, 398-427.
PAECH, B. & KERKOW, D. Year. Non-functional requirements engineering-quality is essential.
In, 2004. 27-40.
PAECH, B. & MARTELL, C. 2008. Innovations for requirements analysis: from stakeholders'
needs to formal designs: 14th Monterey Workshop 2007, Monterey, CA, USA,
September 10-13, 2007: revised selected papers, Springer-Verlag New York Inc.
POHL, K. 1994. The three dimensions of requirements engineering: a framework and its
applications. Information systems, 19, 243-258.
POWELL, T. C. & DENT-MICALLEF, A. 1997. Information technology as competitive advantage:
The role of human, business, and technology resources. Strategic management
journal, 18, 375-405.
RINZLER, B. 2009. Telling Stories, A Short Path to Writing Better Software Requirements,
Indianapolis, Indiana, Wiley Publishing, Inc.
66
SCHAFFER, E. M. 2004. How to Develop an Effective GUI Standard. Fairfield: Human Factors
International, Inc. .
SCHWANDT, M. 2008. SAP Enhancement Package: Frequently Asked Questions. Available:
http://wiki.sdn.sap.com/wiki/display/EHP/EhP+FAQ [Accessed Jul 13, 2012].
SEHLHORST, S. May 25th 2006. Writing Good Requirements – The Big Ten Rules. Tyner Blain
[Online]. Available from: http://tynerblain.com/blog/2006/05/25/writing-good-
requirements-the-big-ten-rules/ [Accessed Oct 19th, 2012].
SHULMAN, J. H. 1992. Case methods in teacher education, Teachers College Press New York.
SOMMERVILLE, I. 2007. Software Engineering, Essex, England, Addison-Wesley Publishers.
STANDISH GROUP 2009. Chaos Summary 2009. Boston MA: Standish Group.
TEC, T. E. C. 2012. RFP Templates [Online]. Technology Evaluation Centers Inc. Available:
http://rfp.technologyevaluation.com [Accessed 2012, Aug 02].
TELETECH 2007. Human Capital as a Force Multiplier. TeleTech Holdings, Inc.
THE OPEN GROUP, T. 2004. The Open Group Architecture Framework (TOGAF) Version 9.
THE OPEN GROUP, T. 2009. The Open Group Architecture Framework (TOGAF) Version 9. The
Open Group.
THE STANDISH GROUP 1995. Chaos Report.
TOBOLA, R. May, 2009 2009. RE: Maintenamence Strategy of SAP Applications and
Enhancement Packages.
VAN DEN BRINK, P. 2003. Social, organizational, and technological conditions that enable
knowledge sharing.
VIE, D. L. 2009. Writing Software Requirements Specifications. Available: http://www.techwr-
l.com/techwhirl/magazine/writing/softwarerequirementspecs.html [Accessed 2009,
Jan 26].
WIEGERS, K. E. 1999. Writing quality requirements. Software Development, 7, 44-48.
WIEGERS, K. E. 2000. Karl Wiegers describes 10 requirements traps to avoid. Software Testing
& Quality Engineering, 2.
WIEGERS, K. E. 2009. Software requirements, O'Reilly Media, Inc.
WIKIPEDIA. 2012. Timeline of Microsoft Windows. Available:
http://en.wikipedia.org/wiki/Timeline_of_Microsoft_Windows [Accessed 2012, Aug
01].
ZAVE, P. 1997. Classification of research efforts in requirements engineering. ACM Computing
Surveys (CSUR), 29, 315-321.
ZOWGHI, D. & COULIN, C. 2005. Requirements Elicitation: A Survey of Techniques, Approaches,
and Tools In: AURUM, A. & WOHLIN, C. (eds.) Engineering and managing software
requirements. Berlin, Germany: Springer-Verlag.
67
Anexo 1: Lista de acrónimos e siglas
AHP Analytical Hierarchy Process
CEO Chief Executive Officer
CIO Chief Information Officer
DFD Diagrama de Fluxos de Dados
ER Engenharia de requisitos
ERD Entity–relationship model
ERP Enterprise Resource Planning
FCS Fatores Críticos de Sucesso
GUI Graphical User Interface
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
ISO International Organization for Standardization
MD5 Message-Digest algorithm 5
RFI Request For Information
RFP Request For Proposal
SRS Software Requirements Specification
STD State Transition Diagram
SyRS System Requirements Specification
TBD To Be Determined
TEC Technology Evaluation Center
TI Tecnologias da Informação
UML Unified Modeling Language
STD State-Transition Diagram
68
Anexo 2: Glossário
Analytical Hierarchy O processo de hierarquização analítica (do inglês Analytical
Process Hierarchy Process, associado à sigla AHP) é um método de
tomada de decisão sistemática de priorização de requisitos de
software que resulta da comparação de todos os pares
possíveis de requisitos classificados hierarquicamente, de forma
a determinar qual requisito num par tem a prioridade maior e
também qual a grandeza da diferença entre ambos os dois
requisitos desse par (Berander and Andrews, 2005).
Diagrama de Um diagrama de entidade-relacionamento (do inglês Entity-
Entidade-Relacionamento Relationship Diagrams , ERD) é uma técnica de modelação de
dados que ilustra graficamente entidades num sistema de
informações e as relações entre essas entidades (Chen, 1976).
Processo de negócio Consiste num conjunto de ações relacionadas entre si de forma
lógica e coerente a fim de promover um output favorável à
empresa (qualidade total e satisfação do cliente), tanto a nível
interno como externo.
Produto de software Conjunto de programas de computador, procedimentos e
possíveis dados e documentação associada (ISO and IEC, 2008).
Requisito Propriedade que tem de existir para que um determinado
problema do mundo real possa ser resolvido (Abran et al.,
2004).
Requisito de Software Necessidade ou restrição colocada sobre um produto de
software que contribui para a solução de alguns problemas do
mundo real (Kotonya and Sommerville).
Stakeholder Um indivíduo ou uma organização que tenha um direito, uma
participação, uma reclamação ou um interesse num sistema ou
de que este disponha de características que atendam às suas
necessidades e expectativas (ISO and IEC, 2008).
Usabilidade Medida na qual um produto pode ser usado por utilizadores
específicos para alcançar objetivos específicos com eficácia,
eficiência e satisfação num contexto de uso específico (ISO,
1998).
69
Anexo 3: Métodos de ensino planeados
método expositivo
O método de ensino planeado para a lição assenta essencialmente no método expositivo.
Segundo este método, também designado de dedutivo, o professor apresenta conceitos,
princípios, deduções ou afirmações a partir dos quais se tiram conclusões ou consequências.
Embora na maioria das vezes seja o professor a tirar as conclusões, também podem ser os
alunos a fazê-lo (Ausubel, 1960).
Neste método, o ensino está no professor e a aula segue uma estrutura de degraus, em que
cada degrau é iniciado pelo professor que disponibiliza informação e coloca questões. Os
alunos e o professor interagem em ciclos de iniciação-resposta e de avaliação.
Os materiais de apoio referentes a esta aula serão disponibilizados aos alunos através da
plataforma moodle (em moodle.iscac.pt), uma aplicação baseada na Internet que suporta uma
pedagogia construcionista social moderna.
método da aprendizagem baseada em problemas

Para obviar as limitações normalmente apontadas ao método expositivo, nomeadamente a
eventual limitação da oportunidade dos alunos construírem as suas experiências e
monitorarem as suas aprendizagens, propõe-se ainda que a aula tenha igualmente a utilização
do método de aprendizagem baseada em problemas (ou PBL, do inglês "Problem Based
Learning").
Este método é um método de ensino caraterizado pelo uso de problemas da vida real,
estimulando desta forma o desenvolvimento do pensamento crítico e o desenvolvimento de
competências de solução de problemas e a aprendizagem de conceitos fundamentais. Durante
a aula, são inúmeros os exemplos apresentados, caraterizando o uso de problemas da vida
real, desde os exemplos de objetivos de negócio até aos exemplos de requisitos funcionais e
não-funcionais específicos.
método de estudo de caso

O estudo de caso é um método de ensino indireto muito útil para aprender um determinado
assunto através da análise de problemas. De acordo com Shulman (1992), "um caso tem uma
narrativa, uma história, um conjunto de eventos que se desenrola ao longo do tempo em um
determinado lugar" (Shulman, 1992).
A presente aula não terá obviamente tempo para desenvolver uma estratégia de ensino deste
tipo. No entanto, pretende-se desafiar os alunos para um projeto de especificação de
requisitos de software. Esse projeto enquadrará e caracterizará os requisitos necessários ao
desenvolvimento de um sistema de informação numa organização real. Neste caso, a história
70
referida por Shulman (1992), desenrolar-se-á à volta da organização escolhida e dos processos
de elicitação, análise, especificação e validação dos requisitos.
Com este estudo de caso pretende-se motivar os alunos através da pesquisa/investigação e do

debate de problemas sobre essa organização específica e sobre possíveis ideias para a sua
resolução.
71
Anexo 4: Projeto Prático
Este projeto tem por objetivo consolidar e desenvolver as competências referentes à

elicitação, análise, especificação e validação de requisitos de software. Consiste na
especificação de um documento de requisitos de software relativo ao desenvolvimento de um
sistema de informação para uma determinada organização que atua numa determinada área
de atividade. Este será um trabalho a desenvolver fora do tempo de contacto das aulas, mas,
com a supervisão e apoio do professor.
Deverão ser constituídos grupos de trabalho, com um número máximo de 3 alunos.
Este projeto deverá contemplar os seguintes passos:
1. A seleção duma organização (empresa ou organismo público) que concorde

previamente com o desenvolvimento deste projeto;
2. Um trabalho de campo onde os alunos deverão conseguir caraterizar essa organização,
nomeadamente o seu ambiente, os seus processos, as pessoas e os outros recursos
relevantes;
3. Com base no anterior ponto, deverão detetar oportunidades de melhoria
organizacional e, consequentemente, selecionar qual(ais) o(s) propósito(s) do projeto,
considerando que existem genericamente quatro alternativas não exclusivas:
• grandes melhorias para uma aplicação existente
• desenvolvimento de novas aplicações
• desenvolvimento de aplicações de substituição
• pedido de propostas (RFP)
4. Proceder à adequada elicitação dos requisitos, utilizando adequadas técnicas de
recolha de informação para esse efeito;
5. Proceder à adequada análise dos requisitos, utilizando adequadas técnicas de
modelação para esse efeito;
6. Proceder á elaboração dum documento de especificação de requisitos de software
(SRS), com base no modelo apresentado nas aulas.
7. Por fim, deverão ser validados os requisitos apresentados no SRS.
O prazo de entrega do projeto é o último dia de aulas.
72

Requisitos Como Definir

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Requisitos Como Definir

Enviado por

Direitos autorais:

Formatos disponíveis

Especificação de

Provas públicas de avaliação da competência

Fernando Paulo dos Santos Rodrigues Belfo

C. Outros aspetos relacionados com a especificação de requisitos ................................ 44

Tabela 1. Exemplos de objetivos de negócio. Adaptado de Wiegers (2009)............................ 11

O docente tem desempenhado funções letivas no Instituto Superior de Contabilidade e

Como será melhor explicado nesta lição, a especificação de requisitos de software,

Nomeadamente o conceito de sistema, as caraterísticas

Nomeadamente algumas competências relativas às

Nomeadamente algumas competências relativas à

O documento começa por apresentar uma introdução ao tema e á sua pertinência,

Em seguida, apresenta um capítulo com os fundamentos sobre requisitos de software,

O terceiro capítulo mostra propriamente aspetos práticos associados à elaboração do

O último capítulo deste documento escrito apresenta questões para além da

No final do documento encontram-se ainda as referências usadas e alguns anexos,

Fernando Paulo Belfo

Coimbra, Outubro de 2012

Figura 1. Resolução de projetos em 2000 e 2008 (Standish Group, 2009)

B. A complexidade da gestão dos requisitos

O processo de gestão de requisitos está preocupado em saber como as atividades de

Figura 2. O ciclo de desenvolvimento da arquitetura empresarial (The Open Group, 2009).

Algumas das principais referências de enquadramento na área do governo das tecnologias de

A gestão de requisitos é obviamente importante e também complexa. Exige da parte da

Figura 3. Alguns aspetos a considerar numa política de gestão de requisitos.

A Figura 3 representa a complexidade que a definição duma política de gestão de requisitos

C. Da noção de requisitos à especificação de requisitos de software

Segundo Abran et al. (2004), a "especificação de requisitos de software" refere-se tipicamente

Questões Processo dos

Esta lição expõe sobretudo o conhecimento relativo à especificação de requisitos, embora se

Figura 5. Processo iterativo no desenvolvimento de requisitos. Adaptado de Wiegers (2009).

sistema. Em rigor, um produto ou serviço de software é sempre considerado um item do

A lição guiar-se-á especialmente pela abordagem de Wiegers (2009) e pela norma

II. Fundamentos sobre requisitos de software

A especificação dos requisitos de software está intrinsecamente relacionada com a

Para entender a diferença entre ambas as especificações é fundamental perceber a importante

A reputada associação internacional Institute of Electrical and Electronics Engineers (IEEE)

B. Requisitos de negócio, de utilizador e de software

No sentido de tentar esclarecer alguma terminologia acerca da especificação das caraterísticas

Figura 6. A pirâmide de requisitos. Adaptado de Leffingwell and Widrig (2003).

Figura 7. Os três níveis de requisitos: requisitos de negócio, de utilizador e de software.

C. Dos requisitos de negócio aos requisitos de software

Os requisitos de software são normalmente constituídos por requisitos funcionais e requisitos

Especificação Especificação dos Especificação

Figura 8. Etapas na especificação dos requisitos do software. Adaptado de Wiegers (2000).

A principal vantagem de começar sempre pelos requisitos de negócio, passando pelos

1. A elaboração dos requisitos de negócio

Os antecedentes da criação do novo produto consistem na explicação das razões e no contexto

Um outro aspeto a considerar no documento "Visão e Âmbito do Sistema" deverá contemplar

Figura 9. Possível modelo do documento "Visão e Âmbito do Sistema" (Wiegers, 2009).

Este documento deverá igualmente conter os objetivos de negócio, ligando-os a critérios de

Objetivos Financeiros Objetivos Não Financeiros

Os requisitos de negócio deverão ainda sumarizar os principais riscos do negócio, associados

ao desenvolvimento, ou ao não desenvolvimento, do produto. Algumas categorias de risco

• Para ... [clientes-alvo do segmento a alcançar]

Vejamos o seguinte exemplo do designado "Sistema de Rastreamento de Químicos".

As assunções ou pressupostos apresentados por qualquer uma das partes interessadas

c) Âmbito e as limitações do projeto

A estratégia associada às várias versões tem normalmente subjacente o princípio de que a

Um stakeholder é uma parte interessada no produto. Pode ser um indivíduo ou uma

• O maior valor acrescentado ou benefício que o stakeholder usufruirá do produto e que

Outro aspeto importante na contextualização do projeto face ao negócio resulta na definição

Caraterística Prioridade Risco

No sentido de uma melhor gestão do âmbito do projeto, pode-se igualmente associar o