#Product label
A software requirements specification (SRS document) describes how a software system should be developed. Simplificando, um SRS fornece a todos os envolvidos um roteiro para esse projeto.ele oferece definições de alta qualidade para as especificações funcionais e não funcionais do software, e também pode incluir casos de uso que ilustram como um usuário iria interagir com o sistema após a conclusão.,nota: deixe-nos ajudá-lo a escrever uma especificação de requisitos de Software. Solicite uma chamada com o nosso CTO preenchendo este formulário.
Índice
por que é importante um documento SRS?
suponha que deseja criar uma aplicação de chat com uma aparência e funcionalidade específicas e gostaria que fosse orientada especificamente para as empresas. Você sente que pode cortar os recursos extras que aplicativos de chat comercial usam para apelar ao público e se concentrar em recursos que as empresas precisam. Mas tu não és uma desenvolvedora.,
então você precisa terceirizar o desenvolvimento da aplicação. Mas também tens de ter a certeza que quem contratares para transformar a tua ideia em realidade sabe exactamente o que estás a tentar realizar. Sem todos os detalhes para terminar o aplicativo, tempo e custo pode rapidamente sair do controle. Os desenvolvedores podem tomar um caminho errado e têm que refaturar o código se o produto acabado não corresponde à imagem que você tinha em sua cabeça.
um documento SRS obriga você a colocar a idéia no papel para cobrir todos estes detalhes. Você deve traduzir esta ideia para uma linguagem que os desenvolvedores entendem., Um documento SRS descreve o que um cliente quer e o que os desenvolvedores irão fornecer. É o acordo escrito sobre todos os detalhes do aplicativo.ter um conjunto claro de requisitos garante que uma equipe de desenvolvimento cria software que atende às necessidades dos clientes. Um SRS ajudará a estimar o custo do trabalho e a cobrir o âmbito do projecto. Ele também dá aos programadores uma idéia da pilha de tecnologia que eles vão precisar e os ajuda a planejar seu trabalho, mas isso não é tudo:
- Designers obter insights do projeto através de documentos SRS para que eles possam combinar o projeto com o caso de uso.,
- Testadores obter as Diretrizes para a criação de casos de teste que correspondem às necessidades do negócio.os utilizadores finais utilizam a SRS para compreender o software.fornece aos investidores uma visão geral das características do sistema para que possam tomar decisões de investimento.
um SRS é importante porque é uma única fonte de informação e expectativas, o que evita mal-entendidos entre gestores de projeto, desenvolvedores, designers e testadores.
o que inclui um SRS?,
um SRS deve ter informações suficientes para que os desenvolvedores completem o software descrito. Ele não só estabelece a descrição do software em desenvolvimento, mas também o propósito que ele vai servir: o que o software é suposto fazer e como ele deve executar.,o software ou o que é suposto fazer
A Diferença Entre Funcionais e Não-funcionais os Requisitos
os requisitos Funcionais são os objetivos do novo sistema que está desenhando., Eles descrevem o sistema e como ele funcionará para ajudar com as tarefas de um usuário. Eles definem como o sistema vai responder à entrada do Usuário e tem detalhes sobre cálculos, dados de entrada e processos de negócios. Você pode considerar os requisitos funcionais uma descrição detalhada das características da aplicação e as necessidades do Usuário. Sem cumprir os requisitos funcionais, o sistema não funcionará.embora os requisitos funcionais especifiquem o que um sistema faz, os requisitos não funcionais descrevem como o sistema o fará. Os requisitos não funcionais não afetam a funcionalidade da aplicação., Mesmo sem cumprir requisitos não funcionais, o sistema irá realizar as tarefas desejadas.os requisitos não funcionais também são importantes porque definem as características gerais que afectam a experiência do utilizador. Em vez de se concentrarem nos requisitos dos utilizadores, concentram-se nas expectativas dos utilizadores e abrangem temas como desempenho, segurança, fiabilidade, disponibilidade e usabilidade.,
Como Escrever um Documento de Especificação de requisitos de Software
por Isso, é melhor para organizar o processo que você usa para escrever um SRS documento, iniciando com um esqueleto e informações gerais sobre o software que está em desenvolvimento, e acabamento de adicionar detalhes para concretizar o seu projecto. Aqui estão seis passos envolvidos na criação de um documento SRS:
Get Software Requirements Specification Document
we helped 200+ companies build their software products. Contrate nosso analista de negócios com 6 anos de experiência para escrever um SRS para você.,
requisitar SRS
criar um esboço
o primeiro passo no processo é criar um esboço para a sua SRS. Você pode criar isso você mesmo ou usar um modelo SRS existente como um ponto de partida. Aqui está um exemplo básico de um SRS contorno:
faça o Download do ebook
- Introdução
- Objetivo
- Público-alvo
- se Pretende Utilizar
- Escopo
- Definições
- Descrição Geral
- as Necessidades do Usuário
- Suposições e Dependências
- Os Recursos de sistema e Requisitos de
- Requisitos Funcionais
- Interface Externa Requisitos
- Funcionalidades do Sistema
- Requisitos Não-funcionais
Definir o Propósito
uma Vez que você tenha uma estrutura de tópicos, você deve carne-lo., Comece por definir o objectivo do produto na introdução das suas SRS. Aqui você vai descrever o público pretendido e como eles vão usar o produto. Aqui está como você deve estruturar a finalidade:
- Defina o escopo do produto
- descreva o valor que ele irá entregar
- mostre quem irá usar o software
- detalhe como ele irá ajudar com o trabalho dos usuários pretendidos
dê uma visão geral
Depois de definir a finalidade do produto, resuma como ele irá funcionar., Aqui você vai dar uma descrição geral das características do software e como eles se adequam às necessidades do Usuário.
Você também irá descrever as suposições que você está fazendo sobre a funcionalidade do produto e qualquer coisa que depende no ecossistema de tecnologia atual.
descreva requisitos funcionais e não funcionais
Agora que você escreveu a informação geral, é hora de ficar mais específico. Completar a sua visão geral antes de trabalhar em requisitos funcionais e não funcionais dá-lhe uma referência para se certificar de que satisfaz as necessidades básicas do utilizador enquanto preenche os detalhes.,Esta descrição detalhada dos requisitos do sistema é o componente mais essencial de um documento SRS. Descreva os requisitos funcionais com bastante detalhe para que os desenvolvedores possam começar a trabalhar e os requisitos não funcionais, como especificações de segurança e desempenho.
aqui é onde você adiciona casos de uso para descrever vividamente como um usuário irá interagir com o seu sistema. É onde os objetivos do seu projeto são detalhados e irão medir como o projeto está progredindo durante o desenvolvimento.,
adicionar detalhes suplementares
a última etapa na criação do rascunho do seu documento SRS é adicionar quaisquer detalhes que possam ajudar os desenvolvedores a terminar o trabalho na forma de apêndices, glossários de termos e referências.
obter aprovação
Uma vez que você tenha adicionado detalhes suficientes ao SRS para descrever o que o sistema é suposto fazer, é hora de ter as partes interessadas aprovar o documento.
Você provavelmente terá que fazer uma apresentação para as pessoas envolvidas no processo de desenvolvimento., Eles podem pedir alterações, e você terá que atualizar o documento SRS com base no feedback das partes interessadas antes da aprovação final.este é um bom sinal. Significa que tanto os desenvolvedores quanto os stakeholders estão tornando o documento mais preciso, então o projeto é menos como sair do caminho.
como escrever Casos de Uso de Software em um SRS
um caso de Uso descreve como um usuário irá interagir com o sistema. Ele irá descrever o produto do ponto de vista do usuário final em um formato de história simples. Escrever casos de uso obriga você a pensar sobre o que os usuários farão com o software e como ele responderá., É a visualização da vida real dos requisitos funcionais.
Aqui estão os passos que você pode seguir para escrever um caso de uso:
- descreva os usuários finais do seu produto.
- Focus on one of these users.
- quebra as interacções deste utilizador em casos de Utilização. Cada interação é um caso de uso.descreva a sequência de eventos para cada caso de Utilização.
- escreva uma descrição detalhada das ações do Usuário e como o sistema deve responder.
- expanda cada caso de uso com ações alternativas do Usuário e Respostas do sistema.Repetir 1-6 para cada tipo de utilizador final.,
Quais são as características de um grande SRS?
existem características específicas que cada SRS deve ter. Ao rever esta lista e compará-la com a sua SRS, você pode garantir que ela será um documento útil para todas as partes interessadas.
explícito
um documento SRS deve ser fácil de compreender. Nada deve ser vago, pelo que não há mal-entendidos entre as partes interessadas.,
mensurável
os requisitos do seu documento SRS precisam ser mensuráveis, para que o produto acabado possa ser validado e verificado com base nas especificações.
completar
um documento SRS deve ter informação suficiente para a sua equipa de desenvolvimento terminar o produto e para os testadores validarem que o produto satisfaz as necessidades do Utilizador sem erros.
viável
os requisitos devem corresponder à realidade do ambiente actual, incluindo o orçamento, a cronologia e a tecnologia. Não devem depender dos avanços tecnológicos que se avizinham.,
flexível
porque as coisas podem mudar no ambiente de trabalho, o seu documento SRS deve ser suficientemente flexível para permitir actualizações. Não adicione informações redundantes a várias seções que têm de ser atualizadas com cada alteração.
verificável
todos na equipa de desenvolvimento devem ter acesso ao documento para que possam referenciá-lo com a frequência necessária. Os requisitos têm de ser precisos para que os membros da equipa não tenham de pedir mais pormenores. Todos eles devem estar disponíveis no documento SRS.,os requisitos devem caber uns aos outros. Uma seção de seu documento de requisitos não deve entrar em conflito com outra. O documento deve ser formatado de forma consistente e utilizado a mesma terminologia ao longo de todo o processo.
sem restrições de implementação
um documento SRS deve ser detalhado o suficiente para terminar a tarefa, mas não deve ser excessivamente específico, porque isso pode restringir o desenvolvimento. Um monte de desenvolvimento depende de serviços de terceiros que os desenvolvedores não têm controle sobre.,os objectivos num documento de requisitos devem ser precisos para evitar confusões. Evite o seguinte:
- lacunas: “a aplicação deve carregar em 3 segundos se puder ser feito.”
- ambiguidade: “o produto MVP deve ser lançado o mais rápido possível.subjetividade: a IU deve ser de fácil utilização.”
- superlativos: “esta deve ser a melhor aplicação em sua classe.”
- comparativo: “esta aplicação deve ser melhor do que frouxa.,”
A Software Requirement Specification (SRS) Example
here is a trimmed down example of an SRS document for an enterprise chat app called eChat:
Introduction
This document details the project plan for the development of ” eChat.”
é destinado a desenvolvedores, designers e testadores que trabalham em “eChat”, bem como investidores de projetos., Este plano irá incluir um resumo de:
- como o sistema irá funcionar
- o escopo do projeto a partir do ponto de vista de desenvolvimento
- tecnologia utilizada para desenvolver o projeto, e
- as métricas utilizadas para determinar o progresso do projeto
- Descrição Geral
as Empresas precisam remoto ferramentas de comunicação, especialmente agora que mais pessoas estão trabalhando a partir de casa. O problema é que a maioria das empresas acaba usando várias aplicações para realizar isso: uma para bate-papo de texto, uma para bate-papo de vídeo, e uma para conferências e reuniões., “eChat” irá resolver este problema combinando estas características em uma aplicação.
faça o Download do whitepaper
os Clientes
Os clientes serão empresas. Não terá como alvo o público em geral.
funcionalidade
- Os utilizadores devem ser capazes de se inscrever nas contas LDAP da empresa.,os utilizadores devem ser capazes de criar grupos de chat ad hoc que incluam conjuntos de utilizadores e enviem mensagens privadas a utilizadores individuais.
- Os usuários devem ser capazes de ter conversas de texto que eles podem quebrar em threads.
- A aplicação deve ser capaz de lidar com conversação de vídeo em grupo de até 100 usuários de cada vez.
plataforma
a aplicação será desenvolvida em Reat Native para permitir a criação de uma aplicação baseada na web, um aplicativo móvel iOS e um aplicativo móvel Android.
estas aplicações irão ligar-se a uma API de descanso construída com .,Núcleo da rede para armazenar e recuperar dados de um banco de dados MySQL.a autenticação
será feita através das instalações LDAP existentes.
responsabilidades de desenvolvimento
os desenvolvedores da equipe” eChat ” serão responsáveis por escrever todo o código para a aplicação, desenvolver a base de dados e gerenciar lançamentos.,
Classe de Usuário e Características
Haverá uma classe de usuários chamado de administrador que tem permissões para aceder a todas as funcionalidades do aplicativo, incluindo:
- Criar canais, onde vários usuários podem interagir
- Fazer esses canais públicos para toda a empresa ou privado para um grupo de pessoas
- Excluir esses canais
- Arquivamento destes canais
Padrão, os usuários terão acesso a todas as funcionalidades do aplicativo, exceto aqueles listados acima.,os utilizadores devem ser capazes de criar grupos de chat ad hoc que incluam conjuntos de utilizadores e enviar mensagens privadas a outros utilizadores.
Interfaces de utilizador
- Software de primeira linha: Reat Native
- Software de segunda linha: .,s sistemas operacionais através de seu navegador da web padrão
- iPhone
- Android
- Requisitos Não-Funcionais
Requisitos de Desempenho
- A aplicação deve carregar e ser utilizável dentro de 3 segundos
- A aplicação deve atualizar a interface de interação dentro de 2 segundos
- O banco de dados deve ser normalizado para evitar dados redundantes e melhorar o desempenho
- O banco de dados deve ser distribuído para evitar interrupções
Requisitos de Segurança
- Bancos de dados deve usar sharding ser redundantes para evitar a perda de dados.,as cópias de segurança das bases de dados devem ser feitas de hora a hora e mantidas durante uma semana.todas as chaves utilizadas para a API de resto devem ser guardadas de forma segura.
- apenas a API restante deve ser capaz de se conectar às bases de dados.as bases de dados devem estar por detrás de uma firewall.
atributos de qualidade do Software
- disponibilidade: como esta aplicação é fundamental para a comunicação de negócios, teremos um objetivo de quatro noves(99.99%) disponibilidade.,correcção: a aplicação nunca deve permitir que ninguém leia mensagens ou discussões não destinadas a essa pessoa.
- Maintainability: a aplicação deve usar integração contínua para que as funcionalidades e correções de erros possam ser implantadas rapidamente sem tempo de inatividade.usabilidade
- : A interface deve ser fácil de aprender sem um tutorial e permitir que os usuários cumpram seus objetivos sem erros.
resumo
um documento SRS é uma parte necessária para completar um projeto de desenvolvimento de software., É o roteiro que dá direção a todos os envolvidos no projeto, de modo que o produto final atende às necessidades do Usuário.
sem um documento SRS completo no lugar antes de iniciar um projeto, será difícil dizer quando um projeto está terminado e poderia desviar o desenvolvimento para a criação de recursos não intencionais. Um documento SRS lhe dá a capacidade de estimar um projeto com precisão e atribuir tarefas de forma eficiente.
criar um documento SRS pode ser um processo demorado e meticuloso., Felizmente, a equipe do Relevant ajudou mais de 200 empresas a criar documentos SRS e lançar novos produtos. Estamos prontos para ajudar com o seu próximo projeto de software, basta deixar-nos uma linha.