Specification
-
I just applied for a Job in the rural Australian coast (which is very good as I have some health related problem with city's pollution). It's for a mining company. They look for a developer with ... blah blah blah ... and very strong analytical skills. Now I wonder, I always worked in small company, and only once write some (short) specification. Most of the time it was informal. So, I wonder, if anyone can give some advice / tip / links / exemple, on what a specification should looks like, how much times does it take to write one (I saw a 200 page document recently..), how does one start, what are the user expectation? all sort of good advice related to this problem would be welcome. To share my thoughts so far: basically I thought I could just describe the problem to solve, my idea of a solution, put it in some diagram to quickly see use case and important class hierachy and which do what and how they work together. It takes times, and the document start small but probably swell and we dwell on every section and refine them.
Does analytical skills really mean writing long specs ? A long spec is needed when you need people to sign off on a big job before you start. If you can understand the process, then I don't think the part where you write it down is such a big deal, but I'd be buying a book on software requirements and looking through it to get some idea of 'standard' ways of doing that sort of stuff, and arming yourself with some buzzwords if they are needed, 'Rapid Development' is a good book, which covers different methodologies, I recommend it, regardless.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
Does analytical skills really mean writing long specs ? A long spec is needed when you need people to sign off on a big job before you start. If you can understand the process, then I don't think the part where you write it down is such a big deal, but I'd be buying a book on software requirements and looking through it to get some idea of 'standard' ways of doing that sort of stuff, and arming yourself with some buzzwords if they are needed, 'Rapid Development' is a good book, which covers different methodologies, I recommend it, regardless.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
thanks for the feedback. I think I will drop by the library hey!...
-
I just applied for a Job in the rural Australian coast (which is very good as I have some health related problem with city's pollution). It's for a mining company. They look for a developer with ... blah blah blah ... and very strong analytical skills. Now I wonder, I always worked in small company, and only once write some (short) specification. Most of the time it was informal. So, I wonder, if anyone can give some advice / tip / links / exemple, on what a specification should looks like, how much times does it take to write one (I saw a 200 page document recently..), how does one start, what are the user expectation? all sort of good advice related to this problem would be welcome. To share my thoughts so far: basically I thought I could just describe the problem to solve, my idea of a solution, put it in some diagram to quickly see use case and important class hierachy and which do what and how they work together. It takes times, and the document start small but probably swell and we dwell on every section and refine them.
-
great link thanks!! :-D
-
I just applied for a Job in the rural Australian coast (which is very good as I have some health related problem with city's pollution). It's for a mining company. They look for a developer with ... blah blah blah ... and very strong analytical skills. Now I wonder, I always worked in small company, and only once write some (short) specification. Most of the time it was informal. So, I wonder, if anyone can give some advice / tip / links / exemple, on what a specification should looks like, how much times does it take to write one (I saw a 200 page document recently..), how does one start, what are the user expectation? all sort of good advice related to this problem would be welcome. To share my thoughts so far: basically I thought I could just describe the problem to solve, my idea of a solution, put it in some diagram to quickly see use case and important class hierachy and which do what and how they work together. It takes times, and the document start small but probably swell and we dwell on every section and refine them.
The best advice I can give regarding size/scope of a specification is dependant upon it's intent. If the specification will be used to create a proposal, including an estimate that you will be required to stick to or eat the cost, then you need to spend as much time on it as you can. The more information you can finish ahead of time, the easier it is later to actually do it. Of course, the balance point with this, is that if it is not accepted, this is time lost. If it is, the time spent is just rolled into project time. The middle ground is found with a balance of trust with the customer. When defining the requirements for a project, attempt to involve them as much as possible. Perhaps even to the point of wireframing or prototyping. Sometimes you can't trust the customer, other times they trust you fully to do what is right. There is purpose on both sides: The customer needs to know that what they are buying meets their needs, and the developer needs to know what is expected/required of their product. If either party is unsatisfied, bad things can happen; breach of contract one either side. Basically you want the spec to be detailed enough to describe what the customer needs, and what you are going to do for them. It should be detailed enough to provide an estimate of time/cost of a project. It's purpose is to keep both parties satisfactorily on the same page. Brad BAMDevelopment.com
-
I just applied for a Job in the rural Australian coast (which is very good as I have some health related problem with city's pollution). It's for a mining company. They look for a developer with ... blah blah blah ... and very strong analytical skills. Now I wonder, I always worked in small company, and only once write some (short) specification. Most of the time it was informal. So, I wonder, if anyone can give some advice / tip / links / exemple, on what a specification should looks like, how much times does it take to write one (I saw a 200 page document recently..), how does one start, what are the user expectation? all sort of good advice related to this problem would be welcome. To share my thoughts so far: basically I thought I could just describe the problem to solve, my idea of a solution, put it in some diagram to quickly see use case and important class hierachy and which do what and how they work together. It takes times, and the document start small but probably swell and we dwell on every section and refine them.
I think a good starting point is the ieee standard for writing software specifications ( software requirements specifications to be more exact ). Here’s a link http://standards.ieee.org/reading/ieee/std\_public/description/se/830-1998\_desc.html I hope it helps!
-
The best advice I can give regarding size/scope of a specification is dependant upon it's intent. If the specification will be used to create a proposal, including an estimate that you will be required to stick to or eat the cost, then you need to spend as much time on it as you can. The more information you can finish ahead of time, the easier it is later to actually do it. Of course, the balance point with this, is that if it is not accepted, this is time lost. If it is, the time spent is just rolled into project time. The middle ground is found with a balance of trust with the customer. When defining the requirements for a project, attempt to involve them as much as possible. Perhaps even to the point of wireframing or prototyping. Sometimes you can't trust the customer, other times they trust you fully to do what is right. There is purpose on both sides: The customer needs to know that what they are buying meets their needs, and the developer needs to know what is expected/required of their product. If either party is unsatisfied, bad things can happen; breach of contract one either side. Basically you want the spec to be detailed enough to describe what the customer needs, and what you are going to do for them. It should be detailed enough to provide an estimate of time/cost of a project. It's purpose is to keep both parties satisfactorily on the same page. Brad BAMDevelopment.com
If the project has a UI, knock out some non-functional designs to show your customer. These can be achieved relatively quickly, with little effort and start to give an identity to your project. Once they have been accepted or otherwise, these can become the functional panels/forms. The inclusion of pictures helps breakdown what can be a stressful document and improves its presentation. BTW your FDS (functional design specification) should be a document that develops throughout the project - with agreement between yourself and the customer of course!
-
Does analytical skills really mean writing long specs ? A long spec is needed when you need people to sign off on a big job before you start. If you can understand the process, then I don't think the part where you write it down is such a big deal, but I'd be buying a book on software requirements and looking through it to get some idea of 'standard' ways of doing that sort of stuff, and arming yourself with some buzzwords if they are needed, 'Rapid Development' is a good book, which covers different methodologies, I recommend it, regardless.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Got to go with that one - Analytical skills does NOT mean the ability to write specifications. In my opimion it means the ability to understand the business process and translate that into a data structure and a software solution. If it is a small project then there will be 1 or 2 developers, probably a BA and maybe even a project lead with a couple of users thrown in to test the solution. The BA should be doing the spec, the project lead can do the high level requirements and dump the procedural doco on the users. Ahh heaven.:-D If it is a large project then you will not be writing the specs anyway, just understanding them and creating the solution. Even if it is a tiny project (you and a couple of users) the business should be doing the requirements, you do the functional spec, and there is good advice in other replies, but it could be simply the process logic. It is sill UNDERSTANDING not writing. Good luck, my worst ever contract was in gosford but I loved the location.:cool:
Quote from Great Outdoors: its a confident traveller who farts in India
-
I just applied for a Job in the rural Australian coast (which is very good as I have some health related problem with city's pollution). It's for a mining company. They look for a developer with ... blah blah blah ... and very strong analytical skills. Now I wonder, I always worked in small company, and only once write some (short) specification. Most of the time it was informal. So, I wonder, if anyone can give some advice / tip / links / exemple, on what a specification should looks like, how much times does it take to write one (I saw a 200 page document recently..), how does one start, what are the user expectation? all sort of good advice related to this problem would be welcome. To share my thoughts so far: basically I thought I could just describe the problem to solve, my idea of a solution, put it in some diagram to quickly see use case and important class hierachy and which do what and how they work together. It takes times, and the document start small but probably swell and we dwell on every section and refine them.
Terminology: Are you talking requirments document? Or project charter?
MrPlankton
-
I just applied for a Job in the rural Australian coast (which is very good as I have some health related problem with city's pollution). It's for a mining company. They look for a developer with ... blah blah blah ... and very strong analytical skills. Now I wonder, I always worked in small company, and only once write some (short) specification. Most of the time it was informal. So, I wonder, if anyone can give some advice / tip / links / exemple, on what a specification should looks like, how much times does it take to write one (I saw a 200 page document recently..), how does one start, what are the user expectation? all sort of good advice related to this problem would be welcome. To share my thoughts so far: basically I thought I could just describe the problem to solve, my idea of a solution, put it in some diagram to quickly see use case and important class hierachy and which do what and how they work together. It takes times, and the document start small but probably swell and we dwell on every section and refine them.
For good ideas look here, professional requirements writers: http://complianceautomation.com/ In particular, check out her book. Truth is though, if you can capture half of what the compliance automation people are saying, then you're probably at the top of the documentation class :)
Super Lloyd wrote:
basically I thought I could just describe the problem to solve, my idea of a solution, put it in some diagram to quickly see use case and important class hierachy and which do what and how they work together.
This strategy generally works in a small Business 2 Business scenario where you can put all 3 stakeholders in a room. But for big business scenarios you've just crossed analysis (problem to solve, solution idea) with design (class hierarchy) and that's a big no-no. Even in my small business scenario, I separate the two pieces. I'm normally on the analysis side and that's what I do. I describe the problem, I describe the desired outputs and I agree on these items with the client. Sometimes I'll even draw some screens with them, but only in the context of describing the problem, the process and its outputs. Once you're done with the client, then you put on your design hat and talk to the programmers and then you can talk classes and inheritances and data models. Truth be told though, if you're going to work for a big established company, you're probably not doing any of this stuff. You'll likely be working on giant pre-existing systems and you'll be responsible for gluing in new pieces. The requirements for this are large amounts of domain knowledge, a good testing environment and a huge attention to detail. When you're adding one screen to a 200 screen system, you're only doing a day of programming, but it still takes two weeks to cover all of the other bases and make sure that you haven't broken the system (if it sounds tedious, be prepared) Gates