Eric lippert - Amazon Web Services

Typically, a project starts when a Vision document is created and
approved. That document may include a Vision Statement, overall
scope of the project and the organization of the team. Once this
document is approved, the project kick starts. The Team then
collects the requirements and a requirement document is
created. The raw requirements may come in the form of Minutes of
the Meeting, Emails or a document created by the customer. This
requirement document goes through a process of refinements and
approvals. At the end of that process, it is finalized so that initial
requirements / user stories / PBIs can be added in the TFS. A link
back to the requirement document is inserted in each of these work
items. A similar process is carried out for architecture of the
solution where design documents and diagrams are the driving
force. Approval of these architectural artifacts triggers the
construction (development) phase of the project. We may assume
that if the team follows one of the Agile methodologies, these
architectural documents may not exist, but they do exist to a
certain extent. Iteration zero of any project that follows Agile
creates an overall architectural strategy for the solution and that
is documented. Any phase change in the project is documented
regardless of methodology that is being followed.
it is approved.
2. Link another list of documents to an approval workflow, so that a
document like a requirement document (SRS) is created – reviewed
– approved by the authorized team members.
3. When a document is finalized, appropriate work items should get
created with the required metadata in the appropriate team project
in TFS.
4. When a requirement is added in the team project, a set of tasks
should get spawned to implement that requirement.
In this case, we will first focus on the vision document and then a
requirement document as the driver. Processing the requirement
document creates an additional complexity that is, a requirement
document may (and usually does) contain multiple requirements.
We will need to read those requirements and create appropriate
work items for each requirement. This will require that the structure
of the requirement document should be predefined using a
template. This type of template is a common practice.
We will take a case where the documents are stored in SharePoint
list that works as the document repository. TFS stores the metadata
in the form of work items for the same documents. These work items
can be used for creating hierarchies and for the purpose of
reporting. What we would like to achieve, is a workflow like this:
We begin by creating a library of documents in the portal that is at
the team project collection level. This library will be used to host
the ‘Vision document’. We name that document library as ‘Project
Initiation Documents’ and keep a template of such documents in the
library. Permissions to this library are set in such a way that only the
people who are involved
in the project creation
can access it. We
create two columns for
this library using ‘Library
Settings’ page. One of
them is a simple one
line text property named
as ‘Team Project Name’.
This property allows
the initiator to assign
a name to the team
project. Second column
represents status of the
document which can be
- Needs Approval
- Approved
- Needs Rework
1. When a Vision document is approved in the SharePoint list,
trigger the process to create a new team project in TFS. Name of the
team project should be given as a property of the document when
For this coulmn, we select the type as Choice and provide these
values as available options.
DNcmagazine www.dotnetcurry.com | 31