How to write a 'system spec' for an app based on a business spec.
-
I have asked this question in Quick Q&A, but I only got one answer there, and that answer also said something I agree with. That is that the quick answers are not the place for that answer, so I have accepted it, based on the two sample documents and styles it gave, but now I'm asking the same question on a proper board, hopefully to glean more answers/discussion. I suppose what I'm actually asking for is at best a template, then some suggestions of what areas I must specify. I have a business spec in terms of user stories together with additional validation rules etc. per story. I think my spec, which should be divided into front and back-end, for two teams of developers, will be quite large on the basic makeup of the app - how it should be implemented (ASP.NET MVC is a requirement, as that is our standard), and thorough descriptions of the horizontal services. It will then have small appendages of detail for each use case. Am I on the correct track here?
Immanentize the Eschaton!
-
I have asked this question in Quick Q&A, but I only got one answer there, and that answer also said something I agree with. That is that the quick answers are not the place for that answer, so I have accepted it, based on the two sample documents and styles it gave, but now I'm asking the same question on a proper board, hopefully to glean more answers/discussion. I suppose what I'm actually asking for is at best a template, then some suggestions of what areas I must specify. I have a business spec in terms of user stories together with additional validation rules etc. per story. I think my spec, which should be divided into front and back-end, for two teams of developers, will be quite large on the basic makeup of the app - how it should be implemented (ASP.NET MVC is a requirement, as that is our standard), and thorough descriptions of the horizontal services. It will then have small appendages of detail for each use case. Am I on the correct track here?
Immanentize the Eschaton!
Current physical -> current logical -> new logical -> new physical. Sounds like you're at the "new logical" phase. You can now do a proper "logical" design at this point (DFD's; ERD's; data dictionary; EPC's; UML; pseudo-code; etc.); or go "agile" and just start programming.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I have asked this question in Quick Q&A, but I only got one answer there, and that answer also said something I agree with. That is that the quick answers are not the place for that answer, so I have accepted it, based on the two sample documents and styles it gave, but now I'm asking the same question on a proper board, hopefully to glean more answers/discussion. I suppose what I'm actually asking for is at best a template, then some suggestions of what areas I must specify. I have a business spec in terms of user stories together with additional validation rules etc. per story. I think my spec, which should be divided into front and back-end, for two teams of developers, will be quite large on the basic makeup of the app - how it should be implemented (ASP.NET MVC is a requirement, as that is our standard), and thorough descriptions of the horizontal services. It will then have small appendages of detail for each use case. Am I on the correct track here?
Immanentize the Eschaton!
Brady Kelly wrote:
I have a business spec in terms of user stories together with additional validation rules etc. per story.
So you have a description of what the system, the entire system, will do.
Brady Kelly wrote:
I think my spec, which should be divided into front and back-end, for two teams of developers, will be quite large on the basic makeup of the app
You have a description of what it will do. You do not have a description of how it will do it. Those are two different things. And a "large" system should start with one or more architecture documents so there is some framework for understanding how the pieces will fit together. That plus some more specific designs will also provide direction on how front and back end work is divided. If there are pieces that cannot be quickly white boarded or where there are arguments about the 'best' way to do it, then it needs to be designed.