The deep universal problem in software is in 98% of outfits, there are no designers and nothing resembling design artifacts. A proper specification involves exactly what the problem is, what the user needs are, and how it will be solved for the client (mostly this is something a designer/architect should do, and it can take many forms). If you are building a building an architect comes up with a cogent, wholistic plan of how to erect the building. The sad, but true fact is that in software there are no architects, and (raw) user needs are thrown down in excel (or something more traceable) and sent to the "builders". This process is equivalent to building construction in 100B.C.
In FACT requirements should be WHAT YOU REQUIRE TO BE BUILT when you have a clear developed understanding of the user solution. The traditional excel/bugzilla/whatever_tool requirements in text form are a transformation and expression of what it takes to build the DESIGN. Chop up the solution into "sorta atomic" req's. There are of course technical specs which would be mostly for the internal team (how big pieces are architected and fit).
The big problems in software have nothing to do with tools, nothing to do with traceability, nothing to do with agile, and everything to do with management having no idea how to envision and specify a transformation of user needs into solutions. The lack of design is keeping the industry in 100BC.
The strength of a dev's (negative) reaction to this is evidence of the extent of the problem. Most cannot even "see"? how design is the lack of a problem. As a dev turned designer (it just so happens this was what I was fated to do), I have seen this is the core issue - and the most dev teams have the most cursory understanding of how to solve user problems, and how to understand users. The best evidence for this approach is that Apple is the #1 tech company in the world and #3 company in the world after Exxon Mobil and Petrochina. Everything I have said in this email is "their secret sauce."
Slashdot Mirror
The deep universal problem in software is in 98% of outfits, there are no designers and nothing resembling design artifacts. A proper specification involves exactly what the problem is, what the user needs are, and how it will be solved for the client (mostly this is something a designer/architect should do, and it can take many forms). If you are building a building an architect comes up with a cogent, wholistic plan of how to erect the building. The sad, but true fact is that in software there are no architects, and (raw) user needs are thrown down in excel (or something more traceable) and sent to the "builders". This process is equivalent to building construction in 100B.C.
In FACT requirements should be WHAT YOU REQUIRE TO BE BUILT when you have a clear developed understanding of the user solution. The traditional excel/bugzilla/whatever_tool requirements in text form are a transformation and expression of what it takes to build the DESIGN. Chop up the solution into "sorta atomic" req's. There are of course technical specs which would be mostly for the internal team (how big pieces are architected and fit).
The big problems in software have nothing to do with tools, nothing to do with traceability, nothing to do with agile, and everything to do with management having no idea how to envision and specify a transformation of user needs into solutions. The lack of design is keeping the industry in 100BC.
The strength of a dev's (negative) reaction to this is evidence of the extent of the problem. Most cannot even "see"? how design is the lack of a problem. As a dev turned designer (it just so happens this was what I was fated to do), I have seen this is the core issue - and the most dev teams have the most cursory understanding of how to solve user problems, and how to understand users. The best evidence for this approach is that Apple is the #1 tech company in the world and #3 company in the world after Exxon Mobil and Petrochina. Everything I have said in this email is "their secret sauce."