# LinkTypes

LinkDescription:
The requirement has an 'existence dependency' upon the main requirement.

Advice:
Check whether there are real dependencies between the following requirements.


Advice:
Check whether the following requirements are genuinely equivalent and determine whether they can be merged into a single requirement.


Advice:
Check whether there is a genuine conflict between the following requirements.


LinkDescription:
The two requirements overlap and are complementary to each other

Advice:
Check whether the overlapping aspects of these requirements can be factored out into a separate, stand-alone requirement.


LinkDescription:
The second requirement is a subset of the first requirement.

Advice:
Check whether each of the following requirements are subsets and whether the 'minor' requirement can be merged into the main requirement or whether the main requirement requires decomposition.


# ProcessModel

ModelDescription:
Agree team members, record basic contact details and arrangements for team meetings.


ModelDescription:
Agree project terms of reference, client details and project name


ModelDescription:
Check all documents available, all team members have copies


ModelDescription:
Use organisation charts and personnel descriptions to create a list of organisational units


ModelDescription:
Cross reference the stakeholders to organisational units


ModelDescription:
Analyse each stakeholder and organoisational unit and consider the obstacles they face in achieving their business goals


ModelDescription:
Identify those general constraints, outside the control of the business, which may impact the business


ModelStep:
Review initial units, stakeholders, problem and constraints list

ModelDescription:
Ensure consensus amongst the team on the key stakeholders and their problems


ModelDescription:
Using the identified problems, create an initial requirements list.  Ensure that requirements are specific, achievable and address the problem.


ModelDescription:
Review the initial set of requirements, checking for completion.  Use the Validation report to check that requirements are linked to problems.  Ensure that there is at least one requirement for each stakeholder.


ModelDescription:
Consider the events at the system boundary.  What does each stakeholder input to the system- identify the control message and underlying event type.


ModelDescription:
Take each event in turn and identify the data which accompanies the event


ModelDescription:
Identify initial objects by considering clusterings of events on data items


ModelDescription:
Review each event and consider the objects that the event impacts; link event to those objects


ModelDescription:
For each object, use the Analyst Fact Workbench to suggest possible data items which might form part of an object's description


ModelDescription:
Consider the processing that needs to be carried out by the system by reviewing each event at the system boundary and considering what activity that will start


ModelDescription:
Show how processes support identified requirements


ModelStep:
Validate requirements and their processes

ModelDescription:
Identify whether any requirements are not supported by processes and add additional processes as necessary


ModelDescription:
Identify any constraints which might impact processes and create a link between them


ModelDescription:
Consider the impact that each process will have upon each object and record it as C, R, U or D


# ExportModel

ModelDescription:
Agree team members, record basic contact details and arrangements for team meetings.


ModelDescription:
Agree project terms of reference, client details and project name


# Help- Reports

Description:
The "Activity Summary" provides a summary of the number of minutes spent on each activity defined in the system's process model.  Durations are entered in the activity log.  The number of entries for each activity and the average time spent per session of the activity are also shown.

Validation:
No activity should show a zero value (unless the activity is optional).


Description:
The "Constraints" report lists all constraints recorded in the fact base and the processes upon which the constraints impact.

Validation:
Each constraint should impact upon at least one process.


Description:
The "Events" report lists all the events recorded in the fact base.  The report also shows known aliases for the event, the control message by which the event is made known to the system and the source of the control message (for example, 'arrival of order in the post' is a control message and 'customer' would be the source of the control message.  The data items 'carried' with an event, and their type (e.g. date/time, integer, string etc.) is also shown.  Events should be linked to objects (zero, one or more) and associated objects are shown in the report.  Events may also start zero, one or more processes.

Validation:
All events should have a control message (the means by which the event is made known to the system), as well as a source.  In the case of more than one source, the event should be differeniated by another name.  

There should normally be at least one data item associated with an event and at least one object to which the event is assigned.  A check should be made that the data associated with an event can be used to identify a specific instance of each associated object.  For example, if an event was 'return of library book', there should be a data item associated with the event that identifies the associated object 'library book'.


Description:
The "Objects" report lists all objects recorded in the fact base, together with known aliases.  Data items associated with each object are listed, together with their type  (e.g. date/time, integer, string etc.), as well as the events with which the object is associated.  The report also lists those processes which manipulate the object and their impact upon the object (CRUD, create, read, update or delete).

Validation:
Objects should have at least one data item, at least one event and a set of processes which manipulate the object.  In particular, there should be at least one process which reads or updates the object; at least one create event which creates a new instance of an object and optionally one or more delete events.


Description:
The "Organisational Units" report lists all the organisational units recorded in the fact base, giving a textual description of the unit and a list of the stakeholders related to the unit.

Validation:
An organisational unit should have a description and at least one stakeholder member.


Description:
The "Team Requirement Preferences" report list the requirements voting of each team member.  For example, whether requirement 1 is more or less important than requirement 2.

Validation:
All pairs of requirements should be voted on by each team member.


Description:
The "Business Problems" report summarises the business problems recorded in the fact base.  Each problem has a description, the symptoms nby which the problem can be identified and measured, the impact that the problem has on the business and the seriousness of the problem (e.g. critical).  Problems are also assessed as being within the scope of the system or outside the scope of the system.  The report has a list of requirements which stem from the problem and a list of relevant stakeholders.

Validation:
Each business problem must have symptoms by which it can be identified and measured, otherwise it is not possible to quantify and prioritise the significance of the problem.  

Problems must have at least one associated requirement which can be used to address the problem.


Description:
The "Processes" report lists all processes recorded in the fact base.  Each process has a description and list of known aliases.  The report also lists the objects which are manipulated by each process and the impact the processes has on each object (CRUD, create, read, update or delete).  Also listed are the events which start the processes, the constraints which impact the process and the requirements which the process supports.

Validation:
Each process must manipulate at least one object, be started by at least one event and support at least one requirement.


Description:
The "Requirements" report lists all requirements recorded in the fact base.  Requirements can be classified into their importance and whether they are within or outside the scope of the system.  The report also shows the business problems which each requirement is intended to tackle and the processes which implement the requirement.

Validation:
Each requirement should have at least one associated business problem.  It is possible for a requirement to be associated with more than one business problem and for one business problem to be associated with more than one requirement. Every requirement should be supported by at least one process.


Description:
The "Team Requirement Scores" report lists all requirements recorded in the fact base and a summary score for each team member.  The higher the score, the greater the importance place on the requirement by the team member.  

A score of zero generally indicates that the team member has not voted on the requirement or ranks it as totally unimportant.

Validation:
Where a 'voting completion' figure is given, it shows the percentage of requirement pairs matching completed by the team member.  Such team members need to complete their voting.


Description:
The "Stakeholders" report lists all the stakeholders recorded in the fact, the organisational unit to which they are assigned, a description of the stakeholder and a list of problems related to the stakeholder.

Validation:
A stakeholder should have a description.  A check should be made to ensure that all problems recorded in the fact base are properly assigned to stakeholders (may be more than one stakeholder).  When presenting the problems identified, it is important that these problems are related back to stakeholders so that each stakeholder can identify those problems related to their activity.  It will be more effective to present problems in relation to stakeholders than in the abstract.


Description:
The "Team Activity Summary" shows the number of minutes recorded for each task performed by a team member and recorded in the system's activity log.

Validation:
A team member should have a non-zero value for their 'total project effort'.


Description:
The "System Validation" report lists possible errors associated with the various facts recorded in the fact base.  The report is structured around different fact types (events, objects, processes etc.)

Validation:
Potential errors should be analysed and the necessary corrections made.  

Note that some error messages are advisory.


