Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • D digitec-wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Digitec
  • digitec-wiki
  • Wiki
  • digitec spec process

digitec spec process · Changes

Page history
rcabral created page: digitec-spec-process authored Feb 05, 2014 by Rene Cabral's avatar Rene Cabral
Hide whitespace changes
Inline Side-by-side
digitec-spec-process.markdown
View page @ ea09de2b
......@@ -13,7 +13,13 @@ In every specification, unambiguous language is of paramount importance and to t
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
###### REF - [Key words for use in RFCs to Indicate Requirement Levels](https://vc.digitec.local/digitec/digitec-wiki/blob/master/wiki-assets/files/rfc/rfc2119.txt)
---
Words matter, especially when you are legally binding yourself to the delivery of services. The language you use in the specification should observe a criteria that ensures clarity for both the developer (writer of the spec) and the client.
Words matter, especially when you are legally binding yourself to the delivery of services. The language you use in the specification should observe a criteria that ensures clarity for both the developer (writer of the spec) and the client. As a rule both the developer and the client need to sign off on the specification before work begins.
It may be worth noting that at times the role of client can be played played by the project manager or other personnel requesting the job. Although this spec is destined for internal use, it is just as necessary as one that is destined for a client.
The end result should be that the developer is ensured a properly scoped job, in which the requirements he must satisfy are clear. Any new requirements that come up can be confidently labeled _out of scope_ and the developer is protected from having to fulfill them without a re-negotiation. For the client it means, a clear articulation of the job requirements which legally ensure that the client is getting what he paid for.
The following text is a great guideline for the type of language that you need to use when writing a specification.
Specifications are printed documents that establish procedures and requirements for a particular project. Specifications are legally enforceable as contract documents and must be prepared with concern and respect of their legal status. Specifications should include the correct use of words and grammar with properly constructed sentences and paragraphs. Specifications must be clear, correct, complete, and concise using these guidelines:
......
Clone repository
  • alpha beta testing
  • browser testing
  • camtasia licenses
  • code delivery processes
  • coding practices
  • css and sass coding standards
  • database schema standards
  • dependency management
  • development environments
  • digitec agile process
  • digitec gitlab styles
  • digitec software promises
  • digitec spec process
  • gitlab administration
  • gitlab issues tags
View All Pages