|
|
|
###### [Home](home) / [Digitec Coding Practices](coding-practices) / Digitec Specification Process
|
|
|
|
###### [Home](home) / [Digitec Coding Practices](coding-practices) / Digitec Software Promises
|
|
|
|
|
|
|
|
---
|
|
|
|
|
| ... | ... | @@ -7,18 +7,20 @@ |
|
|
|
|
|
|
|
###### Preamble
|
|
|
|
|
|
|
|
During the stages of client engagement, the following instances
|
|
|
|
During the stages of client engagement, the project manager will request information from the software engineering department in order to make fulfillment promises to the client.
|
|
|
|
|
|
|
|
It is worth noting that, as a general rule, implementors are discouraged from creating the specification for a project that they will be working on. Implementation details tend to cloud and weaken the conceptual integrity of a specification. Thus, it is preferred that the project manager be responsible for creating the specification.
|
|
|
|
Software promises at Digitec can not be made without two official documents which are generated by the Software Engineering Department:
|
|
|
|
|
|
|
|
- [Software Requirements Specification (SRS)](digitec-spec-process)
|
|
|
|
- Time Estimate
|
|
|
|
|
|
|
|
### The Guidelines:
|
|
|
|
---
|
|
|
|
For large projects we use an abbreviated form of the IEEE SRS standard which relies on the functional requirements section. This document is also a great overall reference for learning about software specifications.
|
|
|
|
###### REF - [830-1998 - IEEE Recommended Practice for Software Requirements Specifications](https://vc.digitec.local/digitec/digitec-wiki/blob/master/wiki-assets/files/specification/IEEE%20830-1998-SRS-template.pdf)
|
|
|
|
---
|
|
|
|
In every specification, unambiguous language is of paramount importance and to that end it is useful to reference the _Key words RFC_ which clearly specifies the use of the words:
|
|
|
|
"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)
|
|
|
|
The only binding documents for software production are the SRS and the Time Estimate related to that SRS.
|
|
|
|
All SRS must be approved by a Senior Software Engineer.
|
|
|
|
All Software Architecture requirements must be approved by a Senior Software Engineer.
|
|
|
|
All Server Deployment Architecture requirements must be approved by a Senior Software Engineer.
|
|
|
|
All UI Mockups and interactions that must be realized through software (CSS, HTML, Javascript), require an SRS and its related Time Estimate.
|
|
|
|
---
|
|
|
|
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 specification) and the client. As a rule both the developer and the client need to sign off on the specification before work begins.
|
|
|
|
|
| ... | ... | |
