States
All main project artifacts have their own lifecycle which is used to control them. Primary requirements (issues) are created, refined, implemented, tested, and so on. Each state (stage) is linked with the production technology. System requirements are, in turn, developed, approved, reconciled, and then implemented. These states correspond to requirement development and documenting.
Each state may have the following attributes:
- color that will be used to fill background with the state text;
- form field settings - you can redefine visibility/necessity for fields on the create/edit form of the artifact;
- system actions - internal triggers that are activated when you assign this state to a project artifact.
System calculates how long the artifact is in each particular state. This time is displayed in "State duration" field and can be used in different lists and boards. System also calculated the total duration of lifecycle. It can be used, for example, to know the duration of development of a particular document section. In some states, a team does not work on the artifact, e.g., we wait for the customer reconciliation. In order to avoid impact of the wait time on the lifecycle duration, you can exclude it from accounting by setting "Exclude this state duration from resolution time" flag.
Basic state allows system to know without detailing on which stage of lifecycle the artifact is now - whether it was created recently, or it’s in progress / completed. Basic states are used in system actions, as well as to display artifact UIDs, and to create cross-project boards.
Rules for transitions from one state to another are specified by "transitions". In the transition settings, you can specify whether to request reason of state change, which roles are allowed to execute such transition, and which preconditions must be met before the transition. Also, you can link certain transitions to execution of system actions or reset of field values.
You can develop a PHP script and set it as a precondition for transition. If the condition is met, script must return true, else it returns false. Before the transition is performed, system will execute the script. Depending on the execution result, an operation is treated as successful, otherwise system notifies about the violation of precondition for the transition. You can use the described functionality if you have license for module "Script automation" and set up permissions for this module. To monitor results of script execution, use PHP scripts module in the administrative section.
You can specify additional attributes for issue and enhancement states:
- Tasks - specified list of task types will be inherent to the specified stage, e.g., when decomposing an issue to tasks, system will offer exactly these task types.
- Work-In-Progress restriction - limits used in Kanban process allow to inform your team about the maximum number of uncompleted cards in this state.
- Artifacts - system will offer to create artifacts of this type in this state.
- You can create artifacts in this state immediately - this option allows to control the capability to create artifact in the given state. Users can add cards using boards only in those columns for which this flag is set.
System actions for primary requirements (issues and enhancements) can be enhanced by means of automatic actions. These actions allow to modify issue attributes, reset their values, create tasks or comments when the attribute state or values are changed, comments are created, or by schedule.
Lifecycle differences for different types of one artifact
Errors and enhancements represent different types of one artifact (issue or user story). There are also tasks, requirements, and other project artifacts of different types. You can set up different lifecycles (status models) for different types of one artifact.
Lifecycle differences can be significant or insignificant. For example, if an error must pass the additional reproduction stage by tester, such difference from lifecycle of other issues is insignificant. On the other hand, requests processed by tech support and issues implemented by development team have completely different lifecycles.
| Degree of lifecycle difference | Setup methods |
|---|---|
| Insignificant differences | In the transition settings, you can use predicates "Type: Error" to enable moving artifacts of a certain type to the particular state. |
| Significant differences | As a rule, significant lifecycle differences are caused by different processes that this artifact is involved in. For example, processing requests (custom requirements) on the first line of support requires additional setup of software interface. For this reason, different lifecycles for custom requirements are formed by different processes (projects). You can unite such processes and projects into the single control space by means of Project program or Project portfolio. Thus, you can see all custom requirements on the project program level, and control lifecycle of a particular custom requirement on the sub-project level (different processes) depending on the processing stage: support or implementation. |
System actions
System actions actions have attributes, values of which are described in the table below.
For system actions, you can specify flag "Notify user before action execution” that allows to notify in advance that this system action will be executed at the moment of transition or state modification. For example, this can be useful when executing such cascade actions, as state modification for parent or nested sections of requirements, test or operational documentation.
Issues and enhancements
| Action name | Purpose and specifics of use |
|---|---|
| Modify state of source issues |
If a story, an issue, or a request is linked with one or several issues using the link of type "Implementation", you can control state of these issues using this system action. Specify system name of the state to which source issues must me moved. This system name must be used as attribute. |
| Implement in project |
When the system action is executed, a copy of issue, story, or request will be created in the target project. A link of type "Implementation” will be created between issues. Code name of the target project in which a copy must be created is specified in the system action attributes. You can specify several code names separated by commas. In this case, several implementations of the source issue will be created. |
Tasks
| Action name | Purpose and specifics of use |
|---|---|
| Modify the state of story or issue (during the first transition) if all tasks of the current stage have one state |
For example, story or enhancement is on development stage. At the same time, the story is decomposed to testing, documenting tasks, etc. You need to move the story to the development stage automatically if all development tasks are completed. You can link task types to the stage (the state of story or enhancement) on the edit form for enhancement state:
|
| Move linked artifacts to the next state |
The linked artifact can be a business or a system requirement, a test scenario or a technical documentation section. This action allows to automate modification of the linked artifact's state, e.g., when the task is completed. Application options:
|
Requirements
| Action name | Purpose and specifics of use |
|---|---|
| Mark the documentation of linked function as obsolete |
A requirement can be linked with one or several functions. That means that this requirement refines (specifies) these system functions or product features. Functions can also be linked with test scenarios or test documentation sections. This system action allows to mark function documentation as obsolete. |