Wiki
This website is a wiki. If you like and use our processes, techniques and tools, please add your experience and best practices. Just register and share.

Contents


User


Smart


Community

Forum






The main goal for the stage Propose is to deliver a project proposal. One of the key elements in a proposal is to get a valid estimate for the project at hand. This estimate is based on smart estimation. Smart estimates are based on smart use cases - as you might expect. Before modeling smart use cases, you should first perform an intake on the input documents from the customer. This input then allows you to distill the smart use cases.

Customer input

On of the crucial activities of the Propose stage is to perform an intake of the input the customer presents you with. This material is then transformed to smart use case diagram, to create the actual estimate. In general the handover process can be executed using the following recipe.

Recipe
  1. Identify the business processes at high level from the customer input.
  2. Model the elementary business processes from these high level business processes. In some cases these are already present in the customer input. Elementary business process generally follow the OTOPOP prinpiple, one-time, one-place, one-person.
  3. Model a use case diagram per elementary business process. Place a use case with the same name on the diagram. this use case resides at user goal level.
  4. Add sub-function level use cases to the use case diagrams when applicable. Follow the guidelines for smart use case modeling.

Customer input can consist of:
  • Request for proposal. A request for proposal in most cases contains a high level overview of the business processes to be supported.
  • Enterprise architecture. Enterprise architectures in general consists of a combination of components and services, domain models (e.g. for mortgages) and modeled business processes.
  • Business models.
  • Business analysis.
  • Workshop.
  • Functional design. Detailed
  • Business analysis. Every business analysis report will contain an overview of business processes.
  • Traditional design.
  • Existing documentation.
  • Existing application.

Handover for request for proposal

In most cases a request for proposal that is issued by a customer contains an high level overview of which business processes the new software should support, what the new software should look like, and how it should be built.

Handover from request for proposal

Handover from request for proposal

The handover process from this request for proposal to smart use cases can best be performed using the following recipe.

Recipe
  1. Identify all high level business processes from the request for proposal.
  2. Model business processes in workshops with the customer or his representatives (either business architects or analysts, up to the level of elementary business processes.
  3. From here, model smart use case diagrams per elementary business process. Modeling these smart use cases works well in requirements workshops with the actual end users.

Handover for enterprise architectures

Enterprise architectures in general will consist of a number of deliverables. These include modeled components and services, domain models (e.g. for mortgages) in class diagrams and modeled business processes, quite often modeled in sequence diagrams of collaborating services.

Handover from enterprise architecture

Handover from enterprise architecture

Apart from the handover process for domain models, which are off course also needed in software development, the handover process from an enterprise architecture to smart use cases should be performed using the following recipe.

Recipe
  1. Identify all high level business processes from the modeled business processes.
  2. Model business processes, up to the level of elementary business processes.
  3. From here, model smart use case diagrams per elementary business process.
  4. If the enterprise architecture contains models of services collaborating to perform the business processes, model these services as actors on your use case diagrams.
  Name Size