GoFuckYourself.com - Adult Webmaster Forum - View Single Post - How do you usually format a project outline?

Coyote · 02-26-2006, 06:04 AM

First, let me preface this reply with an apology for it being so long.

A functional requirements spec can and should be as detailed as possible to limit the features to only those you want incorporated. When the spec is complete it should restrict all programmers from deviating from the intended functionality of the application.

Since applications are procedural by nature you could use an objective hierarchy as the method to create your spec. This allows you to break each objective down to the task and step level. For each objective, there may be one or more assigned tasks, and for each task, there may be one or more assigned steps. You can call these elements whatever you like, it's the structure that matters.

I'll explain this using an excerpt from a spec I did some years back. I've edited out a lot of company-, programming-, and nda-specific information but the basic elements are present. This excerpt describes adding a "Search" feature to an existing application.

Objective There needs to be a means by which the user can select the type of object they want to work with and, optionally, provide a partial or complete object name to further isolate the desired object. This is the primary means by which a user locates one or more objects within the database.

Task 1 Create a combobox that contains all the valid objects.
*omitted*

Task 2 Create a textbox where the user can enter a partial or whole object name.

1. The user may enter a wildcard to denote Any Name. This wildcard is represented by an asterisk (*).
2. The user may prefix the wildcard to a text string to denote any name ending with the text string.
3. The user may append the wildcard to a text string to denote any name beginning with the text string.
4. The user may combine the use of both wildcard positions to denote any name that contains the text string. This is the system default when no astersik is specified.
5. If no text entry is made, then the default entry * is assumed. This is identical in function to selecting the Object Type from the View menu on the application main menu.

Task 3 Create an action button that performs the search against the object database.
*omitted*

At the end of your spec, you should include the general business rules that govern the specific objective. Like so,

Business Rules
1. Only valid object types as determined by user roles and node assignments are listed in the search combobox.
2. If no results are returned, a dialog box is displayed. The search combobox and object name textbox must contain the user?s entries as they appeared at the time of the search request. Refer to the Dialog Box Specification for more information about using dialog boxes and user error messages.

Finally, you could add additional sections to your spec that cover issues such as,

Other areas of the application that may be affected by this project,
An application version history,
Specific test cases to validate the submitted code, to name a few.

Hope this helps.

02-26-2006, 06:04 AM
Coyote Drinker of Scotch Industry Role: Join Date: May 2003 Location: Texas Posts: 242	First, let me preface this reply with an apology for it being so long. A functional requirements spec can and should be as detailed as possible to limit the features to only those you want incorporated. When the spec is complete it should restrict all programmers from deviating from the intended functionality of the application. Since applications are procedural by nature you could use an objective hierarchy as the method to create your spec. This allows you to break each objective down to the task and step level. For each objective, there may be one or more assigned tasks, and for each task, there may be one or more assigned steps. You can call these elements whatever you like, it's the structure that matters. I'll explain this using an excerpt from a spec I did some years back. I've edited out a lot of company-, programming-, and nda-specific information but the basic elements are present. This excerpt describes adding a "Search" feature to an existing application. Objective There needs to be a means by which the user can select the type of object they want to work with and, optionally, provide a partial or complete object name to further isolate the desired object. This is the primary means by which a user locates one or more objects within the database. Task 1 Create a combobox that contains all the valid objects. omitted Task 2 Create a textbox where the user can enter a partial or whole object name. 1. The user may enter a wildcard to denote Any Name. This wildcard is represented by an asterisk (). 2. The user may prefix the wildcard to a text string to denote any name ending with the text string. 3. The user may append the wildcard to a text string to denote any name beginning with the text string. 4. The user may combine the use of both wildcard positions to denote any name that contains the text string. This is the system default when no astersik is specified. 5. If no text entry is made, then the default entry is assumed. This is identical in function to selecting the Object Type from the View menu on the application main menu. Task 3 Create an action button that performs the search against the object database. omitted At the end of your spec, you should include the general business rules that govern the specific objective. Like so, Business Rules 1. Only valid object types as determined by user roles and node assignments are listed in the search combobox. 2. If no results are returned, a dialog box is displayed. The search combobox and object name textbox must contain the user?s entries as they appeared at the time of the search request. Refer to the Dialog Box Specification for more information about using dialog boxes and user error messages. Finally, you could add additional sections to your spec that cover issues such as, Other areas of the application that may be affected by this project, An application version history, Specific test cases to validate the submitted code, to name a few. Hope this helps.