{"id":147,"date":"2014-02-01T09:31:57","date_gmt":"2014-02-01T12:31:57","guid":{"rendered":"http:\/\/www.hectordufau.com.br\/wp\/?p=147"},"modified":"2014-06-27T23:17:47","modified_gmt":"2014-06-28T02:17:47","slug":"como-escrever-um-documento-de-requisitos-de-software-drs","status":"publish","type":"post","link":"https:\/\/www.hectordufau.com.br\/wp\/?p=147","title":{"rendered":"Como escrever um Documento de Requisitos de Software (DRS)"},"content":{"rendered":"

Este artigo \u00e9 baseado no padr\u00e3o IEEE Std 830-1998 (IEEE Recommended Practice for Software Requirements Specifications).<\/p>\n

Esta pr\u00e1tica recomendada tem como objetivo a especifica\u00e7\u00e3o de requisitos de software a ser desenvolvido, mas tamb\u00e9m pode ser usada na escolha de produtos comerciais de software. No entanto, a sua aplica\u00e7\u00e3o a software j\u00e1
\ndesenvolvido pode ser contra-producente.<\/p>\n

Quando o software est\u00e1 embebido em sistemas de grande escala, como sejam equipamentos m\u00e9dicos, ent\u00e3o tudo o que est\u00e1 fora do \u00e2mbito deste documento deve ser visto em particular.<\/p>\n

Esta recomenda\u00e7\u00e3o pr\u00e1tica descreve o processo da cria\u00e7\u00e3o de um produto e o conte\u00fado desse mesmo produto. O produto \u00e9 um Documento de Requisitos de Software (DRS). Estas recomenda\u00e7\u00f5es pr\u00e1ticas podem ser usadas para criar um DRS ou podem ser usadas como modelo para um padr\u00e3o mais espec\u00edfico.<\/p>\n

Esta recomenda\u00e7\u00e3o pr\u00e1tica n\u00e3o identifica nenhum m\u00e9todo, nomenclatura ou ferramenta espec\u00edfica para a prepara\u00e7\u00e3o de um DRS.<\/p>\n

 <\/p>\n

1. Natureza do DRS<\/strong><\/p>\n

O DRS \u00e9 uma especifica\u00e7\u00e3o particular de um software, produto, programa ou conjunto de programas que executam certas fun\u00e7\u00f5es num ambiente espec\u00edfico. O DRS pode ser escrito por um ou mais representantes do fornecedor, um ou mais representantes do cliente, ou por ambos.<\/p>\n

Quem escreve um documento de EES deve sempre ter em conta os seguintes pontos base:<\/p>\n

    \n
  1. Funcionalidade. O que deve fazer o software?<\/li>\n
  2. Interfaces externas. Como interage o software com as pessoas, com o hardware do sistema, com outro hardware, e com outro software?<\/li>\n
  3. Performance. Qual \u00e9 a velocidade, disponibilidade, tempo de resposta, tempo de recupera\u00e7\u00e3o das v\u00e1rias fun\u00e7\u00f5es do software, etc.?<\/li>\n
  4. Atributos. Quais as considera\u00e7\u00f5es relativas \u00e0 portabilidade, correc\u00e7\u00e3o, mantenabilidade, seguran\u00e7a, etc.?<\/li>\n
  5. Restri\u00e7\u00f5es de desenho impostas numa implementa\u00e7\u00e3o. Existem exig\u00eancias padr\u00e3o, linguagem de implementa\u00e7\u00e3o, pol\u00edticas para integridade da base de dados, limites de recursos, ambientes operacionais, etc.?<\/li>\n<\/ol>\n

    Quem escreve deve evitar introduzir exig\u00eancias de desenho ou de projeto no DRS.<\/p>\n

     <\/p>\n

    2. Caracter\u00edsticas de um bom DRS<\/strong><\/p>\n

    Um DRS deve ser:<\/p>\n

      \n
    1. Correto. Um DRS est\u00e1 correto se, e s\u00f3 se, todas as exig\u00eancias expressas nele ser\u00e3o correspondidas pelo software.<\/li>\n
    2. N\u00e3o amb\u00edguo. Um DRS \u00e9 n\u00e3o amb\u00edguo se, e s\u00f3 se, todas as exig\u00eancias expressas nele t\u00eam apenas uma \u00fanica interpreta\u00e7\u00e3o. Como m\u00ednimo, isto requer que cada caracter\u00edstica do produto final seja descrita usando termos simples e \u00fanicos.<\/li>\n
    3. Completo. Um DRS \u00e9 considerado completo se, e s\u00f3 se, inclui os seguintes elementos: Todas as exig\u00eancias significantes, quer se prendam com a funcionalidade, o desempenho, restri\u00e7\u00f5es de desenho,
      \natributos, ou interfaces externas (em particular, quaisquer exig\u00eancias externas impostas por especifica\u00e7\u00f5es de sistemas) est\u00e3o reconhecidas e tratadas. Est\u00e3o definidas as respostas do software a todas as classes realiz\u00e1veis de entradas de dados em todas as classes de situa\u00e7\u00f5es. Legendas e refer\u00eancias completas para todas as figuras, tabelas e diagramas do documento de EES bem como a defini\u00e7\u00e3o de todos os termos e unidades de medida.<\/li>\n
    4. Consistente. Consist\u00eancia refere-se \u00e0 consist\u00eancia interna. Se um DRS n\u00e3o est\u00e1 de acordo com um documento de mais alto n\u00edvel, tal como seja uma especifica\u00e7\u00e3o de exig\u00eancias de sistema, ent\u00e3o ele n\u00e3o est\u00e1 correto.<\/li>\n
    5. Classific\u00e1vel por import\u00e2ncia e\/ou estabilidade. Um DRS encontra-se classificado por import\u00e2ncia e\/ou estabilidade se cada exig\u00eancia nele contido tem associada um identificador de estabilidade e\/ou import\u00e2ncia.<\/li>\n
    6. Verific\u00e1vel. Um DRS diz-se verific\u00e1vel se, e s\u00f3 se, cada exig\u00eancia especificada \u00e9 verific\u00e1vel. Uma exig\u00eancia \u00e9 verific\u00e1vel se, e s\u00f3 se, existe um processo finito e de custo aceit\u00e1vel atrav\u00e9s do qual uma pessoa ou uma m\u00e1quina pode verificar que o produto de software cumpre essa exig\u00eancia. Em geral uma exig\u00eancia amb\u00edgua n\u00e3o \u00e9 verific\u00e1vel.<\/li>\n
    7. Modific\u00e1vel. Um DRS diz-se modific\u00e1vel se, e s\u00f3 se, a sua estrutura e estilo s\u00e3o tais que mudan\u00e7as a exig\u00eancias podem ser efetuadas de forma f\u00e1cil, completa e consistente, preservando simultaneamente estrutura e estilo.<\/li>\n
    8. Rastre\u00e1vel. Um DRS diz-se rastre\u00e1vel se cada uma das suas exig\u00eancias \u00e9 clara e facilitadora da identifica\u00e7\u00e3o da mesma exig\u00eancia em vers\u00f5es futuras do desenvolvimento ou da documenta\u00e7\u00e3o.<\/li>\n<\/ol>\n

       <\/p>\n

      3. Modelo de estrutura de um DRS<\/strong><\/p>\n

      O modelo apresentado aqui apenas sugere uma estrutura, entretanto n\u00e3o \u00e9 obrigat\u00f3rio usar os mesmos nomes dos seus componentes.<\/p>\n

        \n
      1. Introdu\u00e7\u00e3o\n
          \n
        1. Prop\u00f3sito<\/li>\n
        2. \u00c2mbito<\/li>\n
        3. Defini\u00e7\u00f5es, acr\u00f3nimos e abreviaturas<\/li>\n
        4. Refer\u00eancias<\/li>\n
        5. Organiza\u00e7\u00e3o<\/li>\n<\/ol>\n<\/li>\n
        6. Descri\u00e7\u00e3o geral\n
            \n
          1. Perspectiva do produto<\/li>\n
          2. Funcionalidades do produto<\/li>\n
          3. Caracter\u00edsticas do usu\u00e1rio<\/li>\n
          4. Restri\u00e7\u00f5es<\/li>\n
          5. Assun\u00e7\u00f5es e depend\u00eancias<\/li>\n<\/ol>\n<\/li>\n
          6. Requisitos espec\u00edficos\n
              \n
            1. Requisitos de Interface Externos\n
                \n
              1. Interfaces de Usu\u00e1rio<\/li>\n
              2. Interfaces de Hardware<\/li>\n
              3. Interfaces de Software\n
                  \n
                1. Interfaces de Comunica\u00e7\u00e3o<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n
                2. Caracter\u00edsticas de sistema\n
                    \n
                      \n
                    1. Caracter\u00edstica de sistema 1\n
                        \n
                      1. Introdu\u00e7\u00e3o\/Objectivo da caracter\u00edstica<\/li>\n
                      2. Est\u00edmulo\/Sequ\u00eancia de resposta<\/li>\n<\/ol>\n
                          \n
                        1. Requisitos Funcionais Associados\n
                            \n
                          1. Requisito Funcional 1<\/li>\n
                          2. Requisito Funcional n<\/em><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n
                          3. Caracter\u00edstica de sistema 2<\/li>\n
                          4. Caracter\u00edstica de sistema m<\/em><\/li>\n<\/ol>\n<\/ol>\n<\/li>\n
                          5. Requisitos de Performance<\/li>\n
                          6. Restri\u00e7\u00f5es de Desenho<\/li>\n
                          7. Atributos do Sistema de Software<\/li>\n
                          8. Outros Requisitos<\/li>\n<\/ol>\n<\/li>\n
                          9. Tabela de conte\u00fados<\/li>\n
                          10. Ap\u00eandices<\/li>\n
                          11. \u00cdndice remissivo<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

                            Este artigo \u00e9 baseado no padr\u00e3o IEEE Std 830-1998 (IEEE Recommended Practice for Software Requirements Specifications). Esta pr\u00e1tica recomendada tem como objetivo a especifica\u00e7\u00e3o de requisitos de software a ser desenvolvido, mas tamb\u00e9m pode ser usada na escolha de produtos […]<\/p>\n","protected":false},"author":1,"featured_media":150,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[46],"tags":[],"class_list":["post-147","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ferramentas"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.hectordufau.com.br\/wp\/wp-content\/uploads\/2014\/02\/requisitos.jpg?fit=800%2C600&ssl=1","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p4cTO8-2n","jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=\/wp\/v2\/posts\/147","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=147"}],"version-history":[{"count":4,"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=\/wp\/v2\/posts\/147\/revisions"}],"predecessor-version":[{"id":152,"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=\/wp\/v2\/posts\/147\/revisions\/152"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=\/wp\/v2\/media\/150"}],"wp:attachment":[{"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=147"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=147"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hectordufau.com.br\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=147"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}