I will use this document to write down some requirements/features I've been asked around DTGov/S-Ramp so they can be taken into consideration for later releases. I will provide no order and no concrete target where should be implemented, but a description of the feature.

As a user, we can model a "project" in S-Ramp as a group of artifacts that related together. This project has, or can have, a defined lifecycle, from inception to definition, implementation, operations,...

Usually, the people that wants to include a governance solution into an organization is the people that manages the organization, as governance is a way of reducing/analyzing performance and/or costs. These people need to get metrics on every/different information related to the project, so they can see whether a project is worth the investment they have made, a group is working as expected, what tasks are taking longer (which are costing more). At the end, we need that every step defined in the "lifecycle" of the project need to create an event with relevant information, that could be sent to a RTGov server (or similar) and have business managers, project managers, team managers, developers, architects,... get the information they want in an easy way (with dashboards). Some samples of the information that could be of interest is:

• How long does it take to a project to go from "starting" to "end"
• How many projects do an organization have in each of their lifecycle/stage
• What projects are more "used"/"reused"?
• What steps of the workflow are usually taking longer time to execute
• How do a company "reuse" the assets they create for a project

This is a brief list of things that may be of interest to the management side of governance, which is usually the one that will enforce the use of a governance solution in an organization.

Another important feature is "consumers" of "artifacts". As artifacts for a project will be stored in S-Ramp, this should be the source of every artifact. If a developer needs an artifact (doc, spec, wsdl, project, jar) he should be able to get it from here, at design time. There needs to be connectors to consume this artifacts in an easy way, from "command line", "web" and "IDEs". So if a user needs a wsdl can fetch it and ad it to their own project. Ideally, they should not always get the artifact itself, but a way to reference that artifact, so at build time can be resolved. In case of a "jar file", there needs to provide with the "gav" coordinates to fetch it from the repo. If it is a wsdl file, maybe should provide with the artifact itself (the wsdl) or maybe with a "url" to discover the artifact at runtime. When working from an IDE it is crucial that the repository is part of the IDE in terms of dependencies, so it does not introduce many/any additional step to use the repo. So there should be IDE plugins that will manage this interaction seamlessly with the repository. 

There needs to be a way to visualizing graphically the dependencies between artifacts and also between projects (in the ui).

There should be the possibility to add SLAs/Policies to states/transitions in the lifecycle of a project, and be able to trigger some actions based on the policies. This way, a manager can create a policy that an implementation must be made within 10 days after the definition has been approved, otherwise he'll be notified.

There should be a way of seeing the state of the projects, so if there are different versions, know where is each versions, or what projects are in certain state (in production, in development,...).

As repositories might be dispersed (a very big organization) will not rely on a single repository, it should be possible to federate multiple repositories. One option is to have proxy repositories and hosted repositories (ala Nexus) or have a more tight federation (maybe by using teiid).