O formulário foi enviado com sucesso.
Encontrará mais informações na sua caixa de correio.
Selecionar a língua
Neste artigo, vamos tentar explicar porque é que a especificação do desenvolvimento de software é tão importante e porque é que se deve dedicar a ela.
Inicialmente, os documentos SRS são criados para especificar os objectivos futuros da aplicação e a quantidade de trabalho a realizar pelo fornecedor de serviços de software. Assim, um esboço detalhado permite que os programadores percebam como podem implementar e construir o software. Posteriormente, a especificação ajuda-o a verificar o software que foi desenvolvido e a verificar se tem todas as características necessárias implementadas. A elaboração de um bom documento SRS deve ser iniciada ainda antes do desenvolvimento propriamente dito. Pode haver casos em que o software criado não satisfaça os requisitos necessários, e é aí que as especificações entram em ação, pois são a fonte de referência para os programadores e, depois de estudarem as SRS, podem continuar a trabalhar no software para satisfazer os requisitos existentes.
Assim, a criação de uma especificação técnica de alto nível é o primeiro passo mais importante em qualquer projeto, e tem de ser compreendida tanto pelos responsáveis pelo desenvolvimento do software como pelos proprietários do software. O documento SRS orienta a equipa na conceção e desenvolvimento do software. Assim, se fornecer uma especificação completa e inequívoca, há uma grande hipótese de dedicar menos tempo ou mesmo nenhum tempo à correção, redefinição e reimplementação do seu software. Quanto mais cedo o problema for descoberto, mais eficazmente poderá afetar o tempo, uma vez que atualizar uma especificação antes de iniciar o desenvolvimento é mais simples do que a funcionalidade que já existe. Normalmente, uma especificação técnica é o resultado da primeira conversa entre o cliente e a equipa de desenvolvimento, porque é utilizada como referência para estimar o tempo e os custos do projeto. E como inicialmente um documento SRS se destina a fornecer um esboço detalhado do software a desenvolver, é muito mais rápido e fácil realizar a estimativa exacta do projeto.
Além disso, como a construção de uma aplicação é um processo contínuo, as pessoas que participam no projeto mudam quase constantemente. Assim, quando o projeto for entregue a outra parte da equipa, a especificação será absolutamente indispensável. Não é uma boa razão para se sentar e fazer um SRS?
Uma especificação de alto nível significa também que será mais fácil atualizar o produto de software. O SRS tem de ser atualizado sempre que houver uma modificação e, neste caso, todos os membros devem estar envolvidos na reconsideração das futuras alterações.
Por isso, como dissemos anteriormente, é absolutamente necessário elaborar um documento SRS de elevada qualidade.
Como é que escrevo um bom documento SRS? Aqui vamos falar sobre as principais regras que devem ser seguidas ao escrever uma especificação.
1. Apenas uma pessoa deve escrever as especificações. É claro que há muitos membros da equipa que contribuem com ideias incríveis para este documento, no entanto, deve ser apenas uma pessoa a reunir todas as ideias numa proposta sólida.
2. O SRS não é uma espécie de manual. É claro que um SRS contém algo que ainda não existe, mas isso não significa que tenha de descrever todos os pormenores. Não mergulhe profundamente em todas as pequenas coisas, inclua apenas as que são realmente significativas.
3. Não faça com que a sua escrita pareça aborrecida. Se entender que a informação que escreveu é aborrecida, então há poucas hipóteses de alguém gostar de a ler.
4. Não tente terminá-lo a todo o custo. Não há problema nenhum em deixar de lado algumas partes, como o TBD. Se apenas informar os leitores de que isto é o que deve ser feito e certificar-se de que terminou todas as ideias antes do arranque.
5. Ter em conta que não haverá uma segunda versão. Algumas pessoas cometem um erro comum quando começam a pensar que há uma hipótese de propor uma solução a curto prazo, uma vez que haverá uma reescrita em breve. Infelizmente, isso é muito improvável, uma vez que os sistemas raramente são substituídos, sendo apenas corrigidos e alargados com o passar do tempo. Pode indicar alguns componentes e processos que podem ser melhorados posteriormente, mas não se esqueça de que as principais decisões de conceção vão durar muito tempo.
Diz-se que "bem começado é meio caminho andado", por isso, se escrever uma boa introdução, estará a meio caminho do sucesso. Em primeiro lugar, é necessário definir o objetivo do produto. A introdução fornece um resumo de todo o documento, especifica a ideia do projeto e é um componente significativo das especificações do software.
Antes de começar a construir a aplicação, tem de conhecer a situação do mercado no nicho que pretende ocupar, e não se esqueça de pesquisar o nível de concorrência, porque diferentes factores, incluindo os acima mencionados, podem afetar os requisitos. Os seus leitores serão provavelmente os peritos actuais e futuros que se ocuparão das suas tarefas e precisam de compreender o ambiente empresarial. Quando o contexto empresarial for evidente, pode definir as principais prioridades e organizar o processo de desenvolvimento de software.
Outro ponto que deve ser mencionado na secção de introdução é a quantidade de trabalho no projeto futuro. Aqui, deve falar sobre as especificações do produto: as suas vantagens, características únicas, objectivos e assim por diante. É essencial fazer uma estimativa exacta do projeto e tornar produtiva a cooperação com o seu fornecedor de serviços.
Outro ponto crucial a mencionar na introdução é o seu público-alvo: quem vai utilizar este software, quais são as suas expectativas e preferências. Uma boa ideia seria pensar num acesso limitado a alguns grupos de utilizadores, nos dispositivos que os utilizadores irão utilizar e na sua localização.
Se quiser, também pode incluir a secção de abreviaturas e definições para evitar confusões, o que é totalmente da sua responsabilidade. Normalmente, os programadores fazem um bom trabalho quando a aplicação se destina a uma área específica, como os cuidados de saúde ou o sector automóvel.
Lembre-se: quando escreve, o seu princípio básico deve ser o princípio do geral para o específico. Por isso, antes de passar diretamente para as especificações técnicas do produto, é necessário fornecer uma visão geral do mesmo. Um bom começo é mencionar se se trata de uma nova aplicação ou de uma aplicação atual que precisa de ser alterada.
Em seguida, devem ser mencionadas as principais interfaces e elementos estruturais. Pode utilizar conteúdos visuais para apoiar as suas palavras e ajudar os seus leitores.
Em seguida, pode passar para os modos e estados do futuro sistema, requisitos gerais, o que deve ser capaz de fazer e quais são as suas limitações. Não é necessário fazer aqui uma descrição exaustiva, uma vez que voltará a este ponto mais tarde no seu documento.
Não se esqueça de incluir conjecturas e dependências (os elementos que podem ter impacto no facto de esta variante do SRS ser relevante). Deve mencioná-los para reduzir os riscos potenciais. Por último, mas não menos importante, estão os cenários operacionais, ou seja, a forma como os elementos do sistema interagem entre si, com o ambiente e com o utilizador. Uma boa maneira de mostrar a sua interação é criar uma cadeia de eventos que ocorrem com o utilizador.
Esta parte é da maior importância, por isso, certifique-se de que delineia os elementos de forma exaustiva, pois é a secção que ajuda os programadores, designers e outros membros da equipa a compreender as suas ideias e requisitos.
Aqui descrevemos os requisitos que podem ser subdivididos em dois grupos: não funcionais e funcionais. Os primeiros podem ser bastante semelhantes para uma série de sectores. Descrevem o desempenho do sistema e o principal componente aqui é o documento de requisitos comerciais que contém as antecipações e as necessidades dos utilizadores finais.
O segundo tipo de requisitos descreve o comportamento do sistema, ou seja, o que se espera que ele faça em vários casos.
Seguem-se os requisitos lógicos dos dados. Caso tenha dificuldades em escrever esta parte, pense no processamento de dados no sistema, no seu tipo, na forma como estão organizados e ligados. A criação de um modelo visual é uma óptima solução.
A RTM (Matriz de rastreabilidade dos requisitos) é um instrumento especial que permite verificar se todos os requisitos para os testes são satisfeitos. Esta secção do SRS garante o bom desenrolar do processo de desenvolvimento. A matriz de rastreabilidade dos requisitos é uma tabela que contém todos os elementos do documento técnico e os pedidos de alteração.
O aspeto deste documento depende da empresa que o produz.
A partir do momento em que decide iniciar o desenvolvimento do seu software (website, aplicação móvel, etc.), certifique-se de que o seu primeiro passo é criar uma SRS de alta qualidade. As especificações devem ser escritas para benefício dos futuros clientes do seu software e da equipa de desenvolvimento de software, pelo que as SRS devem ser claras e precisas. Dedicar tempo e esforço à elaboração de uma boa especificação resultará na construção do software que o seu cliente necessita e espera.
Se tiver problemas ao escrever o seu próprio SRS, entre em contacto connosco e teremos todo o prazer em ajudar.
Avaliar este artigo:
4.9/5 (42 comentários)
Conteúdo relacionado
Após termos recebido e processado o seu pedido, entraremos em contacto consigo para detalhar as necessidades do seu projecto e assinar um NDA para garantir a confidencialidade das informações.
Após a análise dos requisitos, os nossos analistas e programadores elaboram uma proposta de projecto com o âmbito dos trabalhos, tamanho da equipa, tempo e custos e custos.
Marcamos uma reunião consigo para discutir a oferta e chegar a um acordo.
Assinamos um contrato e começamos a trabalhar no seu projecto o mais rapidamente possível.
Ao inscrever-se, concorda com os nossos Termos de utilização e Política de privacidade, incluindo a utilização de cookies e a transferência das suas informações pessoais.
© 2007-2024 Innowise. Todos os direitos reservados.
Política de privacidade. Política de cookies.
Innowise Sp. z o.o Ul. Rondo Ignacego Daszyńskiego, 2B-22P, 00-843 Varsóvia, Polónia
Obrigado!
A sua mensagem foi enviada.
Processaremos o seu pedido e contactá-lo-emos o mais rapidamente possível.
Obrigado!
A sua mensagem foi enviada.
Processaremos o seu pedido e contactá-lo-emos logo que possível.