DevSpec 3.0 User Guide
  • Author:TechExcel co.Ltd
  • Date:
Table of Content
DevSpec 8.0 User Guide

Key Benefits

  • Define product or project requirements.
  • Track what requirements are not covered by a development work items or test cases.
  • Identify which features or functions in the design are not required internally or externally.
  • Control requirement changes and view the impact of the implementation of such changes.
  • Provide lifecycle traceability and review requirement implementation and validation

 

Features Overview

  • Create, manage, discuss and link project requirements and features.
  • Fully supports Scrum, Iterative development, Waterfall, and many other methodologies
  • Automaticrequirement versioning whenever specified changes are made combinedwith approval tracking and a robust workflow engine.
  • Requirements,specification and other key digital assets are stored in a reliable andsecure central data repository (with support for storage in externalSCM systems from Perforce and Subversion.)
  • Outof the box integrations with DevTrack and DevTest allowing projectmanagers to view the complete development lifecycle for all projectrequirements.
  • Poll stake holders on requirement and feature value, risk or other user-defined criteria.
  • Create "what if" scenarios for product feature sets and time estimates using DevSpec "Options".
  • Definerequirement and feature interfaces you want with extensivecustomization options including user-defined field labels, field types,drop-down menu options, master-detail relationships, and custom reports.
  • Integration with Microsoft Office and Adobe PDF
  • Built-inpresentation quality reports enable you to easily report on allrequirement and feature data, change control and change impact as wellas implementation and testing data for requirements and features.
 Chapter 1 Requirement Management with DevSpec
1.1 TechExcel DevSpec

DevSpec is a software tool for requirements management. It is built around modern collaboration technologies. Managing requirements with DevSpec is easy and fun with a WYSIWYG wiki editing tool, coupled with the full power and flexibility of workflow controls, process automation tools, a definable GUI, and built in support of popular development methodologies including Agile, iterative, and traditional waterfall methods.

Before explaining too much about what DevSpec is, it would be best to define the two terms used most in this guide.

Requirements- A requirement represents a description of some feature or set of features. Requirements can take many forms, and these differ based on your processes and your team. We will cover the various ways to use requirements later in the document.

Specifications- A specification details work to be done. This is the easiest way to understand specs in DevSuite. A specification should be detailed enough so that the person responsible for implementing it knows what their role should be. In most cases, specifications should cover 1-5 days of work.

DevSpec is not only a tool for gathering and refining ideas, but also for defining the repeatable processes that ensure that good ideas are consistently realized and delivered in the final product. DevSpec enables businesses to define and manage a process for transforming good ideas into requirements and specifications, so that those ideas may be fully realized and delivered to the customer.

Requirements, specifications, and other key digital assets are stored in a reliable, scalable, and secure central data repository. In addition, requirements and specifications may be linked to development work items and test cases, so that all project stakeholders -- management, development, and QA -- may collaborate and track changing requirements and specifications throughout the project lifecycle.

The system also enables project team members to organize, prioritize, and monitor project requirements at every stage in the project lifecycle, manage multiple versions of requirements, track requirement changes, and ensure the accurate implementation of specifications. DevSpec facilitates access to information and collaboration between internal and external stakeholders, so that good ideas are expressed in thorough requirements and well-defined specifications, so that the end product realizes the initial vision.

1.2 DevSpec as a Part of DevSuite

TechExcel DevSuite is a family of integrated application lifecycle management (ALM) tools that place knowledge management - from ideas, to formal specifications, to competitive information, to issue resolution and customer insight - at the core of any product development initiative.

The DevSuite knowledge-centric strategy enables improved communication, ensures users are up-to-date on changes, and reduces the development cycles, so that businesses may deliver the right products for the right markets in the shortest possible time.

DevSuite places knowledge management at the core of all development processes. TechExcel KnowledgeWise provides for the easy and efficient collection and organization of informal ideas, gathered from a wide variety of sources, that area shared across multiple DevSpec, DevTrack, and DevTest projects.

KnowledgeWise projects provide controlled access to documents, improve communication and coordination between distributed development teams, and facilitate the management and sharing information between development teams and project stakeholders.

TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work.

1.3 TechExcel ALM Solutions

TechExcel DevSuite features five ALM solutions that operate in an n-tier architecture: TechExcel KnowledgeWise, TechExcel DevTrack, TechExcel DevPlan, TechExcel DevSpec, and TechExcel DevTest.

All DevSuite products share the same core architecture - the DevSuite Database Server, DevSuite Application Server, DevSuite Document Server, and DevSuite Web Services - and are fully integrated enabling every branch of the development organization to communicate and work together.

KnowledgeWise

TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work during a development project. Documents are shared with all resources involved in the execution of the project allowing for an uncompromised vision to direct the path of any development project.

DevPlan

TechExcel DevPlan manages the transformation of concepts into formal strategic plans. DevPlan offers an intuitive planning hierarchy to formalize scope and optimize resource usage, team-based planning and calendaring capabilities. These features enable complete control over all product development projects from design planning to implementation and enables increased team efficiency and collaboration.

DevSpec

TechExcel DevSpec is an integrated requirements management solution that is specifically designed to provide visibility, traceability and validation of your product or project requirements. DevSpec provides a framework to create new requirements, specifications and features that can be linked to development and testing implementation projects.

DevTrack

TechExcel DevTrack enables development teams to manage every aspect of the development process including issue management, team management, and communications management.

DevTest

TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing lifecycle - from test case design, to test execution, to test analysis. DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.

While each element is valuable even when functioning independently, the DevSuite architecture is founded upon the assumption of future scaling and is capable of advanced inter-module integration. Whether used as separate components or as an incorporated set of applications, the DevSuite solutions are ideal for companies at any stage in their product development.

1.4 Administration of DevSpec

DevSpec is customized and configured using the DevSuite Admin. This tool is used to configure various aspects of the system.

1.4.1 Workflow in DevSpec

TechExcel DevSuite solutions enable development organizations to define custom workflow rules for managing every aspect of the ALM life cycle. DevSpec requirement workflow defines how requirements are created, managed, and tracked in a DevSpec project.

Administrator-defined workflow rules determine the sequence of workflow states, how and when a requirement may pass from one workflow state to the next, and who may own and edit a requirement in each stage of its life cycle.

A typical requirement workflow might consist of eight workflow states. Each state is either an active or inactive state: {New}, Proposed, Approved, Delayed, Dropped, Implemented, In Development, and Change Requested.

In DevSpec, every workflow state is defined as either an active or inactive workflow state based on its status - active or inactive. The status assigned to a workflow state determines how the specification is managed in that workflow state.

The requirement life cycle consists of at least two workflow states: an active workflow state and an inactive workflow state. By default, all new requirements start in the New workflow state, an active state.

1.4.2 GUI Customization

DevSpec project administration is largely the process of defining structures for recording, managing, and tracking work items - requirements, specifications, change requests - in a project.

Customized project management structures are manifested in the DevSpec client as views, panels, folders, and pages.

A view is an interface that displays and organizes data in the client workspace. DevSpec supports three customizable views: the requirements views, the specifications view, and the change request view.

Views enable project members to manage and track different types of data using structures that are specifically designed to manage that data. The building blocks of each view - folders, pages, and controls - may be customized to support custom business processes.

The building blocks of client interface include: controls, folder pages, and GUI pages.

Control: A control is a GUI element displayed in a folder page or custom page that enables the user to define, update, and track data. DevSpec supports system controls and custom controls. Controls are displayed in system pages and custom pages.

System Page: A system page is a predefined form that enables project members to collect, manage, and track project data in a project. A system page displays a predefined set of system controls.

Custom Page: A custom page is a form conceived, designed, and built by a project administrator that enables project members to collect, manage, and track project data. A custom page may display system controls and custom controls.

Function Page: A function page is a compound page composed of multiple custom pages and system pages. In the DevSpec client, function pages are displayed as multiple-page form that enable the user to perform a particular function such as adding or updating a folder or a requirement.

1.4.3 Sample Projects and Templates

DevSuite builds on TechExcel's commitment to the rapid deployment of its ALM by providing development organizations with the tools they need to quickly configure and implement projects that enforce good development practices and drive the quality of releases.

To facilitate the configuration of a fully integrated site and projects that support your development processes, DevSuite provides develpers with tools for evaluating and testing DevSuite features.

Sample Projects: A sample project is a project that provides development organizations with a sandbox for configuring and evaluating DevSuite features and integrations in a risk free environment.

Project Templates: A project template is a blueprint for creating a project of a specific type.

TechExcel strongly recommends that development organizations deploy and test DevSuite in a test environment prior to your DevSuite implementation. A test environment enables development organizations to test project configurations and to train users in new processes prior to the "go live" date in a production environment.

1.4.3.1 Sample Projects

In DevSuite, a sample project is a project that provides the development organization with a sandbox for configuring and evaluating features and integrations in a risk free environment.

DevSuite features ten predefined projects that provide devleopment organizations with a sandbox to experiment with KnowledgeWise, DevSpec, and DevTrack tools and features. All sample project include sample data, sample project team members, and fully configured workflow rules. Project administrators may freely configure sample projects to represent their development processes.

  • Project configurations and settings tried and tested in sample projects may be imported into newly created "live projects".
  • Sample projects provide development organizations with a tool for training new users or to introduce existing users to new features or changes in businesses processes.

Using controls in the DevSuite Admin client, administrators may create additional sample KnowledgeWise, DevSpec, and DevTrack projects.

1.4.3.2 Project Templates

In DevSuite, a project template is a blueprint for creating a project of a specific type - KnowledgeWise knowledge management projects, DevSpec requirements management projects, or DevTrack development projects.

Each project template defines a complete set of project-level settings including the definition of all project business objects, workflow rules, team representation, and project integrations.

Project templates may be used to quickly configure new projects whenever they are created in a DevSuite site.

1.5 Additional Help and Information

TechExcel DevSuite solutions enable development organizations to define custom workflow rules for managing every aspect of the ALM life cycle. DevSpec requirement workflow defines how requirements are created, managed, and tracked in a DevSpec project.

Administrator-defined workflow rules determine the sequence of workflow states, how and when a requirement may pass from one workflow state to the next, and who may own and edit a requirement in each stage of its life cycle.

A typical requirement workflow might consist of eight workflow states. Each state is either an active or inactive state: {New}, Proposed, Approved, Delayed, Dropped, Implemented, In Development, and Change Requested.

In DevSpec, every workflow state is defined as either an active or inactive workflow state based on its status - active or inactive. The status assigned to a workflow state determines how the specification is managed in that workflow state.

The requirement life cycle consists of at least two workflow states: an active workflow state and an inactive workflow state. By default, all new requirements start in the New workflow state, an active state.

 Chapter 2 DevSpec Client Basics
2.1 Getting Started

 

DevSpec is accessed through a smart-client: a system that uses HTTP requests to communicate from the client to the server. This means that a connection from anywhere is a guaranteed good performance.

 

DevSpec implements project-level security by assigning a unique username, password, and account type to all project team members. Individual logins enable the DevSpec system to identify, control, and track the changes that each user makes to project data. Passwords provide accountability for all transactions and other changes to project data and enable the organization to ensure that only authorized individuals may access and change project data. Every user is assigned an account type that defines the role and responsibilities of that user in the project.

 

Login

 

1. To login to DevSpec, select the DevSpec icon from your DevSuite program folder.



2. DevSpec client login screen will be prompted. Enter a username and password to login.

 


Users who do not have a username and password can login with the built-in sample user that TechExcel offers:   

User Name: terry-j

Password: terry-j

 

Optional:To select a web service, select an option from theWeb Servicedropdown list. Click the ellipses button (…) to define a new web service connection.

 

Note:Additional controls such asLanguage,LDAP server, and theWork Offlinecheck box would also be displayed in the login dialog box if these features are turned on by the system administrator: 

 

Language:To choose the language used in DevSpec client, select an option from theLanguagedropdown list.  

 

LDAP Server:To connect to the LDAP server to authenticate logins, select an option from theLDAP Serverdropdown list. 

Work Offline:Selecting theWork Offlinecheck box enables users to work on DevSpec projects locally by connecting to the local web service, while the work will be synced to the live system later.

 

3. Click theOKbutton to log into the DevSpec client.

 

Project Selection

If the user is a member of multiple DevSpec projects, theSelect Project to Logindialog box appears. TheSelect Project to Logindialog box displays the user’s DevSpec projects and qll open work items (requirements, specifications, and change requests) in each project.

Select a DevSpec project or work item in the project list and click theOKbutton. The DevSpec smart client will then display the selected project (and work item).
 


Note:DevSpec includes several pre-configured sample projects with different settings to help users understand and manage product design using various types of development methods. DevSpec initially comes with three sample projects: Scrum Design Project, Defect Tracker Design, and CMMI Requirement Management Projects.

 

Exiting DevSpec

 

To exit DevSpec, selectFile>Exitin the menu bar.

 

2.2 Understanding the DevSpec Client User Interface


The DevSpec Client is a web service-based client that enables users to view, manage, and track requirements, specifications, and change requests.

The client workspace organizes project data in multiple views. A view is an interface that displays and organizes data in the client workspace. Each view displays tools and controls that enable the user to process the work items managed in that view.
 
The workspace of each view is organized into panels (the specification tree panel, list panel, and detail panel) and bars (the menu bar, tool bar, and status bar).

2.2.1 Views

 

Every DevSpec project is represented in the DevSpec client by a customized graphical user interface (GUI) that provides project members with the tools that they need to manage and track specifications, requirements, change requests and changes to specifications and requirements.

 

The DevSpec client may display seven different views: the Requirement/Specification view, the Knowledge view, the Change Request view, the Report view, the Baseline View, the DevPlan view and the Mind Map view.

 

 

 

 

Requirement/Specification View:

The specification view is the primary view for creating, managing, and tracking requirements/specifications in the DevSpec client.

Knowledge View:

The knowledge view is the primary view for creating, managing, and tracking knowledge items in the DevSpec client.

Change Request View:

The change request view is the primary view for creating, managing, and tracking change requests in the DevSpec client. 

Baseline View:

The baseline view is used to compare one of the previous specifications and the current specification, and view the differences between them.

Report View:

The report view is used to generate various types of reports against Requirements, Specifications and Knowledge. 

DevPlan View:

The DevPlan view allows users to view the specifications/requirements implementation schedule.

Mind Map View:


The Mind Map is used to represent ideas and concepts in a graphical way.

2.2.2 Bars

 

DevSpec client bars enables the user to manage the work items displayed in the view where the user is currently situated. For instance, if a user is in the specification view, he or she would be able to use the bars to perform various actions to the specification items.

 

Every view displays three tool bars:

 

Menu Bar:The menu bar organizes DevSpec commands into six different menus: theFilemenu,Editmenu,Viewmenu,Toolmenu,Systemmenu, andHelpmenu.

 

Tool Bar: The tool bar displays buttons and controls that enable users to perform common tasks, such as switching between views or filtering the items displayed in the list panel.

 

Status Bar: The status bar displays information about the number of items displayed in the list panel.

 

Menu Bar Functions

 

The menu bar organizes DevSpec commands into seven different menus. The commands displayed in the menu bar can be frequently accessible by shortcut keys or using commands elsewhere in the application.

 

The menu bar displays six different menus, each including multiple functions:

 

File Menu

  • New: creating a new work item
  • Forward: forwarding an existing work item to a different member
  • Delete: deleting an existing work item
  • Save: saving changes made in DevSpec client
  • Import: importing data from either a text or a XML file to DevSpec  
  • Export: exporting data in DevSpec to either a text or a XML file  
  • Switch Project: switching between DevSpec projects
  • Login: logging in again with different username
  • Exit: exiting the DevSpec client                    

Edit Menu

  • Select All: selecting all the work items in the list panel
  • Search: bringing up the search window
  • Go To: bringing up the quick searchGo tobox
  • Load Query: bringing up the query loading box        

View Menu

  • Tool Bar: displaying or hiding the tool bar
  • Status Bar: displaying or hiding the status bar
  • Refresh: refreshing the list panel
  • Reload Project Setting: reloading project setting to reflect changes made in the Admin client

Tool Menu

  • Product Release Management: bringing up the product release management window
  • Project Member Directory: bringing up the team member contact information window
  • KnowledgeWise Add-In Setup: setting up the Microsoft Office add-in
  • Mind Map Manager: switching to the Mind Map view
  • Mind Map Manager Setup: Installing/uninstalling the Mind Map tool

System Menu

  • User Preferences: configuring the DevSpec client personalization

Help Menu

  • Help Topics: accessing the DevSpec help articles
  • Check for Updates: checking to see if the DevSpec client application is up to date
  • About DevSpec: viewing the DevSpec client version and build info

Tool Bar Functions

 

The tool bar displays buttons and controls that enable users to perform common tasks

 

 TheKnowledge Viewbutton enables the user to display the knowledge view in the workspace.

 

 TheSpecification Viewbutton enables the user to display the specification view in the workspace.

 

 TheChange Request Viewbutton enables the user to display the change request view in the workspace.

 

 TheBaseline Viewbutton enables the user to display the baseline view in the workspace.

 

 TheDevPlan Viewbutton enables the user to launch the DevPlan client from DevSpec.

 

 TheReport Viewbutton enables the user to display the report view in the workspace.

 

 TheMind Map Viewbutton enables the user to display the mind map view in the workspace.

 

 TheSavebutton enables the user to save changes made to a work item (knowledge item, requirement, specification, or change request).

 

 ThePrintbutton enables the user to print work item (knowledge item, requirement, specification, or change request) details.

 

TheNewbutton enables the user to submit a new work item (knowledge item, requirement, specification, or change request) to the project.

 

 TheForwardbutton enables the user to forward a selected work item (knowledge item, requirement, specification, or change request) to another project member.

 

TheEditbutton enables the user to edit a selected work item (knowledge item, requirement, specification, or change request).

 

TheSearchbutton enables the user to filter the work items displayed in the list panel using a custom-defined query.

 

 TheCancel Searchbutton enables the user to cancel the query used to filter the work items displayed in the list panel.

 

TheProduct Version Treebutton enables the user to display the product tree panel in the workspace.

 

TheDisplay folder properties as detail tabsbutton enables the user to switch the display of detailed information between a selected work item and a work item folder in the detail panel.

 

Status Bar

 

The status bar displays the number of items displayed in the list panel and the sequence number of the selected item.

 

 

To display or hide the status bar in the workspace of the DevSpec client, selectView>Status Barin the menu bar. The status bar is displayed in the workspace if a black check mark is displayed next to theStatus Barcommand in theViewmenu.

 

Using status bar control buttons, users may view the first item, previous item, next item, and last item in the list.

 

 To go to the first item in the list, click the Start button.

 

 To go to the previous item in the list, click the Previous button.

 

 To go to the next item in the list, click the Next button.

 

 To go to the last item in the list, click the Last button.

2.2.3 Panels

 

Panels are important concepts in the knowledge view, specification view, change request view and the baseline view. In these views, the DevSpec workspace is divided into three, or sometimes four, panels for efficient data management.

 

 

Specification Tree Panel:The specification tree panel is a hierarchal structure composed of folders and subfolders that organizes work items into distinct areas of work.

 

List Panel: The list panel shows high-level information for multiple work items in a tabular format of rows and columns.

 

Detail Panel:The detail panel displays detailed information for a single work item or work item folder in multiple tabs.

 

Product Tree Panel:The product tree panel organizes development items by product, version, and build.

 

Note:The product version tree panel may be optionally displayed in the requirement view, specification view, and change request view. Use theProduct Version Treebuttonin the tool bar to display or hide the product version tree panel.

 

Specification Tree Panel

 

The specification tree panel is a hierarchal structure composed of folders and subfolders that organizes work items into distinct areas of work.

 

For more information about the specification tree panel, please see chapter 3, section 1.2,Specification Details.

 

List Panels

 

DevSpec list panels enable the user to quickly view high-level information for multiple development work items (knowledge items, requirements, specifications, or change requests) in a tabular list of rows and intersecting columns.

 

Using controls in the tool bar, the tree panel, and the product tree panel, users may filter and sort records based on various work item property values.

 

Tracking/Filtering Work Items in the List Panel  

 

In DevSpec, list panels enable project members to quickly view high-level information for multiple work items in each view. The list panel shows high-level information for work items (knowledge item, specifications, requirements, and change requests) in a tabular list of rows and intersecting columns. Note that detailed information for the highlighted item in the list panel is displayed in the detail panel. 

 

Since there may be a long list of items displayed in the list panel, work item filtering and querying is therefore crucial. To work effectively, users must be able to quickly identify and execute appropriate filters so that they can quickly access relevant work items based on key indicators. Filtering minimizes the time needed to review large numbers of records, as well as to maximize effectiveness.

 

In DevSpec, a filter is a simple query that returns development work items matching a defined set of criteria. Records matching the criteria are displayed in the report—all other work items are “filtered out” and not shown. Filtering controls, such as the owner list and status list, enable project members to filter work items by owner, state, status, and other properties:

 

Owner List:The Owner List enables project members to view a subset of work items based on the current owner or original submitter.

 

Status List:The Status List enables project members to view a subset of work items based on the work item status or workflow state.

 

For more information about filtering the list panel, see chapter 4,Searches and Queries.

 

Refreshing the List Panel

 

The refresh command enables project members to refresh the items displayed in the list panel with the latest data from the DevSpec database. Project members can refresh the list panel by two methods:


• Press F5.

• SelectView>Refreshin the menu bar.


Detail Panels

 

In DevSpec, the detail panel displays detailed information for a single work item or work item folder. The data displayed in the detail panel is view-specific: knowledge item data is displayed in the knowledge view, requirement and specification data in the specifications view, and change request data in the change request view. 

 

TheSwitch Detailbutton enables the user to display detailed information for a selected work item or work item folder in the detail panel. When the detail panel is set to display the work item information, the detail panel will display the detailed information about the highlighted work item in the list panel. And when the detail panel is set to display the work item folder properties, the detail panel will display the detailed information for the highlighted work item folder in the tree panel.

 

For more information about the specification tree panel, please see chapter 3, section 1.2,Specification Details.

 

Product Version Tree Panel

 

The product tree represents the products, versions, and under-development builds in a DevSuite site in a hierarchical structure of folders and subfolders. Each folder in the product tree represents a specific product, version, or build.

 

Project members may filter the work items (knowledge items, requirements, specifications, and change requests) displayed in the list panel by selecting a work item folder in the product version tree panel.

 

For more information about the specification tree panel, please see chapter 3, section 2.2,Product/Version Folder Tree.

2.3 DevSpec Personalization

 

Every DevSpec project is represented in the DevSpec client by a customized graphical user interface (GUI) that provides project members with the tools that they need to manage and track specifications, requirements, change requests and changes to specifications and requirements.

 

The DevSpec client may display seven different views: the Requirement/Specification view, the Knowledge view, the Change Request view, the Report view, the Baseline View, the DevPlan view and the Mind Map view.

 

 

 

 

Requirement/Specification View:

The specification view is the primary view for creating, managing, and tracking requirements/specifications in the DevSpec client.

Knowledge View:

The knowledge view is the primary view for creating, managing, and tracking knowledge items in the DevSpec client.

Change Request View:

The change request view is the primary view for creating, managing, and tracking change requests in the DevSpec client. 

Baseline View:

The baseline view is used to compare one of the previous specifications and the current specification, and view the differences between them.

Report View:

The report view is used to generate various types of reports against Requirements, Specifications and Knowledge. 

DevPlan View:

The DevPlan view allows users to view the specifications/requirements implementation schedule.

Mind Map View:


The Mind Map is used to represent ideas and concepts in a graphical way.

2.3.1 Personalizing Default Settings on Login

 

Under theDefault on Logintab, users can set which view will open first when they log in to DevSpec, set the default filter settings for each view, and change their DevSpec password.

 

 

Default view on login

 

To set the default view after logging in to DevSpec, select a view from theDefault view on project logindropdown control. There are up to three options:Knowledge View,Spec View, orChange Request View(if user has access).

 

 

Default filter settings

 

To set the default filter settings for each view, under theDefault values for each viewsection, select a view. Then set the default value for each filter for that particular view. Repeat for the other views as well.

 

 

For more information on using filters in DevSpec, please see chapter 4, section 1,Quick Filters.

 

Change password

 

If a user wishes to change their password:

 

1. Click theChange Password…button.

 

 

2. In the newly openedChange Passworddialog, enter the current password, enter the new password, and then confirm the new password again.

 

 

3. Click theOKbutton to submit the password change.

 

2.3.2 Personalizing the Work Item Submission Dialog

 

Under theSubmittab, users can set how data is retained after the submission of a new specification. For more information on submitting specifications, please see chapter 3, section 1.1,Specification Workflow.

 

 

In the dialog used to submit new specifications, there is a checkbox to close the window after submission. To have this box (in the submission dialog) checked by default, check theClose submission dialog after a SPEC is submittedcheckbox (in theUser Preferencedialog).

 

 

When this checkbox is unchecked, the submission dialog will not close after a submission. In this case, users may also set how the submitted data is handled in regards to the next specification. In theData for the Next Submissioncontrol, users may choose from one of three radio buttons:

 

  • Reset data for next submission: All fields and controls are cleared and/or returned to their default values.
  • Retain data for next submission: The folder, item type, and template fields remain the same from the previous submission. The title, status, and description fields remain the same too only when a template is selected; otherwise, they are cleared.
  • Use template folder default value: When a template is selected, after submission, all fields return to their template default values, regardless if these values have been edited. However, if no template is selected, this is equivalent toRetain data for next submission.

 

For more information on using templates, please see chapter 3, section 1.1,Specification Workflow.

 

2.3.3 Personalizing the List Panel

 

Under theList View Datatab, users can set how they view the list panel: adding, removing, and ordering visible property fields; setting the number of specifications that are displayed per page; and defining the default sorting rules.

 

 

Adding and removing fields

 

To add a field, highlight a field name from theAvailable Fieldslist, and then click the right arrow button to move it to theList View Columnlist.

 

To remove a field, highlight a field name from theList View Columnlist, and then click the left arrow button to move it back to theAvailable Fieldslist.

 

To define the field order, highlight a field name from theList View Columnlist, and use theUpandDownbuttons to set the field’s position.

 

Click theResetbutton to restore the project’s default settings, as defined by the project administrator.

 

 

In the above screenshot,ID,Title,Spec Owner, andStatusare the properties that will be displayed in the list view, in that order.

 

Note: To select multiple fields, press and hold Ctrl while selecting other fields. To select all fields, click on the first field, and then while pressing and holding Ctrl and Shift, select the final field.

 

Number of specifications in list

 

To set the number of specifications that are displayed per page in the list panel, enter a number between 10 and 500 in theNumber of specifications in listfield. The list panel will not show more than 500 specifications in order to preserve optimal performance.

 

 

Default sorting selection

 

Users can also set the default specification sorting rules. For more information on sorting, please see chapter 4, section 1.7,Sorting.

 

To define default sorting rules:

 

1. Click the ellipses button (…) in theDefault sorting selectionsection. TheColumn Sorting Selectiondialog will open.

 

 

2. To select a default property by which to be sorted, highlight a property name from theAvailable columnslist, and then click the right arrow button to move it to theSorting columnslist. To remove a property, highlight a property name from theSorting columnslist, and then click the left arrow button to move it back to theAvailable columnslist.

 

 

Note: To select multiple fields, press and hold Ctrl while selecting other fields. To select all fields, click on the first field, and then while pressing and holding Ctrl and Shift, select the final field.

 

Ascending or descending order: Once a property is added, the order in which the specifications are sorted, ascending or descending, can be defined. The default value is ascending order, but to switch to descending order, highlight a property in theSorting columnslist, and then click theDescendbutton. The button will change to theAscbutton–used to switch back to ascending order. Each property’s current sorting value is display with a proceeding(ASC)or(DESC).

 

 

The screenshot above demonstrates what happens when theDescendbutton is clicked.

 

Secondary sorting: In cases when multiple specifications have the same value of the property that is being sorted, users can add multiple properties and define an order for secondary sorting. To define the sorting order, highlight a property name from theList View Columnlist, and use theUpandDownbuttons to set the property’s sorting priority.

 

 

Last sorting selection: Users can choose the default sort to simply be however the list panel was sorted when the list panel was last used, even when that may be a manual sort, and even when users have logged off and on. To select this option, check theLast sorting selectioncheckbox. This will make all other previously mentioned controls in theColumn Sorting Selectiondialog inactive, or “grayed-out”. Since this option simply applies the most recent sort, all other sorting rules would be overridden.

 

 

3. Click theOKbutton to submit the default sorting rules, and to return to theUser Preferencedialog.

 

2.3.4 Personalizing the History Page in the Detail Panel

 

Under theHistorytab (in theUser Preferencedialog), users can add and remove sections to theHistorytabin the detail panel. For more information on using theHistorytab in the detail panel, please see chapter 3, section 1.2,Specification Details.

 

 

There are five possible sections in theHistorytab in the detail panel:

  • Summary
  • Owner and State Change History
  • Tracking History
  • Change Log
  • All Linked Items

To add a section, highlight a section name from theAvailable history sectionslist, and then click the right arrow button to move it to theHistory section displayedlist.

 

To remove a section, highlight a field name from theHistory section displayedlist, and then click the left arrow button to move it back to theAvailable history sectionslist.

 

To define the section order, highlight a field name from theHistory section displayedlist, and use theUpandDownbuttons to set the section’s position.

 

Click theResetbutton to restore the project’s default settings, as defined by the project administrator.

 

Note: If no section is added to theHistory section displayedlist, theOwner and State Change HistoryandSummarysections will be displayed by default, in that order.

 

Note: To select multiple fields, press and hold Ctrl while selecting other fields. To select all fields, click on the first field, and then, while pressing and holding Ctrl and Shift, select the final field.

 

2.3.5 Personalizing the Owner Dropdown List

 

Under theUser Listtab, users can define which users, groups, and group folders of the project are displayed in the owner filter dropdown control in the tool bar. This could be beneficial to users who don’t need to see items owned by other particular owners. For more information on filtering with the owner filter, please see chapter 4, section 1.2,Filtering by Owner.

 

 

To simply select all users, groups, and group folders, leave theFilter the user list to selected project memberscheckbox unchecked, as in the previous screenshot. The owners list will remain inactive, or “grayed-out”.

 

To select the owners one-by-one, check theFilter the user list to selected project memberscheckbox, which will make the owners list active and accessible. Then click on the users, groups, and group folders that are to be shown in the owner filter (a red check appears next to each selected owner); click again to uncheck.

 

Users are denoted by their project member name.

Groups are denoted by a preceding asterisk (*).

Group folders are denoted by a preceding plus sign (+).

 

 

Whether all owners are selected or not, users have the option to include inactive project members in the owner list. To show inactive users, check theShow inactive project members in user listcheckbox. To hide inactive users, uncheck the box.

 

 

Note: Although inactive users may not be displayed in the owner filter in the tool bar, they still will always be displayed in the user list on theUser Listtab of theUser Preferencesdialog.

 

2.3.6 Personalizing Date/Time Settings

 

Under theDate/Timetab, users can define the format of time stamps, including selecting a time zone. These settings can be set only when the project administrator allows it. If not allowed, these controls are inactive, or “grayed-out”.

 

 

To select a time zone, choose a time zone from theTime Zonedropdown control.

 

 

To select a date format, choose a format from theDatesection. The current date will appear as a sample of the selected format.

 

 

To select a time format, choose a format from theTimesection. The current time will appear as a sample of the selected format.

 

 

Note: Regardless of who submits, forwards, or edits a work item, or even where it happened, time stamps in DevSpec, when the format is user-defined, will always be displayed according to the time zone defined by the user who is viewing the time stamp.

 

2.3.7 Additional Personalization Settings

 

Under theDate/Timetab, users can define the format of time stamps, including selecting a time zone. These settings can be set only when the project administrator allows it. If not allowed, these controls are inactive, or “grayed-out”.

 

 

To select a time zone, choose a time zone from theTime Zonedropdown control.

 

 

To select a date format, choose a format from theDatesection. The current date will appear as a sample of the selected format.

 

 

To select a time format, choose a format from theTimesection. The current time will appear as a sample of the selected format.

 

 

Note: Regardless of who submits, forwards, or edits a work item, or even where it happened, time stamps in DevSpec, when the format is user-defined, will always be displayed according to the time zone defined by the user who is viewing the time stamp.

 

 Chapter 3 Using DevSpec
3.1 Basic Usage

3.1.1 Specification Workflow

The DevSpec workflow, managed in the specification view, defines how requirements or specifications are created, managed, and tracked in a DevSpec project.

Administrator-defined workflow determines the sequence of workflow states-how and when a specification may pass from one workflow state to the next. Each state is also privileged controlled-who may submit, forward, edit, or delete a specification at each stage of its lifecycle. This provides traceability for DevSpec projects.

The follow diagram is a possible workflow. For example, after a new specification is created, it can start in theFunctional Reviewstate. Then it can move on to theTechnical Reviewstate (via theTech Reviewtransition), or even further along to theReady to Implementstate (via theGo Developmenttransition).

3.1.1.1 Submitting

(Mandatory steps in bold)

1. Open theSubmission Pageswindow by one of the following commands:

  • Click theSubmit New Specbutton in the tool bar

  • Right click in the specification list panel and clickNew…

  • From the menu bar, selectFile>Submit New…

  • Press Ctrl + N.

* To auto-populate the value of the folder field in the submission dialog, click on a folder in the specification folder tree prior to performing any of the above actions.

2. Select the folder to which the specification is to be added. New specification may be created within a folder.

3. Select whether the new item is a requirement or a specification.

4. Select the state of the specification. By default it will start in theNewstate.

5. Select a specification template. For more information about creating specification templates, see the ensuing section,Creating a Template.

6. Define the specification title.

7. Define the specification owner.

8. Define the specification description.

9. To close the window upon submission, check theClose submission dialog after a Spec is submittedbox. To keep the window open to submit another new specification, leave the box unchecked.

10. Click theOKbutton.

3.1.1.2 Creating a Template

A template is a predefined collection of definitions-namely the item type, title, owner, and description-that may be used to submit a new specification, quickly and easily.

1. Right-click in the folder tree panel and clickView Template.

2. Click on the newly appearedTemplate Folder.

3. Create a new specification template just as if an actual specification were being created (see the previous section,Submitting). Although a template will appear as a specification in the list panel, it is not an actual specification.

3.1.1.3 Forwarding

Forwarding is primarily done to change the owner of the specification, but can also be used to change the state of the specification as well.

(Mandatory steps in bold)

1. Open theForward Pageswindow for the specification to be forwarded. This can be done by one of the follow options:

  • Highlight a specification in the list panel and press theForward Specbutton in the tool bar.

  • Right-click a specification in the list panel and clickForward…

  • Highlight a specification in the list panel and from the menu bar, selectFile>Forward…

  • Highlight a specification in the list panel and press Ctrl + F.
  • Highlight a specification in the list panel and click theSpec Descriptiontab in the detail panel. (No window opens, but rather the specification is forwarded directly from the detail panel.)

2. Once theForward Pageswindow opens up, define the new specification owner, to whom the specification will be forwarded.

3. Make any other necessary changes to the specification properties, such as title, state, and description.

4. Click theOKbutton to forward the specification to the next owner and/or next state.

3.1.1.4 Editing

(Mandatory steps in bold)

1. Open theEditing Pageswindow for the specification to be edited. This can be done by one of the follow options:

  • Highlight a specification in the list panel and press theEdit Specbutton in the tool bar.

  • Right-click a specification in the list panel and clickEdit…

  • Highlight a specification in the list panel and click theSpec Descriptiontab in the detail panel. (No window opens, but rather the specification is forwarded directly from the detail panel.)

2. Once theEditing Pageswindow opens up, the user can change the properties of the specification, such as folder, type, title, state, owner, and description. For example, using theTypecontrol, a requirement can be changed to a specification (and vice versa).

3. Click theOKbutton to save the changes made to the specification.

3.1.1.5 Deleting

Warning: Deleting a specification is a non-recoverable action!

1. A specification can be deleted by one of the follow options:

  • Right-click a specification in the list view and clickDelete…

  • Highlight a specification in the list view and from the menu bar, selectFile>Delete…

2. A confirmation box will appear. Press the OK button.

3.1.2 Specification Details

The detail panel (bottom pane with tabs) displays detailed information about the highlighted specification or requirement in the specification view. Details of each item is further divided and distributed across multiple tabs, allowing you to quickly view different information for the highlighted requirement or specification.

Note: The label for each specification detail tab is easily customizable in the DevSuite Admin.

3.1.2.1 Description

TheSpec Descriptiontab is the main page that displays key specification details. It consists of standard fields and custom defined fields.

Standard Fields:

Title: A short, one line description of the specification (used in the list view). It’s a single line edit box.

Description: Detailed description of the specification. It’s a multi-line edit box. This field can be enabled for editing with time stamps. Administrators can enable this field for HTML editing, spell check, support image base and URLs.

Status: This field indicates the current state of a specification within the specification workflow. The specification state is normally changed using the transition buttons on the secondary tool bar.

Owner: This field indicates the current owner of a specification. It’s a dropdown field.

Other custom defined fields: DevSpec administrator may define and place additional custom fields on this tab as needed.

3.1.2.2 History

As a specification progresses through states and is modified, every change to the specification is tracked and logged under theHistorytab. It consists of different sections that allow users to easily view the information. This tab is a consolidated “one-page stop” for viewing all specification details that are distributed across all other tabs.

History Sections:

Owner and State Change History --- This section is a graphical representation of the specification flow through different states and different owners, along with time stamps.

Summary --- This section provides information on all specification fields being tracked for the highlighted specification.

All Linked Items --- This section provides information on other items currently linked to the highlighted specification. This includes other specifications, requirements, knowledge items, development items, and test tasks linked to the current specification.

Tracking History --- As the specification is forwarded from one owner to another, each owner’s comment is recorded and the new owner assignment is time stamped. This section provides a complete log of owner changes and owner comments, along with time stamps.

Change Log --- GUI fields defined to track requirements or specifications may be modified or updated during the lifecycle of the DevSpec item. Any change to a field value is tracked in this section, along with the time stamp. It also records the user who changed the field value.

3.1.2.3 Version

A specification may be modified several times before it is completed or closed. In some cases, you may want to refer back to a previous version before further modification, or even rollback completely. For complete traceability and flexibility, DevSpec allows users to save multiple versions of a specification at different points of time throughout the specification lifecycle.

To save the current version:

  1. Select a requirement or specification
  2. In theDetailtab, go toVersiontab
  3. Click theNewbutton
  4. Enter the version name, and add a comment if necessary
  5. Click theOK button
  6. The current copy of the requirement or specification is saved under this version

To view a previous version:

  1. Select a requirement or specification
  2. In theDetailpanel, go to theVersiontab
  3. Click theViewbutton

To rollback the current version:

  1. Select a requirement or specification
  2. In theDetailpanel, go to theVersiontab
  3. Highlight a previous version to which you want the requirement or specification to be rolled back
  4. Click theRollbackbutton
  5. Enter the version name, and add a comment if necessary
  6. Click theOKbutton
  7. The requirement or specification is rolled back to the selected version

Specification workflow can be configured such that the system automatically generates a new version when certain changes are made to a specification.

3.1.2.4 Linked Specification

Often there is a need to link two or more specifications, because of a relationship or dependency amongst them. Users can also link a specification to a requirement, as well as link two requirements. Such linking of requirements and specifications is done on this tab.

To link the current specification to an existing specification or requirement:

  1. Select a requirement or specification
  2. In theDetailtab, go to theLinked Specificationtab
  3. Click theSelectbutton
  4. Highlight a folder under which the other specification is located
  5. Select the checkbox next to the specification that is to be linked

(Multiple items can be linked at the same time by selecting multiple checkboxes)

6. Click theLinkbutton

To link a new specification or requirement to the current specification:

  1. Select a requirement or specification
  2. In theDetailtab, go to theLinked Specificationtab
  3. Click theNewbutton
  4. Fill out the information to submit and link the new specification or requirement (For more information on submitting specifications, see chapter 3, section 1.1,Specification Workflow)

To view a linked specification or requirement:

  1. Select a requirement or specification
  2. In theDetailtab, go to theLinked Specificationtab
  3. Highlight a linked specification or requirement
  4. Click theViewbutton

To edit a linked specification or requirement:

  1. Select a requirement or specification
  2. In theDetailtab, go to theLinked Specificationtab
  3. Highlight a linked specification or requirement
  4. Click theEditbutton

3.1.2.5 All Links

This tab is an extension of theLinked Specificationtab. It is used to link not only specifications and requirements, but also other items, such as knowledge items, development items, and test task items. Multiple knowledge items can be linked to one specification, and multiple specifications can be linked to one knowledge item. This facilitates better visibility to all items throughout DevSpec.


To link knowledge item(s):

  1. Select a requirement or specification
  2. In theDetailtab, go to theAll Linkstab
  3. Highlight theLinked Knowledgefolder
  4. Click theSelectbutton
  5. Highlight a folder under which the knowledge item is located

  1. Select the checkbox next to the knowledge item that is to be linked

(Multiple items can be linked at the same time by selecting multiple checkboxes)

  1. Click theLinkbutton

To link development item(s):

  1. Select a requirement or specification
  2. In theDetailtab, go to theAll Linkstab
  3. Highlight theLinked Developmentfolder
  4. Click theSelectbutton
  5. Highlight a folder under which the development item is located

  1. Select the checkbox next to the development item that is to be linked
  2. Click theLinkbutton

To link QA test item(s):

  1. Select a requirement or specification
  2. In theDetailtab, go to theAll Linkstab
  3. Highlight theLinkedQA Testfolder
  4. Click theSelectbutton
  5. Highlight a folder under which the QA test item is located

  1. Select the checkbox next to the QA test item that is to be linked
  2. Click theLinkbutton
3.1.2.6 Events

Events facilitate team collaboration in DevSpec. Events are tasks that need to be completed before a specification is finalized, approved and/or committed. All events for a specification are easily managed under theEventstab.

To create a new event:

  1. Select a requirement or specification
  2. In theDetailtab, go to theEventstab
  3. Click theNew Eventbutton
  4. Select an event template from the dropdown list

(Some examples of possible event may be design meetings, customer request discussions, or approval events)

  1. Fill out the event properties, such as name, description, state, owner, start date, and due date
  2. If the event requires other users to be notified about a meeting they should attend, click the ellipses button to select the even attendees
  3. Click theOKbutton

Events can also be auto-generated based on conditions defined in the Admin.

TheEvent Change Logtab under theEventstab allows you to track any changes made to the highlighted event.

3.1.2.7 Quick Reports

Users can quickly generate simple reports under theQuick Reporttab. Users can generate list reports or burn down reports under this tab.

List Reports

There are two types of list reports:

  • Brief list reports
  • Detailed list report

To configure a list report:

  1. SelectSpec List (Brief)orSpec List (Detailed)in the report dropdown list underQuick Reporttab
  2. Click thebutton

  1. Users can customize this report as needed
  2. Apart from using the regular filters, such as user, state and query, to filter the items, users can also select a branch of theproduct/versiontree to filter out irrelevant items in the report
  3. Click theTree Settingsbutton and select the applicableproduct/versionbranch

Burn Down Report

To configure a burn down report:

  1. Select a burn down report in thereportdropdown list underQuick Reporttab
  2. Click thebutton

  1. Users can customize this report as needed
  2. Users can also select a specific subproject or sprint in the project tree view(defined in DevPlan) to get a burn down analysis report of selected items in the project tree
  3. Click theTree Settingsbutton and select the applicable subproject

3.1.2.8 Backlog

When a specification or requirement is finalized and approved in DevSpec, it is ready to be scheduled in a subproject to be implemented.A product backlog is created to facilitate smooth transition through the design, planning, and implementation phases. It consists of a list of prioritized items that needs to be developed in the next implementation cycle.As specifications reach their final approval state, they are dropped into the backlog folder, indicating the project managers that these specifications are ready for implementation.

To add a specification to the product backlog:

  1. In theDetailtab, go to theBacklogtab
  2. Highlight a linked specification or requirement
  3. In the specification list view, drag any open specification and drop it into aSpecification Backlogfolder

3.1.2.9 Item Voting

DevSpec users may vote on a requirement or specification. This allows distributed teams to evaluate the impact and need for a requirement that is going to be implemented.

To add voting points to a specification or requirement:


  1. Select a specification or requirement in the list view

  2. In theDetailtab, go to theItem Votingtab

Note:The DevSuite administrator needs to turn on and configure the Voting Feature before users can add their votes.


  1. Click theAddbutton next to theVoting Pointsfield


  1. From theVoting Fielddropdown list, select aVoting Type:

  • Revenue Impact

  • Ranking

  • Point Allocation



  1. Enter the vote points as a numeric value and click theOKbutton

Voting types

Revenue Impact - Users can contribute to the evaluation of the revenue impact for a proposed requirement. The product design team, stakeholders and other DevSpec users can enter their estimates of the revenue impact towards the implementation of a suggested feature.

Ranking - Each DevSpec user can rank a requirement based on urgency, usefulness, and triviality of a requirement.

Point Allocation - Apart from ranking and revenue impact, users can also allocate points to each requirement.

The system then automatically calculates the total, mean and median for each of the previously mentioned voting options.

The DevSpec Administrator can restrict the range for voting points based on users’ privileges in the system. For example, executive managers and product managers will have a larger voting range than other users who belong to marketing, sales, or service groups.

3.2 Advanced Usage

The DevSpec workflow, managed in the specification view, defines how requirements or specifications are created, managed, and tracked in a DevSpec project.

Administrator-defined workflow determines the sequence of workflow states-how and when a specification may pass from one workflow state to the next. Each state is also privileged controlled-who may submit, forward, edit, or delete a specification at each stage of its lifecycle. This provides traceability for DevSpec projects.

The follow diagram is a possible workflow. For example, after a new specification is created, it can start in theFunctional Reviewstate. Then it can move on to theTechnical Reviewstate (via theTech Reviewtransition), or even further along to theReady to Implementstate (via theGo Developmenttransition).

3.2.1 Specification Folder Tree

The DevSpec folder tree is a hierarchical structure composed of multiple folders and subfolders that organize specifications into distinct areas of work.Project members with the appropriate privileges may create any number of nested specification folders to any level of depth.Every specification category and subcategory is represented by a specification folder. Specifications may be grouped by specification class, stakeholder, functional area, or any other category that is useful to a business.

The tree allows users to view subsets of work items in the list panel.Users can view just the work items in the selected folder or the work items contained within descendant folders.In addition, the DevSpec folder structure allows users to define a set of access rules to secure the contained work items, define applicable work item owners, and sort the folder tree.All changes made to the DevSpec folders are stored in the built-in change log easily accessible by the appropriate manager.

Creating a Folder

To create a folder, right-click on an existing folder and clickNew Folder:

  • SelectNew Child Folderto create a subfolder underneath the current folder.

  • SelectNew Sibling Folder Aboveto create a folder in the same level but above the current folder.

  • SelectNew Sibling Folder Belowto create a folder in the same level but below the current folder.


*Refer to theFolder Propertiessection.

Copying/Moving Folders

Users can create an identical set of folders and its specifications to another folder from the current selected folder.

1.Right-click on a folder and selectCopy.

2.Right-click on a destination folder and selectPaste.

Users can also choose to move a folder and its contents to a different directory.

1.Right-click on a folder and selectCut.

2.Right-click on a destination folder, and selectPaste

Filtering Work Items

To filter work items, begin by selecting a folder in the tree panel.

To display or hide work items in descendent folder(s):

1.Right-click a work item folder in a tree panel.

2.Define the scope of the folder filter:

    • To display the work items in that folder and the work items of every descendent folder, select theShow All Descendentcommand. (Alternatively, check theshow items of child folderscheckbox on the top-left corner of the list panel.)

    • To display the work items in that folder and that folder only, deselect theShow All Descendentcommand.
3.2.1.1 Folder Properties

To access folder properties, right-click on the folder and selectProperties.

Folder Description

This section allows users to accurately describe the details of a folder.

1.Provide an accurate folder name so that work items can be easily filtered.

2.Provide a folder status to indicate whether or not this folder should still be in use.

3.Provide a priority value.

*Administrators can add custom fields and pages to track additional details.

Access Control:

This section allows users with sufficient privileges to secure the contents within a DevSpec folder and the folder itself.

Managers can select 1 out of 3 different folder access types. All folder access types are split into two panes. This allows the manager to view the permissions defined by the administrator for folders and work items within the folders.

Public Folder:

A set of account types defined in the Admin.

    • No Access – users will not be able to see existing folder/work items

    • Read-Only – users cannot update existing folder/work items

    • Can Edit – users can only update existing folder/work items

    • Can Create and Edit – users can submit new folder/work items

    • Can Delete, Create and Edit – users can submit new folder/work items as well as delete existing items

Private Folder:

A second set of account types defined in the Admin.

    • No Access – users will not be able to see existing folder/work items

    • Read-Only – users cannot update existing folder/work items

    • Can Edit – users can only update existing folder/work items

    • Can Create and Edit – users can submit new folder/work items

    • Can Delete, Create and Edit – users can submit new folder/work items as well as delete existing items

Secured Folder:

This folder access type is used if the public / private folder access types are not sufficient.Administrators can define different sets of custom access levels for account types and team groups that can be applied to any folder.This is beneficial if privileges may need to be changed later.

To view privileges for each access type, left-clickview access type.

In addition, individual users can also be added as an exception to the account type and team group privileges defined in the access level:

1.To add a user, clickAdd User, select the user(s) and give applicable privileges.

2.To remove user(s) from the access level, clickRemove User.

*Check offsame as parentto inherit the access control from the parent folder

Applicable Owner:

This section allows managers to define account types, groups and individuals that can own a work item in the folder.Users that do not belong in the account types or groups defined here cannot be selected as a specification owner, even though the workflow permits them.

SelectAll Applicableto quickly allow all DevSpec users to be able to own work items if the workflow permits them.

SelectDefine Applicableto define specific account types, groups and users to be able to own work items if the workflow permits them.

*Check offsame as parentto inherit the access control from the parent folder

Change Log:

This section allows managers to easily see accurate information on all changes performed on the folder. The date, the user who performed the change, and the change description are displayed.

Folder Order:

This section allows managers to be able to sort the subfolders underneath the selected folder.

Click the up button to move a subfolder higher in the tree.

Click the down button to move a subfolder lower in the tree.

3.2.2 Product/Version Folder Tree

To access folder properties, right-click on the folder and selectProperties.

Folder Description

This section allows users to accurately describe the details of a folder.

1.Provide an accurate folder name so that work items can be easily filtered.

2.Provide a folder status to indicate whether or not this folder should still be in use.

3.Provide a priority value.

*Administrators can add custom fields and pages to track additional details.

Access Control:

This section allows users with sufficient privileges to secure the contents within a DevSpec folder and the folder itself.

Managers can select 1 out of 3 different folder access types. All folder access types are split into two panes. This allows the manager to view the permissions defined by the administrator for folders and work items within the folders.

Public Folder:

A set of account types defined in the Admin.

    • No Access – users will not be able to see existing folder/work items

    • Read-Only – users cannot update existing folder/work items

    • Can Edit – users can only update existing folder/work items

    • Can Create and Edit – users can submit new folder/work items

    • Can Delete, Create and Edit – users can submit new folder/work items as well as delete existing items

Private Folder:

A second set of account types defined in the Admin.

    • No Access – users will not be able to see existing folder/work items

    • Read-Only – users cannot update existing folder/work items

    • Can Edit – users can only update existing folder/work items

    • Can Create and Edit – users can submit new folder/work items

    • Can Delete, Create and Edit – users can submit new folder/work items as well as delete existing items

Secured Folder:

This folder access type is used if the public / private folder access types are not sufficient.Administrators can define different sets of custom access levels for account types and team groups that can be applied to any folder.This is beneficial if privileges may need to be changed later.

To view privileges for each access type, left-clickview access type.

In addition, individual users can also be added as an exception to the account type and team group privileges defined in the access level:

1.To add a user, clickAdd User, select the user(s) and give applicable privileges.

2.To remove user(s) from the access level, clickRemove User.

*Check offsame as parentto inherit the access control from the parent folder

Applicable Owner:

This section allows managers to define account types, groups and individuals that can own a work item in the folder.Users that do not belong in the account types or groups defined here cannot be selected as a specification owner, even though the workflow permits them.

SelectAll Applicableto quickly allow all DevSpec users to be able to own work items if the workflow permits them.

SelectDefine Applicableto define specific account types, groups and users to be able to own work items if the workflow permits them.

*Check offsame as parentto inherit the access control from the parent folder

Change Log:

This section allows managers to easily see accurate information on all changes performed on the folder. The date, the user who performed the change, and the change description are displayed.

Folder Order:

This section allows managers to be able to sort the subfolders underneath the selected folder.

Click the up button to move a subfolder higher in the tree.

Click the down button to move a subfolder lower in the tree.

 Chapter 4 Searches and Queries
4.1 Quick Filters

 

In the specification view the user can apply filers and queries on work items. To work effectively, and to minimize the time needed to review large numbers of records, project members must be able to quickly identify relevant work items based on key indicators, such as item owner, status, or type (i.e. requirement or specification).

 

In DevSpec, a filter is a simple query that returns work items matching a defined set of criteria. Records matching the criteria are displayed in the list panel.

 

 

4.1.1 Go To

 

TheGo tofeature may be used to quickly filter work items by their ID numbers.

 

1. Open theGo Todialog by doing one of the follow:

 

  • From the menu bar, selectEdit>Go to…

 

 

  • Press Ctrl + G.

 

2. Type an ID number in the text box.

 

3. Press theOKbutton.

 

 

TheGo tofeature also comes equipped with different operators to expand the search.

 

  • A comma (,) or a space may be used as separators for multiple single IDs. For example, inputting2,3,4would return items 2, 3, and 4.
  • A hyphen (-) may be used for an interval of IDs. For example, inputting5-8would return items 5, 6, 7, and 8.
  • An asterisk (*) may be used to denote wildcard characters; that is, any string of numbers. For example, inputting*5would return items: 5, 15, 25 … 105, etc.

 

Note: Multiple operators may be used in a single search, as shown in the example provided in theGo todialog.

 

4.1.2 Filtering by Owner

 

In DevSpec, all specifications, requirements, and change requests are at all times owned by one-and-only-one user or group folder. Using the owner filter, the work items displayed in the list panel may be filtered by the current owner.

 

The owner filter in the search bar displays the names of all users, groups, and group folders.

 

Users: Users are the individual project team members. When a user is selected, all items owned by that user are displayed. Users are identified by the users’ names.

 

Groups: Groups are administrator-defined teams of users who share a common set of responsibilities within a project. When a group is selected, all items owned by any individual belonging to that group are displayed. Groups are identified by a leading asterisk (*).

 

Group folders: Group folders give groups the ability to own items, while preserving a set of access rights within the group. Group folder ownership and user ownership are exclusive; therefore, when a group folder is selected, all items owned by that group folder, and not any other user, are displayed. Group folders are identified by a leading addition sign (+).

 

 

In the above screenshot, where theDevelopmentgroup is selected, only the work items currently being owned by that group will be returned in the search results.

 

4.1.3 Filtering by Status

 

In DevSpec, all work items, specifications, requirements, and change requests, are defined by their workflow status and whether that status is opened or closed.

 

Using the status filter, the work items displayed in the list panel may be filtered by the current status. The status filter in the search bar displays every workflow state that is applicable to the work items managed in the view.

 

 

Status groups: The status control may also be used to filter multiple common statuses, a status group. These are identified by the statuses which are not indented in the status list, and are enclosed by braces ({…}).

 

In the above screenshot,Open only,Closed only,DesignandDevelopmentare defined as status groups. Also in the example, where theDevelopmentstatus group is selected, only the items in that status group (i.e. the statuses listed thereunder) will be returned in the search results.

 

Note: All DevSpec projects have the predefined status groups,OpenandClosed, as all workflow states are defined as such. Any further status groups must be set up by the project administrator in the Admin.

 

4.1.4 Filtering by Work Item Type

 

Using the requirement and specification buttons in the tool bar, work items may be filtered by their type, displaying only requirements, only specifications, or both. Linked requirements and specifications may also be shown or hidden in the list panel.

 

 

In the example above, all three buttons are shown as clicked. When not clicked, the buttons are grayed-out. At least one item type is always displayed. It is not possible to uncheck both the requirement and specification buttons.

 

When linked items are shown in the list panel, they are displayed as child items to each parent item.

 

 

4.1.5 Filtering Using the Folder Tree

 

Using the folder tree as a filter, the user may view subsets of work items in the list panel. Only the work items contained in the selected work item folder are displayed in the list panel.

 

Select a folder in the folder tree to filter the work items displayed in the list panel.

 

 

To display or hide work items in the descendent folder(s), follow one of the following methods:

 

1. Right-click on a folder in the folder tree, and choose the scope of the folder tree filter:

 

  • To display the work items in that folder and the work items of every descendant folder, select theShow All Descendentsoption.
  • To display the work items in that folder and that folder only, deselect theShow All Descendantsoption.

 

 

OR

 

2. Highlight a folder in the folder tree, and choose the scope of the folder tree filter:

 

  • To display the work items in that folder and the work items of every descendant folder, check theShow items of childfolders box.
  • To display the work items in that folder and that folder only, uncheck theShow items of childfolders box.

 

 

Organizing and managing work items in the folder tree:

 

Folder tree management is the task of defining the structures that organizes requirements and specifications in a DevSpec project. All DevSpec items are stored and managed in the folder tree.

 

The folder tree is a hierarchical structure composed of multiple folders and subfolders that organize items into distinct areas of work. Project members with the appropriate privileges may create any number of nested folders to any level of depth. Each folder is defined by a set of access rights, applicable products/version rules, and applicable owner rules.

 

Each category and subcategory is represented by a folder. Items may be grouped by item class, stakeholder, functional area, or any other category that is useful to a business. However, TechExcel recommends that the folder structure is not organized by product, version, and build; this is done by the product version tree.

 

4.1.6 Filtering Using the Product Version Tree

 

As an extension of the folder tree, the product version tree may also be used to further filter work items. The product version tree structure represents all categories, products, versions, and builds throughout the entire application lifecycle.

 

 

To view the product version tree, click theShow Product Version Treebutton in the tool bar. Click it again to hide.

 

 

Note: To use the product version tree to filter work items, items must be defined with the product/version property. This is not a default item property, so this must first be set up by the project administrator.

 

4.1.7 Sorting

 

The results of a filter are displayed in the list panel. To find all relevant information quickly, work items may be sorted by its properties. Depending on the data type, this will sort a particular property alphabetically or numerically.

 

To sort by a work item property, click on its title in the header section.

 

 

The first time a property is sorted, the data is displayed in ascending order (A to Z). If clicked a second time, the data will be displayed in descending order (Z to A). An arrow will arrear next to the title of the property that is being sorted. This denotes ascending or descending order.

 

 Ascending order

 Descending order

 

The user may customize which work item properties are displayed in the list panel and also define a default property by which to sort on login. For more information, see chapter 2, section 6, DevSpec Preferences.

 

Note: Text fields, such as item description, are not sortable.

 

4.2 Defining Search

 

TheGo tofeature may be used to quickly filter work items by their ID numbers.

 

1. Open theGo Todialog by doing one of the follow:

 

  • From the menu bar, selectEdit>Go to…

 

 

  • Press Ctrl + G.

 

2. Type an ID number in the text box.

 

3. Press theOKbutton.

 

 

TheGo tofeature also comes equipped with different operators to expand the search.

 

  • A comma (,) or a space may be used as separators for multiple single IDs. For example, inputting2,3,4would return items 2, 3, and 4.
  • A hyphen (-) may be used for an interval of IDs. For example, inputting5-8would return items 5, 6, 7, and 8.
  • An asterisk (*) may be used to denote wildcard characters; that is, any string of numbers. For example, inputting*5would return items: 5, 15, 25 … 105, etc.

 

Note: Multiple operators may be used in a single search, as shown in the example provided in theGo todialog.

 

4.2.1 Search by Keyword

 

In DevSpec, a keyword is a term (word, phrase, or alphanumeric string) that is used as a search condition in a query. The DevSpec search engine searches for instances of a keyword in a record set and returns those records in which the keyword is found.

 

Using the DevSpec Search feature, the user may search for requirements, specifications, knowledge items and change requests based on the text strings found in text fields. These text fields include title, description, history, note title, note description, link comments, event title, and event description fields.

 

To search using keywords:

 

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the General Properties tab.
  3. Enter one or more keywords in the keyword text box. The search engine can search for keywords in the description control, and other multiple line text box controls as well. By default the keyword search is executed against the title field of an item.

 

  1. Check the Include Description checkbox to search for a keyword in the description field of an item.
  2. Check the Include All Text Fields checkbox to search for a keyword in any text/memo field (defined by the DevSpec Administrator).
4.2.2 Search by Owner and Status

 

This search is an extension of the owner and status filters in the tool bar. Unlike these dropdown lists, users can select more than one owner and/or status to filter specifications.

 

To define owner and status search condition:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the Owner and Status tab.
  3. Select one or more owners and/or workflow states.

 

 

  1. Click the Search button.

In the above example, the resulting list would be items currently owned by any user in the Design group, Development group, or For Review group folder, and which are currently in the Functional Review, Technical Review, or Work Review states.

 

4.2.3 Search by Product/Version

 

This search is an extension of using the product/version tree as a filter (described in section 4.1 Quick Filters). The product/version tree structure is defined by the DevSpec administrator, and is available for users to link specifications and requirements to applicable products and versions. This search allows users to find items related to a set of products and product versions easily.

 

To define product/version search conditions:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the Product/Version tab.
  3. Select a specific version under a product folder to find all related specifications; OR select the checkbox next to a product name to find specifications for all versions of the selected product. 

 

  1. Click the Search button.

In the above example, the resulting list will include all specifications for Defect Tracker, version 65.

 

4.2.4 Search by Linked Item

 

In DevSpec, a specification or requirement can be linked to a development item in DevTrack. It can also be linked to a test case template, or even test tasks in DevTest. Searching for linked DevSuite items allows users to find any specifications that are currently linked to either a development item or a test case/task. For more information on linking items across DevTrack and DevTest, please see chapter 7, DevSuite Integration.

 

To define linked item search conditions:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the Linked DevSuite Items tab.
  3. Select a search condition based on linked DevTrack and DevTest items.
    • To find specifications with a linked DevTrack item, select With Linked DevTrack items in the drop-down list.
    • To find specifications with no linked DevTrack items, select No Linked DevTrack work items in the drop-down list.
    • To find specifications with or without linked DevTrack item, select All in drop-down list.      

Use the same principle for the other two dropdown lists: Linked DevTest Templates and Linked DevTest Test Tasks.

 

 

  1. Click the Search button.

In the above example, the resulting list will include all specifications that have a linked DevTrack item, a linked DevTest template, or a linked DevTest test task.

 

4.2.5 Search by Event

 

This search allows users to search for specifications and requirements that have associated events. Users may define search conditions based on event templates and event workflow states. For more information on events in DevSpec, please see chapter 8, section 3, Events.

 

To define event search conditions:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the Events tab.
  3. Select one or more event templates and/or event workflow states.

 

  1. Click the Search button.

In the above example, the resulting list would be items that currently have an associated Spec Review or Design Meeting event, and which are currently in the Open state.

 

4.2.6 Search by Field

 

DevSpec administrators may define a variety of field types to track and manage items.These field types typically include:

  • Dropdown lists
  • Combo boxes
  • Date-time fields
  • Single line edit boxes
  • Multiple line edit boxes
  • Multiple selection list boxes
  • Checkboxes 

Searching by fields allows users to search for items with a specific value in these admin-defined fields.

 

4.2.6.1 Dropdown Field Search

 

To define dropdown field search conditions:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the Additional attributes tab.
  3. Highlight a field name of the dropdown list, multiple selection, or combo box type, and select its values.

 

  1. Click the Search button.

In the above example, the search result would include all specifications where the Completion Milestone field value is Milestone 1 or Milestone 2.

 

Note: In the Additional Attributes tab, all fields on which a search condition has been defined is indicated by an asterisk (*) after the field name.

 

4.2.6.2 Edit Box/Text Field Search

 

To define edit box/test field search conditions:

  1. Launch the search dialog in DevSpec (use button).
  2. Select the Additional attributes tab.
  3. Highlight a field of the edit box type.
  4. Enter a text to find all items where this text is found in the edit box field.
  5. To find all items where the edit box field is empty (no text), check the box Is empty (Null).

 

  1. Click the Search button.

In the above example, the search result would include all specifications where the Comments field contains the string, “verified”. If we wanted to search for all specifications where the Comments field is blank/null, we would check the Is empty (Null) checkbox.

 

Note: In the Additional Attributes tab, the fields on which a search condition has been defined is indicated by an asterisk (*) after the field name.

 

4.2.6.3 Date-Time Field Search

 

A date-time search enables the user to search for items based on the date and time that those items were submitted, assigned, last edited, or any other custom defined date-time field.

 

Static Date-Time Search

 

A static date-time condition returns all items that fall within a fixed time period. Static date-time search conditions are defined by a fixed starting date and fixed ending date.

 

To define Static Date Time field search condition:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the Additional attributes tab.
  3. Highlight a field of the date-time type.
  4. Enter a From date and a To date.

 

  1. Click the Search button.

In the above example, the search result would include all specifications that were created between May 5, 2009 and June 5, 2009.

 

Note: In the Additional Attributes tab, the fields on which a search condition has been defined is indicated by an asterisk (*) after the field name.

 

Dynamic Date Time Search

 

A dynamic date-time condition returns all items that fall within a dynamically defined time period, a range relative to the current date.

 

To define dynamic date-time field search conditions:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the Additional attributes tab.
  3. Highlight a field of the date-time type.
  4. Select the Dynamic Time radio button.
  5. Select the Current date radio button if today is the pivot/starting point. Otherwise, select the days before or days after radio button. Then enter a positive numeric value to set the pivot/starting point.

 

  1. Enter the number of days in the In days section. This number could be before or after the relative date (or pivot/starting point) defined in the previous step.

In the above example, the search result would include all specifications that were created 30 days prior to yesterday. In this case, yesterday is defined by setting the relative date to be one day before the current date. Therefore, if the current day is May 5, 2009, the search will find all specifications created between April 4, 2009 and May 4, 2009.

 

Note: In the Additional Attributes tab, the fields on which a search condition has been defined is indicated by an asterisk (*) after the field name.

 

4.2.6.4 Search by ID

 

Search conditions may also be used to retrieve items by their system-defined ID numbers. Each item in DevSpec is assigned a unique sequential ID number when submitted.

 

Using basic punctuation marks (commas, hyphens, and asterisks) as logical operators, project members may define complex queries to locate multiple work items based on a range of work item ID numbers.

 

This search is equivalent to the Go To feature in DevSpec. For more information, including the use of logical operators, please see section 1.1 in this chapter, Go To.

 

 

The above example will result in a list of specifications with IDs ranging from 100 to 500.

 

Note: In the Additional Attributes tab, the fields on which a search condition has been defined is indicated by an asterisk (*) after the field name.

 

4.2.6.5 Search by Change Request Inclusion

 

In DevSpec, one or more specifications may be grouped together and flagged for a change. All change request items are tracked under the change request view in DevSpec (must be enabled by the project administrator). For a complete explanation of the change request feature in DevSpec, please see chapter 8, section 1, Change Request.

 

In the specification view, users can filter specifications based on whether they are linked to a change request. To search for specifications/requirements linked to a change request:

  1. Launch the search dialog in DevSpec (use button).
  2. Go to the General Properties tab.
  3. In the Change Requests section, select a radio button.

 

    • Select Included in an open change request to find all specifications that are currently linked to a change request item.
    • Select Not included in open change requests to find all specifications that are not linked to any change request item.
    • Select Ignore change request inclusion to find all specifications, regardless whether they are linked to a change request item.

Click the Search button.

4.3 Using Queries

 

In DevSpec, all specifications, requirements, and change requests are at all times owned by one-and-only-one user or group folder. Using the owner filter, the work items displayed in the list panel may be filtered by the current owner.

 

The owner filter in the search bar displays the names of all users, groups, and group folders.

 

Users: Users are the individual project team members. When a user is selected, all items owned by that user are displayed. Users are identified by the users’ names.

 

Groups: Groups are administrator-defined teams of users who share a common set of responsibilities within a project. When a group is selected, all items owned by any individual belonging to that group are displayed. Groups are identified by a leading asterisk (*).

 

Group folders: Group folders give groups the ability to own items, while preserving a set of access rights within the group. Group folder ownership and user ownership are exclusive; therefore, when a group folder is selected, all items owned by that group folder, and not any other user, are displayed. Group folders are identified by a leading addition sign (+).

 

 

In the above screenshot, where theDevelopmentgroup is selected, only the work items currently being owned by that group will be returned in the search results.

 

4.3.1 Query vs. Search

 

In DevSpec, a "query" is sometimes distinguished from a "search" in that queries are saved to the database and many be accessed and used again and again to retrieve work items that meet its search conditions, while a search is an ad-hoc query that is used once if not saved.

 

4.3.2 Query Types

 

Queries are also distinguished from searches in that queries are defined by its type. A query type defines query access rights; that is, who may access and use the queries saved in a project. DevSpec supports two types of queries:

 

Private Query: A private query is only available to the user who created it.

 

Public Query: Public queries are available to all other DevSpec users. To create a public query, a project team member must belong to an account type that has been granted the Can Define Public Query privilege by a DevSpec administrator.

 

Running Queries

 

To run a private or public query, select a query from the query dropdown list in the tool bar of the DevSpec client.

 

Creating Queries

 

Project members may save user-defined search parameters as queries using the search function in the DevSpec client.

 

4.3.3 Defining and Saving Queries

 

To create a query:

 

  1. Click the button in the tool bar (or)
  2. Select {Ad-hoc Query} from the dropdown list as shown below (or)

  1. Select Edit > Search in the menu bar (or)
  2. Use CTRL + S.
  3. Define search conditions across one or more tabs in the Search dialog.
  4. Click the Save button at the bottom of the Search dialog.
  5. The Save dialog box appears.

 

 

  1. Define a name for your query in the Save As text field.
  2. Select an option from the Type drop-down list.
    • To make the query available to all users, select the Public option.
    • To create a query that is only available to yourself, select the Private option.

Note: Only the users who have been granted the Can Define Public Query privilege by the DevSpec administrator will be able to save a query as Public.

 

  1. Click the OK button.
  2. To run the search

All saved queries will be listed in the search dropdown list in tool bar.

 

 

The saved queries can also be used in the report view when the properties of a report are being defined.

 

 

4.3.4 Loading Queries

 

To load a saved query:

 

  1. Launch the search dialog in DevSpec (use button).
  2. Click the Load button. The Load dialog appears.

Note: The Load dialog can also be opened by selecting Edit > Load Query in the menu bar.

 

 

 

  1. Select a query in theQuery Namelist.
  2. Click theLoadbutton (in theLoaddialog).
  3. Click theSearchbutton (in theSearchdialog).
4.3.5 Editing/Renaming Queries

 

To edit/rename a saved query:

 

  1. Launch the search dialog in DevSpec (use button).
  2. Click the Load button. The Load dialog appears.

Note: The Load dialog can also be opened by selecting Edit > Load Query in the menu bar.

 

 

  1. Select a query in the Query Name list.
  2. Click the Rename button.
  3. Edit or rename the query.
  4. Click the OK button.
  5. Click the Cancel button (in the Load dialog).
  6. Click the Close button (in the Search dialog).

Note: Users may only rename public queries if they have been granted the Can Define Public Query privilege by the DevSpec administrator.

 

4.3.6 Deleting Queries

 

Project members may delete private and public queries. Project members may only delete public queries if they have been granted theCan Define Public Queryprivilege by a project administrator.

 

To delete a saved query:

  1. Launch the search dialog in DevSpec (use button).
  2. Click theLoadbutton. TheLoaddialog appears.

Note:TheLoaddialog can also be opened by selectingEdit>Load Queryin the menu bar.

 

 

  1. Select a query in theQuery Namelist.
  2. Click theDeletebutton.
  3. Click theCancelbutton (in theLoaddialog).
  4. Click theClosebutton (in theSearchdialog).

Note:Users may delete public queries only if they have been granted theCan Define Public Queryprivilege by the DevSpec administrator.

 

4.3.7 Adding More Search Conditions to Queries

 

Project members may delete private and public queries. Project members may only delete public queries if they have been granted theCan Define Public Queryprivilege by a project administrator.

 

To delete a saved query:

  1. Launch the search dialog in DevSpec (use button).
  2. Click theLoadbutton. TheLoaddialog appears.

Note:TheLoaddialog can also be opened by selectingEdit>Load Queryin the menu bar.

 

 

  1. Select a query in theQuery Namelist.
  2. Click theDeletebutton.
  3. Click theCancelbutton (in theLoaddialog).
  4. Click theClosebutton (in theSearchdialog).

Note:Users may delete public queries only if they have been granted theCan Define Public Queryprivilege by the DevSpec administrator.

 

 Chapter 5 Importing
5.1 Import data using Microsoft Office Add-on


Requirements, specifications and other knowledge items can come from a variety of sources and may initially be stored in Microsoft Office applications, such as Word, Outlook, PowerPoint, etc. A good requirements management tool should facilitate easy import of data from such commonly used applications.

 

The DevSpec Office Add-in module allows users to integrate Microsoft Office tools with DevSpec.

5.2 Installing the Microsoft Office Add-In Module


To install the Microsoft Office Add-In module:

 

  1. SelectTools>KnowledgeWiseAdd-In Setup.

 

  1. The KnowledgeWise Add-In installation wizard appears.

 

  1. Click theStart Installbutton, and complete the installation.

Note: Make sure all Microsoft Office applications are closed before running this installation.

 

  1. After successful installing the DevSpec Office Add-in module, users can see DevSpec tools in Microsoft Office applications:

    • DevSpec tools in Microsoft Word:

    • DevSpec tools in Microsoft Outlook:

    •  DevSpec tools in Microsoft PowerPoint:

 

5.3 DevSpec and Microsoft Word

 

5.3.1 Default Settings

 

To define DevSpec default settings in Microsoft Word:

 

  1. Open Microsoft Word and selectKnowledgeWise>Settingsin the main menu; or click the icon on the tool bar. TheSettingsdialog appears.

 

  1. Select a default DevSpec project in the dropdown list
  2. Click theChangebutton. TheChange Projectdialog appears.

 

  1. Select a web service in theWeb Servicedropdown list.
  2. Enter a username and password.
  3. Optional: To save the login settings, select theRemember my user name and passwordcheck box.
  4. Click theOKbutton. TheChange Projectdialog closes.
  5. In theSettingsdialog, select theAutomatically add the following notescheck box.
  6. Enter a brief message in theNotestext box. This will be used as the default note when checking in items to DevSpec.
  7. Click theOKbutton.
5.3.2 Initializing Requirement Documents


Using controls in theInitialize KnowledgeWise Documentdialog box, project team members may create (or initialize) new KnowledgeWise knowledge documents and DevSpec requirement documents.


To initialize a requirement document:


  1. Click theInitialize KnowledgeWise Documentbutton in the DevSpec tool bar or the Microsoft Word tool bar. TheInitialize KnowledgeWise Documentdialog appears.

  1. Define the title and provide a brief description of the requirement in theTitleandDescriptiontext boxes. TheSave Aswindow appears.

  1. Identify an existing Microsoft Word document.

  2. Click theSavebutton. TheMicrosoft Worddialog appears.

  1. Select an option for saving the requirement document.
    • To overwrite the selected file with text, select theReplace Existing Fileradio button.
    • To save text as a different file, select the Save Changes With Different Name option button.
    • To merge text into the selected file, select the Merge Changes Into Existing File option button.
  1. Click theOKbutton.

Note: Using controls in theNew Document from KnowledgeWise Templatewindow, project team members may add new requirements, child requirements, or knowledge

documents.

 

To create a requirement document from a template:


  1. Click theNew Documentbutton in the DevSpec tool bar or the Microsoft Word tool bar. TheNew Documentdialog box appears.

 

  1. Click the Add button. TheAdd New dialog appears.

  1. Optional: To change projects, select theChangebutton and update the web service, user name, and password in theChange Projectdialog box.
  2. Select theRequirementoption in the Add word document as section.
  3. Optional: If the requirement contains child requirements, select theContains Child Requirementscheck box.
  4. Optional: To switch projects, select a project in theProject Namedropdown list.
  5. Select a requirement template folder in the requirement template tree panel.
5.3.3 Creating Items from Checked Out Documents

 

To create a new requirement document from checked out document:

 

  1. Check out a requirement document.
  2. Click theCheck Inbutton in the Word tool bar. TheCheck In Requirement Documentdialog appears.

 

 

  1. Enter check in notes in theCheck In Notestext box.
  2. Optional: To keep the requirement document locked, select theKeep Lockedcheck box.
  3. Click theAdd As Newbutton. TheAdd New Requirement Document dialog appears.

 

 

  1. Optional: To change the login profile, select theChangebutton and update the web service, user name, and password in theChange Projectdialog.
  2. Select the requirement option in the Add word document as section.
  3. Optional: If the requirement contains child requirements, select theContains Child Requirementscheck box.
  4. Optional: To switch projects, select a project in theProject Namedropdown list.
  5. Select a requirement template folder in the requirement template tree panel.
  6. Click theContinuebutton. 
5.3.4 Checking Out Requirement Documents

 

To check out a requirement document:

 

  1. Click theCheck Outbutton in the Word tool bar. TheCheck Out dialog appears.

 

            

  1. To change the login profile, select theChangebutton and update the web service, user name, and password in theChange Projectdialog.
  2. Select theRequirementoption in theTypesection.
  3. Optional: To switch projects, select a project in theProject Namedropdown list.
  4. Select a requirement in the requirement template tree panel.
  5. Select a requirement in the requirement document list.
  6. Optional: To display child requirements, select theShow Child Documentscheck box.
  7. Click theCheck Outbutton. TheCheck Outdialog appears.

 

 

  1. Optional: To open the file, select theOpen This File Nowcheck box.
  2. Optional: To place a lock on the file, select theLock This Filecheck box.
  3. Click theOKbutton.
5.3.5 Checking In Requirement Documents

 

To check in a requirement document:.

 

  1. Click theCheck Inbutton in the Word tool bar. TheCheck In Requirement Documentdialog appears.

 

 

  1. Enter check in notes in theCheck In Notestext box.
  2. Optional: To keep the requirement document locked, select theKeep Lockedcheck box.
  3. Click theCheck Inbutton.
5.4 Managing Word Requirements

 

To define DevSpec default settings in Microsoft Word:

 

  1. Open Microsoft Word and selectKnowledgeWise>Settingsin the main menu; or click the icon on the tool bar. TheSettingsdialog appears.

 

  1. Select a default DevSpec project in the dropdown list
  2. Click theChangebutton. TheChange Projectdialog appears.

 

  1. Select a web service in theWeb Servicedropdown list.
  2. Enter a username and password.
  3. Optional: To save the login settings, select theRemember my user name and passwordcheck box.
  4. Click theOKbutton. TheChange Projectdialog closes.
  5. In theSettingsdialog, select theAutomatically add the following notescheck box.
  6. Enter a brief message in theNotestext box. This will be used as the default note when checking in items to DevSpec.
  7. Click theOKbutton.
5.4.1 Adding Word Requirements to Requirement Documents

 

To add a Word requirement to a requirement document:

 

  1. Create or open a requirements document in Microsoft Word.
  2. Highlight one or more lines of text in the document.
  3. Click theAdd Newbutton in the Word tool bar. TheNew Requirementdialog appears.

 

 

  1. Define the name and a brief description of the requirement line item.
  2. Click theOKbutton.

The selected text is enclosed in DevSpec markup tags:

5.4.2 Editing Word Requirements

 

To edit a Word requirement:

 

  1. Create or open a requirements document in Microsoft Word.
  2. Highlight one or more lines of text in the document.
  3. Click theEditbutton in the Word tool bar. TheEdit Requirementdialog appears.

 

 

  1. Update the title or description of the requirement.
  2. Click theOKbutton. The selected Word requirement is updated.
5.4.3 Deleting Word Requirements

 

To delete a Word requirement:

  1. Create or open a requirements document in Microsoft Word.
  2. Highlight one or more lines of text in the document.
  3. Click theDeletebutton in the Word tool bar. A confirmation dialog appears.

 

 

  1. Click the Yes button. The selected Word requirement is deleted.
5.4.4 Browsing Word Requirements

 

To browse Word requirements in a Word document, select thePrevious Requirementbutton orNext Requirementbutton in the DevSpec bar.

 

  • The Previous Requirement button enables the user to select the previous Word requirement in a document.
  • The Next Requirement button enables the user to select the next Word requirement in a document.
5.4.5 Browsing Word Requirement Summaries

 

Using controls in theRequirement Summarywindow, project team members may quickly browse the Word requirements in a requirements document, go to selected Word requirements, or delete selected Word requirements.

 

To browse requirement summaries:

 

  1. Create or open a requirements document in Microsoft Word.
  2. Highlight one or more lines of text in the document.
  3. Click theRequirement Summarybutton in the Word tool bar. TheRequirement Summarydialog appears.

 

 

  1. Select the check box next to the title of the Word requirement.
  2. Optional: To go to the selected Word requirement, select theGo Tobutton.
  3. Optional: To delete the selected Word requirement, select theDeletebutton.
5.4.6 Publishing Word Requirements As Knowledge

 

Every Word requirement in a requirement document may be published independently of the other line items in that requirement document. Word requirements may be

published as requirements, knowledge items, or specifications.

 

Using controls in thePublish As Requirementdialog, project team members may publish Word requirement-line items in a requirement document-as independent standard requirements.

 

To publish a Word requirement as knowledge:

 

  1. Create or open a requirements document in Microsoft Word.
  2. Select a requirement line item-a Word requirement-in the requirement document.
  3. Click thePublishbutton in the Word tool bar. ThePublish dialog appears.

 

 

  1. Select thePublish As Knowledgeoption button.
  2. Optional: To switch projects, select a project in theProject Namedropdown list.
  3. Optional: To change login profile, click the Change button and define the web service, user name, and password.
  4. Select a knowledge folder in the knowledge template tree panel.
  5. Click theNextbutton.
5.4.7 Publishing Word Requirements As Requirements

 

Every Word requirement in a requirement document may be published independently of the other line items in that requirement document. Word requirements may be

published as requirements, knowledge items, or specifications.

 

Using controls in thePublish As Requirementdialog, project team members may publish a Word requirement-a line item in a requirement document-as a standard requirement.

 

To publish a Word requirement as a standard requirement:

 

  1. Create or open a requirements document in Microsoft Word.
  2. Select a requirement line item-a Word requirement-in the requirement document.
  3. Click thePublishbutton in the Word tool bar. ThePublish dialog appears.

 

            

  1. Select thePublish As Knowledgeoption button.
  2. Optional: To switch projects, select a project in theProject Namedropdown list.
  3. Optional: To change login profile, click the Change button and define the web service, user name, and password.
  4. Select a requirement folder in the knowledge template tree panel.
  5. Click theNextbutton.
5.4.8 Publishing Word Requirements as Specifications

 

Every Word requirement in a requirement document may be published independently of the other line items in that requirement document. Word requirements may be

published as requirements, knowledge items, or specifications.

 

Using controls in thePublish As Requirementdialog, project team members may publish a Word requirement-a line item in a requirement document-as a standard requirement.

 

To publish a Word requirement as a standard requirement:

 

  1. Create or open a requirements document in Microsoft Word.
  2. Select a requirement line item-a Word requirement-in the requirement document.
  3. Click thePublishbutton in the Word tool bar. ThePublish dialog appears.

 

            

  1. Select thePublish As Knowledgeoption button.
  2. Optional: To switch projects, select a project in theProject Namedropdown list.
  3. Optional: To change login profile, click the Change button and define the web service, user name, and password.
  4. Select a requirement folder in the knowledge template tree panel.
  5. Click theNextbutton.
 Chapter 6 Backlog Management
6.1 Backlog Management - Concept

 

DevSpec provides rich functions and features and can be used as a stand alone requirement and product design management tool. However, the true value of DevSpec is to provide better product design management. This allows enterprises to achieve more mature development process control. An essential part of agile development is backlog management.

The product backlog can be formally defined as the specifications that are ready to be implemented. While a specification in DevSpec represents a feature, enhancement, change or defect to be fixed, it becomes a backlog item once it is ready to be implemented. Backlog items represent a link for a specification to be implemented within a certain development iteration. A specification may need to be implemented multiple times, and therefore can be linked with multiple implementation links.

DevSpec is designed and developed based on TechExcel's conceptual modeling ideology: requirements should be formally represented and can be quantified. Quantified requirements can better drive implementation and testing.

With specifications serving as the quantified requirements, application development project planning, implementation, and QA testing can all be managed with specificaitons as their foundation.

 

•Project planning with specifications is about committing a set of features for development iterations, planning the resources needed for each specification, assigning the proper start and end time for the development work, and providing estimates on time for the development team to finish the new features, enhancements, and bug fixing specifications.

 

•Development implementation tracking becomes about task management around the committed specifications. Each specification may require one or many development tasks, and development teams can update the development task's status, update the finish date, the time spent and the time remaining. As a result, the planned time and resources can be used to display the time and resources used for each development task.

 

•QA testing becomes requirement-driven thorough specifications. As specifications are committed, planned, and implemented, QA test tasks are created for each specification. Specifications can be used to define a QA test library, and to better quantify and standardize the QA testing process.

 

All the above mentioned functions are facilitated by the Backlog feature in DevSpec. It enables DevSpec users to easily move a committed Specification or Feature to a temporary repository of prioritized items, before these items are actually scheduled for implementation and testing.

 

6.2 Managing the Specification Backlog

 

In DevSuite, a specification defines a conceptual product that may be implemented in one or more development subprojects. Each subproject represents a distinct area of development and defines the framework that development organization uses to manage, schedule, and track iterations of development within that area.

Implementation linking enables development organizations to schedule the development of designed product - as defined by a specification - in development subprojects. Every development issue managed in a subproject may be linked to a single "implementation specification" - a pairing of a specification and an implementation module.

A specification may define one or more subprojects. In DevSuite, every subproject may be defined by one or more implementation modules, as well as its subproject type (regular, iteration, iteration group, and product defect), a product and version, and multiple specifications.

A requirement, that is evaluated by users in DevSpec and well defined through Specification, is ready for implementation as soon as it is finalized and approved.

Specification is one of the key components in Product Design. It clearly defines the development goals. Before the implementation team begins working on a committed specification, Project Managers need to properly plan when the actual development work will commence. They need to allocate resources to work on the implementation of this specification. Project Managers also need to specify which Product Module will include this Specification.

A Product Backlog is created to facilitate smooth transition from the Design phase to the Planning and Implementation phase. It consists of a list of prioritized items that need to be developed in the next implementation cycle. As Specifications reach their final approval state, they are dropped into the Backlog folder, indicating Project Managers that these Specifications are ready for implementation.


  


In DevSpec, the Backlog tab allows users to select a specification and easily add it to the appropriate Product Backlog folder. To do so, highlight a specification in the List View, go to the Backlog tab, select the appropriate Backlog folder and click "Assign to Product Backlog" button. You can also drag-and-drop a Specification from List View into one of the Specification Backlog Folder under Backlog.

 

6.3 Tracking Implemented Specifications

 

DevSpec further uses a concept called implementation modules, which can be used to more formally represent the relationship between areas of the product design and the implementation backlog.

While adding a Specification to the Backlog, users can also select different areas of development in which the particular Specification needs to be completed.

 


 

In the DevSpec client, project team members may manage and track the implementation of specifications across multiple development projects in the Implementation Tracking tab.

 

Using controls in the Specification tab, project team members may manage and track implementation links between specifications and iterations (subprojects).

 

Implemented specifications are organized into three folders. Each specification is identified by a distinct icon.

 

Pending: The pending folder contains specifications that have been assigned to the specification backlog, but not yet committed to an iteration.

 

Assigned: The assigned folder contains specifications that have been implemented in an iteration. A specification is automatically moved to the closed folder when the linked iterative subproject is closed.

 

Closed:The closed folder shows implementations of the specification that have been implemented. A specification is automatically moved to the closed folder when the linked iterative subproject is closed.

 

The Implementation Tracking tab displays high-level information about specifications that are in various stages of development, including the status (open or closed) of the specification, the status of linked development issues, owner, estimated time, estimated time remaining, and specification points.

6.4 Managing Pending Implementations of Specifications

 

In DevSuite, a pending implementation identifies a implementation of a specification that has been approved for development, but which has not yet been committed to a particular iterative subproject (iteration or sprint).

 

A pending implementation is defined by a specification, implementation module, specification backlog folder, owner, estimated time, and optionally, specification points.

 

Using controls in the Edit Pending Implementation window, project team members may add implementation specifications - paired specifications and modules - to the specification backlog and define preliminary time estimates and specification points for the feature.

 

The Specification backlog is a hierarchical tree structure that enables development organizations to prioritize the implementation of features in a DevTrack development project.

 

 

 

To add a pending implementation:

 

1. Select a specification in the specification list panel. Specification may be added to the specification backlog only if they are in an applicable open workflow state. Closed specifications may not be scheduled for development.

 

2. Select the Backlog tab in the specification detail panel.

 

3. Click the Edit Pending Implementation button. The Edit Pending Implementation window appears.

 

4. Select one or more implementation modules in the module list. An implementation module is a tool for organizing a distinct area of development - such as a platform (Windows, Linux), an application (thick client, thin client, smart client), plug-in, tool, widget, or any other development item. A specification may be scheduled for implementation in multiple modules.

 

5. Optional:To choose the development project, select a development project in the Development Project drop-down list.

 

6. Select a specification backlog folder in the specification backlog tree. The specification backlog is a hierarchical tree structure that enables development organizations to prioritize the implementation of features in a DevTrack development project.

 

7. Optional:To define a project team member as the owner of the implementation specification, select a project team member in the Owner drop-down list. A distinct owner may be defined for each pending implementation.

 

8.Input the estimated time required to complete the development task in the Est. Total text box. Numbers are automatically converted into days, weeks, and hours. For example, the number 90 will equate 2W 1D 2H. Distinct time estimates may be defined for each specification/module pairing.


9. Optional: To define specification points for the feature to be implemented, input the number in the Story Points text box. A specification point is a tool for rating the relative complexity of a feature - as defined by the specification and the module in which it is to be implemented - so that the team may better estimate the work that may be completed in an iteration. Distinct specification points may be defined for each specification/module pairing.

 

10. Click the OK button. One implementation is displayed in the Pending folder for each implementation module selected.

 

To edit a pending implementation specification:

 

1. Click the Edit Pending Implementation button. The Edit Pending Implementation window appears.

 

2.Select an implementation modules in the module list.

 

3. Update implementation properties.

 

4. Click the OK button. The update definitions are displayed in the implementation list.

 

To delete a pending implementation specification:

 

1. Select the Implementation Tracking tab in the specification detail panel.

 

2. Select a pending implementation in the implementation list.

 

3. Click the Delete button. Confirmation dialog box appears.

 

4. Click the Yes button. The pending implementation is deleted from the implementation list.

6.5 Adding Specifications to the Specification Backlog

 

In DevSuite, the specification backlog is a prioritized list of features that have been cued for development, but not committed to a specific iteration.

 

The specification backlog enables development organizations to control which specifications may be assigned to iterative subprojects - iterations - in development projects using state-based specification assignment rules.

 

Using controls in the Edit pending Implementation window, project team members may link paired specifications and modules to one or more specification backlog folders and define preliminary time estimate and specification points for the feature.

 

The Edit pending Implementation Module window displays a list of applicable implementation modules, preliminary owners, time estimates, and specification points for each implementation module, and the specification backlog tree for the selected development project. 

 

To link a pending implementation specification:

 

1. Select a specification in the specification list panel. Specifications may be added to the specification backlog only if they are in an applicable open workflow state. Closed specifications may not be scheduled for development.

 

2.Select the Implementation Tracking tab in the specification detail panel.

 

3. Click the Edit Pending Implementation button. The Edit Pending Implementation window appears.

 

4. Select one or more implementation modules in the module list. An implementation module is a tool for organizing a distinct area of development - such as platform (Windows, Linux), an application (thick client, thin client, smart client), plug-in, tool, widget, or any other development item. A specification may be scheduled for implementation in multiple modules.

 

5. Optional:To choose the development project, select a development project in the Development Project drop-down list.

 

6. Select a specification backlog folder in the specification backlog tree. The specification backlog is a project-specific list of the features that have been cued for development, but not committed to a specific iteration.

 

7. Optional: To define a project team member as the owner of the implementation specification, select a project team member in the Owner drop-down list. A distinct owner may be defined for each specification/module pairing.

 

8. Input the estimated time required to complete the development task in the estimated Total text box. Numbers are automatically converted into days, weeks, and hours. For example, the number 90 will equate to 2W 1D 2H. Distinct time estimates may be defined for each specification/module pairing.

 

9. Optional: To define specification points for the feature to be implemented, input the number in the Story Points text box. A specification point is a tool for rating the relative complexity of a feature - as defined by the specification and the module in which it is to be implemented - so that the team can better estimate the work that may be completed in an iteration. Distinct specification points may be defined for each specification/module pairing.

 

10. Click the OK button. One implementation is displayed in the Pending folder for each implementation module selected.

 

To edit a pending implementation specification: 

 

1.Click the Edit Pending Implementation button. The Edit Pending Implementation window appears.

 

2.Select an implementation modules in the module list.

 

3.Update implementation properties.

 

4.Click the OK button. The updated definitions are displayed in the implementation list.

 

To delete a pending implementation specificaiton:

 

1. Select the Implementation Tracking tab in the specification detail panel.

 

2. Select a pending implementation in the implementation list.

 

3. Click the Delete button. A confirmation dialog box appears.

 

4. Click the Yes button. The pending implementation is deleted from the implementation list.

6.6 Assigning Implementation to Subprojects

 

In DevSuite, an assigned implementation identifies a specification that has been assigned to development subproject. An assigned implementation link is a development task that has been assigned to a subproject. Assigned implementation links are defined by a owner, estimated time, and optionally, story points.

 

Using controls in the Assign Implementation Links to Subproject window, project team members may link specifications to development subprojects, define the owner of development issues, the time required to complete the development task, and the story points for that task.

 

A specification may be assigned to one subproject per implementation module. In DevSuite, an implementation module is a tool for organizing a distinct area of development - such as a platform (Windows, Linux), an application (thick client, thin client, smart client), plug-in, tool, widget, or any other development item.

 

A single specification may be implemented multiple times in many different areas of development. For example, the same feature may implemented in a Windows-based client and a browser-based client.

 

To assign an Implementation specification to a development subproject:

 

1.Select a specification in the specification list panel.

 

2.Select the Implementation Tracking tab of the specification detail panel.

 

3. Click the Assign Pending button. The Assign Implementation Module to Subproject window appears. Select one or more implementation modules in the implementation list. Pending implementations are selected by default.

 

4. Select a project.

 

5. Select a subproject.

 

6. Select a development project team member in the Owner drop-down list.

 

7. Define the estimated time to complete the development task in the Estimated Time text box.

 

8. Input the number of story points in the Story Points text box.

 

9. Click the Assign button. The Assign Implementation Module to Subproject window closes.

 

To delete an assigned implementation specification:

 

1. Select the Implementation Tracking tab in the specification detail panel.

 

2. Select an assigned implementation in the implementation list.

 

3. Click the Delete button. A confirmation dialog box appears.

 

4. Click the Yes button. The pending implementation is deleted from the implementation list.

6.7 Editing Assigned Implementation Specifications

 

Using controls in the Edit Implementation Links to Subproject window, project team members may link specifications to a development subproject and define the owner of development issues, the time required to complete the development task, and the story points for the task.

To edit an implementation specification:

 

1.Select a specification in the specification list panel.

 

2.Select the Implementation Tracking tab of the specification detail panel.

 

3.Click the Edit Existing button. The Edit Implementation window appears. The pending implementation is deleted from the implementation list.

 

To assign implementation specification to a different subproject:

 

1.Select a specification in the specification list panel.

 

2.Select the Implementation Tracking tab of the specification detail panel.

 

3.Click the Edit Existing button. The Edit Implementation window appears. The pending implementation is deleted from the implementation list.

 Chapter 7 DevSuite Integration
7.1 DevSpec and DevPlan as part of DevSuite

 

TechExcel DevSuite is a comprehensive Application Lifecycle Management Tool. It consists of integrated tools to manage different phases in the application lifecycle. 
 


DevSuite consists of following integrated tools:

  1. DevSpec (Requirement Management Tool)
  2. DevPlan (Project Planning Tool)
  3. DevTrack (Implementation Tool for Development Team)
  4. DevTest (Test Management Tool)
7.1.1 DevPlan

 

DevPlan is DevSuite's project planning tool. DevPlan users, such as product and project managers, can ensure that a proposed initiative/feature completes within a defined time frame at a managed cost.

Some of the key activities of Product and Project Managers in DevPlan are listed below:

  • Schedule and define projects/sub-projects. Sub-project tree represents functional breakdown of projects.
  • Allocate timelines for Projects and define dependencies.
  • Allocate Resources for Project. Through resource allocation, estimate the man-hours required for the completion of a project or area of work.
  • Schedule events, such as meetings, brainstorming sessions, discussions, designer presentation, etc.
  • Make sure that knowledge, concepts, and design ideas are shared across all teams and properly linked to the development tasks.
  • Generate reports and charts to monitor progress and balance work load.
  • Adjust timelines based on design changes and other estimates.


7.1.2 Need for DevSpec - DevPlan Integration

 

For DevPlan users to plan projects efficiently, it is essential that they clearly understand the proposed design, features, and specifications that will drive the future implementations. Since all requirements, design, and concepts are well tracked and managed in DevSpec, it would be nice to have a view or window to DevSpec from within DevPlan. This will empower Project Managers working in DevPlan to better understand the features and therefore better plan a project.

Generally, a product design consists of complete specifications that include:

  • Functional requirements and design documents
  • Product components and breakdown
  • Design parameters and feature specifications
  • Architecture and database design documents
  • Programming logic and QA test case documents
  • Business logic and user interface design
All these items are managed in DevSpec and serve as guidelines for developers during product implementation phase. So it is equally important to link these documents with appropriate development work items. DevSpec-DevPlan integration facilitates accomplishing this goal.
7.1.3 Understanding and Managing DevSpec and DevPlan Integration

 

When a Requirement/Specification in DevSpec is ready to be implemented, it is assigned to a Product Backlog through the Implementation Module feature.

 



With the help of DevSpec-DevPlan integration, this Backlog is made available to the DevPlan users.

Specification Backlog in DevPlan

The specification backlog enables development organizations to organize and prioritize features - as defined by DevSpec specifications - that have been approved for development, but which have not yet been committed to a particular subproject.

Using the backlog, product and project managers may identify those features that are highest priority for the business, schedule those specifications for development by assigning them to a sub-project or a sprint. In DevPlan, this is done on the "Backlog" page for a highlighted sub-project. This requires simply dragging a Specification from Backlog and dropping it into a sub-project or sprint.

 



Knowledge sharing in DevPlan
DevPlan users can also link relevant Knowledge artifacts, managed in DevSpec, to the development project.

 



Specification History and Work Details in DevPlan
DevPlan can also display the properties and history of a specification through the work details view. Project managers can view this information by selecting "View" on the Work Details tab.


 


Each Development work item that is created for this subproject will be linked to the specification driving the development work. So everyone on the development side and project planning side are always aware of clear requirements and in sync.

7.2 DevSpec and DevTrack as part of DevSuite

 

DevPlan is DevSuite's project planning tool. DevPlan users, such as product and project managers, can ensure that a proposed initiative/feature completes within a defined time frame at a managed cost.

Some of the key activities of Product and Project Managers in DevPlan are listed below:

  • Schedule and define projects/sub-projects. Sub-project tree represents functional breakdown of projects.
  • Allocate timelines for Projects and define dependencies.
  • Allocate Resources for Project. Through resource allocation, estimate the man-hours required for the completion of a project or area of work.
  • Schedule events, such as meetings, brainstorming sessions, discussions, designer presentation, etc.
  • Make sure that knowledge, concepts, and design ideas are shared across all teams and properly linked to the development tasks.
  • Generate reports and charts to monitor progress and balance work load.
  • Adjust timelines based on design changes and other estimates.


7.2.1 Need for DevSpec - DevTrack Integration

 

It is essential for the implementation team in DevTrack to clearly understand the features and concepts to make sure that the final implemented product precisely represents the designed product (or the conceptual product).

 

The picture below illustrates the relationship between the conceptual product and the implemented product in an iterative development model.

 



The conceptual product, is an illustration to quantitively represent the requirements and business logic of an application.

The implemented product is the end result of the implementation teams working towards a final deliverable product, but building upon the conceptual product.

Using this model, both the design team and the implemented team can always be in sync by sharing clear and common goals. This is facilitated through DevSpec - DevTrack integration.

7.2.2 Understanding DevSpec - DevTrack Integration

 

Requirements and specifications tracked and committed in DevSpec drive the implementation work in DevTrack. As each development item progresses through workflow towards completion, it is appropriately associated with a specification defined in DevSpec. The visibility to the specification details is facilitated by the "Specification" tab in DevTrack Client.

 



DevTrack users can quickly refer to the linked specification and get a better understanding of the design requirement.

On the subproject links tab for a highlighted development item, users can view, edit, and link all other linked documents, knowledge, requirements.

In DevSpec, users can view all the development items for a requirement/specification under the "All Links" tab -> Linked Development folder.

 

7.3 DevSpec and DevTest as part of DevSuite

 

For DevPlan users to plan projects efficiently, it is essential that they clearly understand the proposed design, features, and specifications that will drive the future implementations. Since all requirements, design, and concepts are well tracked and managed in DevSpec, it would be nice to have a view or window to DevSpec from within DevPlan. This will empower Project Managers working in DevPlan to better understand the features and therefore better plan a project.

Generally, a product design consists of complete specifications that include:

  • Functional requirements and design documents
  • Product components and breakdown
  • Design parameters and feature specifications
  • Architecture and database design documents
  • Programming logic and QA test case documents
  • Business logic and user interface design
All these items are managed in DevSpec and serve as guidelines for developers during product implementation phase. So it is equally important to link these documents with appropriate development work items. DevSpec-DevPlan integration facilitates accomplishing this goal.
7.3.1 Understanding DevSpec - DevTest Integration

 

TechExcel DevTest is an integrated test management solution that is specifically designed to manage the entire software test lifecycle. DevTest gives you total control of every aspect of your testing process from test planning and team management to analyzing your test results. DevTest enables you to create and manage release and test cycles, plan and assign test tasks to your testing teams, execute test coverage, and submit product defects - all from a single application.

 

The picture below shows the DevSuite model and the significant role played by DevSpec and DevTest in the ALM process:

 


DevTest-centric approach to test management ensures that the test team has access to the complete picture of the project they are testing for each phase of the test lifecycle. From test design to test execution and analysis, DevTest provides test teams with a connection to the knowledge items they need to implement an effective test management process.

In addition to the global knowledge access, DevTest team can also refer to the requirements/specifications driving the implementation and validation work. The requirements and specifications managed in DevSpec are easily linked to the test cases managed in DevTest.

 Chapter 8 Advanced Features
8.1 Change Request

 

Any software development project should welcome changes to the design at any point during the development lifecycle. Customers and other stakeholders may demand a requirement/specification change at any time. A requirement/specification management tool should be able to accommodate these changes with minimal impact, minimal risk, and minimal overhead. 

 

In DevSpec requirement changes are completely tracked and controlled through a change process. The change request view in DevSpec allows users to define a change and link all affected specifications. Users can be notified about the suggested change, and meetings and events can be scheduled to gather stakeholders’ opinion. The suggested change follows a strict workflow to make sure each intricate detail is considered and everyone is on the same page and well prepared for the suggested change to the product Design.

 

Just as with other views in DevSpec, the change request view is divided into three panels:

  • List panel
  • Folder panel
  • Detail panel
8.1.1 Submitting a Change Request

 

To submit a change request:

  1. Switch to the change request view by clicking the button in the tool bar
  2. Click the button in the tool bar, or selectFile >Submit New…in the menu bar



  1. Complete the change request submission form and clickOK.
8.1.2 Linking Specifications to a Change Request

 

To link specifications and requirements to a change request:

 

  1. In the change request view, right-click on a change request in the list panel
  2. SelectAdd Requirement/Spec Change.
  3. In the new dialog, highlight a specification folder in the tree panel and select the requirements/specifications that will be effected by the proposed change

 

Note:The icon represents aSpecificationand the icon represents aRequirement.

 

  1. Click OK
  2. All linked requirements and specifications are displayed under the change request item in the list panel

 

Note:In the list panel of the change request view, the icon represents alinked specificationand the icon represents alinked requirement(linked to a change request item).

 

8.1.3 The Change Request Process

 

After a change request has been submitted and requirements/specifications are linked, users can view the change request details in the detail panel. The detail panel for a change request consists of two tabs:

  • Change Request Description
  • History Page

TheChange Request Descriptiontab provides users with general information about the selected change request record. It consists of standard fields, such asTitle,Description,StateandOwner. DevSpec Administrators can add more fields to this tab as needed.

 

TheHistory Pageprovides a summary and tracking history of the selected change request record. It consists of multiple sections that can be included or excluded by each user as needed.

 

 

Each change request follows the workflow defined by the DevSpec administrator. A typical change request workflow is shown in the picture below.

 

                  

 

In the diagram above,New Change RequestandPendingare workflow states where a change request remains open.CommittedandDroppedare workflow states where a change request remains closed.

 

All linked requirements and specifications are flagged and rendered read-only as long as the change request item remains open. While in the specification view, users can easily differentiate these linked specifications from other regular, non-linked specifications.

 

 

Note:In the list panel of the specification view, the icon represents a specification linked to a change request item and the icon represents a requirement linked to a change request.

 

For each specification that is currently linked to a change request item, users will see an additional tab in the list panel of the specification view. This tab is labeledChange Description. In this tab users can view the details of the change request.

 

 

8.1.4 Change Flagging Events

 

For each specification that is linked to a change request, a special type of event can be created to track the progress with respect to the suggested change. These events are calledchange flagging eventsin DevSpec, and are different from other regular events. Change flagging events are only applicable to any specification or requirement that is linked to a proposed change request. When defining an event template, the DevSpec Administrator can customize the label of such special events.

 

The purpose of a change flagging event is to notify users (including the owner of the linked specification) about the proposed change request. Users can conduct meetings to review the proposed change and the impact on the linked specifications. After evaluating and making the appropriate adjustments to the linked specification, the event owner confirms that the specification is ready for the proposed change. This is done by closing the change flagging event.

 

To create a change flagging event:

  1. In the list panel of the change request view, highlight a specification linked to the proposed change request item
  2. In theDetailpanel, click theEventtab
  3. Select theChange Eventradio button
  4. Click theNew Eventbutton. TheNew Eventdialog pops up

 

 

  1. Select a change flagging event from the dropdown list at the top
  2. Complete other fields on the form
  3. Users can also choose a list of attendees for this event meeting. To do so, click the button
  4. Users can also create sub-events for any development tasks that are linked to the selected specification. This is done under the section labeledCreate Sub-Events for Linked Tasks
  5. Click theOKbutton
  6. TheEventtab now displays all change flagging events, along with any sub-events for linked development tasks

 

Note:All change flagging events are indicated by the  icon in theEventtab.

 

  1. On theEventtab, users can select theSpec Eventradio button to view any regular events associated with the highlighted linked specification

 

Note:For more details on events, please see section 3 in this chapter,Events.

 

Identifying Specifications with Change Flagging Events

 

Users can easily differentiate between regular specifications and specifications with change flagging events in the list panel of the specification view. Each user must add an extra specification property before utilizing this feature:

 

1.     In the menu bar, selectSystem>User Preferences…

2.     In the new dialog, go to theList View Datatab

3.     Add{Spec Change Flagging}to theList View Columnson the right side

 

 

Now such specifications with change flagging events will be identified with a flag icon in the list view.

 

 

Note:For more details on events, please see section 3 in this chapter,Events.

 

8.1.5 Change Request Workflow vs. Specification Change Workflow

 

When a change request is open, there are three separate workflows involved:

 

Specification workflow: Specifications follow the specification workflow defined by the DevSpec administrator.

 

Change request workflow: Change request items follow the change request workflow defined the DevSpec administrator.

 

Specification change workflow: Specifications linked to a change request follow the specification change workflow while the change request is open.

 

An open change request item can be linked to multiple specifications. Since each of these linked specifications can potentially be in different states in the specification workflow, until the change request item is closed or committed, all its linked specifications are frozen from further modifications. During this period, each linked specification follows the specification change workflow.

 

To edit the linked specifications and the specification change workflow:

 

  1. In the list view of the change request view, highlight a specification linked to the proposed change request item.
  2. In the detail panel, click theSpec Descriptiontab.

 

  1. Click theEditbutton inside theChange Summarysection

 

  1. Users can edit theSpec Change Description,OwnerandState.
  2. ClickOKbutton.
8.1.6 Specification History vs. Specification Change History

 

All specifications linked to a change request item maintain two workflows: the specification workflow and the specification change workflow.

 

The specification workflow is frozen as soon as a specification gets included in the proposed change request. This specification workflow remains dormant as long as the change request item remains open. While the specification workflow remains dormant, DevSpec allows users to track changes to each linked specification via a separate workflow, called the specification change workflow.

 

Users can easily view both workflows for each specification on theHistorytab in the detail panel of the change request view.

 

To view the history of a specification linked to a change request item:

 

  1. In the list panel of the change request view, highlight a specification linked to the proposed change request item.
  2. In the detail panel, click theHistorytab.
  3. To view the specification workflow history, click theSpec Historyradio button.

 

  1. To view the specification change workflow history, click theChange Historyradio button.

 

8.1.7 Committing/Closing a Change Request

 

Before a change request item can be closed, the owner of the change request item must make sure all linked requirements and specifications have been reviewed and are ready for the proposed change to be committed. Owners of each linked requirement/specification must close all change flagging events and other meeting events prior to change request closure.

 

To close a change request:

 

  1. In the list panel of the change request view, highlight a change request item.
  2. In the detail panel, click theChange Request Descriptiontab.
  3. Select a closing state from theStatedropdown list (e.g. select “Committed”).

 

  1. In the newly openedCommit Conformationdialog, review the status of all linked requirements and specifications.

 

  1. Click theOKbutton to confirm and commit the change, or click theCancelbutton to go back.
  2. After the change request item is closed, theChange Summarysection for each linked specification is rendered read-only, and the specification change workflow is frozen.

 

  1. All specifications linked to the committed change request item return to their prior states in the specification workflow, and all specification fields become active again (editable).

 

 

8.2 Baseline

 

To submit a change request:

  1. Switch to the change request view by clicking the button in the tool bar
  2. Click the button in the tool bar, or selectFile >Submit New…in the menu bar



  1. Complete the change request submission form and clickOK.
8.2.1 Creating a New Baseline

 

1. In the baseline view, click the ellipsis button (…) in the tool bar. This will open theBaseline Managerdialog.

 

 

2. In theBaseline Managerdialog, highlightBaseline Top Folder, and click theNew Baselinebutton. This will open theBaseline Submissiondialog.

 

 

3. In theBaseline Submissiondialog, the appropriate folder(s) need to be selected first. To do so, click the ellipses button next to theSpecification Foldercontrol. This will open theSelect Specification Folder Treedialog.

 

 

4. In theSelect Specification Folder Treedialog, select the appropriate folder(s) for the new baseline and press theOKbutton. Since a baseline is a set of specifications, this action will cause the system to capture all current details for all specification within the selected folders.

 

 

In the screenshot above, where theVersion 7.0folder and each of its child folders are selected, all specifications belonging to these checked folders will be included in the baseline.

 

5. Once back in theBaseline Submissiondialog, define the new baseline name, status, and description.

 

6. Click theSave and open baselineto save the new baseline, close all dialogs, and view the saved baseline in the detail panel; OR click theOKbutton to save and return to theBaseline Managerdialog.

 

 

Note: A new baseline cannot be saved if theSpecification FolderandBaseline Namefields are not filled out.

 

8.2.2 Opening a Baseline

 

After a baseline is created and saved, it can be opened at any point in future. When needing to compare current and previous designs, a previously saved baseline can easily be opened and compared with the current design.

 

1. In the baseline view, click the ellipsis button (…) in the tool bar. This will open theBaseline Managerdialog.

 

 

2. In theBaseline Managerdialog, highlight a previously saved baseline, and click theOpen Baselinebutton.

 

 

8.2.3 Baseline View Interface

 

The baseline view in DevSpec is divided into three separate panels:

  • Folder panel
  • List panel
  • Detail panel

 

If no baseline is opened, these panels will be empty. At any instance, only one baseline can be opened in the baseline view.

 

 

The folder panel shows the selected folder tree for the opened baseline in a tree structure. Selecting a folder in the folder tree will work as a filter; that is, all specifications that belong to that folder will appear in the list panel (specifications in child folders are displayed too).

 

Using the controls in the tool bar can also filter specifications in the list panel. Click the ellipses button (…) for the owner control to filter by owner, or click the search button (binoculars icon) to search by other attributes. For more information on filtering and searching in DevSpec, please see chapter 4,Searches and Queries.

 

 

The specification icons in the list panel denote whether the specification has been changed since the current baseline. An orange asterisk will appear over an icon in the case that there has been a change.

 

 Specificationhas notbeen changed since the current baseline.

 

 Specificationhasbeen changed since the current baseline.

 

When a specification in the list panel is highlighted, its comparison details will appear in the detail panel. The detail panel has three tabs:

  • TheBaselinetab displays information for the highlighted specification at the time of baseline creation (saved sometime in past).
  • TheCurrent Versiontab displays the most updated and/or latest information for the highlighted specification.
  • TheDifferencestab displays the differences between the baseline information and the current information for the selected specification.

 

 

8.2.4 Version Comparison

 

This information shown in theDifferencestab allows the users to select two different versions of the selected specification, and compare the two.

 

Versions may be created manually in theVersionstab. For more information on managing versions in theVersionstab, please see chapter 3, section 1.2,Specification Details. Versions are also created automatically by a few events:

·       When an specification is created or edited (most common)

·       When a new baseline is created

·       When a specification is rolled back to a previous version

 

 

The screenshot above is an expanded dropdown list in theDifferencestab. After taking a look at this, we know that:

  • Version 1represents the first version of the specification (when it was submitted).
  • The currently-opened baseline, denoted by{Current Baseline}, was created when the specification was onVersion 3.
  • During the lifetime of this specification, there have been seven versions.

To compare two versions:

 

Select two different versions in the version dropdown lists. In the section below, the version on the right-hand side will display the difference of the specification properties, such as title, status, owner, and description. Added text will be in red (example), while removed text will be struck through (example). Even if only one character has been added or removed, the entire word will be denoted as a change.

 

 

In the above screenshot, in theDifferencessection, under theVersion 8 Valuerow, the differences fromVersion 6toVersion 8are shown. For example, in the title, “limitation” has been changed to “limit”. The status and owner have been changed as well.

 

8.2.5 Editing a Baseline

 

To edit the properties of an existing baseline, open theBaseline Manager, highlight the baseline to be edited, and click theEdit Baselinebutton. TheBaseline Editdialog will open for the selected baseline. Make the desired changes and save by following the similar steps for creating a baseline.

 

TheSpecification Folderfield cannot be edited. Since a new version was created for all involving specifications upon baseline creation, prior versions cannot be added or deleted.

 

8.2.6 Deleting a Baseline

 

To delete a baseline, open theBaseline Manager, right-click on the baseline to be deleted, and selectDelete. In the conformation dialog, click theYesbutton.

 

Note: A baseline cannot be deleted if it is currently open.

 

8.3 Events

 

To link specifications and requirements to a change request:

 

  1. In the change request view, right-click on a change request in the list panel
  2. SelectAdd Requirement/Spec Change.
  3. In the new dialog, highlight a specification folder in the tree panel and select the requirements/specifications that will be effected by the proposed change

 

Note:The icon represents aSpecificationand the icon represents aRequirement.

 

  1. Click OK
  2. All linked requirements and specifications are displayed under the change request item in the list panel

 

Note:In the list panel of the change request view, the icon represents alinked specificationand the icon represents alinked requirement(linked to a change request item).

 

8.3.1 Understanding DevSpec Events
 

Eventsusually representa list oftasks that need to be completedor confirmedasarequirement or specification isfinalized, approved,and/or committed. All events are easily managed in theEventtabin the detail panel.

 

 

By utilizing events in DevSpec, users can createmanydifferenttasksassociated with a work item, assign each of those tasks to a different project member, define separate start and due dates for each subtask, and manage and track each of those tasksindependently in its own workflow.

 

Each event is based on an administrator-defined event template.An event template is a blueprint for creating a specific type of event, such as a meeting,apresentation, orademo.

 

Event templates exist in DevSpec in one of these twotypes: standard events and change flagging events.

 

Standardevents: Standard events are used to track the activities that are going on during the specification management process. It can be a design review meeting, a presentation, or any other activity that needs to take place. This type of events may be created and tracked in both the specification and the change request viewsof the DevSpec client. 

 

Changeflagging event: Change flagging events are used to track the activities that are going on during the specification change process. This type of events may be created and tracked only in the change request view of the DevSpec client. 

 

Each event is also defined by a unique workflow that is applicable to the template it derives from.The life cycle of an event is defined by two or more workflow states: an initial open state, a final closed state, and any number of intermediary states. An event state represents a specific stage of the life cycle of that event. Each event state is defined by its status: open, closed-successfully, or closed-failed.

 

The following is a list of event icons that identify the tasks by type and status in the event list:

 

 Regular events are tagged with an event icon.

 

 Changeflaggingevents with anopenstatus are tagged with a red flag icon.

 

 Changeflaggingevents with aclosed: failedstatus are tagged with a yellow flag icon.

 

 Changeflaggingevents with aclosed: successfullystatus are tagged with a green flag icon.

 

 Linked DevTrack development issues are tagged with a DevTrack icon. Each changeflaggingevent subtask is the child of a linked development issue.

 

At each stage in its life cycle, an eventcan beowned by one (and only one) project member. The event owner is responsible for that specific event andshould make sure it iscompleted successfully.

 

Note:For information on creating event templates, please see theDevSpec Admin Guide

 
8.3.2 Tracking Standard Events

 

Project managers may create, edit, and review standardrequirement/specificationevents in theEventstab of the detail panel. 

 

 

 

The event tab displays high-level and detailed information about the events associated with a particular requirement or specification.

 

TheEventtab consists of three main areas:

 

Eventlist: The event list displays high-level information about events in a tabular format. Each column represents an event property, such as name, state time, end time, owner, and status.Each row represents an event and displays the event property valuesofthat event.

 

Eventinfo: TheEvent Infotab displays high-level information about an event, including its name, status, owner, start time, end time, and description.

 

Eventchangelog: TheEvent Change Logtab displays a list of all changes made to an event from creation closure. It logsthe change that was made, the person who made the change, and the time the change took place.

 

 

Eachgeneralevent consists of one or more of the followingproperties:

 

Name: TheNameproperty identifies the title of the event. Events may inherit their name from the event template that was used to create them.

 

Start Time: TheStart Timeproperty identifies the date and time the event is scheduled to begin.

 

End Time: TheEnd Timeproperty identifies the date and time the event is scheduled to end.

 

Owner: At every stage in its life cycle, an event is owned by one project member. The event owner is responsible for the event and seeing that it successfully completed.

 

State: An event represents a specific stage of the life cycle of that event. Each event workflow state is defined by its status: open, closed successfully, or closed failed.

 

8.3.3 Managing Standard Events
 

Eventsrepresenta list oftasks that need to be completedor confirmedasawork item isfinalized, approvedand/or committed.


Examplesof standard eventsinclude:

 

• Brainstorming session

• Design review

• Management review

• Presentation

• Product demo

 

Using controls in theNew Eventdialog, project team members maycreate a new event associated with a work item,definetheevent schedule,andinvite project team members.

 

As mentioned, each standard event is based on an administrator-defined event template. An event template is a blueprint for creating a specific type of event, such as a meeting, presentation, or demo, that defines the business rules that determine how that event is managed in the project.

 

To create a standard event:

 

1.     Select a work item in the list panel of the specification view

 

2.     Go to theEventstab in the detail panel.

 

3.     Select theNewbutton in the Events tab. TheNew Eventdialog appears.

 

4.     Select an event template from theEvent Templatedrop-down list.

 

5.     Define a unique and descriptive name for the event in theNewtext box.

 

6.     Provide the event details in theDescriptiontext box. Event details may include the event agenda, the event location, or other key information.

 

7.     Select an option from theStatedrop-down list. Each standard event is defined by its event workflow state. An event state represents a specific stage of the life cycle of that event.

 

8.     Select an option from theOwnerdrop-down list to populate the ownership of the event. TheOwnerdrop-down list displays the names of every project member that has been designated as an applicable owner.

 

9.     To define the date, time, and duration of the event, select the date and time of the event in theStart DateandEnd Datecontrols.

 

10. Optional: To define the event attendee list, click the ellipsis button (…) and add attendees to the event in theAdd Attendeedialog box. The standard event attendee list may be used to define which project members are invited to the event by e-mail notification.

 

11. Click the OK button. A general event associated with a work item is successfully created.

 

 

 

To edit a standard event:

 

1. Select an event in theEventtab.

 

2. Click theEditbutton in theEventtab. TheEdit Eventdialog appears.

 

3. Optional: To update the event details, edit the text in theDescriptiontext box. Event details may include the event agenda, the event location, or other key information.

 

4. Optional: To change the status of an event, select an event workflow state in theStatedrop-down list.

 

5. Optional: To assign the event to another project member, select a user name in theOwnerdrop-down list. TheOwnerdrop-down list displays the names of each project member that has been designated as an applicable owner.

 

6. Optional: To update the date, time, and duration of the event, define the event start and end times in theStart DateandEnd Datecontrols.

 

7. Optional: To define the event attendee list, click the ellipsis button (...) and add attendees to the event in theAdd Attendeedialog box. The standard event attendee list may be used to define which project members are invited to the event by e-mail notification.

 

  For information on defining the attendee list, please see the section below,Defining Event Attendee Lists.

 

8. Click the OK button to submit the changes made to the event.

 

 

 

To delete a standard event:

 

1. Select an event in theEventtab.

 

2. Click theDeletebutton in theEventtab. A warning dialog box appears.

 

3. Click the OK button to confirm the action.

 

 

 

8.3.4 Defining Event Attendee Lists

 

An event attendee is a project member that is invited to attend a particular event. Once a project member has been designated as an event attendee, they may be formally invited to the event by e-mail notification.

Project members may add attendees to events whenever they create or edit a standard event in theEventtab of the detail panel.

The standard event attendee list may be used to define the e-mail address list for the meeting request.

To define the event attendee list:

 

1. Submit a new event or select an existing event in theEventtab.

 

2. Click theAttendeebutton in theEdit Eventdialog. TheAdd Attendeesdialog box appears.

 

3. Add or remove project members to the attendee list. To add project members as attendees, select the names of the project members in theAvailable Team memberslist and click the right arrow button. To remove project members as attendees, select the names of the project members in theApplicable Attendeeslist and click the left arrow button.

 

4. Click the OK button.

 

 

 
8.3.5 Tracking Change Flagging Events
 

Change flagging events may be created in support of requirement or specification change management processes. It is identified as a development task that links a requirement change or specification change to one or more DevTrack development issues.
 
Change flagging events are useful in notifying linked development task owners that the original requirement or specification is under change review, and thus the linked development tasks should temporarily be placed on hold until the requirement or specification is reviewed and finalized.
 
Change flagging events may be managed and tracked in the change request view of the DevSpec client.

 

 

The Eventtab displays high-level and detailed information about the events associated with a particularchange request item.

 

Note that there are two radio buttons available for selection at the top of theEventtab:Change EventandSpec Event. Click theChange Eventradio button to display all the events (both the regular events and the change flagging events) associated with the change request item; or click theSpec Eventradio button to display the events (only the regular events) associated with the specification item. 

 

Similar to theEventtab found in the specification view, theEventtabin the change request viewconsists of three main areas:

 

Eventlist: The Event list displays high-level information about events in a tabular format.Use theChange Eventand theSpec Eventradio buttons to switch the display of events.

 

Eventinfo: TheEvent Infotab displays high-level information about an event, including its name, status, owner, start time, end time, and description.

 

Eventchangelog: TheEvent Change Logdisplays a list of all of the changes made to an event from its creation to its closure. It logsthe change that was made, the person who made the change, and the time the change took place.

8.3.6 Managing Change Flagging Events
 

In DevSpec, a change flagging event is a development task that links a requirement change or specification change to one or more DevTrack development issues. The links between the change flagging event and the development issues are managed and tracked as change event flagging subtasks.

 

Using controls in theNew Eventwindow, project team members maycreate a change flagging event, define theevent schedule, invite project team members, and identify change flagging event subtasks.

 

 

To create a change flagging event:

 

1.     Select a requirement or specification change in the list panel of the change request view.

 

2.     Select theEventtabin thedetail panel.

 

3.     Select theChangeEventradiobutton.

 

4.     Select theNew Eventbutton. TheNew Eventdialog appears.

 

5.     Select a change flagging event template in theEvent Templatedropdown list. TheEvent Templatedropdown list displays all event templates (standard event template or change event template) that may be used to create an event for the selected change request.

 

Note: The scope of a change flagging event template may be limited to requirement changes or specification changes, based on administrator-defined rules.

 

6.     Define a unique name for the event in the Name text box and a brief description in the Description text box.

 

7.     Select the event workflow state in theStatedropdown list. Each change flagging event is definedbyits event workflow state. An event state represents a specific stage of the life cycle of that event.

 

8.     Select an option from theOwnerdropdown list. TheOwnerdropdown list displays the names of all project members that have been designated as an applicable owner of thework item.

 

9.     Optional:Toupdate the date, time, and duration of the event, define the event start and end times in theStart DateandEnd Datecontrols.

 

10. Optional: To define the event attendee list, click the ellipsis button (…) and add attendees to the event in theAdd Attendeedialog box. The change flagging event attendee list may be used to define which project members are invited to the event by e-mail notification. For step-by-step instructions, please see the prior section,Defining Event Attendee Lists.

 

11. Select an integrated DevTrack development project and one or more development issues in theCreate Subverts for Linked Tasksarea.

 

12. Click the OK button.

 

Note:Some of the controls mentioned above might not be accessible to users if project administrators set them to be invisible.

 

To edit a change flagging event:

 

1.     Select an event in theEventtab of the change request detail panel.

 

2.     ClicktheEdit Eventbutton in theEventtab. TheEdit Eventdialog appears.

 

3.     Optional: To update the event details, edit the text in theDescriptiontext box. Event details may include the event agenda, the event location, or other key information.

 

4.     Optional: To change the status of an event, select an event workflow state intheStatedropdown list. An event state represents a specific stage of the life cycle of that event.

 

5.     Optional: To assign the event to another project member, select a user name in theOwnerdropdown list.

 

6.     Optional:Toupdate the date, time, and duration of the event, define the event start and end times in theStart DateandEnd Datecontrols.

 

7.     Optional: To define the event attendee list, click the ellipsis(…)button and add attendees to the event in theAdd Attendeedialog box. The attendee list may be used to define which project members are invited to the event by e-mail notification. For step-by-step instructions, please see the prior section,Defining Event Attendee Lists.

 

8.     Click the OK button.

 

To delete a change flagging event:

 

1.     Select a change flagging event in theEventtab of the change request detail panel.

 

2.     Click theDeletebutton in the Event tab. A warning dialog box appears.

 

3.     Click the OK button.

 

8.3.7 Managing Change Flagging Event Subtasks

 

A change flagging event subtask isadevelopment event that links the change made to a requirement or specification to a specific DevTrack development issue. Change flagging event subtask may be independently managed and tracked in the DevSpec and DevTrack clients.

 

All change flagging event subtasks are managed in a workflow consisting of three states: theOpenstate, theClose Successstate, and theCloseFailstate. Using controls in theEdit Linked Task Flaggingdialog, project team members may change the workflow state of change flagging event subtasks and add flagging notes.

 

 

To edit a change flagging event subtask:

 

1.     Select a change flagging event subtask in theevent list of the change request detail panel. Every change flagging event is defined by one or more event subtasks.

 

2.     Click theEditbutton in theEventtab. TheEdit Linked Task Flaggingdialog appears.

 

3.     To change the workflow state of the subtask, select an option in theStatusdropdown list. The lifecycle of change flagging event subtasks is defined by three workflow states:

 

Open
When theOpenstate is selected, the icon (a red flag) will be displayed in front of the subtask.

 

Close Success
When theClose Successstate is selected, theicon (a green flag) will be displayed in front of the subtask.

 

Close Fail
When theClose Failstate is selected, the icon (a yellow flag) will be displayed in front of the subtask.

 

4.     Optional: Toadd a note to this subtask,entersometext in theFlagging Notetext box.

 

5.     Click theOKbutton.

 

8.3.8 Tracking Change Flagging Events in DevTrack

 

8.4 Voting

 

After a change request has been submitted and requirements/specifications are linked, users can view the change request details in the detail panel. The detail panel for a change request consists of two tabs:

  • Change Request Description
  • History Page

TheChange Request Descriptiontab provides users with general information about the selected change request record. It consists of standard fields, such asTitle,Description,StateandOwner. DevSpec Administrators can add more fields to this tab as needed.

 

TheHistory Pageprovides a summary and tracking history of the selected change request record. It consists of multiple sections that can be included or excluded by each user as needed.

 

 

Each change request follows the workflow defined by the DevSpec administrator. A typical change request workflow is shown in the picture below.

 

                  

 

In the diagram above,New Change RequestandPendingare workflow states where a change request remains open.CommittedandDroppedare workflow states where a change request remains closed.

 

All linked requirements and specifications are flagged and rendered read-only as long as the change request item remains open. While in the specification view, users can easily differentiate these linked specifications from other regular, non-linked specifications.

 

 

Note:In the list panel of the specification view, the icon represents a specification linked to a change request item and the icon represents a requirement linked to a change request.

 

For each specification that is currently linked to a change request item, users will see an additional tab in the list panel of the specification view. This tab is labeledChange Description. In this tab users can view the details of the change request.

 

 

8.4.1 Voting


In DevSpec, the approval and scheduling ofwork itemsmay be managed using the votingfeature.Voting is an optional feature in DevSpec thatallows distributed teams to evaluate the impact and need for awork item. Project managers can then collect and track the numerical data submitted by team members to further analyze the pending work item. 

 

Using customized voting grids, project teams may track “votes” from individual project members, as well as the median, mean, and total value of allavailable voting types. 

 

 

A voting type is a custom data field that may be used to track numerical data in a voting grid control. Each column in a voting grid represents an administrator-defined voting type. A voting type is defined by three properties: its title, its field type (integer, decimal, or currency), and its scope–a range of acceptable values.

 

Examples of voting types include:

 

Revenue Impact -Users can contribute to the evaluation of the revenue impact for a proposedwork item. The product design team, stakeholders, and other DevSpec users can enter their estimates of the revenue impact towards the implementation of a suggested feature.

 

Ranking -Each DevSpec user can rank a requirement based on urgency, usefulness, and triviality of aproposed work item. 

 

Point Allocation -Apart from ranking and revenue impact, users can also allocate points to eachwork item.The more points allocated by a member, the more important and urgent he or she thinks this work item is.  

 

Note:Votingis anoptional DevSpec feature that must be enabled in each DevSpec project and requiresthat the project administratorconfigure the voting types, as well ascreate a custom page to manage and track the “votes” submitted bytheteam members.

 

For information on administering voting types, see theDevSuite Admin Guide.

 

 Chapter 9 Reporting
9.1 Managing reports in the report view


DevSpec is a powerful tool in tracking requirements, specifications and change requests. Built-in is a robust and customizable reporting tool to further assist project members in analyzing DevSpec data. Reports can also be used to analyze how items in DevSpec relate to their linked development and QA tasks in other DevSuite components.
 
With this reporting too, project members may:

  • Select from twelve different styles of reports.

  • Define report parameters and data ranges.

  • Dynamically modify reports using quick filters.

  • Print and export reports.

By utilizing the reporting feature, DevSpec users can generate the information they are looking for accurately and efficiently.

9.1.1 Understanding the report view interface
 
A report is an organized presentation of data displayed in either tabular or graphical formats. Reports are managed in the DevSpec report view.
 
To access the report view, click the report view icon in the tool bar. The report view workspace is organized into two panels (the tree panel and the report panel) and three bars (the menu bar, the tool bar, and the report bar).
 
 

 

Tree Panel

 

The tree panelin the report vieworganizes reports into two system-defined project folders:DevSpecandKnowledgeWise. They are placeholders for specification and knowledge related reports, respectively. Reports created under either of the project folders can be categorized as public or private. Reports created under thePublic Reports foldercan be accessed by all users in DevSpec, while those created under thePrivate Reportsfolder can only be accessed by the report author.

 

  

 

 
Report Panel
 
The report panel displays the report data.
 
Menu Bar
 
The menu bar organizes DevSpec commands into five different menus: theFilemenu,Editmenu,Viewmenu,Toolmenu, andHelpmenu.For details about the menu bar, please see Chapter 2,DevSpec Client basics. 

Tool Bar

 

The tool bar displays four filters that enable report viewers to define the scope of a report based on work item property values. Toolbar filters include:

  •  Tree folder filter: define the scope of the report by selecting one or more folders.
  •  Owner filter: filter reports by current owner
  •  State and status filter: filter reports by workflow state or status
  •  Query filter: filter reports by detailed search queries

For more information on filters and queries, please see chapter 4,Searches and Queries.

  

 

Report Bar

 

The report bar displays tools and controls that enable the report creators to customize the display of the report data. The controls displayed in the report bar are report style-specific.

 

Common functionalities include:

 

 First:Go to the first page of the report.

 Previous:Go to the previous page of the report.

 Next:Go to the next page of the report.

 Last:Go to the last page of the report.

  Properties:Define report-specific properties including report title, fields to display and item types.

 Ascending Sort:Display the report list in ascending order.

 Descending Sort:Display the report list in descending order.

 Export Report:Export the report in display to the Excel format.

 

For more information on using the report bar to customize a specific kind of report, please see sections 2 and 3, later in this chapter.

9.1.2 Report Basics
 

This section shows how to create, edit and delete a report or report folder.

 

Adding a report folder

 

Using commands in the tree panel shortcut menu, users may add subfolders within the system-defined root folders to further organize the reports. 

 

To create a report folder:

 

  1. Choose whether the report folder is public or private:

    • To create a public report folder, right-click on the rootPublic Reportfolder and selectNew Folder.

    • To create a private report folder, right-click on the rootPrivate Reportfolder and selectNew Folder.
  1. TheReport Folderdialog box appears. Define the report name and description.

      

 

     3. Click theOKbutton. A new report folder is created.

 

Editing a report folder


To edit an existing report folder, right-click on a report folder in the report tree panel, and selectPropertiesin the shortcut menu. In the newly opened dialog, update the report folder properties, and click theOKbutton to save the changes.

Deleting a report folder

 

  1. Right-click a report folder in the tree panel of the report view.
  1. Select theDeletecommand in the shortcut menu. A confirmation dialog box appears.

     

 

  1. Click theYesbutton to confirm.

Note:Report folders that contain reports cannot be deleted. All reports need to be moved to the root folder or other subfolders before the report folder can be deleted. To move the report(s), simply drag and drop the report(s) in the tree panel.   

 

Adding a report


Using commands in the tree panel shortcut menu, a report author may add requirement, specification, and change request reports.

To create a report:

 

  1. Right-click on a report folder in the report tree panel. The folder selected determines the report type:

    • To create a public report, select a subfolder within the rootPublic Reportfolder.

    • To create a private report, select a subfolder within the rootPrivate Reportfolder.

 

 

 

2. Select a report style in the shortcut menu

 

The shortcut menu displays commands that enable the report author to create and manage report styles that are appropriate to the selected folder. Once the report style is defined, the report properties dialog appears.

 

Note:This dialog is report style-specific. The tools and controls displayed in the report manager depend on the style of report open in the report panel.

 

  1. Define report properties, such as report title, item type, report query or filter, and other report style-specific attributes.

4. Click theOKbutton. The report is displayed in the report panel.

 

Editing a report
To edit an existing report, select a report in the report tree panel and click the properties button in the report bar. Update report properties in the properties dialog.

Deleting a report:

 

  1. Right-click on a report in the tree panel of the report view.

 

  1. Select theDeletecommand in the shortcut menu. A confirmation dialog box appears.

 

 

3. Click theYesbutton to confirm the deletion.

 

Note:Deleting a report is an unrecoverable procedure!

9.2 DevSpec Reports
9.2.1 Specification List Reports

 

The specification list report displays information tracked under the specification view in DevSpec. Any field or attribute related to a specification or requirement can be included in the report.

 

Below is an example of a specification list report:

 

 

Creating a specification list report

 

To create a specification list report:

 

1. Go to theReportview by clicking the button on the tool bar.

 

2. In theTreepanel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder (or any subfolder underneath them). SelectNew Spec Report>List. TheSpecification List Reportdialog appears.

 

 

 

3. In theSpecification List Reportdialog, define the report title, subtitle, and bottom title. Users can also insert pre-defined system fields by clicking theInsert contentbutton. Highlight the fields that are to be added to the subtitle or bottom title, and click theOKbutton.

 

 

4. Define the report columns. Users can click the buttons to add or remove fields between theAvailable FieldsandView Columnslists. Users can also define the column order by using the buttons.

 

5. TheUser, State,andQuerydropdown lists allow the user to filter the report data. These three filters can also be found in the tool bar in the report view.

 

 

6. Users can also define the report as brief or detailed by using theFormat Optiondropdown list. More columns can be included in a detailed report than a brief one.

 

7. Define how the specification list is displayed. Users can customize the report by configuring theGroup By,Sort By,Layout, andSortingoptions.

 

8. ThePage Sizevalue allows users to determine the number of records displayed per page.

 

 

9. Define the report scope. Click theTree Settingsbutton to select a specific branch of the specification folder tree. When a parent folder is selected, all the descendent child folders will be selected automatically.

 

 

10. Define which item types, specifications and/or requirements, are covered in the report. Click the ellipses (…) button to select the item types. Choosing at least one item type in the report is mandatory. If no item type is selected, no data will be returned.

 

 

11. Users can choose to insert a page break after every grouping of records when printing the report. Page breaks can also be inserted based on the number of records. This can be configured by selecting the checkboxes, as shown below:

 

 

12. Click theOKbutton.

 

 

In the screenshot above, a specification list report, calledSpecification List Report--Defect Track 7.0, is created. The list is sorted by specification ID, and is displayed in an ascending order.

 

This report allows project members to view all specifications in theDefect Tracker 7.0folder of theScrum Design Project. Project members are also able to tell from this report when a specification was created, who currently owns it, and what its status is.  

 

Tip:Once a report is created, users can use the filter controls in the report bar to dynamically customize the report. For more information on using these filter controls in the report bar, please see section 1,Report Basics, earlier in this chapter.

9.2.2 Traceability Distribution Report

 

A traceability distribution report shows the relative distribution of a set of linked work items within a population, based on its property values. The traceability distribution report displays the raw data of the report in a tabular list, and a graphical representation of the report data as a pie chart. The traceability distribution report enables project team members to view the distribution of the work items linked to specifications based on their workflow state.

Below is an example of a traceability distribution report:

 

 

Creating a traceability distribution report

 

To create a traceability distribution report:

 

  1. Go to theReportview by clicking the button on the tool bar
  1. In the tree panel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder (or any subfolder underneath them). SelectNewSpec Report>Traceability Distribution.TheSpecificationTraceability Distribution Reportwindow appears.

 

 

 

  1. Define the report title, subtitle, and bottom title. Users can also insert system fields by clicking theInsert contentbutton. Highlight the fields that you would like to add, and click theOKbutton.

 

  1. Select the linked development project associated with this DevSpec project. Select theInclude Developmentcheckbox, and choose the correct DevTrack project from theProjectdropdown list.
  1. The report can be based on all states in the selected DevTrack project, or users can select a set of states to narrow down the report coverage. To include all states in the report, select theAll Statesradio button. To include only a set of states, select theSelected Statesradio button.

 

  1. Go to theLinked QA Testtab to configure the linked DevTest project. Follow steps 4 and 5 to display the DevTest linked issue distribution in the report. Otherwise, uncheck theLinked DevTestcheckbox. 
  1. TheUser, StateandQuerydropdown list fields allow you to filter the data fetched in the report.

 

Note:These three filters can also be found in the tool bar in the report view.

  

  1. Define the report scope. Click theTree Settingsbutton to select a specific branch of the specification folder tree.

 

Note:When a parent folder is selected, all child folders will be selected automatically.

 

  1. Define which item types are covered in the report. Click the ellipses (…) button to select one or more item types.

    

 

Note:Choosing the spec type to report on is mandatory. If no spec type is selected, no data will be returned.

     

   10. Click theOKbutton. 

 

 

 

In the example shown here, a traceability distribution report is generated. Project members can view the total number of specifications, as well as the status breakdown of each linked development item. Percentages are also displayed in the pie chart.

 

Of the 16 specifications in the report, there are 16 linked development issues, with four in QA Testing (25% of the total). From reading the chart, project members can easily get an overall idea on the status of development issues for a specific area of work.

 

Tip:Once a report is created, users can use controls in the report bar to dynamically customize the report. For more information on using controls in the report bar, please see section 1 of this chapter.

9.2.3 Traceability Summary Report

 

A traceability summary report provides a summary of a subset of linked work items in a list report. The traceability summary report displays raw data for linked work items in a tabular list report of rows and columns.

In specification traceability summary reports, selected data for linked work items (specifications, development issues, and test tasks) is displayed in a tabular list report.

 

Below is an example of a traceability distribution report:

 

 

Creating a traceability summary report

 

To create a traceability summary report:


1. Go to theReportview by clicking the button in the tool bar.


2. In theTreepanel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder (or any subfolder underneath them). Select NewSpec Report>Traceability Summary. TheSpecificationTraceability Summary Reportdialog appears.


 

 

3. Define the report title, subtitle, and bottom title. Users can also insert system fields by clicking theInsert contentbutton. Highlight the fields to be added to thesubtitle or bottom title, and click theOKbutton.


 

4. Define which linked items will be shown in the traceability summary report. Go to theSelect Linked Sectiontab and move the desired linked work types (Linked Specification,Linked Development, andLinked QA Test) to theSelected Link Sectionslist on the right.

 

In the example shown below, the report would only show the linked specifications and the linked DevTrack development items associated with the filtered specifications.


  


5. Go to theSpecificationtab and define which properties will be shown for the specifications, as well as each linked work types (linked specification, linked DevTrack issues, and linked DevTest issues). Users can click the buttons to add or remove fields from theAvailable Fieldslist to theView Columnslist, and vice versa. Users can also set the field order by using the buttons.


Use theSpec Typecontrol to define the type(s) of linked items to include in the report.When this field is left blank, the report will display no data.


 

6. TheUser, StateandQuerydropdown lists allow yu to filter the data fetched in the report.

 

 

Note:These three filters can also be found in the tool bar in the report view.

 

7. Define how the specification list is displayed. Users can customize the report by configuring theGroup By, Sort By, LayoutandSortingoptions.

 

8. Define the report scope. Click theTree Settingsbutton to select a specific branch of the specification folder tree.

 

 

Note:When a parent folder is selected, all child folders will be automatically selected.

 

11. When printing the report, users can choose to insert a page break after each grouping of records. Page breaks can also be inserted based on the number of records. This can be configured by selecting the checkboxes, as shown below:

 

 

12. Click theOKbutton.

 

 

Tips:Once a report is created, users can use the controls in the report bar to dynamically customize it. For more information on using controls in the report bar, please see Section 1 of this chapter.

9.2.4 Specification Elapse Time Report

 

Specification elapse time reports show the time that has elapsed between the date a specification was submitted and the date the specification first entered, last entered, or last left a particular workflow state or state status (open or closed).

 

The list report shows detailed information about each specification that has passed through a selected state or state status, including the date and time the specification was submitted, the date and time it entered or left the selected state, and the total elapsed time between these two actions.

 

 

Creating a specification elapse time report


To create a specification elapse time report:


1. Go to theReportview by clicking the button in the tool bar..


2. In theTreepanel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder, and selectNew Spec Report>Elapse Time.

 


 

3. Edit the title, subtitle, and bottom title fields. Users can also insert certain values from the database, by clicking theInsert contentbutton.


 

4. Users can click the buttons to add or remove fields from theAvailable Fieldslist to theView Columnslist, and vice versa. Users can also set the field order by using the buttons.


5. TheUser, StateandQuerydropdown lists allow you to filter the data fetched in the report.

 

 

6. Users can select a field in theGroup Bydropdown list to define the grouping of data in the report.


7. Click theTree Settingsbutton to select a specific branch of the specification folder tree that will be used to fetch the data in the report.

 

 

8. Click the ellipses (...)button to select the type: specification, requirement, or both.

 

 

9. Select the Elapse time to option from the drop down list

 

 

10. Users can also choose between list or summary report in theReport Optiondropdown field.


    • List Report

 

    • Summary Report

 

11. The button at the bottom of the report can be used to change the report properties.


12. The button at the bottom of the report facilitates exporting to an Excel, Word, or CSV format.


13. The button at the bottom of the report can be used to select a specific branch of the specification folder tree that is used to fetch the data in the report.
9.2.5 Close Rate Report

 

In DevSpec, a close rate report shows the number of work items that have been closed within a defined time period.

 

The close rate report shows the total number of work items, the number of work items closed, and the percent of work items closed within a specific time period in a tabular list report and a column chart.

 

 

Close rate report data may be grouped by seven different work item properties. TheGroup Bycontrol defines the x-axis in the column chart. The y-axis represents the number of work items closed within the report time period.

 

Creating a specification close rate report


To create a specification close ratereport:


1. Go to theReportview by clicking the button in the tool bar.

    2. In theTreepanel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder, and selectNew Spec Report>Close Rate.

     

     

    Note:Only users with the required privileges are able to create public reports. All reports created under this folder are accessible by all other DevSpec users. Private reports are only available to the report author. For more information on reports, please see section 1 at the beginning of this chapter.

     

     

    3. Define the report title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.



    4. Users can select a field in theGroup Bydropdown list to define the grouping of data in the report.

     

     

    5. DevSpec administrators can define a specification workflow, so that there are multiple closed states in the specification lifecycle. Users generating reports can choose to include closed specifications in only selected closed states or all closed states.

     

     

    6. Define a date range for the report in theDate Created Rangesection. Only those specifications submitted in this date range will be included in the report.

     

     

    7. TheUser,State,andQuerydropdown lists allow you to filter the data fetched in the report.

     

     

    8. Click theTree Settingsbutton to select a specific branch of the specification folder tree that will be used to fetch the data in the report.

     

     

    9. Click the ellipses (...)button to select the type: specification, requirement, or both.

     

     

    10. The button at the bottom of the report can be used to change the report properties.


    11. The button at the bottom of the report facilitates exporting to an Excel, Word or CSV format.


    12. The button at the bottom of the report can be used to select a specific branch of the specification folder tree that is used to fetch the data in the report.

     

                                                         

     

     

                                       

     

9.2.6 Change Rate Report


In DevSpec, a change rate report shows the number of work items that have changed their workflow state within a defined period of time.

 

 

Change rate report data may be grouped by seven different work item properties. TheGroup Bycontrol defines the x-axis in the column chart. The y-axis represents the number of work items closed within the report time period.

 

Creating a specification change rate report


To create a specification change ratereport:


1. Go to the report view by clicking the button in the tool bar.


2. In the tree panel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder, and selectNew Spec Report>Change Rate.

 

 

Note:Only users with the required privileges are able to create reports in thePublic Reportfolder. Public reports are accessible to all other DevSpec users, while private reports are only available to the report author. For more information, please see section 1, at the beginning of this chapter.

 


3. Define the report title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.


4. Users can select a field in theGroup Bydropdown list to define the grouping of data in the report.

 

 

5. Define the date range. Only those specifications submitted in this date range will be included in the report.

 

 

6. TheUser, StateandQuerydropdown lists allow the user to filter the data fetched in the report.

 

 

7. Click theTree Settingsbutton to select a specific branch of the specification folder tree that will be used to fetch the report data.

 

 

8. Click the ellipses (...)button to select the item type: specification, requirement, or both.

 

 

9. The button at the bottom of the report can be used to change the report properties.


10. The button at the bottom of the report facilitates exporting to an Excel, Word or CSV format.


11. The button at the bottom of the report can be used to select a specific branch of thespecification folder tree that will be used to fetch the report data.

 

                                                     

 

 

                              

9.2.7 Complete Rate Report

 

In DevSpec, a close rate report shows the number of work items that have been completed within a defined period of time.

 

 

Complete rate report data may be grouped by seven different work item properties. TheGroup Bycontrol defines the x-axis in the column chart. The y-axis represents the number of work items completed within the report time period.

 

Creating a specification complete rate report


To create a specification complete ratereport:


1. Go to the report view by clicking the button on the tool bar.


2. In the tree panel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder, and selectNew Spec Report>Complete Rate.

 

 

Note:Only users with the required privileges are able to create reports in thePublic Reportfolder. Public reports are accessible to all DevSpec users, while private reports are only available to the report author. For more information, please see section 1, at the beginning of this chapter.

 

 

3. Define the report title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.

 


4. Users can select a field in theGroup Bydropdown list to define the grouping of data in the report.

 

 

 

5. DevSpec administrators can define a specification workflow so that there are multiple closed states in the specification lifecycle. Users generating reports can choose to include closed specifications in only certain closed states or all closed states.

 

 

6. Define the date range. Only those specifications submitted in this date range will be included in the report.

 

 

7. TheUser, StateandQuerydropdown list fields allow users to filter the data fetched in the report

 

 

8. Click theTree Settingsbutton to select a specific branch of the specification folder tree that will be used to fetch the report data.

 

 

9. Click theellipses (...)button to select the item type: specification, requirement, or both.

 

 

10. The button at the bottom of the report can be used to change the report properties.


11. The button at the bottom of the report facilitates exporting to an Excel, Word or CSV format.


12. The button at the bottom of the report can be used to select a specific branch of the specification folder tree that will be used to fetch the report data.

 

                                                     

 

 

                                   

9.2.8 Burndown Report

 

In DevSpec, the burndown report shows the estimated work remaining to be done within an iterative subproject, or sprint. The amount of work remaining is based on the time estimates made when a specification is linked to an iterative subproject. The burndown compares this time estimate to the time remaining in the iteration (usually 30 days).

 

Burndown reports enable product and project managers to monitor the progress of a product/module development. This report is mostly applicable to agile or iterative development methodologies. Once all specifications in a subproject/iteration are scheduled and linked to a development task, all resources are allocated, and all time lines are assigned, the burndown report will displays a graph with a green line indicating the steady standard progress path from start date to finish date. The time remaining to finish all development tasks is deducted in each interval in the burndown chart.


This chart also displays a graph with a blue line representing the actual progress through each interval from start date to current date. Based on the previous progress pace, the chart then plots a graph with a dotted blue line to predict the future progress pace leading to the end of the project, indicating the projected finish date. This projected finish date may fall behind or ahead of the planned finish date. Based on this information and other supporting data, managers can compare the planned progress path against the actual progress path and take appropriate measures to adjust the project plan so that the deadline is met.


An example of a burndown report is depicted below.

 

 

The DevSpec burndown report is divided into three primary sections:

  • The specification list report

  • The task list report

  • The burndown chart

The specification list report

The specification list report shows the ID number, title, current status, implementation module, link date, and close date for every specification linked to the selected iterative subproject.

 

The task list report

The task list report shows the ID number, title, owner, and current status for every development issue managed within the iterative subproject.

 

The burndown chart

The burndown chart is a graphical representatiaon of the work that needs to be done in an iterative subproject, or sprint, over time.

 

In the burndown report the y-axis represents the backlog - the estimated number of hours required to implement a set of specification designs. The x-axis represents development time-the time between the date the specification was initially linked to the development task until the end of the sprint.

 

If multiple iterative subprojects are selected, distinct burndown charts, specification lists, and task lists are displayed for each subproject selected in the subproject tree.

 

Report authors may choose to display the task burndown, specification burndown, or both the task burndown and the specification burndown. Specifications are represents by a solid green line; development issues by a solid blue line.


Creating a burndown list report


To create a burndown list report:


1. Go to the report view by clicking the button in the tool bar.


2. In the tree panel, under the DevSpec folder, right-click onPrivate ReportorPublic Reportfolder and selectNew Spec Report>Burn Down For Sprint SubProject.
 

 
 
Note:Only users with the required privileges are able to create reports in thePublic Reportfolder. Public reports are accessible to all other DevSpec users, while private reports are only available to the report author. For more information, please see section 1, at the beginning of this chapter.
 

 
3. Define the report title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.
 

 
4. Users can choose a report type option.
 

 
5. Users can also choose theDisplay Optionto specify which type of data will be included in the burndown report.
 

 
6. Users can check theDisplay Item Listcheck box to include the specification list and linked DevTrack development tasks.
 

 
7. User can set the number of burndown rate points.
 

 
Time Unit:The x-axis of the burndown chart represents the duration of the iterative subproject, or sprint, from the time that the specificaiton was assigned to the iterative subproject to the end date. Using controls in the report manager, report authors may define the time intervals used in the report.
 
    Daily,   Weekly,    Bi-Weekly,   Monthly,   Semi-Yearly,   Yearly
 

 
8. Click theTree Settingsbutton to select a specific branch of the DevTrack subproject tree that will be used to fetch the report data.
 

 
9. ClickOKbutton
 



10. The button at the bottom of the report facilitates exporting to an Excel, Word or CSV format.


11. The button at the bottom of the report can be used to change the report properties.


12. The button at the bottom of the report can be used to select a specific branch of the DevTrack subproject tree that will be used to fetch the report data.
9.2.9 Feature Completion Report

 

The DevSpec feature completion reports show the implementation of specifications, within an iteration.

 

In the velocity chart the y-axis represents the backlog-the estimated number of hours required to implement a set of specification designs. The x-axis represents the development time-the time between the date the specification was initially linked to the development task until the end of the sprint.

 

If multiple iterative subprojects are selected, distinct burndown charts, specification lists, and task lists are displayed for each subproject selected in the subproject tree.

 

Creating a feature completion report


To create a feature completionreport:


1. Go to the report view by clicking the button in the tool bar.


2. In the tree panel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder, and selectNew Spec Report>Feature Completion.
 

 
Note:Only users with the required privileges are able to create reports in thePublic Reportfolder. Public reports are accessible to all other DevSpec users, while private reports are only available to the report author. For more information, please see section 1, at the beginning of this chapter.
 

 
3. Define the report title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.
 

 
Time Unit:The x-axis of the burndown chart represents the duration of the iterative subproject, or sprint, from the time the specification was assigned to the iterative subporject to the end date. Using controls in the report manager, report authors may define the time intervals used in the report.
 
    Daily,   Weekly,    Bi-Weekly,   Monthly,   Semi-Yearly,   Yearly
 

 

4. The button at the bottom of the report can be used to change the report properties.


5. The button at the bottom of the report facilitates exporting to an Excel, Word or CSV format.


6. The button at the bottom of the report can be used to select a specific branch of the specification folder tree that will be used to fetch the report data.
9.2.10 Velocity Report


The term velocity is used in agile development to indicate the amount of work a team can handle in one iteration. The DevSpec velocity report shows the implementation of specifications, within an iteration.

 

In the velocity chart the y-axis represents the backlog-the estimated number of hours required to implement a set of specification designs. The x-axis represents development time-the time between the date that the specification was initially linked to the development task until the end of the sprint.

 

If multiple iterative subprojects are selected, distinct burndown charts, specification lists, and task lists are displayed for each subproject selected in the subproject tree.

 

Creating a velocity report


To create a velocityreport:


1. Go to the report view by clicking the button in the tool bar.


2. In the treepanel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder, and selectNew Spec Report>Velocity.
 

 
Note:Only users with the required privileges are able to create reports in thePublic Reportfolder. Public reports are accessible to all DevSpec users, while private reports are only available to the report author. For more information, please see section 1, at the beginning of this chapter.
 

 
3. Define the report title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.
 

 
Time Unit:The x-axis of the burndown chart represents the duration of the iterative subproject (sprint)-from the time the specification was assigned to the iterative subproject to the end date. Using controls in the report manager, report authors may define the time intervals used in the report.
 
    Daily,   Weekly,    Bi-Weekly,   Monthly,   Semi-Yearly,   Yearly
 

 

4. The button at the bottom of the report can be used to change the report properties.


5. The button at the bottom of the report facilitates exporting to an Excel, Word or CSV format.


6. The button at the bottom of the report can be used to select a specific branch of the specification folder tree that will be used to fetch the report data.
9.2.11 Velocity Across Sprints Report

 

The term velocity is used in agile development to indicate the amount of work a team can handle in one iteration. The DevSpec velocity report across sprints report shows the implementation of specifications, within multiple iterations.

 

In a velocity across sprints report, the y-axis in the chart represents the backlog-the estimated number of hours required to implement a set of specification designs. The x-axis represents development time-the time between the date each specification was initially linked to a development task until the end of the sprints.

 

Creating a velocity across sprint report


To create a velocity across sprintreport:


1. Go to the report view by clicking the button in the tool bar.


2. In the tree panel, under the DevSpec folder, right-click on thePrivate ReportorPublic Reportfolder, and selectNew Spec Report>Velocity Across Sprints.
 

 
Note:Only users with the required privileges are able to create reports in thePublic Reportfolder. Public reports are accessible to all other DevSpec users, while private reports are only available to the report author. For more information, please see section 1, at the beginning of this chapter.
 

 
3. Define the report title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.
 

 
Time Unit:The x-axis of the burndown chart represents the duration of the iterative subproject (sprint)-from the time that the specification was assigned to the iterative subproject to the end date. Using controls in the report manager, report authors may define the time intervals used in the report.
 
    Daily,   Weekly,    Bi-Weekly,   Monthly,   Semi-Yearly,   Yearly
 

 

4. The button at the bottom of the report can be used to change the report properties.


5. The button at the bottom of the report facilitates exporting to an Excel, Word or CSV format.


6. The button at the bottom of the report can be used to select a specific branch of the specification folder tree that will be used to fetch the report data.
9.2.12 Change Request List Report

 

The change request list report displays information tracked under the change request view in DevSpec. Any field or attribute used to manage a change request can be included in thisreport.

 

 

Creating a change request list report


To create a change request list report:


1. Go to the report view by clicking the button in the tool bar.


2. In the tree panel, under the DevSpec folder, right-click the onPrivate ReportorPublic Reportfolder, and selectNewChange Request Report>List.
 

 

 

3. Define the project title, subtitle, and bottom title. Users can also insert certain values from the database, by clicking theInsert contentbutton.



 

4. Users can click the buttons to add or remove fields from theAvailable Fieldslist to theView Columnslist, and vice versa. Users can also set the field order by using the buttons.


5. TheUser, StateandQuerydropdown lists allow users to filter the data fetched in the report.
 

 
6. Users can also define the report to be brief or detailed under theFormat Optioncontrol. A detailed report allows inclusion of more fields than the brief report does.
 

 

7. Users can further customize the report by configuring theGroup By, Sort By, LayoutandSortoptions.


8. ThePage Sizevalue allows users to restrict the number of records displayed per page.


9. Click theTree Settingsbutton to select a specific branch of the change request folder tree that will be used to fetch the report data.
 

 
10. Users can choose to insert a page break after every grouping of records when printing the report. Page breaks can also be inserted based on the number of records. This can be configured by selecting the check boxes, as shown below:
 

 

11. Click theOKbutton.




Tip:Once a report is created, users can use the filter controls in the report bar to dynamically customize the report. For more information on using these filter controls in the report bar, please see section 1,Report Basics, earlier in this chapter.
9.3 KnowledgeWise Reports
9.3.1 Knowledge List Reports

 

KnowledgeWise reports can be accessed in the DevSpec report view.We currently support one report style for Knowledge items--the knowledge list report.

 Chapter 10 Knowledge Management
10.1 Knowledge Management in DevSpec

 

In the knowledge view users can organize knowledge gathered from a wide variety of sources. Knowledge may include enhancement requests from customers, feature requests from product marketing, design improvements from the development team, or even new product ideas from any employee within the company. This collection of knowledge/ideas is the genesis of the final delivered product.

 

In DevSpec, knowledge items may be entered in different forms: e.g. documents, images, HTML links, and other digital assets. Some knowledge items will be discarded, many will be consolidated and improved, and others will be accepted as is. Knowledge items are completely tracked through workflow.

 

Knowledge is not unique just to the current DevSpec project. Multiple DevSpec projects can be managed under a parent KnowledgeWise project. Thus, users may see the same knowledge folders and items when viewing different projects.

10.2 Knowledge Folder Tree

 

In DevSpec, all knowledge items are well organized via the knowledge folder tree. Users can create knowledge categories and sub-categories in the knowledge folder tree panel (top left).

 

 

Creating a New Folder

 

To create a new folder in the knowledge folder tree, right-click on an existing folder, where the new folder is to be created, and selectNew Folder.

 

 

  • SelectNew child folderto create a subfolder underneath the current folder.
  • SelectNew sibling folder aboveto create a folder in the same level but above the current folder.
  • SelectNew sibling folder belowto create a folder in the same level but below the current folder.

* Please see theFolder Propertiessection for more information on defining folder properties.

 

Editing a Folder

 

To edit the properties of an existing folder in the knowledge folder tree, right-click on an existing folder, and selectProperties.

 

 

* Please see theFolder Propertiessection for more information on defining folder properties.

 

Copying/Moving Folders

 

Users can create an identical set of folders and its knowledge items to another folder from the current selected folder.

 

1. Right-click on a folder and selectCopy.

2. Right-click on a destination folder and selectPaste.

 

Users can also choose to move a folder and its contents to a different directory.

 

1. Right-click on a folder and selectCut.

2. Right-click on a destination folder and selectPaste.

 

 

Deleting a Folder

 

For a folder to be deleted, it must be empty (i.e. not containing any knowledge items), and must not be currently used by a project. To delete a folder in the knowledge folder tree, right-click on an existing folder, and selectDelete.

 

10.2.1 Knowledge Folder Properties

 

To access folder properties, right-click on the folder and selectProperties.

 

 

Folder Description

 

This section allows users to accurately describe the details of a folder.

 

1. Provide an accurate folder name so that work items can be easily filtered.

2. Provide a folder status to indicate whether or not this folder should still be in use.

3. Provide an importance value.

4. Provide a description.

 

*Administrators can add custom fields and pages to track additional details.

 

 

Access Control

 

This section allows users with sufficient privileges to secure the contents within a knowledge folder and the folder itself.

 

Users can select 1 out of 3 different folder access types. All folder access types are split into two panes. This allows the manager to view the permissions defined by the administrator for folders and knowledge items within the folders.

 

Public Folder:

A set of account types defined in the Admin.

    • No Access: users will not be able to see existing folder/knowledge items

    • Read-Only: users cannot update existing folder/ knowledge items

    • Can Edit: users can only update existing folder/ knowledge items

    • Can Create and Edit: users can submit new folder/ knowledge items

    • Can Delete, Create and Edit: users can submit new folder/ knowledge items as well as delete existing items

Private Folder:

A second set of privileges defined in the Admin.

    • No Access: users will not be able to see existing folder/ knowledge items

    • Read-Only : users cannot update existing folder/ knowledge items

    • Can Edit : users can only update existing folder/ knowledge items

    • Can Create and Edit : users can submit new folder/ knowledge items

    • Can Delete, Create and Edit: users can submit new folder/ knowledge items as well as delete existing items

Secured Folder:

This folder access type is used if the public/private folder access types are not sufficient. Administrators can define different sets of custom access levels for account types and team groups that can be applied to any folder. This is beneficial if privileges may need to be changed later.

 

To view privileges for each access type, clickview access type.

 

In addition, individual users can also be added as an exception to the account type and team group privileges defined in the access level:

1.     To add a user, clickAdd User, select the user(s), and give applicable privileges.

2.     To remove user(s) from the access level, clickRemove User.

 

*Check offsame as parentto inherit the access control from the parent folder

 

 

Applicable Owner

 

This section allows managers to define account types, groups and individuals that can own a knowledge item in the folder. Users that do not belong in the account types or groups defined here cannot be selected as a knowledge item owner, even though the workflow permits them.

 

SelectAll Applicableto quickly allow all DevSpec users to be able to own knowledge items if the workflow permits them.

 

SelectDefine Applicableto define specific account types, groups and users to be able to own knowledge items if the workflow permits them.

 

*Check offsame as parentto inherit the access control from the parent folder

 

 

Applicable Product

 

Knowledge items can be defined by the product/version property-a subset of products, versions, and builds applicable to a knowledge item. In this section, users can set the default value of the product/version property for any item created in the current knowledge item folder. Setting this folder property on an existing folder will not change the product/version property values of any existing knowledge items.

 

SelectAny Product/Versionto quickly select all products, versions, and builds as the default value of the product/version property for new knowledge items created in the current folder.

 

SelectDefine Applicableto define specific products, versions, and builds as the default value of the product/version property for new knowledge items created in the current folder.

 

* Check offsame as parentto inherit the access control from the parent folder

 

 

Folder Order

 

This section allows managers to be able to sort the subfolders underneath the selected folder.

 

Click the up button to move a subfolder higher in the tree.

Click the down button to move a subfolder lower in the tree.

 

10.3 Knowledge Items

 

To access folder properties, right-click on the folder and selectProperties.

 

 

Folder Description

 

This section allows users to accurately describe the details of a folder.

 

1. Provide an accurate folder name so that work items can be easily filtered.

2. Provide a folder status to indicate whether or not this folder should still be in use.

3. Provide an importance value.

4. Provide a description.

 

*Administrators can add custom fields and pages to track additional details.

 

 

Access Control

 

This section allows users with sufficient privileges to secure the contents within a knowledge folder and the folder itself.

 

Users can select 1 out of 3 different folder access types. All folder access types are split into two panes. This allows the manager to view the permissions defined by the administrator for folders and knowledge items within the folders.

 

Public Folder:

A set of account types defined in the Admin.

    • No Access: users will not be able to see existing folder/knowledge items

    • Read-Only: users cannot update existing folder/ knowledge items

    • Can Edit: users can only update existing folder/ knowledge items

    • Can Create and Edit: users can submit new folder/ knowledge items

    • Can Delete, Create and Edit: users can submit new folder/ knowledge items as well as delete existing items

Private Folder:

A second set of privileges defined in the Admin.

    • No Access: users will not be able to see existing folder/ knowledge items

    • Read-Only : users cannot update existing folder/ knowledge items

    • Can Edit : users can only update existing folder/ knowledge items

    • Can Create and Edit : users can submit new folder/ knowledge items

    • Can Delete, Create and Edit: users can submit new folder/ knowledge items as well as delete existing items

Secured Folder:

This folder access type is used if the public/private folder access types are not sufficient. Administrators can define different sets of custom access levels for account types and team groups that can be applied to any folder. This is beneficial if privileges may need to be changed later.

 

To view privileges for each access type, clickview access type.

 

In addition, individual users can also be added as an exception to the account type and team group privileges defined in the access level:

1.     To add a user, clickAdd User, select the user(s), and give applicable privileges.

2.     To remove user(s) from the access level, clickRemove User.

 

*Check offsame as parentto inherit the access control from the parent folder

 

 

Applicable Owner

 

This section allows managers to define account types, groups and individuals that can own a knowledge item in the folder. Users that do not belong in the account types or groups defined here cannot be selected as a knowledge item owner, even though the workflow permits them.

 

SelectAll Applicableto quickly allow all DevSpec users to be able to own knowledge items if the workflow permits them.

 

SelectDefine Applicableto define specific account types, groups and users to be able to own knowledge items if the workflow permits them.

 

*Check offsame as parentto inherit the access control from the parent folder

 

 

Applicable Product

 

Knowledge items can be defined by the product/version property-a subset of products, versions, and builds applicable to a knowledge item. In this section, users can set the default value of the product/version property for any item created in the current knowledge item folder. Setting this folder property on an existing folder will not change the product/version property values of any existing knowledge items.

 

SelectAny Product/Versionto quickly select all products, versions, and builds as the default value of the product/version property for new knowledge items created in the current folder.

 

SelectDefine Applicableto define specific products, versions, and builds as the default value of the product/version property for new knowledge items created in the current folder.

 

* Check offsame as parentto inherit the access control from the parent folder

 

 

Folder Order

 

This section allows managers to be able to sort the subfolders underneath the selected folder.

 

Click the up button to move a subfolder higher in the tree.

Click the down button to move a subfolder lower in the tree.

 

10.3.1 Submitting a New Knowledge Item

 

To submit a new knowledge item:

 

1. Open the submission dialog by one of the following commands:

 

  • Click on theSubmit new Knowledgebutton in the tool bar

 

 

  • Right-click in the list panel and selectNew...

 

 

  • SelectFile>Submit New...in the menu bar


 

  • Press Ctrl + N

* To auto-populate the value of the folder field in the submission dialog, click on a folder in the knowledge item folder tree prior to performing any of the above actions.

 

2. Optional: Select a knowledge item template. For more information, please see the section,Creating a Template, later in this section.

 

3. In the submission dialog, define the knowledge item properties. For more detailed information on knowledge item properties, please see the section,Knowledge Properties, later in this chapter.

 

4.To close the dialog upon submission, check theClose submission dialog after a Knowledge is submittedcheckbox. To keep the dialog open to submit another new knowledge item, leave the box unchecked.

 

5. Click theOKbutton.

10.3.2 Forwarding a Knowledge Item

 

Forwarding is primarily done to change the owner of a knowledge item, but can also be used to change the state of the knowledge item, as well. To forward a knowledge item:

 

1. Open the forward dialog by one of the follow commands:

 

  • Highlight a knowledge item in the list panel and press theForward Knowledgebutton in the tool bar

 

 

  • Right-click a knowledge item in the list panel and clickForward...

 

 

  • Highlight a knowledge item in the list panel and from the menu bar, selectFile>Forward...

 

 

  • Highlight a knowledge item in the list panel and press Ctrl + F
  • Highlight a knowledge item in the list panel and go to theKnowledge Descriptiontab in the detail panel (no window opens, but rather the knowledge item is forwarded directly from the detail panel)

 

 

2. In the forward dialog, define the new knowledge item owner, to whom the knowledge item will be forwarded.

 

3. Make any other necessary changes to the knowledge item properties. For more detailed information on knowledge item properties, please see the section,Knowledge Properties, later in this chapter.

 

4. Click theOKbutton to forward the knowledge item to the next owner and/or next state.

10.3.3 Editing a Knowledge Item

 

To edit a knowledge item:

 

1. Open the edit dialog by one of the following commands:

 

  • Highlight a knowledge item in the list panel and press theEdit Knowledgebutton in the tool bar

 

 

  • Right-click a knowledge item in the list panel and clickEdit...

 

 

  • Highlight a knowledge item in the list panel and click theKnowledgeDescriptiontab in the detail panel (no window opens, but rather the knowledge item is forwarded directly from the detail panel)

 

 

2. Make the desired changes to the knowledge item properties. For more detailed information on knowledge item properties, please see the section,Knowledge Properties, later in this chapter.

 

3. Click theOKbutton to save the knowledge item changes.

10.3.4 Deleting a Knowledge Item

 

Warning: Deleting a knowledge item is a non-reversible action!

 

To delete a knowledge item:

 

1. Do one of the following delete commands:

 

  • Right-click on a knowledge item in the list view and clickDelete...

 

 

  • Highlight a knowledge item in the list view and from the menu bar, selectFile>Delete…

 

 

2. In the confirmation dialog, click theOKbutton.

10.3.5 Knowledge Properties

 

This section covers the different properties that can be defined when creating, forwarding, or editing a knowledge item. More properties than those just mentioned here may be used to define knowledge items, when set up by the DevSpec administrator.

 

 

Title

Title of the knowledge item. Cannot be left blank, and must be unique.

 

Status

Status of the knowledge item represents the current workflow state.

 

Owner

Owner of the knowledge item.

 

Description

Description of the knowledge item.

 

File Attachment

The original knowledge file can be attached to a knowledge item, and then later downloaded by other users. For more detailed information on managing file attachments, please see section 5,Knowledge Item Attachments, later in this chapter.

 

Folder

Folder of the knowledge item folder tree, under which the knowledge item will be saved.

10.3.6 Creating a Knowledge Template

 

A template is a predefined collection of definitions that may be used to submit a new knowledge item, quickly and easily. To create a new template:

 

1. Right-click in the folder tree panel and clickView Template.

 

 

2. Click on the newly appearedTemplate Root.

 

 

3. Create a new knowledge item template just as if an actual knowledge item were being created (please see the previous section,Submitting a New Knowledge Item). A template is not actually a knowledge item, although it may appear so in the list panel.

10.4 Linking Knowledge Items

 

In DevSpec, just as with specifications, knowledge items are completely tracked through a workflow, which defines how knowledge items are created, managed, and tracked.

 

An administrator-defined workflow determines the sequence of workflow states-how and when a knowledge item may pass from one workflow state to the next. Each state is also privileged controlled-who may submit, forward, edit, or delete a knowledge item at each stage of its lifecycle.

 

The follow diagram is a possible workflow. A knowledge item workflow is typically simpler than a specification workflow. After a new knowledge item is created, it will start in theDraftstate. Then it will move on to theIn Designstate (via theNeed Designtransition), and finally to theFinalizedstate (via theFinalizedtransition).

 

10.5 Knowledge Item Attachments

 

To submit a new knowledge item:

 

1. Open the submission dialog by one of the following commands:

 

  • Click on theSubmit new Knowledgebutton in the tool bar

 

 

  • Right-click in the list panel and selectNew...

 

 

  • SelectFile>Submit New...in the menu bar


 

  • Press Ctrl + N

* To auto-populate the value of the folder field in the submission dialog, click on a folder in the knowledge item folder tree prior to performing any of the above actions.

 

2. Optional: Select a knowledge item template. For more information, please see the section,Creating a Template, later in this section.

 

3. In the submission dialog, define the knowledge item properties. For more detailed information on knowledge item properties, please see the section,Knowledge Properties, later in this chapter.

 

4.To close the dialog upon submission, check theClose submission dialog after a Knowledge is submittedcheckbox. To keep the dialog open to submit another new knowledge item, leave the box unchecked.

 

5. Click theOKbutton.

10.5.1 Attaching a File

 

To attach a file to a knowledge item, in theFile Attachmentsection, click theSelectbutton. In the newly openedChoose Attachment Typedialog, the user can then choose a file from three possible sources:

 

 

Attaching a file from a template:

 

Users can attach a file from a knowledge item template. Since the file only needs to be duplicated within the document server, no upload time is needed, and the file is quickly attached. Select theAttach a file from a templateradio button, and click theOKbutton to open theTemplate Selectiondialog. Choose a template with an attachment, and click theOKbutton.

 

 

In the newly openedAttach Filedialog, define the file name in theSaved asfield, and click theOKbutton. A copy will be saved to the document server.

 

 

Attaching a new file:

 

Users can attach a file from their local computer. Select theAttach a new fileradio button, and click theOKbutton to open theOpendialog. Navigate to find the file on the local computer, and click theOpenbutton.

 

 

In the newly openedAttach Filedialog, define the file name in theSaved asfield, and click theOKbutton. A copy will be saved to the document server.

 

 

Attaching an HTML path:

 

Users can save a URL to link to a file on a different server, such as a local-area network or the internet. The file itself is not saved on the DevSpec document server, rather the URL serves as a reference to the file. Select theAttach an HTML pathradio button, enter the URL, andclick theOKbutton.

 

 

10.5.2 Downloading and Opening a File

 

Once a file has been attached to a knowledge item, it can be downloaded to and/or opened on the user’s local machine. To download and/or open an attached file:

 

1. In theFile Attachmentsection, click theOpenbutton.

 

 

2. TheOpen Filedialog opens.

 

 

  • ThePathcontrol displays where the file will be saved on the user’s local machine. Click theSave Asbutton to choose a new directory and/or file name. To define a default path, please see chapter 2, section 3,User Preferences.
  • Check theGet a copy of this document from document servercheckbox to download the file from the document server. After the first time a file has been downloaded, unless this checkbox is checked, the file on the local computer will be opened.
  • Check theOpen this file nowto open the file after the download is complete.

3. Click theOpenbutton to download and/or open the file, OR click theOpen with...button to choose a program, with which the file will be opened.

 

4. Press F5 to update the file information in theFile Attachmentsection.

 

 

The file attachment information in the screenshot above states that the current user has downloaded the first version of their local copy, and is modifying it (i.e. the file is opened on the current user’s computer).

10.5.3 Checking Out and Locking a File

 

After a user downloads a file, they may wish to make some changes and then update the attachment with their modified file. A user making any changes to a file can “check out” and “lock” a file from being modified by other users. This prevents other users’ changes in the meanwhile from being overridden.

 

To check out and lock a file simply denotes which user has the control to modify the server file (other users can still download the latest file in the meanwhile). Unless given the required privileges, users cannot check out a file until it has been unlocked by the user who originally checked it out.

 

* Checking out and locking are events that always happen together (i.e. when a user checks out a file, it is automatically locked as well, and vise versa).

 

 

The above screenshot is an example when a file is checked out. The file was originally attached by James Robinson, and is currently checked out by Terry Johnson.

 

To check out a file:

 

1. In theFile Attachmentsection, click theCheck Outbutton, OR theLockbutton.

 

 

2. A new dialog opens (similar to the dialog when downloading and/or opening a file).

 

 

  • TheLock this filecheckbox must be checked. If not, the file will not be checked out and locked, rather only downloaded.
  • Click theHistorybutton for more information on the file’s modification history.
  • Check theGet a copy of this document from document servercheckbox to download the file from the document server. After the first time a file has been downloaded, unless this checkbox is checked, the file on the local computer will be opened.
  • Check theOpen this file nowto open the file after the download is complete.

3. Click theOpenbutton to download and/or open the file, OR click theOpen with...button to choose a program, with which the file will be opened. The file will be checked out and locked.

 

4. Press F5 to update the file information in theFile Attachmentsection.

 

 

Note: The user, to whom the file is checked out, is different from the owner of the corresponding knowledge item.

10.5.4 Checking In and Unlocking a File

 

After a user downloads a file, they may wish to make some changes and then update the attachment with their modified file. A user making any changes to a file can “check out” and “lock” a file from being modified by other users. This prevents other users’ changes in the meanwhile from being overridden.

 

To check out and lock a file simply denotes which user has the control to modify the server file (other users can still download the latest file in the meanwhile). Unless given the required privileges, users cannot check out a file until it has been unlocked by the user who originally checked it out.

 

* Checking out and locking are events that always happen together (i.e. when a user checks out a file, it is automatically locked as well, and vise versa).

 

 

The above screenshot is an example when a file is checked out. The file was originally attached by James Robinson, and is currently checked out by Terry Johnson.

 

To check out a file:

 

1. In theFile Attachmentsection, click theCheck Outbutton, OR theLockbutton.

 

 

2. A new dialog opens (similar to the dialog when downloading and/or opening a file).

 

 

  • TheLock this filecheckbox must be checked. If not, the file will not be checked out and locked, rather only downloaded.
  • Click theHistorybutton for more information on the file’s modification history.
  • Check theGet a copy of this document from document servercheckbox to download the file from the document server. After the first time a file has been downloaded, unless this checkbox is checked, the file on the local computer will be opened.
  • Check theOpen this file nowto open the file after the download is complete.

3. Click theOpenbutton to download and/or open the file, OR click theOpen with...button to choose a program, with which the file will be opened. The file will be checked out and locked.

 

4. Press F5 to update the file information in theFile Attachmentsection.

 

 

Note: The user, to whom the file is checked out, is different from the owner of the corresponding knowledge item.