►METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS
Prof. Dr. rer. nat. Daniel D. Abdala
e-mail: [email protected]
1
 Introduzir
os conceitos de requisitos do
usuário e do sistema;
 Definir requisitos funcionais e nãofuncionais;
 Explicar duas técnicas para descrição de
requisitos do sistema;
2
 Requisitos
Funcionais e Não-Funcionais
 Requisitos do Usuário
 Requisitos do Sistema
 Documento de Requisitos
3
4
 Processo
sistemático para:
• Identificação e registro das necessidades
específicas dos stackholders;
• Refinamento dos requisitos levantados;
• Resolução de conflitos entre requisitos;
• Identificação de interdependências entre
requisitos;
5
 Descrição
de serviços e restrições do
sistema;
 Devem refletir a necessidade dos
usuários do sistema;
 Existem diferentes níveis:
• Alto nível – usados por exemplo em propostas
de contrato;
• Detalhados – usados na redação de contratos.
Definem precisamente o que deve estar
presente no software
6
“If a company wishes to let a contract for a large
software development project, it must define its
needs in a sufficiently abstract way that a
solution is not pre-defined. The requirements
must be written so that several contractors can
bid for the contract, offering, perhaps, different
ways of meeting the client organisation’s needs.
Once a contract has been awarded, the
contractor must write a system definition for the
client in more detail so that the client
understands and can validate what the software
will do. Both of these documents may be called
the requirements document for the system.”
Sommerville
7
 Requisitos
do Usuário (Usuário)
• afirmações em linguagem natural enriquecidos por diagramas
descrevendo os serviços e funcionalidades que um sistema deve
prover, assim como restrições na presença das quais ele deve operar.
 Requisitos
do Sistema (Eng. de Requisitos)
• estabelece as funções do sistema, serviços e restrições em detalhes. O
documento de requisitos do sistema (também chamado especificação
funcional) deve ser preciso e detalhado. Ele deve definir exatamente o
que deve ser implementado. Ele ainda pode ser usado como parte do
contrato entre o comprador do sistema e os desenvolvedores.
 Especificação
do Software (Desenvolvedores)
• Uma descrição detalhada do software que serve como base para o
projeto e implementação
8
Definição de Requisitos
O Software deve prover funcionalidade para impressão de todos os
relatórios gerados .
Especificação de Requisitos
1. O software deve ser capaz de escolher uma dentre as várias
impressoras disponíveis para impressão;
2. A impressão de um relatório deve ser permitida em diferentes níveis
de qualidade;
3. Os níveis de qualidade são: (rascunho, normal e alta qualidade);
4. Deve ser possível imprimir relatórios para arquivos .pdf.
9
 Requisitos
funcionais e não-funcionais
devem ser descritos de tal forma que
eles possam ser entendidos por usuários
que não possuem conhecimento;
 Requisitos do Usuário são definidos
usando Linguagem Natural (LN), tabelas
e diagramas.
 Falta
de claridade
• Alcançar precisão é difícil sem tornar o
documento muito complexo
 Confusão
entre os Requisitos
• Requisitos funcionais e não-funcionais tendem a
se misturar
 Combinação
de Requisitos
• Vários requisitos distintos podem vir a ser
expressos conjuntamente
4.A.5 O banco de dados deve permitir a geração e controle de
objetos de configuração, isto é, objetos que são compostos pela
combinação de outros objetos. As ferramentas de controle de
configuração devem permitir acesso aos objetos em um grupo de
versão por meio do uso de nomes incompletos.
2.6 Grid facilities Para auxiliar o posicionamento de entidades no
diagrama, o usuário poderá habilitar a visualização do grid tanto em
centímetros quanto em milímetros utilizando para tal um painel de
controle. Inicialmente, o grid não deve estar habilitado. O grid pode ser
habilitado e desabilitado a qualquer momento durante uma sessão de
edição assim como poderá ser alterado entre cm e mm. Uma outra
opção chamada “reduce-to-fit” , no entanto o número de linhas
mostradas será reduzido de modo a evitar que diagramas pequenos
sejam rearranjados para se ajustarem as linha do grid.
 Os
requisitos do database incluem tanto
informações conceituais quanto detalhes de
implementação
• Descrevem o conceito de opções de controle de
configuração
• Incluem detalhes a respeito de como os objetos
devem ser acessados (usando nomes incompletos)

Os requisitos do grid incluem três tipos de
requisitos
• Conceitual (a necessidade de um grid)
• Não-Funcional (unidades de medida do grid)
• Não Funcional IU (troca de tamanho do grid)
User requirements
Client managers
System end-users
Client engineers
Contractor managers
System architects
System requirements
System end-users
Client engineers
System architects
Software developers
Software design
specification
Client engineers (perhaps)
System architects
Software developers
15
 Requisitos Funcionais
• definições dos serviços que o sistema de prover;
• define como o sistema deve reagir a diferentes tipos de
entrada;
• como o sistema deve se comportar em situações
particulares.
• definir explicitamente o que o sistema NÃO deve fazer;
 Requisitos Não-Funcionais
• Define restrições dos serviços oferecidos pelo sistema;
• Restrições de tempo;
• Restrições do processo de desenvolvimento;
• Restrições (concordância) de padronização;
• Geralmente são aplicáveis a todo o sistema.
16



O usuário deve ser capaz de pesquisar tanto um
conjunto inicial de bancos de dados como um sub
grupo selecionado dos mesmos.
O sistema deve prover métodos de visualização
adequados de modo que o usuário possa ler os
documentos disponíveis na loja de documentos.
Deve ser atribuído um identificador único (ORDER_ID)
a todos os documentos.
17
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements

Requisitos do Produto
• 4.C.8 Deve ser possível representar toda a comunicação
entre o APSE e o usuário usando o conjunto de caracteres
Ada.

Requisitos de organização
• 9.3.2 O processo de desenvolvimento do sistema assim
como todos os documentos entregáveis devem estar em
concordância com o padrão definido em XYZCo-SPSTAN-95

Requisitos Externos
• 7.6.5 O sistema não deve publicar nenhuma informação
pessoal dos clientes com exceção do nome e número de
referência para o operador do sistema
19
Requisitos não-funcionais podem ser difíceis de
serem definidos claramente, e requisitos
imprecisos podem ser difíceis de verificar.
 Objetivos

• São uma intenção geral do usuário, tal como facilidade de
utilização

Requisitos funcionais verificáveis
• Uma especificação de funcionalidade usando alguma
forma de medida que pode ser testada objetivamente

Objetivos podem ser úteis aos desenvolvedores
uma vez que estes representam as intenções dos
usuários do sistema
 Um
objetivo do sistema
• O sistema deve ser fácil de usar por controladores
experientes e deve ser organizado de forma que os
erros de utilização sejam minimizados
• Um requisito não-funcional verificável
• Controladores experientes dever ser capazes de
usar todas as funções do sistema após um
treinamento de duas horas. Uma vez que o
treinamento tenha sido feito, o número médio de
erros de utilização não deverá ultrapassar duas
ocorrências por dia.
O
documento de requisitos é uma
especificação formal do que é requerido
dos desenvolvedores do sistema
 Ele deve incluir tanto uma definição
quanto a especificação de cada requisito
 Ele NÃO é um documento de projeto.
Tanto quanto possível ele deve definir o
que o sistema deve fazer ao invés de
COMO ele deve fazer
23
 Especificação
detalhada dos requisitos
do usuário;
 Serve como base para o projeto do
sistema.
 Como
princípio, requisitos devem
informar o que o sistema deve fazer e
projeto como deve ser feito
 Na prática, requisitos e projeto são
inseparáveis
• Uma arquitetura do sistema deve ser projetada
para estruturar os requisitos
 Ambigüidade
• Os leitores e escritores dos requisitos podem vir
a interpretar as mesmas palavras de maneiras
diversas. LN é naturalmente ambigua
 Muita
Flexibilidade
• A mesma idéia pode ser expressa de maneiras
diferentes
 Falta
de Modularização
• LN é inadequada para estruturação de requisitos
do sistema
27
Notation
Structured natural
language
Design description
languages
Graphical
notations
Mathematical
specifications
Description
This approach depends on defining standard forms or templates to
express the requirements specification.
This approach uses a language like a programming language but with
more abstract features to specify the requirements by defining an
operational model of the system.
A graphical language, supplemented by text annotations is used to
define the functional requirements for the system. An early example of
such a graphical language was SADT (Ross, 1977; Schoman and Ross,
1977). More recently, use-case descriptions (Jacobsen, Christerson et
al., 1993) have been used.
These are notations based on mathematical concepts such as finite-state
machines or sets. These unambiguous specifications reduce the
arguments between customer and contractor about system functionality.
However, most customers don’t understand formal specifications and
are reluctant to accept it as a system contract.
 Uma
forma limitada de LN pode ser
usada para expressar requisitos
 Sana alguns dos problemas resultantes
da ambiguidade e flexibilidade e impoe
um certo grau de uniformidade para a
especificação
 Definição
de função ou entidade
 Descrição das entradas e de sua
procedência
 Descrição das saídas e seu destino
 Indicação de dependência de outras
entidades
 Pre-condições e pós-condições
ECLIP SE/W orkstati on/Tool s/ DE/FS/ 3.5.1
Function
Add node
Descripti on
Addsa node to an exi st ing design. The user sel ects t he type of node, and it s posi ti on.
When added to the design, the node becomes
the current select ion. The user chooses the node posi ti on by
movi ng t he cursor t o the area where t he node is added.
Inputs Node type, Node posit ion, Design ident ifi er.
Source
Node type and Node posit ion are i nput by the user, Desi gn i denti fier from the database.
Outputs
Design ident ifi er.
Desti nati on
operati on.
The design database. The design is committ ed t o the database on compl et ion of the
Requires
Design graph rooted at input design ident ifi er.
Pre-conditi on
The design is open and displ ayed on the user's screen.
Post-condi tion
at t he given posi tion.
The design is unchanged apart from t he
addit ion of a node of the specified t ype
Side-ef fects
None
Def init ion: ECLIPSE/W orkstati on/ Tools/DE/RD/3.5.1
 Muitos
sistemas operam em conjunto com
outros sistemas. Interfaces entre tais
sistemas devem ser especificadas como
parte dos requisitos
 Três tipos de interfaces podem ser
definidas:
• Interfaces de Procedimentos
• Estruturas de dados que serão intercambiadas
• Representação de dados
 Notações
formais são uma técnica efetiva
para especificação de interfaces
 Requisitos
especificam o que o sistema deve
fazer e definem restrições quanto a sua
operação e implementação;
 Requisitos funcionais especificam serviços
que o sistema deve prover;
 Requisitos não-funcionais restringem o
sistema sendo desenvolvido e/ou o processo
de desenvolvimento;
 Requisitos do usuário são especificações de
alto nível a respeito do que o sistema deve
fazer;
33
 Requisitos
do usuário devem ser escritos
em linguagem natural, tabelas e
diagramas;
 Requisitos do sistema tem como tarefa
comunicar as funcionalidades que o
sistema deve prover;
 Requisitos do sistema devem ser escritos
em linguagem natural estruturada ou
uma linguagem formal.
34
 R. S. Pressman, Engenharia
de Software,
McGraw Hill, 6a Ed., 2002. Chap. 7.
 I. Sommerville. Software Engineering. 7th Ed.
Addison-Wesley, 2004. Chap. 5.
35