Team. We will be using the following numbering scheme for our life-cycle documents.
Each feature will be numbered : F.1 through F.f.
Each requirement for feature f will be numbered R.f.1 through R.f.r.
Each specification for feature f and requirement r will be numbered S.f.r.1 through S.f.r.s.
Each architectural design element for feature f, requirement r, and specification s will be numbered A.f.r.s.1 through A.f.r.s.a.
Each detailed design element for feature f, requirement r, specification s, architectural design element a, will be numbered D.f.r.s.a.1 through D.f.r.s.a.d.
Each implementation item for feature f, requirement r, specification s, architectural design element a, detailed design element d will be numbered I.f.r.s.a.d.1 through I.f.r.s.a.d.i.
Each test case for feature f and requirement r will be numbered T.f.r.1 through T.f.r.t.
From the notes on multidimensional concern partitioning , posts on 01.07.2015 and 01.20.2015, you can conclude that each number I.f.r.s.a.d.i represents a point in our n-dimensional nominal space. Although a number such as I.0.1.2.3.4.5 is represented by digits, each digit is directly mappable to a "natural language description" of a feature, requirement, specification, architectural or detailed design element, or implementation item.
We have a small prototype whose kernel is less than 500 lines of code, 0.5 KLOC. Mostly likely, the life-cycle documents will be less than a total of twenty pages. The executive summary, the feature list, and the requirements analysis document should be available by next Monday, 02.02.2015. We have revised the deliverable date of 01.30.2015 since the extra weekend provides some "breathing room".
Keep hunting. pecking, and thinking. Smart foragers often find low-hanging fruit. Happy Coding. La-La.
No comments:
Post a Comment