Wow! I've been searching for so many videos on how to write a project specification document, yours is my full-stop. Now I know what to do, no doubts and I'm very sure that if it had been the first one I've seen, it'd still be my full-stop.
If i were to just shut my eyes and listen to the video, i would have thought it was Seth Rogen narrating. Anyways thanks for clearing up some doubts i had for writing this part for my Thesis. Great help!
I can't say that I agree with "lots of words" and "don't try and be concise". Be detailed, but be meaningful in everything you write. Don't use five words where one will do.
Mike Goodwin Hi Mike, thanks for your reply. Certainly you are correct that accuracy trumps verbosity but I think you are probably coming at this with more experience than many of our viewers have. We hear from so many clients who just can't seem to get started on spec writing, and the advice that seems to work is to simply 'get going and just write as much as you can' - this helps people to get into the flow of specification writing, but of course it can lead to wordiness and redundancy. Those problems, however, can be fixed later and are preferable to not getting started at all. Sound like you are more practiced :) - thanks for the feedback!!
Thanks Dave. I'm wondering where to draw the line between specifying too much and not enough. I've read in other sources that the requirements document shouldn't constrain the creative / design process, that features should be listed with only enough detail to describe functionality, but not limit the way it might be carried out. "Write down what, but not how". What are your thoughts on this? I'm guessing that maybe the approach here is more geared toward outsourcing to development teams, vs. working with an internal dev team? Thanks again!
+Matt Lashinsky Hi Matt - This is a tough question because every project is different. In general, I would say to write fewer specifications and jump into development rather than spend tons of time trying to define everything. The reason: it's almost impossible to write a 100% complete spec anyways, so best not to try :)
Thanks Dave, after watching this, my wife of 10 years left her girlfriend and came back to me, I also gained the confidence to get my money back from my sh*t head 6-year-old neighbor and i finally feel complete in life. All thanks to you buddy.
Sir, give me an example of gathering requirements for an Admin panel of a product selling website/app. There is a super admin, then admins lets suppose.
Thanks for the very helpful videos. Because of a painful, expensive false start with an under-performing contractor, I've constructed a complete mock-up of my desired app, along with a complete specification. My question is about the IP risk and need for an NDA when distributing these to prospective contractors. An unscrupulous contractor will have a complete 'blueprint' to build and market the app themselves. Although signing an NDA would be expected once a final contractor has been chosen, it seems somewhat demanding to get them to sign an NDA just to look at my project description. What is your advice?
Added 1 day later: I should have watched the most recent videos! Dave Hecker answered my question in the 'Legal Concerns' video. In a nutshell, NDAs are close to impossible to enforce, so I should not show my mock-up to any prospective vendor until I have chosen a final one.
+Karlski I would agree that NDA's can be very hard to enforce, but but I'm not sure that keeping your materials private like that is a good idea. If your idea is so simple that anyone can simply copy it, then it will be hard to succeed, but most startups succeed because the idea is good but the execution is also good - and execution is much harder than coming up with the original idea in most cases. I'd say, unless you have sometime that is so unique that it can be stolen and easily replicated, don't worry about the NDA and just show it around. Focus on being first to market - people will steal your idea if it's good regardless of what you do so best to simply do it faster and better than the rest.
Hello. Thanks for this Video. You explain really well. I need to develope a Mobile Software that operates a wireless Earpiece device. I am now stuck up with what to use as a functionality requirement. Please whats a sample of functionality requirement for an ear piece device? Thank you
hi, guys I'm trying to get started with this idea that I'm thinking of and I believe that it can be the great next thing that can change how we purchase goods and services but I have been going around in circles software developers want the software specs but I don't know what to do or where to begin can you please give advice I really want to do this but I don't know what to do to get the project from the ground up.hope to hear from you soon.
+Kenneth modisane Hi Kenneth, a lot of people have this problem -it's hard to get started! The best way is to just start writing it all down. Diagrams, wireframes, user stories, storyboards, just anything that makes sense to you. The more you capture your idea, the easier everything else will become. Another option is to hire someone to write out the spec for you, but you'll quickly learn that these kinds of people are actually more expensive than software developers much of the time. Good luck!
"You can have many words". in the beginning of the video is in direct contrast with "You can never have too many words" in the ending. Did I miss any context over there?
Hi Dave! Thanks for the video, it's really quite comfortable and helpful to watch your videos ! i just want to share with you one of my issues reading specifications. they are too huge and use-case oriented with lot of details and repetition, just like you described them. each use case involve a bunch of system's sub blocks and scenarios. As a developer, it's my first time doing these things and i found that's so difficult to track and manage requirements !! (i used to get requirements instead of client specs) do you have any ideas or processes to follow, in this context ?? Thanks, Mohammed
A lot of requirements will be much easier to read and work with if you convert them into different formats. If you try to find every opportunity to convert information into things like flow charts, user stories, user personas, diagrams, or wireframes it can make it all less tedious to deal with. It also helps a lot of keep the document very nicely organized, ideally using a numbered outline format i.e. section 1.2.3.4. It's easy to do that in MS Word using headings, and in Google Drive there is a plug-in called 'table of contents' that will do it. Even just keeping the documents clean and consistent makes a big difference, but ultimately there is no way to make a complex specification simple :)
Mohammed YASSINE I'd classify what you showed me as more of a 'list of business rules', which is a really important part of any big specification. It seems well organized and if you are being asked to do things like link each requirement back to the RFQ (sometimes data like that brings unnecessary overhead once it's been confirmed initially) the best you can do is to work to keep that level of maintenance and tidiness to the doc.
SourceSeek Thank you for the remark . it's really helpful. this is what i found on the Internet : * Business rules are lists of statements that tell you whether you may or may not do something or that give you the criteria and conditions for making a decision (what i'm doing) * Business requirements are what you need to do to enable the implementation of and compliance with business rules(There can be many different alternative business requirements to implement/enforce a set of business rules) so if i'm not wrong it works like this : Raw Specs -> Business rules -> requirements -> Design and Implementation ... ??
Mohammed YASSINE Those are good definitions, and if your spec is very large it's good to discern between things like requirements and business rules. But, it's very hard to have a set flow from specs to business rules to requirements to design, etc. It rarely works like that. Keep expanding the spec until the specification is complete enough to allow anyone to read it and understand exactly what needs to be built - that is the only real objective. It doesn't matter exactly how you get there.
Hello Dave! Thanks a lot for your guidance! It was helpful :) Currently we are working on an application which went in to Production & in-use. The real problem is that the application was developed without capturing requirements on any medium & just creating the massive application with inputs from users over daily calls/discussion. Since this app we are working on is so confidential for the organization we are trying to write requirements to have a base document for testing. But we are finding it difficult since we are missing the actual docs & the developers/users who developed have moved out :( We wont be having an actual sign-off process during completion. Could you please help on how to write requirements or the best way to create requirements for a product that is already established for use ? Any help or technique is greatly appreciated :) Thanks, Barni
Hi Barni, Having a live application to document will make things much easier. I would start by first making a list of all the different types of user types (i.e. end-users, admins, unregistered users, etc.) and define each one as it pertains to your application. Then, go through an ordinary series of actions for each particular user, and write down each step of the process - what you see, what you do, etc. Then you'll start having user stories for each user type, and that's a great start for developing a spec. After that you can get into more back-end stuff, and rules/logic, etc. but it's always easy to start with user stories. - Dave
Well, sorry to be the odd one out here, but this video explained very little. For the life of me, I can't seem to find a complete example of a simple piece of software, with the design laid out and explained from start to finish like a tutorial.
I am looking for a software engineering tutorial, basically. Is there such a video? If there is, I can't find it anywhere. I've only found one good book, but it's missing the CD which is crucial to understanding it. It's called Software Engineering for Game Developers.
Wow! I've been searching for so many videos on how to write a project specification document, yours is my full-stop. Now I know what to do, no doubts and I'm very sure that if it had been the first one I've seen, it'd still be my full-stop.
short, clear, and concise.. this is what we want
Thanks Dave.. I was trying to be too formal and you gave me permission to just spit it all out! Great advice!!
Sinking into the depths of my first full scale project. This is a nice mindset and skill to take on while Im starting. Thanks for the help man
Great video, we all forgot how important brainstorming can be!
If i were to just shut my eyes and listen to the video, i would have thought it was Seth Rogen narrating. Anyways thanks for clearing up some doubts i had for writing this part for my Thesis. Great help!
+Matthew Pragasam I'll take that as a compliment (right?)!
Wow, so I've basically already been writing project specs, and I didn't even know it! 👍
simple, clear, and very helpful. Thank you so much.
This really helped a lot, but is it not a better idea to write the goals before starting on the specifications?
Aftab Naveed yea you are right
Great Tips! Many thanks Dave!
I can't say that I agree with "lots of words" and "don't try and be concise". Be detailed, but be meaningful in everything you write. Don't use five words where one will do.
Mike Goodwin Hi Mike, thanks for your reply. Certainly you are correct that accuracy trumps verbosity but I think you are probably coming at this with more experience than many of our viewers have. We hear from so many clients who just can't seem to get started on spec writing, and the advice that seems to work is to simply 'get going and just write as much as you can' - this helps people to get into the flow of specification writing, but of course it can lead to wordiness and redundancy. Those problems, however, can be fixed later and are preferable to not getting started at all. Sound like you are more practiced :) - thanks for the feedback!!
@@Sourceseek I agree.
hi dave, can you please tell me about the template of a PRD as well as the components required in a PRD
Great simple explanation. Thanks!
Very helpful, thanks a lot for sharing!
Hi this very useful to better understand how to drafting functional documents. Could you have any tips to practices to write functional documents.
Awesome video. Do you have the template for the specification Doc available now?
It's a important video. Thank you for make this video.
Thanks Dave. I'm wondering where to draw the line between specifying too much and not enough. I've read in other sources that the requirements document shouldn't constrain the creative / design process, that features should be listed with only enough detail to describe functionality, but not limit the way it might be carried out. "Write down what, but not how". What are your thoughts on this? I'm guessing that maybe the approach here is more geared toward outsourcing to development teams, vs. working with an internal dev team? Thanks again!
+Matt Lashinsky Hi Matt - This is a tough question because every project is different. In general, I would say to write fewer specifications and jump into development rather than spend tons of time trying to define everything. The reason: it's almost impossible to write a 100% complete spec anyways, so best not to try :)
Nicely Explained and very useful to me. Thanks
That was real good and well explained. thanks
loved it, thanks Mr.Dave
Lovely explanation!!👏👍
Thanks Dave, after watching this, my wife of 10 years left her girlfriend and came back to me, I also gained the confidence to get my money back from my sh*t head 6-year-old neighbor and i finally feel complete in life. All thanks to you buddy.
Sir, give me an example of gathering requirements for an Admin panel of a product selling website/app. There is a super admin, then admins lets suppose.
Thanks dear, Its really helpful.
I'm very glad you found it helpful!
Thanks for the very helpful videos. Because of a painful, expensive false start with an under-performing contractor, I've constructed a complete mock-up of my desired app, along with a complete specification. My question is about the IP risk and need for an NDA when distributing these to prospective contractors.
An unscrupulous contractor will have a complete 'blueprint' to build and market the app themselves. Although signing an NDA would be expected once a final contractor has been chosen, it seems somewhat demanding to get them to sign an NDA just to look at my project description. What is your advice?
Added 1 day later: I should have watched the most recent videos! Dave Hecker answered my question in the 'Legal Concerns' video. In a nutshell, NDAs are close to impossible to enforce, so I should not show my mock-up to any prospective vendor until I have chosen a final one.
+Karlski I would agree that NDA's can be very hard to enforce, but but I'm not sure that keeping your materials private like that is a good idea. If your idea is so simple that anyone can simply copy it, then it will be hard to succeed, but most startups succeed because the idea is good but the execution is also good - and execution is much harder than coming up with the original idea in most cases. I'd say, unless you have sometime that is so unique that it can be stolen and easily replicated, don't worry about the NDA and just show it around. Focus on being first to market - people will steal your idea if it's good regardless of what you do so best to simply do it faster and better than the rest.
superb explanation and build up
+Pr Sr Thanks, hope your projects all go well!
Awesome video, thanks!
Awesome explanation about requirements...
Thanks Sourav!
Thank you Dave it help me lot
Hello. Thanks for this Video. You explain really well. I need to develope a Mobile Software that operates a wireless Earpiece device. I am now stuck up with what to use as a functionality requirement. Please whats a sample of functionality requirement for an ear piece device? Thank you
Thanks and glad you enjoyed the video. Unfortunately I don't have an example specification that relates to an earpiece device.
Dave Hecker I figured it out. Thanks for the reply. Have a good year.
Thanks Dave!
Thanks for the video Dave! It is really helpful. Do you have any specific template for software requirement specification document?
This has been requested a lot, so we are producing one soon and will be sharing it here.
Thanks! Looking forward to see it!
SourceSeek Yeah, this video was really helpful. If you don't have a template, even seeing one of your spec docs, as a sample, would help.
@@Sourceseek did you produce it yet brother ?
Great video! Unrelated to the video, this guy looks like Linus Sebastian.
hi, guys I'm trying to get started with this idea that I'm thinking of and I believe that it can be the great next thing that can change how we purchase goods and services but I have been going around in circles software developers want the software specs but I don't know what to do or where to begin can you please give advice I really want to do this but I don't know what to do to get the project from the ground up.hope to hear from you soon.
+Kenneth modisane Hi Kenneth, a lot of people have this problem -it's hard to get started! The best way is to just start writing it all down. Diagrams, wireframes, user stories, storyboards, just anything that makes sense to you. The more you capture your idea, the easier everything else will become. Another option is to hire someone to write out the spec for you, but you'll quickly learn that these kinds of people are actually more expensive than software developers much of the time. Good luck!
Thank you very much
thank you, It was very helpful
"You can have many words". in the beginning of the video is in direct contrast with "You can never have too many words" in the ending. Did I miss any context over there?
+Siva Krishna Karasala I think it was probably "You can't have too many words" :)
+SourceSeek Thanks for the clarification Dave.
Just Simple and superb
Hi Dave! Thanks for the video, it's really quite comfortable and helpful to watch your videos !
i just want to share with you one of my issues reading specifications. they are too huge and use-case oriented with lot of details and repetition, just like you described them. each use case involve a bunch of system's sub blocks and scenarios. As a developer, it's my first time doing these things and i found that's so difficult to track and manage requirements !! (i used to get requirements instead of client specs)
do you have any ideas or processes to follow, in this context ??
Thanks,
Mohammed
A lot of requirements will be much easier to read and work with if you convert them into different formats. If you try to find every opportunity to convert information into things like flow charts, user stories, user personas, diagrams, or wireframes it can make it all less tedious to deal with. It also helps a lot of keep the document very nicely organized, ideally using a numbered outline format i.e. section 1.2.3.4. It's easy to do that in MS Word using headings, and in Google Drive there is a plug-in called 'table of contents' that will do it. Even just keeping the documents clean and consistent makes a big difference, but ultimately there is no way to make a complex specification simple :)
SourceSeek Thank you Dave, it's somehow what i did. please check my solution
drive.google.com/file/d/0B1bBOjY5uGzEVXRaMjBxNzN2U2M/view
Mohammed YASSINE I'd classify what you showed me as more of a 'list of business rules', which is a really important part of any big specification. It seems well organized and if you are being asked to do things like link each requirement back to the RFQ (sometimes data like that brings unnecessary overhead once it's been confirmed initially) the best you can do is to work to keep that level of maintenance and tidiness to the doc.
SourceSeek Thank you for the remark . it's really helpful. this is what i found on the Internet :
* Business rules are lists of statements that tell you whether you may or may not do something or that give you the criteria and conditions for making a decision (what i'm doing)
* Business requirements are what you need to do to enable the implementation of and compliance with business rules(There can be many different alternative business requirements to implement/enforce a set of business rules)
so if i'm not wrong it works like this :
Raw Specs -> Business rules -> requirements -> Design and Implementation ... ??
Mohammed YASSINE Those are good definitions, and if your spec is very large it's good to discern between things like requirements and business rules. But, it's very hard to have a set flow from specs to business rules to requirements to design, etc. It rarely works like that. Keep expanding the spec until the specification is complete enough to allow anyone to read it and understand exactly what needs to be built - that is the only real objective. It doesn't matter exactly how you get there.
Hello Dave! Thanks a lot for your guidance! It was helpful :)
Currently we are working on an application which went in to Production & in-use. The real problem is that the application was developed without capturing requirements on any medium & just creating the massive application with inputs from users over daily calls/discussion.
Since this app we are working on is so confidential for the organization we are trying to write requirements to have a base document for testing. But we are finding it difficult since we are missing the actual docs & the developers/users who developed have moved out :( We wont be having an actual sign-off process during completion.
Could you please help on how to write requirements or the best way to create requirements for a product that is already established for use ?
Any help or technique is greatly appreciated :)
Thanks,
Barni
Hi Barni,
Having a live application to document will make things much easier. I would start by first making a list of all the different types of user types (i.e. end-users, admins, unregistered users, etc.) and define each one as it pertains to your application. Then, go through an ordinary series of actions for each particular user, and write down each step of the process - what you see, what you do, etc. Then you'll start having user stories for each user type, and that's a great start for developing a spec.
After that you can get into more back-end stuff, and rules/logic, etc. but it's always easy to start with user stories.
- Dave
Very useful thank you
what about SMART requirements? this goes against everything I've learned.
Very helpful
Thanks. Great video..
thank you it very helpful
Superbe vidéo ! Très intéressant ! Biz.
+Steven Wong Thank you! Merci!
thank you
Thanks!
amazing........tips.....make s look simple...
Glad it was helpful for you!
Interesting really
thank you :)
Well, sorry to be the odd one out here, but this video explained very little. For the life of me, I can't seem to find a complete example of a simple piece of software, with the design laid out and explained from start to finish like a tutorial.
Sean I'm not understanding exactly what you're looking for. If you are looking for a software development tutorial, this isn't the right video!
I am looking for a software engineering tutorial, basically. Is there such a video? If there is, I can't find it anywhere. I've only found one good book, but it's missing the CD which is crucial to understanding it. It's called Software Engineering for Game Developers.
Awesome
I love it
good
This is the opposite of what the AIA teaches lol
Thanks Dave !