Application specifications and requirements
Project specifications and requirements can be stored and managed directly within the system.
This tight integration has two main benefits. First, your project requirements and specifications are always linked to the current state of your application. This facilitates rapid development projects where documentation and requirements can quickly become out of date. Second, dynamic linking allows the application to evolve without losing the ability to reference what was originally conceived and desired from the application.
Because these associations are made directly in the system, you can:
- Generate up-to-date specifications and requirement lists and matrix reports.
- Gain insight into the application from a specification and requirements point of view.
- Generate application documentation that includes the specification and requirement information (using the Application Document wizard).
About application specifications
Application specifications use business language to describe the steps required to process and resolve work in an application. As you develop your application, you usually write specifications:
- On the Specifications tab on the Application Profile landing page ().
- In Process Modeler or the Case Designer Process Outline view. For a given process, you can associate specifications with:
- Most shapes in Process Modeler. Open a shape's Properties panel to create a new specification or select an existing one using the Specification Actions link in the panel header.
- Steps In the Case Designer Process Outline view. Select a step in the Outline tree to open its Properties panel. Create a new specification or or select an existing one using the Specification Actions link in the panel header.
- The overall process by selecting the Process Modeler canvas, right-clicking, and selecting Specifications.
Specifications can be reused to ensure consistency across other processes in an application, and make it easier to update processing steps when you need to implement a change.
Specifications:
- Specify one or more actors
- Specify a single event or method that triggers it; think of it as one short process in a comprehensive use case
- Do not involve a change of ownership during the steps
- Correspond to one particular step or series of steps within a screen flow type of process, or within a single flow action in the processing of a case.
- Describe the processes to be performed including the steps involved in completing the specification, applicable edits, and the expected behaviors and outcomes
- Provide enough business detail so that a developer can implement it and a user can test it
- Take only a few minutes to enter
About application requirements
Application requirements use business language to describe the project and processing needs that must be met for processing work and data in the application. Think of requirements as an inventory of events, conditions, or functions that must be satisfied and tracked in a development project. They also provide benchmarks against which the application can be tested. Typically, you associate requirements with a corresponding specification, which itself is associated with the processes, subprocesses, and process steps.
Usually, you create requirements:
- On the Requirements tab on the Application Profile landing page ().
- In the Requirements section in the Add/Edit Specifications dialog.
- In Process Modeler or Case Designer Process Outline view, open a shape's properties panel and select to open the dialog.
- On the Specifications tab on the Application Profile landing page, click a specification link on a row.
A good requirement:
- Describes the need in business terms so that it is easily understood by the implementation team
- Has an identified category type (such as "Enterprise standard" or "Business rule") and level of importance to the application
- Indicates its current implementation state (such as
OpenorWithdrawn)
Requirements are typically categorized according to the following requirement types:
| Type | Description | Example |
|---|---|---|
| Business rule | Related to the business processes in the specific application. Is usually associated with a specific use case or step in a process, and identifies the system behavior at that step. | First Name should not be longer than 20 characters |
| Change control | Related to the needs of making modifications in the application and system, and managing those changes. | System shall support two-digit version numbers |
| Enterprise standard | Identifies an enterprise- or industry-wide standard to which the application or system must adhere. | Routing Transit Number must be 9 digits |
| Functional | Similar to the business rule type, identifies what the system has to do. Typically used to identify a function that will be used in the application, such as a data transformation or calculation, rather than describing system behavior. | Remaining budget must be calculated to two decimal points |
| Non-functional | Identifies qualities the overall system must have, typically related to how the system performs. | System needs to have 2-3 seconds screen to screen interaction |
Additional information
Managing your application profile from the Application Overview landing page
How to manage specifications and requirements from the Application Profile landing page
Previous topic Associating project specifications with business impact and complexity Next topic How to use the DCO Compatibility tool