Investigation is the process of analyzing the application model requirements. You must perform several investigations in parallel that may influence each other:

• Investigate Use cases
• Investigate Current applications
• Investigate Other requirements

Deliverables

1. An impact map with an visualisation of scope and underlying assumptions.
2. Use case descriptions for the use cases to be delivered in the first iteration, including a use case connection diagram if there are more than a few (like 4) use cases.
3. Current data model.
4. Current functionality.
5. Current external applications.
6. Current architecture.
7. Other requirements. 

Investigate Use Cases

A use case is a list of steps defining interactions between a role and an application to achieve a goal.

Defining too many uses cases up front, may result in "use case hell" or "story card hell", since a big story list needs to be tracked and managed, which wastes time. Therefore, to guide us an Impact Map is to be set up, and use cases created for the most important actor impact for the moment (the current iteration). Read more about Impact Maps at www.impactmapping.org.

The level of detail can be hard to figure out. Our guidelines are:

• Detailed enough to be able to define an application model during the Draft stage. But not as detailed as the application model itself.
• Readable by your customers, using their concepts or terms.
• Readable by your designers, i.e. your project members drafting the application model.

Each use case must be described with both a minimum and maximum of information. The minimum information is:

• Goal. The goal the use case is trying to satisfy.
• Roles. The roles involved in this use case. A role may be a human or a system. Note, we are not talking about the roles involved in describing the Genus Modeling Process itself.
• Story. Sentences describing steps. A step is a simple statement of the interaction between the role and the system you are creating or changing.

Regarding "maximum of information", the use case should be as short as possible, typically one section or paragraph, making it possible to fit minimum two use cases per page. We do not want elaborate descriptions, but prefer simple statements. We expect different users of the Genus Modeling Process to have different needs.

We do not require a specific notation, i.e. you may utilize UML Use Case Diagrams or textual descriptions, or others as described in your methodology of choice. However, we urge you to keep them short, to avoid "use case hell".

Use cases are often connected, which means there is a need for a use case connection diagram, showing the connections or paths between the use cases. Such a connection diagram should be limited to within an impact (ref. Impact Map).

Investigate Current Applications

Your application model may borrow terms and concepts from other applications. Your application model may even replace one or more applications.

Investigating current applications is a crucial activity to meet your customer’s requirements, as these requirements often are understated or otherwise not well communicated.

We require the following investigation activities:

• Document data model. Find or analyze the relationships between the objects or entities in the current applications. Obtain or draw a data model using a tool, like Genus Studio Diagram. Look at the data, not just the model - make sure you really understand the relationships and the terms or concepts, and the quality of the data.
• Document functionality. Find or analyze the functions in the current applications. Make a structured list of all functions.
• Document external interfaces. Find or analyze how external systems interact with the current applications. Make a structured list of all interfaces.
• Document architecture. Find or analyze if there are any non-functional issues that need to be described and carried forward to your application, like execution qualities (security, usability, performance) and evolution qualities (testability, maintainability, extensibility, scalability).

Investigate Other Requirements

Other requirements are typically requirements that your customer may not (directly) care of or have the competence or experience to describe, like non-functional or technical requirements. Here are some types of requirements you may want to investigate further:

• Security and Privacy
• Audit and control, like audit trails
• Performance
• Configuration Management
• Documentation
• Scalability

These requirements may overlap with findings in the "Investigate Current Applications" activity. Do not document the same requirements twice.

To get more ideas on types of requirements, have look at Wikipedia’s article regarding non-functional requirements.