Implementations state how a business rule or business object is actually realized or built in the software. They may refer to constraints, decisions, batch jobs or menu pages, but also to very specific ways of solving some problem within the repository, or within the organization. Here are some examples of implementations:
Everything covered by constraints and decisions.
Jobs defined with USoft Batch in the USoft Definer.
Rules or objects implemented by means of specially designed web pages, windows, or menu pages. You can either list specific pages or windows by business object, or you can describe special adjustments to screens as separate business rules.
These could be software components that are part of the application being built without being developed within USoft Developer. Design and test documents can also be seen as external elements.
Implementations of a rule of type "Nobody is allowed to ..." in the organization.
Agreed ways of working, communicating or dealing with specific problems. This type of implementation could be completely independent of software, i.e. not directly supported by software.
From the point of view of Business Rule definitions, implementation information allows team members to trace solutions. It helps them find out how something was built even when the builder has left the team, or long after the solution was last touched.
From the point of view of technical structures such as Constraints and Decisions, implementation information allows team members to trace what was the functional purpose of that structure. This allows them, for example, to answer the question of whether a structure is still needed.
To formalize the various types of implementation in use, and thereby improve traceability, you can use implementation types.
Implementations are physical realizations of Business Rules and Business Processes. You can implement a Rule or Business Process by building a data structure, SQL constraint, batch job, menu item, interface element, component or web service, and more. Many Rules and Processes require a combination of these.
By entering Implementations in USoft TeamWork, you establish valuable links between Rule and Process formulations on the one hand and physical realizations on the other. These links are queryable in many ways so that both the history of requirements and the details of the actual software can be traced and maintained with ease.
Implementations in USoft TeamWork are on a take-it-or-leave-it basis. You can independently formulate Rules, implement them, and enter Implementation information (i.e. the link between the Rule and its implementation) in any order and to any degree this is helpful or feasible.