App-Requirement-Arch

 view release on metacpan or  search on metacpan

Todo.txt  view on Meta::CPAN

split load_and_filter_requirements

explain why this module


add output section in the application documentation

master template and master categories when requirements come from different project
	shall we merge or verify each requirement to its own masters?

show  all the files (and structure) needed to run the applications

can we have commands that can be  piped into each other?

	ra select r1 | ra select directory/  | ra check --templates | ra check --script | ra filter- something | ra merge | ra filter- something | ra show --dhtml
	
	can we keep a server instance up to avoid reloading or re-evalauating requirements?
		we could also implement the pipes ourselves
	

lib/App/Requirement/Arch.pm  view on Meta::CPAN

	- Each requirements are gathered in a text file
	- The Requirement must match a specified format
	- The format is Perl
	- The format requires the presence of specific fields
	- The requirements can be gathered from multiple places

=head3 Consequences:

	- gathering requirement is simple (except if your product manager has problems opening files with unix line ending (no this is not a joke))
	- tools to verify the format of the requirements are easilly written

=head3 Positive side effects:

	- requirements can be shared between projects, simply gather them from multiple projects
	- the physical organisation of the file is left to user, have any directory structure you deem good
	- requirements can be under version control and you can choose whatever system you like
	- you can use the tools you are used to (this was listed above as a goal)
		- your favorit text editor
		- your favorit version control system
		- your favorit explorer (konqueror, lynx, mc, tree, ...)

lib/App/Requirement/Arch.pm  view on Meta::CPAN

		CATEGORIES => {TYPE =>$ARRAY, DEFAULT => []},
		NAME => {TYPE =>$SCALAR, DEFAULT =>''} ,
		...
		},

Each field has a 

	TYPE:  $SCALAR or $ARRAY
	DEFAULT: a default value
	ACCEPTED_VALUES: values that are used to verify the contents of the fiels
	OPTIONAL: wether the field is optional or not. I prefer always having all the fields but other user may prefer not seeing them. Unecessary fields
		are ugly (but the whole buisiness is rather unxxx). the disadvantages of not seing all the fields is that the user has to know what she can
		write or not which, IMO, makes it more difficult
		
TODO: add a comment entry in each field so it can be displayed as help to the user	

=head3 Verification

Once you have created your requirement you can check it's validity with tthe B<ra_check> application. You can check multiple requirement
simulteanously.

lib/App/Requirement/Arch.pm  view on Meta::CPAN

		'Runtime build options' => 
			{
			'_DEFINITION' => 'User selectable runtime options for the build tool and expected system'
			},
		...
		},
	}

=head3 Verification

Running the B<ra_*> application will verify the categories you have assigned to requirements. Categories that are declared in
I<master_categories.pl> will be reported.

=head3 Physical sorting of the requirements

The file system layout doesn't have to match the requirement categorization, although that is sound.

Filesystem layout example:

	$> tree -d 
	.                                             

lib/App/Requirement/Arch.pm  view on Meta::CPAN

return get_template_files_from_directory(home() . '/.ra/templates', $master_template_file, $master_categories_file, $free_form_template) ;
}

#--------------------------------------------------------------------------------------------------------------

sub load_master_template
{

=head2 load_master_template($master_template_file)

Load and verify the master template.

I<Arguments>

=over 2

=item * $master_template_file - Name to a file containing the master template.

=back

I<Returns>

lib/App/Requirement/Arch.pm  view on Meta::CPAN

return $requirement_template ;
}

#--------------------------------------------------------------------------------------------------------------

sub load_master_categories
{

=head2 load_master_categories($master_categories_file)

Load and verify the master template.

I<Arguments>

=over 2

=item * $master_categories_file - Name to a file containing the master categories.

=back

I<Returns>