Requisitos compreendidos, analisados e aceitos. Agora é só documentar. A proposta de integração do processo associado ao projeto de interação ao UML ajuda a identificar o momento em que o projeto de interação deve ser realizado (Blaschek, 2002). É a representação dos resultados obtidos até agora, em um documento oficial e formal que contém os requisitos do software com descrições detalhadas sobre o que ele fará, mas ainda sem descrever como fazer o software em termos de tecnologia ou linguagem de programação a ser adotada, por exemplo. Esse documento deve estar correto, sem ambigüidades, completo, consistente, classificado por importância e/ou estabilidade dos requisitos, verificável, modificável e rastreável, além de ser entendível pelos usuários, organizado e conciso. Não há um nome padrão para esse documento, podendo ser adotado, dentre outros, “Especificação de Requisitos de Software (ERS)”, “Documento de Requisitos” ou “Especificação Funcional”.
Este documento descreve:
- o escopo e os objetivos do software;
- os serviços e as funções que o software deve fornecer;
- as informações sobre o domínio de aplicação do software;
- as restrições sob as quais o software deve operar;
- as propriedades gerais do software, tais como atributos de qualidade e desempenho;
- as definições de outros softwares com os quais deve interagir; e
- as restrições ao processo de desenvolvimento adotado.
Uma informações importante neste documento é indicar a fonte dos requisitos, seja uma pessoa, um grupo ou documento. Outras informações importantes são os problemas que se pretende resolver, além das razões e justificativas da escolha de cada solução ou decisão tomada, as demais alternativas consideradas, os fatores avaliados e as argumentações que guiaram cada decisão ou solução. Estes dados adicionais enriquecem a visão do software.
O documento pode ser descrito em linguagem natural, em notações e linguagens semi-formais ou formais. Combinações também são possíveis.
- A linguagem natural facilita a comunicação, pois é expressiva e flexível, mas é pobre para capturar as semânticas do modelo, possibilita ambigüidades. Permite um fácil entendimento pelos usuários, mas a ausência de semântica possibilita a livre interpretação.
- Uma notação semi-formal reflete a estrutura e utiliza semântica com alguma verificação de consistência – é o caso da UML (Unified Modeling Language) com diagramas e relacionamentos.
- Os métodos formais descrevem artefatos de software de forma difícil de compreensão e, por isso, requerem maior tempo de aprendizado, pois não são legíveis para usuários não técnicos.
Não existe um limite claro entre a engenharia de requisitos e o início da fase de projeto do software dando margem ao dilema “o que” versus “como”. Os requisitos são obtidos na engenharia de requisitos (“o que”) ao passo em que são organizados, agrupados e documentados na hierarquia proposta para o projeto de arquitetura (“como”), de forma a organizar uma estrutura de sub-sistemas para o projeto.
Algumas diretrizes propostas ajudam a melhorar a estrutura e organização do documento:
- definir uma estrutura padrão para o documento, contendo, em geral, uma parte comum, mas permitindo algumas variantes e seções opcionais;
- explicar como cada classe de leitores deve usar o documento;
- incluir um sumário de requisitos;
- incluir uma seção explicando por que o software é necessário e como irá contribuir para os objetivos gerais de negócio da organização;
- definir termos especializados em um glossário;
- organizar o leiaute do documento para facilitar a leitura;
- auxiliar os leitores a encontrar a informação, incluindo recursos tais como listas de conteúdo e índices e organizando os requisitos em capítulos, seções e sub-seções identificadas; e
- tornar o documento fácil de alterar.
0 comentários:
Postar um comentário