Technical Specification
The purpose of a technical specification in a software development project is to define the customer's technical requirements that will be addressed by the project.
See: WhatIsaSpecificationAnyway
See Also: FunctionalSpecification
Below I pose three questions {A,B and C} around Tech Specs and have given my brief thoughts about each topic.
-- TimTwelves
A. How does the specification mechanism differ between types of problems?
A technical specification may differ because different types of technical problems may produce drastically different levels of detail in different document structures potentially based on role of the person who wrote the technical specification and type of problem.
In particular, the technical specification for an application that is going to be written from scratch would be vastly more detailed than the technical specification around a feature change. I would even argue that in such a scenario, the templates used would be significantly different.
I would elaborate to say that,
B. Who writes technical specifications? And what does a BusinessAnalyst do that is different from a SoftwareArchitect and SeniorDeveloper? create (w.r.t. technical specifications)?
I find it intriguing how some BusinessAnalysts (in the SoftwareDevelopment field) define their specifications by covering (a) DatabaseSchema?, (b) UserInterface, (c) BusinessRules, (d) XmlSchema. Consider a developer who writes a technical specification that does not relate to business functionality. Would a developer produce a software design or a technical specification? (I expect that every good software developer can be a business analyst.)
Is the output that the BusinessAnalyst produces a TechnicalSpecification? Or is it a SoftwareRequirementsSpecification?? I would say that a developer should not write a SoftwareRequirementsSpecification?.
My real question: When a business analyst produces their specification (functional spec), they sometimes want a response that details what will be done by the developer. What form does this response take? If the BA produces an SRS, the response is an SDD. If business produce an SRS and the BA produces the SDD/functional spec then what does the developer respond with?
There is a slight ambiguity here around who produces what type of output. The SDD/TechSpec? is typically in response to an SRS. (I assume a TechnicalSpecification is a SoftwareDesignDocument?.) Why, then, do InHouseDevelopers? typically work straight off the spec produced by the business analysts instead of responding to it with a TechnicalSpec?? I would agree with one who said that simple specs (changes with a low order of complexity) would not require a TechSpec?. Are there other reasons?
Or, do BusinessUsers? provide the SRS, the BA comes up with a SDD and a test plan and the developer is actually developing off the SDD produced by the BA? Which explains why the developer doesn't need to write a tech spec.
Furthermore, what does an Architect or Senior Developer create that's different from what a business analyst does? A design fulfills a specification, that is for certain. A design has an architecture that is followed.
C. What happens when the SRS is so simple?
Assuming the SRS is produced by a Business Analyst who takes a screenshot and says - put that database field on that webpage.
According to WhatIsaSpecificationAnyway
The template I use follows the IEEE SDD. The key to filling out the SDD is to note as little as possible. Do not write something for the sake of filling out the section. Every line should have a clear purpose. A problem with the spec is that when someone comes with a new feature that is so small, it is too difficult to respond with the particular specification below because the feature is too small. It becomes better to work off the SRS than waste time filling out an SDD.
See: WhatIsaSpecificationAnyway
See Also: FunctionalSpecification
Below I pose three questions {A,B and C} around Tech Specs and have given my brief thoughts about each topic.
-- TimTwelves
A. How does the specification mechanism differ between types of problems?
A technical specification may differ because different types of technical problems may produce drastically different levels of detail in different document structures potentially based on role of the person who wrote the technical specification and type of problem.
In particular, the technical specification for an application that is going to be written from scratch would be vastly more detailed than the technical specification around a feature change. I would even argue that in such a scenario, the templates used would be significantly different.
I would elaborate to say that,
- A technical specification should specify enough so that the solution should be the same, regardless of the SoftwareDeveloper. We should even drop the term software from software developer because a specification applies across the board across industries. When you specify an electronic interface or a roadside advertisement board, you specify something in writing that needs to be delivered. The width and height of the board, the materials, the expected finish, etc.
- A technical specification may be a SoftwareDesign or TechnicalDesign?. You could put together a good technical specification that should include a FunctionalSpecification, a SoftwareDesign, a SystemDesign?, a BillOfMaterials?, etc., that follow a particular SoftwareArchitecture that has been chosen to guide the solution.
- A technical specification serves as an important tool for ProjectCosting? and ProjectScheduling?. Without a spec, there is no basis to justify funding, as you need to be able to produce a ProjectPlan from the technical specification.
- A technical specification would typically specify relationships with other components - responsibilities, dependencies, etc.
B. Who writes technical specifications? And what does a BusinessAnalyst do that is different from a SoftwareArchitect and SeniorDeveloper? create (w.r.t. technical specifications)?
I find it intriguing how some BusinessAnalysts (in the SoftwareDevelopment field) define their specifications by covering (a) DatabaseSchema?, (b) UserInterface, (c) BusinessRules, (d) XmlSchema. Consider a developer who writes a technical specification that does not relate to business functionality. Would a developer produce a software design or a technical specification? (I expect that every good software developer can be a business analyst.)
Is the output that the BusinessAnalyst produces a TechnicalSpecification? Or is it a SoftwareRequirementsSpecification?? I would say that a developer should not write a SoftwareRequirementsSpecification?.
My real question: When a business analyst produces their specification (functional spec), they sometimes want a response that details what will be done by the developer. What form does this response take? If the BA produces an SRS, the response is an SDD. If business produce an SRS and the BA produces the SDD/functional spec then what does the developer respond with?
There is a slight ambiguity here around who produces what type of output. The SDD/TechSpec? is typically in response to an SRS. (I assume a TechnicalSpecification is a SoftwareDesignDocument?.) Why, then, do InHouseDevelopers? typically work straight off the spec produced by the business analysts instead of responding to it with a TechnicalSpec?? I would agree with one who said that simple specs (changes with a low order of complexity) would not require a TechSpec?. Are there other reasons?
Or, do BusinessUsers? provide the SRS, the BA comes up with a SDD and a test plan and the developer is actually developing off the SDD produced by the BA? Which explains why the developer doesn't need to write a tech spec.
Furthermore, what does an Architect or Senior Developer create that's different from what a business analyst does? A design fulfills a specification, that is for certain. A design has an architecture that is followed.
C. What happens when the SRS is so simple?
Assuming the SRS is produced by a Business Analyst who takes a screenshot and says - put that database field on that webpage.
According to WhatIsaSpecificationAnyway
- The four main purposes of a specification document are that it:
- - demonstrates that requirements can be met,
- - clearly states any issues or difficulties,
- - interprets requirements into instructions for a developer,
- - provides detail about resources upon which many developers might need to collaborate - schemas, sequence diagrams, interfaces, physical resources.
The template I use follows the IEEE SDD. The key to filling out the SDD is to note as little as possible. Do not write something for the sake of filling out the section. Every line should have a clear purpose. A problem with the spec is that when someone comes with a new feature that is so small, it is too difficult to respond with the particular specification below because the feature is too small. It becomes better to work off the SRS than waste time filling out an SDD.
- 1. Introduction
- 1.1 Purpose
- 1.2 Scope
- 1.3 System Overview
- 1.4 Solution Requirements
- 1.5 Solution Deliverables
- 1.5.1 Using and configuring
- 2. Design Considerations
- 2.1 Assumptions and Dependencies
- 2.2 General Constraints
- 2.3 Goals and Guidelines
- 2.4 Development Methods
- 2.5 Architectural Strategy
- 3. System Architecture
- 4. Policies and Tactics
- 5. Detailed Subsystem Design
- 5.1.1 <<Component>>
- 6. Test Suite
- 7. Current planning and Issues
- 8. Acceptance Sign-off
Комментариев нет:
Отправить комментарий