Design Documents
-
How do I go about creating Design Documents? Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it" :^) So any pointers? What do design documents contain? :doh: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
How do I go about creating Design Documents? Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it" :^) So any pointers? What do design documents contain? :doh: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
Hakuna-Matada wrote:
Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it"
Sounds like he doesn't know either. Which means you can do pretty much whatever you want :-)
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
-
Hakuna-Matada wrote:
Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it"
Sounds like he doesn't know either. Which means you can do pretty much whatever you want :-)
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
But I would like to do a good job of it. So that even if she shows the documents to someone else, let them say, "Hey, that's a job well done." :rolleyes: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
But I would like to do a good job of it. So that even if she shows the documents to someone else, let them say, "Hey, that's a job well done." :rolleyes: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
Hakuna-Matada wrote:
Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
You missed a line "What a wonderful phrase" above the "It means no worries for the rest of your days" God ive seen lion king waaaaay too much! Current blacklist svmilky - Extremely rude | FeRtoll - Rude personal emails | ironstrike1 - Rude & Obnoxious behaviour
-
How do I go about creating Design Documents? Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it" :^) So any pointers? What do design documents contain? :doh: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
This[^] should give you a good start... along with Software Design Specification Template[^] Document Templates: Design Specification[^] and Ready-to-use Software Engineering Templates[^] Steve
-
This[^] should give you a good start... along with Software Design Specification Template[^] Document Templates: Design Specification[^] and Ready-to-use Software Engineering Templates[^] Steve
Thanks. Much appreciated. :) --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
But I would like to do a good job of it. So that even if she shows the documents to someone else, let them say, "Hey, that's a job well done." :rolleyes: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
Hakuna-Matada wrote:
So that even if she shows the documents to someone else, let them say, "Hey, that's a job well done." :rolleyes:
They will say it to her, but she will not come and praise you...
-
Hakuna-Matada wrote:
Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
You missed a line "What a wonderful phrase" above the "It means no worries for the rest of your days" God ive seen lion king waaaaay too much! Current blacklist svmilky - Extremely rude | FeRtoll - Rude personal emails | ironstrike1 - Rude & Obnoxious behaviour
J4amieC wrote:
ive seen lion king waaaaay too much
Just once is waaaay too much! Rob Manderson I'm working on a version for Visual Lisp++ My blog http://blogs.wdevs.com/ultramaroon/[^]
-
Hakuna-Matada wrote:
Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
You missed a line "What a wonderful phrase" above the "It means no worries for the rest of your days" God ive seen lion king waaaaay too much! Current blacklist svmilky - Extremely rude | FeRtoll - Rude personal emails | ironstrike1 - Rude & Obnoxious behaviour
J4amieC wrote:
You missed a line "What a wonderful phrase" above the "It means no worries for the rest of your days"
I know. The whole part goes like this... Hakuna Matata! What a wonderful phrase Hakuna Matata! Ain't no passing craze It means don’t worry For the rest of your days It's our problem-free philosophy Hakuna Matata! But I chose not to... ;P --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
Hakuna-Matada wrote:
So that even if she shows the documents to someone else, let them say, "Hey, that's a job well done." :rolleyes:
They will say it to her, but she will not come and praise you...
Weiye Chen wrote:
They will say it to her, but she will not come and praise you...
I know she won't, but she would certainly think twice before accepting my resignation. :-> --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
How do I go about creating Design Documents? Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it" :^) So any pointers? What do design documents contain? :doh: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
So exactly how much are you paying us for for coaching you through semester 3 of your IT degree? OK now that 've been nasty, congratulations on knowing you don't know and bothering to find out. Presentation is not without value but content is far more important. Here are some tips from an old hand (and you are paying me, by not producing crap design documents). These documents tell you
- What you are building.
- What you are not building (define the limits)
- How it works.
- Other systems (including people and their manual systems) with which it interacts what services and information all these systems provide to each other.
What you are building may break down into several end products. You describe these in terms of how the end-user will see them, eg
A system that allows up to three operators to go to the moon, stroll around in hard vacuum taking holiday snaps and then make it all the way back to Earth without dying.
That's the space race in a nutshell. It's easy to see whether the requirements have been fulfilled. Spacesuits, rockets, booster stage detachment explosive timers, none of these are objectives except insofar as they contribute to fulfilling the requirements. It's easy to get carried away especially when things are galloping along as they often do in the early stages of a project. How it works is a WIP (work in progress). It starts of as a thumbnail sketch of how you think you're going to put the system together, and is then revised in accordance with bright ideas and harsh realities. Another WIP document you should maintain is a Risk Assessment. Any unknown - all bright ideas, untried 3rd party components and external systems that may not conform to their documented capabilities - should be noted along with all of the things you don't know for certain and which have the potential to (technical term) bite you on the ass. Under no circumstances show the RA to your boss, s/he will panic. When you need to kill a poisonous bright idea from someone powerful, do an RA for it and show that to everyone. Unless you are on an as-long-as-it-takes timeline you will need to estimate. You can do this once you have a fairly detailed how-it-works (properly known as a Functional Specification). Get Microsoft Project or equivalent and learn how to use it. So good so far. The problem is that your estimate tells you the shortest time in which the project will complete if absolutely nothing
-
Weiye Chen wrote:
They will say it to her, but she will not come and praise you...
I know she won't, but she would certainly think twice before accepting my resignation. :-> --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
Hakuna-Matada wrote:
I know she won't, but she would certainly think twice before accepting my resignation.
It won't make any difference. She'll accept it anyway. If you give in your resignation, then you're basically saying that you don't want to be there - any boss with intelligence will accept it and hire someone who does want to be there.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Last modified: Friday, 23 June 2006 04:22:40 -- WYSIWYG editor got me again :-O
-
Hakuna-Matada wrote:
I know she won't, but she would certainly think twice before accepting my resignation.
It won't make any difference. She'll accept it anyway. If you give in your resignation, then you're basically saying that you don't want to be there - any boss with intelligence will accept it and hire someone who does want to be there.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Last modified: Friday, 23 June 2006 04:22:40 -- WYSIWYG editor got me again :-O
Or... Or... She may say, "Ok, I will give you a hefty raise which you can't over look." :rolleyes: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
How do I go about creating Design Documents? Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it" :^) So any pointers? What do design documents contain? :doh: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
1. Requirements - marketing, third party (e.g. industry standards), result of discussion with development team. 2. Specifications - what the product is to do, how it is to appear, dependancies - e.g. OS, third party products (libraries etc.). 3. Development plan. That should get you started. Elaine :rose: The tigress is here :-D
-
So exactly how much are you paying us for for coaching you through semester 3 of your IT degree? OK now that 've been nasty, congratulations on knowing you don't know and bothering to find out. Presentation is not without value but content is far more important. Here are some tips from an old hand (and you are paying me, by not producing crap design documents). These documents tell you
- What you are building.
- What you are not building (define the limits)
- How it works.
- Other systems (including people and their manual systems) with which it interacts what services and information all these systems provide to each other.
What you are building may break down into several end products. You describe these in terms of how the end-user will see them, eg
A system that allows up to three operators to go to the moon, stroll around in hard vacuum taking holiday snaps and then make it all the way back to Earth without dying.
That's the space race in a nutshell. It's easy to see whether the requirements have been fulfilled. Spacesuits, rockets, booster stage detachment explosive timers, none of these are objectives except insofar as they contribute to fulfilling the requirements. It's easy to get carried away especially when things are galloping along as they often do in the early stages of a project. How it works is a WIP (work in progress). It starts of as a thumbnail sketch of how you think you're going to put the system together, and is then revised in accordance with bright ideas and harsh realities. Another WIP document you should maintain is a Risk Assessment. Any unknown - all bright ideas, untried 3rd party components and external systems that may not conform to their documented capabilities - should be noted along with all of the things you don't know for certain and which have the potential to (technical term) bite you on the ass. Under no circumstances show the RA to your boss, s/he will panic. When you need to kill a poisonous bright idea from someone powerful, do an RA for it and show that to everyone. Unless you are on an as-long-as-it-takes timeline you will need to estimate. You can do this once you have a fairly detailed how-it-works (properly known as a Functional Specification). Get Microsoft Project or equivalent and learn how to use it. So good so far. The problem is that your estimate tells you the shortest time in which the project will complete if absolutely nothing
Thanks. :) --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
1. Requirements - marketing, third party (e.g. industry standards), result of discussion with development team. 2. Specifications - what the product is to do, how it is to appear, dependancies - e.g. OS, third party products (libraries etc.). 3. Development plan. That should get you started. Elaine :rose: The tigress is here :-D
Thank You. :rose: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
-
How do I go about creating Design Documents? Our Vice President just came up to me and said, "This is the new product that we will be building, create all the necessary documents for it" :^) So any pointers? What do design documents contain? :doh: --- Hakuna-Matada It means no worries for the rest of your days... It's our problem free, Philosophy
The one major item I see not commented about is a dictionary. Either as an appendix or a sperate document. Every major term you use should be explicitly stated as to what it means. Mankind is very inventive to interpret what they want words to mean. "Yes I know the voices are not real. But they have some pretty good ideas."
-
This[^] should give you a good start... along with Software Design Specification Template[^] Document Templates: Design Specification[^] and Ready-to-use Software Engineering Templates[^] Steve
Steve Mayfield wrote:
This[^] should give you a good start...
Great resources. Thanks for posting those links. Marc Pensieve Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
-
This[^] should give you a good start... along with Software Design Specification Template[^] Document Templates: Design Specification[^] and Ready-to-use Software Engineering Templates[^] Steve
If you do ANYTHING with UML artifacts then RUN don't walk to get "The Elements of UML 2.0 Style" - Scott Ambler ISBN: 0-521-61678-6 Nothing is impossible, we just don't know the way of it yet.
-
So exactly how much are you paying us for for coaching you through semester 3 of your IT degree? OK now that 've been nasty, congratulations on knowing you don't know and bothering to find out. Presentation is not without value but content is far more important. Here are some tips from an old hand (and you are paying me, by not producing crap design documents). These documents tell you
- What you are building.
- What you are not building (define the limits)
- How it works.
- Other systems (including people and their manual systems) with which it interacts what services and information all these systems provide to each other.
What you are building may break down into several end products. You describe these in terms of how the end-user will see them, eg
A system that allows up to three operators to go to the moon, stroll around in hard vacuum taking holiday snaps and then make it all the way back to Earth without dying.
That's the space race in a nutshell. It's easy to see whether the requirements have been fulfilled. Spacesuits, rockets, booster stage detachment explosive timers, none of these are objectives except insofar as they contribute to fulfilling the requirements. It's easy to get carried away especially when things are galloping along as they often do in the early stages of a project. How it works is a WIP (work in progress). It starts of as a thumbnail sketch of how you think you're going to put the system together, and is then revised in accordance with bright ideas and harsh realities. Another WIP document you should maintain is a Risk Assessment. Any unknown - all bright ideas, untried 3rd party components and external systems that may not conform to their documented capabilities - should be noted along with all of the things you don't know for certain and which have the potential to (technical term) bite you on the ass. Under no circumstances show the RA to your boss, s/he will panic. When you need to kill a poisonous bright idea from someone powerful, do an RA for it and show that to everyone. Unless you are on an as-long-as-it-takes timeline you will need to estimate. You can do this once you have a fairly detailed how-it-works (properly known as a Functional Specification). Get Microsoft Project or equivalent and learn how to use it. So good so far. The problem is that your estimate tells you the shortest time in which the project will complete if absolutely nothing
Cynical but unfortunately all too true. As a tormented soul in the deepest depths of software development hell ("why plan it now when we can do a death march in 6 months") I would add: GET THE BUSINESS REQUIREMENTS! Find out the expectations - what the USERS want, need, and are expecting. I suspect your Boss didn't bother with this or he'd know what to ask you to produce. Speak with AND LISTEN TO the developers, testers, support, and the HELP/Manual document writers, if they don't know what you're doing they cannot give you their cases/scenarios and any realistic estimates of time/resource needs, known issues, workarounds, etc Make emails, IM's, phone conversations PART OF THE DOCS - 90% of the things that will kill you - scope changes, bad decisions, parallel development, undocumented dependencies, changes, etc - come from this. In all documents I write I add an appendix which keeps a record of things like rationale, problems, solutions, future ideas/plans, business changes, etc. This pure CYA. Discuss document options with users, developers, etc, but MAKE DECISIONS QUICKLY - don't defer till someone tells you. Otherwise you'll be sitting on your ass 7 hours a day and working in a frenzy for the other 3 hours of the 8 hour day and reading/marking up documents all night. If you have the authority, assign tasks to others with a time expectation - DONT dump it on somebody else, just get them to do THEIR job. A senior developer should do class diagrams, not a business analyst. A business analyst should do use cases, not interaction diagrams. Nothing is impossible, we just don't know the way of it yet.