... | ... | @@ -6,10 +6,6 @@ The first step you must take as a developer BEFORE starting any project and BEFO |
|
|
|
|
|
It is worth noting that, as a general rule, implementors are usually 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.
|
|
|
|
|
|
The project manager should always consult the implementor prior to finalizing the specification in order to identify gaps in functional assumptions, understandings of technology, as well as implied time commitments. Based on the information gleaned the specification can be adjusted accordingly.
|
|
|
|
|
|
If the final specification leads to a conflict with client expectations then either the clients expectations need to be managed or the requirements will need to be adjusted to meet the clients expectations.
|
|
|
|
|
|
### 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.
|
... | ... | @@ -48,7 +44,7 @@ A key point to remember in software specification is that you are writing from a |
|
|
2. __Requirements__: write down all the project requirements as you understand them. Feel free to categorize them into logical groups.
|
|
|
3. __Assumptions__: write down all the general assumptions you have made regarding the project. These assumptions are part of the spec and help delineate the scope of the project. They can include, server software, supported browsers, data supplied in specific formats, etc.
|
|
|
4. __Consultation__: if you are a project manager, you should always consult the implementor prior to finalizing the specification in order to identify gaps in functional assumptions, understandings of technology, as well as implied time commitments based on the complexity of the requirements. Based on the information gleaned the specification can be adjusted accordingly.
|
|
|
5. __Client Agreement__: the final specification if presented to the client, it is supposed to be an exact representation of the scope of the work. If the final specification leads to a conflict with client expectations then the requirements can be negotiated or the adjusted to meet the clients expectations. In the latter case the cycle begins again at step 1.
|
|
|
5. __Client Agreement__: the final specification if presented to the client, it is supposed to be an exact representation of the scope of the work. If the final specification leads to a conflict with client expectations then the requirements can be negotiated or adjusted to meet the clients expectations. In the latter case the cycle begins again at step 1.
|
|
|
|
|
|
### Use Case
|
|
|
|
... | ... | |