What is AppLife DNA?

Welcome to AppLife DNA! AppLife DNA is a software application that can significantly improve your software specification quality by turning the tasks of requirements management and specification authoring into a continuous process that starts with capturing the first ideas of a software application and continues throughout the life of the application.

AppLife DNA transforms your software specification activities into an effort that mirrors the natural iterative process of software creation and continuous improvement, which helps you create better, higher quality software.

Visit http://www.kineticjump.com for information on AppLife products
Send comments on this topic to AppLifeDna@KineticJump.com
© Kinetic Jump Software, LLC
AppLife is a registered trademark of Kinetic Jump Software, LLC


Why use AppLife DNA?

Software teams that stress the importance of defining specifications that thoroughly explain thoughtfully analyzed requirements build better software. AppLife DNA is a tool that helps you accomplish this by synchronizing the natural iterative process of software development with your specification authoring work.

Using AppLife DNA, your software specifications is the result of a repeatable process instead of the goal of a task. With AppLife DNA you endeavor to manage and define the requirements of your software. By focusing your specification efforts on requirements, you produce specifications that address the needs of your users.

Specifications documents are all too often written, reviewed, distributed and shelved. They are not maintained as the development and use of the application inevitably dictates change. Software teams that let their specifications go stale end up with many undocumented, unwanted, and expensive features as decisions are made by the wrong people and without review. This often results when specifications are considered a task and not a process.

Another equally troubling result of document-centric specification work is too many documents. Each iteration results in a new document and before long your application specifications become fragmented and lost to chaos.

Adopting AppLife DNA into your requirements management and specification authoring process supports and encourages continuously evolving specifications, while maintaining the ability to clearly communicate changes to your application domain experts and your development team.


System Requirements

AppLife DNA recommended client system requirements:

· Windows XP (32 bit or 64 bit) / Windows Vista (32 bit or 64 bit)

· 1.0 GHz CPU or faster

· 1 GB RAM or greater

· 1024 X 768 high color display

· Up to 500 MB hard disk space may be required.


License Agreement

KINETIC JUMP SOFTWARE, LLC.

END USER SOFTWARE LICENSE AGREEMENT

IMPORTANT – PLEASE READ CAREFULLY BEFORE DOWNLOADING, INSTALLING OR USING ANY PART OF THIS INTERACTIVE SOFTWARE PRODUCT. THIS IS A LEGAL DOCUMENT THAT STATES THE TERMS AND CONDITIONS THAT GOVERN YOUR USE OF THE PRODUCT. BY DOWNLOADING, INSTALLING OR USING THIS SOFTWARE, OR BY USING ANY PART OF IT, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS AGREEMENT, UNDERSTAND IT AND AGREE TO BE LEGALLY BOUND BY ITS TERMS.

Kinetic Jump Software, LLC will license this product to you, the licensee (“you” or “Licensee”) only if you accept all of the terms of this end user software license agreement (this “Agreement”). Kinetic Jump Software, LLC provides its software and licenses its use either directly or through authorized dealers. You assume responsibility for the selection of software to achieve your intended results, and for the installation, use and results obtained from the software.

1. Grant of License. Subject to the terms of this Agreement, Kinetic Jump Software, LLC hereby grants to you a non-exclusive and non-transferable license (without any right to sublicense), the software program in machine-readable object code form contained in the media (the “Program”), (ii) the associated written documentation provided by Kinetic Jump Software, LLC (the “Documentation”), and (iii) any updates, revisions or upgrades of the Program or the Documentation provided to you by Kinetic Jump Software, LLC or its authorized reseller (each an “Update”) (the Program, the Documentation and any Update collectively the “Product”). If you receive replacement or backup media containing the Program, you may only use it to in fact replace the primary media and may not transfer the original media to any other individual or computer. All rights not expressly granted to you herein are hereby reserved by Kinetic Jump Software, LLC.

2. Scope of Use. You may install the Product on one computer for individual use, so long as a licensed user is using the software. In addition, you shall not, nor permit any party to: (i) sell, lease, sublicense, distribute, or otherwise transfer the Product to any person, firm, or entity; or (ii) copy, modify, adapt, translate, decompile, disassemble create or attempt to create, by reverse engineering or otherwise, the source code from any object code supplied hereunder, except you may make one copy of the Program in object code form as supplied, solely for backup or archival purposes. Portions of the Product may not be used independently of the Product. Single Users: Notwithstanding the foregoing, if you have purchased a single-user License, the Product may not be used concurrently on more than one computer or processor unless you purchase additional licenses for each additional concurrent use.

3. Ownership. This is a license agreement and NOT an agreement for sale. All worldwide Intellectual Property Rights that are embodied in or related to the Product are, and at all times shall remain, the sole and exclusive property of Kinetic Jump Software, LLC, whether or not specifically recognized or protected under local laws. For purposes of this Agreement, the term “Intellectual Property Rights” means, collectively, rights under patent, trademark, copyright and trade secret laws, and any other intellectual property or proprietary rights recognized in any country or jurisdiction worldwide, including, without limitation, moral rights and similar rights. You may not delete, alter, cover, or distort any copyright, trademark, or other proprietary rights notice placed by Kinetic Jump Software, LLC on or in the Product.

4. Limited Warranty, Remedies and Disclaimer of Warranty. Kinetic Jump Software, LLC warrants that the media containing the Product shall be free from defects in materials and workmanship under normal use and service for a period of ninety (90) days from the date of shipment to you (the “Warranty Period”). If a defect in such media appears during the Warranty Period, your sole and exclusive remedy and Kinetic Jump Software, LLC’s sole liability under this warranty is the replacement of defective media. To receive a replacement for defective media, you must return the defective media during the Warranty Period to the place of purchase. Except for the foregoing express warranty, the Product is licensed to you on an “AS IS” basis without any warranty whatsoever. No services, training, support or maintenance is provided to you by Kinetic Jump Software, LLC under this Agreement. Kinetic Jump Software, LLC EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, NOT EXPRESSLY STATED IN THIS SECTION 4, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF TITLE, INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES AND COUNTRIES DO NOT PERMIT THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHER RIGHTS WHICH VARY BY STATE OR COUNTRY.

5. Limitation of Liability. IN NO EVENT SHALL KINETIC JUMP SOFTWARE, LLC BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDING LOSS OF PROFITS) EVEN IF KINETIC JUMP SOFTWARE, LLC HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. KINETIC JUMP SOFTWARE, LLC’S LIABILITY SHALL BE LIMITED IN THE AGGREGATE TO A REFUND OF THE PURCHASE PRICE OF THE PRODUCT THAT GAVE RISE TO THE CLAIM. IN NO EVENT SHALL KINETIC JUMP SOFTWARE, LLC BE LIABLE FOR YOUR COST OF PROCURING SUBSTITUTE GOODS.

6. Export Restrictions. You agree to comply at all times with the provisions of all applicable laws and regulations regarding export controls or technology transfer restrictions of any applicable jurisdiction, including without limitation those of the United States Departments of Commerce and State.

7. Government Rights. Products furnished to the United States or any state or local government are provided on these commercial terms and conditions.

8. General Provisions. This Agreement and its license shall automatically terminate upon failure by you to comply with any of its terms, or if you voluntarily return the Product to Kinetic Jump Software, LLC or the place of purchase. This Agreement will be governed by the laws in force in the state of Minnesota excluding its conflict of law rules and exclusive venue for any litigation shall be in Minnesota. This Agreement will not be governed by the United Nations Convention on Contracts for the International Sale of Goods, the application of which is expressly excluded. If any part of this Agreement is found void and unenforceable, it will not affect the validity of the balance of the Agreement, which shall remain valid and enforceable according to its terms. This Agreement may only be modified in a writing referencing this Agreement and duly signed by an authorized officer of Kinetic Jump Software, LLC. This Agreement constitutes the entire agreement between you and Kinetic Jump Software, LLC relating to the Product, and supersedes any prior purchase order, communications, advertising or representations concerning the Product.


Installation

AppLife DNA is installed using the Windows Installer. A self-extracting zip library containing the installer file (AppLife DNA.msi) can be downloaded from the Kinetic Jump web site. To start the AppLife DNA installation, launch the downloaded executable and click the unzip button. The AppLife DNA installer will self-extract and start automatically.

The installer checks that the .Net Framework 3.5 SP1 from the Microsoft Corporation is installed on your system. If the .Net Framework is not installed, a Microsoft framework installer is initiated. Once you accept the terms of the Microsoft license agreement, the required Microsoft components are downloaded from the Microsoft web site and installed on your computer. This installation could take a few minutes.

With the .Net Framework installed, the AppLife DNA installer is launched. The AppLife DNA End-User license agreement is presented. After reading an agreeing to the terms described in the agreement, check the box to acknowledge the license. The installer prompts you for your preferred installation location. Click the Next button and AppLife DNA will install. When the installation completes, AppLife DNA will launch.


License Management

The first time AppLife DNA is installed on your computer, the software will operate fully featured for 30 days. After the 30 day evaluation period ends, you must purchase a license to continue using AppLife DNA. Licenses can be purchased online 24 hours a day seven days a week at http://www.kineticjump.com/buy.aspx and arrive via email.

Applying a License Code

When you acquire a license code, you can apply the license by selecting the Preferences option from the AppLife DNA application menu. From there, select the License tab.

Enter your license number into the New License Number text box and click Apply. You can use the windows clipboard to aid in transferring your license key. When your license is successfully applied, the license code will be displayed within the Current License area.

Activating your License

Your license must be activated within seven days of being applied in order to prevent interrupting your ability to use the software. If your software is connected to the internet, simply press the Activate Now button on the License tab.

Note: AppLife DNA attempts to automatically detect your network proxy settings. If your network requires manually configuring proxy server settings, you may do so under the Network tab of the application preferences dialog.

Manual Activation

If your computer cannot be connected to the network for activation, you can activate your license manually by using a computer that is connected to the internet or calling Kinetic Jump tech support during business hours.

To activate manually, navigate to the manual activation URL presented on the manual activation dialog (http://www.kineticjump.com/ProductActivation) then enter your License Key, Machine Name, and Version number into the web form. Save the file downloaded from the activation server and transfer it to the client being activated. Click on the Activation File… button and browse to the transferred activation file.

You will only need to activate your software once.


Your First Project

Let’s walk through using AppLife DNA to specify a simple application. This application will simulate shuffling a deck of cards and dealing five cards out. This application will need to:

1. Represent a deck of cards.

2. Be able to randomly pick an individual card

3. Deal out five random cards

4. Display the cards to the user

5. Reshuffle on demand

Let’s launch AppLife DNA and specify this Card Shuffling application. Create a new project by selecting the New Project item in the main application menu.

Once you have a new project, open the project properties dialog and add your name as the author. We’ll also add a project name.

Let’s save the project and name it Card Shuffling.dna. The project and author name is present on reports and specifications that AppLife DNA creates. With these details taken care of we can go straight into adding the requirements of our application.

Adding Requirements

Adding requirements into AppLife DNA can be accomplished in many different ways. The New Requirement ribbon button is available from any application view. The keyboard Insert key is a shortcut for this command and is often easier and faster to use. From requirement grid views, you can also use the New Requirement box.

The New Requirement Box lets you quickly add multiple requirements. You can also add new Category by holding the Alt key while pressing enter to add the item.

We’ll delete the Requirement 1 that was present as part the default template and add the five identified requirements.

Version Two

Thinking ahead, in version two we’ll extend our application to deal five more cards without reshuffling. We’ll also ensure that the application will show how many cards are left in the deck and prevent dealing out five cards if there are not five cards left in the deck. So let’s create version 2 and add more requirements.

Organizing and Versioning

As is often the case with new applications, requirements lists become long. Requirements come from many elicitation meetings and sources. Using categories within AppLife DNA, you as the specifications author can create your own hierarchy to manage your mental picture of the software solution being defined. In this example we’ll create a category to represent the requirements involving dealing the cards multiple times, and place those requirements into the new category. You can add a category using the New Category ribbon command. You can also use the shortcut keys (Alt + Insert), or the New Requirement box.

Note: When dragging requirements between categories, holding the shift key down will place the requirements within the selected category.

Within the Category View, Requirements and Categories are maintained in the explicit order that you place them in. And in addition to the split category view we have been working in, we can also view and work with Categories and Requirements in a combined hierarchal view. The combined view is often a more convenient way to look at the requirements list. Switch to the combined view using the status bar command button.

The Combined View of our categorized requirements

Since we have a plan for implementing these requirements, we’ll create a second version and assign these requirements as planned.

You assign requirements to a specific release by Versioning. Requirements can be versioned to a specific release by using the ribbon Version button. Requirements can also be versioned by being dragged and dropped onto the Version pane.

So we’ll version the requirements in our project by selecting all of the requirements planned for the first release, and using the ribbon Version command.

And do the same thing for Release 2. Select Release 2 from the versions pane, then select the requirements planned for the second iteration and use the ribbon Version command.

After versioning has been completed, notice that the Active Version grid column shows the explicit versioning assigned to each requirement.

Requirement versioning can be changed at any time.

Defining Requirements

In AppLife DNA requirements are defined within Sections. Defining a requirement really means expanding upon the requirement with enough text to ensure that a reader understands what the requirement means, and stakeholders can effectively communicate about the requirement within the context of the whole solution. Common practices include using use cases or user stories.

With our requirements versioned, let’s proceed and define the requirements for Release 1. Because requirements are central to all of our specification authoring work, AppLife DNA includes another requirement grid where items can be grouped, filtered and sorted. This grid is the Group & Filter view. In this view you can configure and save grid configurations (Views). One of the built-in saved views is the Defining View. This view is designed to list the requirements for the current working version, Categorized by category, sorted by priority, that have not yet been marked as completed. This is effectively our to-do list in order to author a specification for Release 1.

So let’s get to defining our requirements. To define a requirement in AppLife DNA, select the requirement you intend to define and use the Define ribbon command. The keyboard shortcut for defining a requirement is to hold down the Alt and Shift keys, then press the D key (Alt+Shift+D).

Let’s define requirement 2. When defining a requirement that has not yet been defined you are asked to select the section to define it in. If the section doesn’t exist yet, you can also create a new section. Since this is our first requirement we will create a new section. In the New Section textbox, type “A Deck of Cards”.

This will be the name of our section. The Section Editor is now opened with our new section ready for editing. A deck of cards includes 52 cards, 4 suites, 2 thru 10, Jack, Queen, King, and Ace. We’ll describe this in our section.

Since this completely describes the requirement, we will flag this requirement as completed. We can flag the requirement as completed from the Requirements pane in the lower left corner of the Section Editor. If more work were required we would not flag as completed.

Now that we have completed this requirement, we can return to the Defining requirement view by selecting the Group & Filter ribbon button.

Moving on to the next requirement, we’ll define requirement 2. From the Home ribbon, choose the Category View button. This will return to the categorized requirement grid.

Notice that the requirement we just finished is no longer in the list. Select requirement 3 in the grid. This requirement can be defined in the same section as requirement 1. So after selecting to Define requirement 2, we’ll select the existing section to expand into.

With requirement 3 defined, we’ll flag that as completed and return again to the Defining view to pick the next requirement.

For the next requirement (4), we’ll take a user story approach to how the application will operate. The purpose of this application is to deal out five cards to a user. Define requirement four into a new section and call it “Deal Five Cards”.

While defining this section, we also covered requirement five (Display the cards to the user). We can add this requirement to the section by using the Define ribbon command while the section editor is open.

After checking requirement three and four as completed, the final requirement for version 1 requires that we include a means to reshuffle on demand. We’ll create a new section to cover this. This new section we’ll call “Re-Shuffle”.

Modifying the Section Hierarchy

Since the re-shuffle topic is related to dealing five cards, we might want to represent this within our specification by indenting the Re-shuffle section under the Deal Five Cards section. You can do this by using the ribbon Move buttons while the Re-shuffle section is selected.

Heading Styles and Section Indents

When the document styles of Heading 1,2,3,4,5 are used within sections bodies, these styles are used during specification generation to create the Table of Contents. In addition as Sections are indented, each Heading style usage is also modified to reflect the identified indent level. For example, usage of the Heading 2 style within the Re-Shuffle Section will be transformed to a Heading 3 as a specification is generated. So when choosing which Heading Style to use within section content, always choose the style relative to Heading 1.

With requirement six defined, we have completed all of the requirements versioned for Release 1.

Generating a Specification

Now that we have defined all five of our requirements, we can generate a specification to share with stakeholders. To generate a specification, use the Create Specification command on the Specification ribbon tab.

A generated specification can be shared with stakeholders as a Word document, Acrobat Pdf, Rtf, or Html.

Let’s now move on to defining the requirements for version two. Change the Working Version to Release 2 from the ribbon.

With the Working Version changed, open the Defining Grid View.

The requirements versioned for Release 2 are now shown. Select requirement seven and Define the requirement. We want to modify the Deal Five Cards section in order to define this requirement. After doing this we are presented with the following dialog.

This dialog is just reminding you that the last time you were editing section content you were editing version 1.0 and this time you are about to edit version 2.0. Understanding why this dialog is asking for confirmation to switch versions means recognizing that section content is inherited from previous versions unless the content has been edited specifically for the current version. (Which is what we are about to do). Click the button for version 2.0.

Once section inheritance is understood you can disable this aid if you prefer.

To be able to allow the user to deal five new cards, this user story needs to be modified to support that. Under the alternative scenarios, add an extension to step 2 to allow a user to deal five new cards. Notice that the Section icons in the Sections list are different colors. The gray color indicates that these sections are inherited from Version 1.0 and have not been modified for Version 2.0.

We have two more requirements to define. Since they will both be defined in this section, click the Define ribbon command while still in the section editor. Choose requirement 8. We’ll now definee ensuring the user knows how many cards are left in the deck. To do so, we’ll add a step four to the success scenario. Then wrapping up, we’ll select Define again and choose requirement 8. To define this requirement we’ll add another alternative scenario to cover the situation where less than five cards are left.

We now have two fully specified versions. From the Specifications tab you can generate a specification for version one and version two.

Comparison Specifications

More than likely, many team members have already read the specification for version one. To more effectively communicate the changes made between the two versions AppLife DNA can generate a comparison specification. A comparison specification is a distributable document that highlights the differences between two versions or snapshots. To generate a comparison specification, open the Specifications tab and select version 2 as the primary specification version and select version 1 as the comparison version.

The resulting specification highlights the changes made.

Comparison Specifications can be generated at any time against previous snapshots and versions. This allows you to share incremental specification authoring work very effectively with team members and stakeholders.

Requirements Reports

Wrapping up this first project, we’ll create a requirements report that includes all of the requirements in this application. The format and configuration of a Requirement Report, as well as which requirements are included in the report is based upon the currently displayed requirement view. The report is easily created by clicking on the Requirement Report ribbon command.

Summary

This simple example project covered many of the features of AppLife DNA that allow you as a specification author to:

1. Create and organize lists of requirements

2. Define requirements into sections

3. Flag them as completed and filter lists based on this flag

4. Generate specifications

5. Continue with defining requirements

6. Generate Comparison Specifications between two versions or two points in time

As you continue to use AppLife DNA, it is our hope that the tool enables you to more easily maintain a living specifications document, keeping it up-to-date and growing as your solution is iteratively created, and provides the means to communicate as changes are made.


Requirements and Specification Methodology

AppLife DNA promotes improved specification authoring activity by centering the entire process on identified requirements and supporting iterative authoring work. Using the reports and specification generation features, analysts can effectively communicate changes to software domain experts as well as development team leads as the specification evolves.

All software is developed in a repeating iterative process of requirement identification, feature elaboration, review and development. The details in how this is process unfolds vary greatly across software teams. Too often, requirement elaboration occurs simultaneously with development, and requirement review by domain experts occurs while reviewing developed software. Teams that emphasize written requirement elaboration with domain expert review before development perform less rework, spend far less on development, and build higher quality software. AppLife DNA helps teams overcome the difficulties of iteratively writing software specifications and communicating the changes to stakeholders.

Step One: Identify Requirements

This is usually done through some form of requirement gathering or brainstorming session involving application domain experts. Whether your panel includes many individuals or just yourself, brainstorming as many ideas as possible will lead to a more thorough list of potential application requirements.

AppLife DNA Actions:

Add requirements to your project using the New Requirement ribbon command. Requirements can also be conveniently added using the Insert keyboard key.

Add categories to your project from the Category View grid using the New Category ribbon command. Categories can also be conveniently added using the Alt-Insert keyboard key combination.

Step Two: Organize and Prioritize Requirements

Requirements can be organized into a hierarchal structure of categories. Categories represent the skeleton or outline of your application. As requirements are analyzed and added, the outline gets filled in. Newly added requirements are automatically assigned to the category of the currently selected requirement.

Requirement order within a category is also saved which allows for keeping similar requirements organized together. There are two primary application views that display requirements.

· The Category View
The Category View displays project requirements in an indented category based hierarchy and keeps the requirements in their defined order. Requirements and categories can be moved up and down as well as indented left and right. In this view there is a combined indented pane as well as a split pane.

· The Group & Filter View
The Group & Filter view displays the requirements in a flat grid that supports customized sorting, grouping and filtering of project requirements. This view provides a great deal of flexibility in working with project requirements. Views can be customized and saved for quick retrieval.

Requirements are prioritized by grading the Priority, Effort and Risk of each requirement as High, Medium, or Low. With these values set, each requirement has a calculated Rank value. Requirements can be sorted, grouped or filtered on these values, making it easy to identify and communicate the high priority requirements.

AppLife DNA Actions:

Requirements and categories are organized within the Category View using the Move commands. Convenient keyboard shortcuts for moving items are Alt-Shift-Arrow(left, right, up, down).

Requirements can also be assigned to a category using the Category Picker from either requirement view. If the category column is displayed on the grid, the category can be chosen by editing the value. Multiple requirements can also be assigned to a category in one action using the Select Category option of the requirement grid context menu.

From the Group & Filter View, requirements can be sorted, grouped and filtered.

Step Three: Define Requirements

With requirements organized and prioritized, each requirement needs to be expanded upon in greater detail. The action of writing the details of each requirement is referred to within AppLife DNA as defining the requirement. The goal for authoring a complete specification is to define each of the requirements included in the iteration. Requirements are defined within Sections. A Section is a part of a specification. Sections can represent a Use Case, User Story, or simply a topic within your specification. A Section can define one requirement or many requirements. A Section may commonly define a portion of many requirements. Sections are authored within the Section Editor View.

The Complete Flag

Requirements have a Complete flag. This flag indicates that the requirement has been completely defined with section text. Once a requirement is defined, the author can flag it as completed by using this flag.

Requirements can be filtered based on the Completed value to quickly identify requirements that are not yet fully defined within your project. The built-in Defining Group & Filter view uses this flag as part of its configuration to filter and show only non-completed requirements.

Requirements that have not been checked as Complete can also be easily identified in any grid view by enabling non-completed highlighting.

AppLife DNA Actions:

Requirements are defined by selecting a requirement and then selecting to Define the requirement from the home ribbon. A convenient keyboard shortcut to define a selected requirement is Alt-Shift-D.

Sections can be moved up and down as well as indented left and right. The order and indent level of sections determine their location within generated specifications. Section order is modified by selecting a section from the section editor and using the move buttons or keyboard shortcuts.

Step Four: Generate Specifications

With all of your requirements defined, a specification can be generated. Generating a specification compiles all of the sections that define your requirements into a single document that can be distributed to application stakeholders for review and discussion. Requirements and section links can optionally be included in generated specifications, and document styles allow for customizing the formatting and aesthetics of the generated specifications.

AppLife DNA Actions:

Generate specifications from the Specifications Ribbon.

Step Five: Iterate

Requirement definitions can be refined and new requirements added as your application evolves. Add new versions as plans are laid for software releases. As sections are modified for new versions, AppLife DNA maintains the previous section body text. Specifications for previous versions can always be viewed and compared to. Comparison specifications are generated documents designed to be readable and highlight content changes between specification versions. In addition to comparing versions, you can compare snapshots of your progress. Snapshots can be created at any time and comparison specifications can be generated between snapshots. Comparison specifications between versions and snapshots are a very effective communications tool to keep team members up-to-date as your application requirements and specifications evolve.

AppLife DNA Actions:

Comparison specifications are generated on the Specifications Ribbon by specifying a baseline version as well as a specification version.

New project versions are created from the road map pane.

Snapshots can be created automatically every time a specification document is generated. This allows for future comparison of any generated specification. You can also create a snapshot manually at any time using the Create Snapshot ribbon command.


The Working Version

Within AppLife DNA, there is one project version that is designated as the Working Version. The working version determines which revision of a section is opened for editing as you define requirements. The working version is set by selecting a project version within the roadmap pane or by using the working version drop down from the home ribbon tab.

Section Versioning Aid

To help prevent inadvertently editing the wrong revision of a section, AppLife DNA prompts when a section editing session starts with a different version than the previous editing session.

When this prompt is displayed, select the version you intend to edit. If you choose to disable this aid and inadvertently edit the wrong version of a section, you can reverse this action using the application undo command. You can also correct the revision status by navigating to the section properties dialog and removing the versioned section body.


Defining Requirements

Defining a requirement means expanding on the requirement within one or more sections. Requirements are defined so that application stakeholders can review and approve your definition of the requirement and so that developers can successfully implement the desired functionality.

When a requirement is first defined using the Define ribbon button, you are presented a Section Selector to choose which section to define the requirement in. You can also create a new section.

After selecting or creating a section, the section is opened in the section editor. Here you can expand upon the requirement in greater detail. The requirement that you are currently defining is displayed in the Section Requirements pane. A list of all other requirements that are fully or partially defined within the open section is also shown in this pane. And for each requirement listed, a list of other sections that define the requirement is shown, allowing for easy navigation between related content. You can navigate to any of these sections by clicking on them.

As you complete the process of defining a requirement, you can flag the requirement as completed. This action checks the Completed requirement property. From within the Group & Filter View, requirements that are not yet fully defined are easily identified by filtering on this property.


Generating Reports

Requirements Report

Requirements that are displayed in the Categorized Requirement View or the Group & Filter Requirement View can be output as a requirements report. The requirements report will follow the same grouping, sorting and column layout of the currently displayed grid. To generate a requirement report, use the Requirement Report ribbon button from the home application ribbon tab.

Specification Document

Specifications are generated from the application ribbon Specifications tab. Specifications can be generated for a selected version or as a comparison between two different versions. To generate a specification, select the version from the Spec Generation tab group drop down and choose the Create Specification ribbon action.

Creating a Comparison Specification

Comparison specifications compare two versions and highlight the differences between them for easy review. Comparison specifications can include the entire version specification or just the Sections that have been modified between the two versions. To create a comparison specification, select the version to compare from the Comparison tab group drop downs. To include only sections with changes, use the Comparison Mode ribbon option.

Printing and Exporting Reports

AppLife DNA requirement and specifications can be printed to a system printer or exported to the following formats:

· Adobe Acrobat (pdf)

· Microsoft Word (doc)

· Rich Text (rtf)

· Html (htm)

To export a report, select the desired format from the Viewer application ribbon tab.


Useful Keyboard Shortcuts

Most actions that can be performed within AppLife DNA have keyboard shortcuts that aid in efficiently using AppLife DNA. This is a list of the available keyboard shortcuts.

Switch Views

Alt-Shift-V: Opens the Requirements Category View

Alt-Shift-F: Opens the Requirements Group & Filter View

Alt-Shift-E: Opens the Section Editor View

Requirements

Insert: Adds a new Requirement

Delete: Deletes the selected requirements

Alt +Insert: Adds a new Category

Alt + Shift-Arrow pad: Moves selected requirements

Alt + Shift + D: Defines the selected requirement

F2: Edits the selected requirement

Space: Edits the selected grid cell

Section Editing

Ctl + B: Bold the current word or selection.

Ctl + I: Italicize the current word or selection.

Ctl + U : Underline word or selection

Ctl + Shift + A: All caps

Alt + Ctl + 1: Apply Heading1

Alt + Ctl + 2: Apply Heading2

Alt + Ctl + 3: Apply Heading3

Ctl + Shift + L: Apply Bullet List

Alt + Ctl + L: Apply Number List

Ctl + E: Center Paragraph

Ctl + J: Justify

Ctl + L: Left Paragraph

Ctl + R: Right Paragraph

Ctl + Shift + F3: Change case. If first letter not capitalized, capitalize it. If is, capitalize entire word. If all caps, switch to lower case.

Ctl + Backspace: Delete Back Word

Ctl + Del: Delete Word

Ctl + shift + c: copy format

Ctl + shift + v: paste format

Ctl + F: Find

Ctl + D: Open font dialog

Ctl + Shift + . : Grow font

Ctl + Shift + , : Shrink font

F1 : Help

Ctl + K: Hyperlink

Ctl + M: Indent

Ctl + Shift + M: Unindent

Ctl + Shift + N : Normal Style

Ctl + Enter: Page Break

Ctl + P : Print

Ctl + F2 : Print Preview

F7 : Spell Check

Ctl + H : Replace

Ctl + S : Save

Ctl + Shift + S: Manage Styles

Ctl + = : Subscript

Ctl + Shift + = : Superscript


New Project Template

When you choose to create a new project from the AppLife DNA application menu, a new project is created based on the project contained in the template.dna file located in the application directory. To customize your new projects, replace the template.dna project file with your own customized template project.


About Versions

A version in AppLife DNA represents a release of software. Specifications for a version are created by assigning (or versioning) requirements to a version. Requirements are assigned explicitly to one version, and each higher version inherits the requirements of earlier versions implicitly.

In the image below there are two versions and four requirements. Requirement 1 and 2 are versioned to version 1. Requirement 3 and 4 are versioned to version 2. When the requirements list for version 2 is shown, you see that the two gray requirements are inherited from version 1.

Version Properties

Friendly Name: This value provides a textual name for the version. A short phrase is commonly used for easier identification of a specific version. When a friendly name has been assigned, the name is present wherever a version is selectable by the user.

Number: The version number, formatted in {Major}. {Minor}. {Revision}. {Build}. Only the major and minor component is required.

Shipped: Versions that have been shipped can be adorned to identify this state.

Description: An identifying description that appears in the roadmap when defined.


The Version Roadmap

The version roadmap pane appears to the left of requirement grid views. Each version within the roadmap represents a release, or planned release of the software the project represents. The roadmap provides a view of all project versions and identifies the current working version.

From the roadmap pane:

· Versions are added

· Versions are removed

· The version abstract is accessed for editing

· The version requirements list is opened

· The properties of versions are accessed

· The current working version is changed


Abstract

Each version has an abstract. Unlike sections, the version abstract is never inherited and exists only for the specific version. When a specification is generated for a version, the abstract is included after the table of contents and before section content. If an abstract has not been provided, it is omitted from generated specifications.

The purpose of an abstract is to provide a concise overview of the goals of the specific version. It is a summary of the version.

The abstract is accessed by the Edit Version Abstract roadmap toolbar button.


Versioning Requirements

When a requirement is included in a version it is said to be versioned to that particular version. Requirements are versioned by using the Version ribbon command or by defining a requirement. When a requirement is defined it is automatically versioned to the working version unless previously versioned. A version has direct requirements and inherited requirements. When a specification for a version is generated, sections that define any direct or inherited requirement are included in the specification.

To move a requirement from one version to another, the requirement must first be cleared and then re-versioned.

A Versions Requirements List

A list of all requirements in a version can be viewed using the Show Version Requirements roadmap toolbar button. This special grid shows direct and inherited requirements. Adding and removing the requirements from this grid will version or un-version them.

The Active Version

Requirements grids include an Active Version column. This column shows, among other information, the version that the requirement is versioned to. This column can be used in the Group & Filter requirements view to organize requirements based on their version.


Shipped Versions

Shipped versions are software versions that have been released to users. When a version is shipped, this indicates that the software has been developed and additional specifications work will needed to change or remove them. Requirements in a version that has been designated as shipped are adorned as shipped in the Active Version column. In addition, the requirement’s status property changes to Shipped.

To ship a version, open the version properties dialog and click the Ship button. The time and date of shipping is recorded.


Removing Requirements

Removing a developed requirement requires work that should be specified within the specification of the first software version that does not include that requirement. AppLife DNA captures this concept through removing requirements.

A removed requirement is a requirement that is inherited from a previous version and then deleted in a later version. To identify a requirement as removed, open the version requirements list from the roadmap toolbar and remove the intended requirement from the list.

In the image below, requirement 2 was removed in version 2. Sections that define requirement 2 would be included in version 2 specifications, but not in higher versions.


The Version - Requirement - Section Relationship

Sections are related to versions through requirements. A requirement is versioned to a specific version and a requirement is defined within one or more sections. This relationship determines whether a section is included in a specification for a version.

For a section to be included in a specific version, at least one of the requirements that are defined within the section must be directly versioned to that version or inherited from an earlier version.

Section content is also based on versions. Section content defined in one version is inherited in higher versions until the content is extended or overridden. Within a section, each version will have content specific to itself or content that is inherited from earlier versions.

In the image of the section properties dialog below, you see that this section has explicit content for version 1, inherited content for version 2, and explicit content for version 3. Changes made to this section for version 1 will automatically be inherited in version 2. Version 3 has independent content that.

This version specific inheritance of requirements and section content allows the specification author to iteratively add content as the software is developed and released. The information contained within AppLife DNA allows for continuous communication as changes are made. AppLife DNA keeps the application specifications for all versions immediately at hand for consideration and expansion.


Requirements in AppLife DNA

In AppLife DNA requirements are at the core of the entire specifications authoring process. Requirements identify what needs to be detailed into sections. Requirements identify what sections are included in a version specification. Requirements essentially identify what is expected of your software. A good specification describes in adequate detail all of the requirements of the proposed software.


Entering Requirements

New requirements can be added from any application view using the New Requirement ribbon command. From either of the Requirements Views, new requirements can be added by pressing the Insert key. A requirement has the following properties:

ID: A unique numeric identifier.

Name: Text that titles the requirement.

Description: Expands upon the name of the requirement to capture and convey more understanding of the requirement.

Type: Describes the requirement as one of four high level types.

· Functional (Default)

· Non-Functional

· Quality

· Performance

Priority: Quantifies the importance of the requirement. Combined with the effort and risk property determines a rank value for the requirement. Possible values are low, med, and high.

Effort: Quantifies the overall work involved with researching, designing, and implementing the requirement. Combined with the priority and risk property determines a rank value for the requirement. Possible values are low, med, and high.

Risk: Quantifies the risk involved with pursuing the requirement. Combined with the priority and effort property determines a rank value for the requirement. Possible values are low, med, and high.

Completed: A flag that marks that the requirement as has been completely expanded upon.

Category: Identifies the category that this requirement belongs to.

Status: Identifies the current status of the requirement.

· Proposed
Indicates that the requirement has not yet been versioned

· Versioned
Indicates that the requirement has been versioned.

· Shipped
Indicates that the version this requirement is associated with has been flagged as shipped.

· Removed
Indicates that the requirement has been removed in a version later than the version it was first introduced in.

Created: The date and time that the requirement was first created.


Custom Requirement Fields

You can add new custom fields to requirements for tracking information related to your application or organization. Custom fields are defined on a project scope and are added from the project properties dialog.

Custom fields can be text, numeric (integer), or decimal values. Custom fields can be added to requirements grids and reports.

Columns are added to requirement grids by right-clicking the column header row.

Custom fields can be sorted, grouped, and filtered just like any requirement property.


Prioritizing

Requirements are prioritized by setting the priority, effort, and risk properties. Requirements can be organized based on these fields in the Group & Filter view. In addition to using these fields individually, the Rank property quantifies the fields into a single value based on a mathematical calculation. Using the rank value can help in determining requirements to pursue or postpone by taking all three prioritization fields into account together.

How Rank is Determined

Rank is determined by taking into account the designated priority, risk and effort of requirements. Rank is directly proportional to priority, inversely proportional to effort, exponential and inversely proportional to the risk. So a requirement with high priority, low effort and low risk would score the highest rank and a requirement with low priority, high effort and high risk would score the lowest rank.

Rank Weights

Rank weights determine the contribution of the three components to the rank value and are configurable per project. The default value for rank weights is:

Priority: 30

Effort: 20

Risk: 50

Modifying these values change the overall contribution of the components to the rank value.

Rank = (Priority/3 * Priority Weight + Effort Weight / Effort + (1/Risk)^2 * Risk Weight) * 100/Sum of weight factors


Requirement Categories

Requirements can be organized into hierarchal categories. Categories highlight the skeleton of your application. Categories and their contents can be moved up and down, indented, or out-dented.

Categories are created using the New Category ribbon command. Categories can also be added with the keyboard shortcut Alt + Insert.

Multiple requirements can be categorized in one step by using the Select Category context menu item.


Viewing Requirements

In AppLife DNA there are two primary requirements views.

· Category View
This view presents an indented hierarchal view of requirements and categories. Requirements are grouped by category and their order within their category is maintained. Requirements inserted in this view are automatically categorized and located as a sibling to the currently selected requirement. Categories can be collapsed, but no other sorting or filtering is capable. This view provides a hierarchal structural view of all requirements in the project.

· Group & Filter View
This view displays requirements in a grid capable of complex sorting, grouping and filtering. This view is best for organizing requirements and working with discrete requirement sets.

Requirement grid columns can be re-ordered to your preference. In the Category View, the left most column is required to be the requirement name column. Columns can be added or removed by right-clicking on the column header and selecting the columns of interest.

Group Sort and filter

The Group & Filter grid allows for very flexible organization of requirements. Columns can be filtered on their content. Columns can be sorted ascending or descending. Columns can be grouped. The grid below is being grouped on the value of the priority column, filtered to include only requirements that are of type functional AND status of proposed. Multi-column filters can be configured to optionally match any column filter instead of all column filters by selecting the Match Any Filter context menu option.

Saving a Custom View

You can save a custom view in the Group & Filter view by selecting the Save Current View As… command from the Group & Filter view dropdown menu.

Select the Save Current View As… menu item and enter a view name. You can save modifications to a previously saved view by selecting the Save Current View command.

Saved views can be recalled by selecting the view in the Group & Filter view dropdown.

Selecting Standard Views

There are three standard views designed for common AppLife DNA activities.

The Normal view is designed as a starting view for sorting, grouping, and filtering your project requirements.

The Defining view filters your requirements on the currently selected working version and the completed checkbox, grouped on Category. Requirements displayed in this view represent those that are not yet fully defined within project sections. They represent what the user is currently working on (or defining).

The Ranking view displays the Priority, Effort, Risk, and Active Version columns for ranking requirements.

Standard views can be modified and saved.

Managing Saved Views

Saved views can be renamed or removed from the view management dialog. To access the management dialog select the Manage Views… menu item.


Searching Requirements

Requirements can be searched using the ribbon Search command. Requirements are full-text searched for the provided search phrase across all requirement attributes. Search results can be further sorted, grouped and filtered using grid columns.

Using the OR operator

The default search behavior is to include requirements that include all words in the search. By using the OR operator, you can expand your search results to include requirements in your search results that hit any of your search words.

Phrase Searches

By enclosing your search phrase in quotes, you can include only exact phrase matches in your search results.

Exclusions

You can exclude requirements that include specific words from your search results by preceding the word with a – sign. (ex: Apple –orange).


The Requirements Report

The requirements report presents the contents of a grid view in a printed page format. The requirement report is created using the Requirement Report ribbon command.

The report layout mirrors the columns, grouping, sorting, and filtering of the current grid view. Columns are shrunk to a minimum size and columns that don’t fit the width of the report page setup are omitted. The grid and report below demonstrates the report configuration mapping.

Requirement Report Page Setup

The requirement report page can be setup independently of the specifications page setup. The setup dialog is accessed using the Requirement Report ribbon button drop down.


Importing Requirements

Requirements can be imported from multiple sources. Source formats include:

· Delimited Text Files

· MS Excel Workbooks (xls, xlsx)

· Microsoft SharePoint Lists

· Fog Creek Fogbugz Projects

To import requirements into AppLife DNA, an import source is configured by performing the following steps:

1. Identifying the Source Type and Location

2. Mapping Columns to Requirement Properties

3. Converting Source Values to Requirement Attribute Values

4. Filtering Source Rows

5. Defining a Source Identity Field

Once configured, you can import from the source repeatedly without duplicating requirements in AppLife DNA.

To import requirement in AppLife DNA, open the main application menu and select the Import menu item.

Identify Source Type and Location

Delimited Text File

You can import requirements from any type of delimited text file. The most common format is comma or tab delimited files. You can also specify the delimiter character. If the file contains header information you can choose to ignore the first few lines of the file. You can also ignore unquoted white space.

To configure a delimited text file, choose the location of the file, the delimiter type and lines to ignore. Once configured, AppLife DNA will analyze the file columns and present the column configuration user interface. The source information is persisted after configuration is complete. AppLife DNA will attempt to use the last ignored row as column headers to help in mapping columns to AppLife DNA requirements.

Excel Workbook

You can import requirements from a Microsoft Excel workbook. Most requirements and list management solutions support exporting content to an Excel workbook that you can use to import requirements into AppLife DNA. Once an Excel file is selected, a list of worksheets in the workbook is presented for you to choose the appropriate one. If the worksheet contains header rows you can choose to ignore the first few rows. AppLife DNA will attempt to use the last ignored row as column headers to help in mapping columns to AppLife DNA requirements.

To configure an Excel worksheet, choose the location of the file, the worksheet and rows to ignore. Once configured, AppLife DNA will analyze the worksheet columns and present the column configuration user interface. The source information is persisted after configuration is complete.

SharePoint List

Requirements can be imported from a Microsoft SharePoint server. To import requirements from a SharePoint server, you provide the SharePoint server URL, authentication mode, and authentication credentials.

With URL and credentials provided, you use the Refresh Lists command button to query the server for the content lists available. Select the content list that contains the source of requirements. With the appropriate list selected, use the Refresh Views command button to query the views available for the selected list. Select the appropriate view.

With the list and view selected, AppLife DNA will query the view and present the contents for mapping to AppLife DNA Requirements.

Fogbugz Project

Requirements can be imported from a Fog Creek Fogbugz server. To import requirements from a Fogbugz server, you provide the Fogbugz server URL, user email address and password.

With URL and credentials provided, you use the Refresh List command button to query the server for the list of server based filters available. Select the filter that contains the source of requirements. Select the appropriate filter.

With the filter selected, AppLife DNA will query the server and present the contents for mapping to AppLife DNA Requirements.

Mapping Columns to Requirements Properties

With a requirement source configured, columns can be mapped to AppLife DNA requirements. In addition, column values can be converted to appropriate AppLife DNA requirement values during the import. Source rows can also be further filtered by AppLife DNA prior to importing.

To map a column to a Requirement property, select the column in the data view. With the column selected, the Requirement Property can be selected. Once selected, the requirement property that the column is mapped to will be displayed on the top of the column.

Converting Source Values

Source values that correspond to, but don’t directly match up with possible values for AppLife DNA requirements can be converted during the requirement import process.

Conversion possibilities depend on the AppLife DNA requirement property that is being targeted. The example below shows a SharePoint list Priority column that is configured to import into an AppLife DNA requirement Priority attribute. The possible values are High, Medium, and Low. Conversions for the original source values can be added using the Conversion dialog. Within this dialog, you can add mappings between the original source value and the targeted Requirement Attribute.

Fallback value

For requirement attributes that are limited to specific values, you can specify a fallback value that will be assigned in the event that the source value cannot be imported or converted.

Filtering Source Rows

Source rows can be filtered by AppLife DNA prior to importing. Filters are column based and can be filtered based on text, number, or date. To add a column filter, select the column that you want to apply a filter to and use the Filter… command button.

Text filters can specify a text value that must be equal to, contains, starts with, or ends with the original column value.

Number and Date filters can compare the source to be equal to, greater than, at least, less than, at most, or between two values.

Any row value that matches the filter is included in the import. The preview list will show the results of the filter so that you can see the effect of the applied filter prior to performing the import.

Filter Settings

The import can match any column filter or match all column filters for inclusion. If match any is selected, rows that match any of the defined column filters will be included in the import. If match all is selected, rows must match all defined column filters to be included in the import.

Source Identity

Setting a source identity value allows you to define how subsequent imports from the same requirement source will behave.

To set a source identity, the column that identifies uniqueness in the source must be imported into an AppLife DNA custom property. You can define a new custom property during the import or you can select an existing property. With the source identity value imported, subsequent imports can compare and match the incoming requirement with the existing requirement that was previously imported.

Set the identity column from the list of imported columns and choose whether to update matching requirements during the import or skip them.

With the import source completely configured, you can choose to import now or save for importing later. The configured source is persisted with the project file.


Exporting Requirements

Requirements in AppLife DNA can be exported to a Microsoft Excel worksheet. Excel exporting is configured through the Group & Filter View. The columns, order, and filtering applied to the grid governs the format of the export.

To export requirements to Excel:

1. Open a Group & Filter View

2. Configure the view to match your desired Excel export.

3. Under the main application Save Project As sub menu, select Excel Spreadsheet option.

Note: You can save a customized Group & Filter view setup, allowing you to quickly recall a previously configured export setup.


Sections

In AppLife DNA specifications are created by expanding upon requirements within sections. A section is a document that describes one or more requirements in detail. Specifications are created by combining the sections that define requirements that are versioned within a project version. Sections can be written in any style or format. Common formats include user stories or use cases.

As features and requirements are added to your software application, your specification is also extended. In AppLife DNA, as sections are extended, their previous version state is preserved for reference and comparison. After version 1 has been completely specified and work begins on identifying and specifying version 2, the version 2 specification begins where version 1 left off through inheriting all of the requirements and sections of version 1.

Splitting a Sections Inheritance

When a new version is added to an AppLife DNA project, the requirements and sections of the prior version are automatically inherited. This means that comparing a specification of a newly added version 2 to a project with a completely specified version 1 specification would be identical. In this circumstance, changing any section in version 1 would also change version 2.

As specification work begins for version 2 and a section body is modified, the version 1 body is duplicated and a new separate revision for version 2 is created and open for editing. The version 1 revision is maintained separate and independent from version 2. All other sections still inherit from version 1 until a modification is made. This inheritance and separation is indicated in the AppLife DNA user interface. Notice in the image below, the section header status indicating that the section is inherited from version 1.

The section icon is also gray, which indicates that the current section text is inherited.

Now upon first edit, the section body is replicated and this section will now maintain two independent documents, one for version 1 and one for version 2. In the image below, the section header status indicates the change as the document was modified.

With both versions available, the two specifications can be reviewed and compared as the version 2 iteration proceeds.

Returning a Section Revision to Inheritance

To return a section to an inheritance behavior, the version revision can be removed. To do so, open the section properties dialog and refer to the Versions tab.

Comparing Section Versions

Different versions of a section can be compared for quick identification of differences. This comparison aids in moving requirements from one version to another. To compare two versions, click on the Compare versions link in the section header. The section editor will display the previous version below the current version, with a comparison toolbar. The comparison view displays marked up text identifying the differences between the two revisions.

Comparison Toolbar

Revision List: Selects the revision to compare the upper version with.

Edit: Toggles the lower pane to an editable state.

Compare: Toggles the lower pane to a read-only marked up comparison view between the upper version and the lower version.

Remove: Removes the lower revision from the section and reverts the section to inheritance for the specified version.

Previous Change: Jumps to the previous change in the comparison.

Next Change: Jumps to the next change in the comparison.

Print: Sends the lower document to the viewer for printing or exporting.

Close: Closes the comparison pane.

Ordering and Indenting

Sections can be moved up and down as well as indented within the section hierarchy. The order and indent level is honored as specifications are generated.

Section Hierarchy Inheritance

When a new version is created, the section order and indent levels are inherited from the next previous version and changes to the previous version affects the new inherited version as well. Once an explicit assignment has been made to the order or indent level of sections for the new version, its hierarchy is independent from previous versions. Changes made to previous versions will not automatically affect the section hierarchy of the new version.

Global Sections

A global section is designated to be included in all version specifications, regardless of requirements relationships. A section is marked global from the section properties dialog.

Content that are written in global sections usually doesn’t represent any particular requirement. An application scoped vision statement is an example of a good use of a global section. The AppLife DNA example project includes four global sections. Global sections are adorned with a globe in their icon and are easily identifiable within the section list.

Global sections can define requirements but they do not need to in order to be included in version specifications.

Showing All Sections

When the section editor is open, the sections included in the current working version are displayed in their proper hierarchy within the sections list. These are global sections and sections that are related to the current working version by defining one or more requirements from that version. There may be other sections that are not displayed in the list because they do not define any of the versions requirements. To access those sections, all sections can be displayed by clicking the Display All Sections icon button.

While showing all sections, the sections are listed in alphabetical order. Sections that would not appear in the specification for the current working version are adorned with a red circle and slash. These sections can be opened for edit or comparison.


Specifications in AppLife DNA

AppLife DNA generates specifications for versions by compiling sections that define requirements included in the version into a single document. A specification document layout includes:

Cover Page

The cover page includes the project name, version information, and date of generation. If the author name and company information is included in the project properties, this information is also included.

Table of Contents

As the specification is generated, a table of contents is generated. All sections are included in the table of contents. In addition, section content styled with a Heading document style (1,2,3,4,5) are included in the table of contents. The section level hierarchy is honored within the table of contents. Table of content items are hyperlinked to the corresponding specification content.

Abstract

If the version abstract includes content, it is included immediately following the table of contents. If the version abstract does not include content, it is omitted. If the abstract is included, the table of contents includes an entry for the abstract.

Sections

Global sections and sections that define versioned requirements are included in their configured order.

Headers and Footers

Specification pages following the title page include headers and footers. The header includes the project name. If the project properties include a company name, it will appear in the footer. The footer also includes page x of y information.

Specification Options

When a specification is generated there is content that can optionally be included.

Page Breaks between Sections

When this option is enabled, a page break is included between first level sections.

Include Related Section Links

When this option is enabled, links between sections that define common requirements are added at the end of the sections. These links present the page number of their destination.

Include Defined Requirements

When this option is enabled, a list of the requirements that are defined in a section is appended to the section. The list includes the id and name of each requirement defined within the section.

Draft Watermark

Enabling the draft watermark option will include a watermark labeling the printed page as a draft.

NOTE: This watermark does not appear in the specification viewer. The watermark only appears on a printed page.

Insert Structured Numbering

The Insert Structured Numbering option adds number outlining to sections and heading values within the generated specification.


Comparison Specifications

Comparison specifications identify and highlight the differences between two versions of a specification. Distributing comparison specifications as work progresses creates a highly effective communications tool. Stakeholders quickly consume changes to previously distributed specifications in full context.

Comparison specifications identify changes to the text of a specification and mark up new content, changed content and deleted content. In a comparison specification, any paragraph with changed content has a left border applied for easy yet unobtrusive identification. Comparison specifications only identify content changes. Changes to formatting are not identified in order to reduce the amount of markup and maintain the readability of the document.

Deleted content is shown as text with strikethrough or optionally omitted. When deleted text is omitted a red | character is inserted as a marker indicating that text was deleted. This option results in text that is often easier to read when there are large amounts of deleted text.

Comparison mark up legend:

Change Legend:

New Text

| Deleted Text Placeholder

Changed Text

In a comparison specification the table of contents identifies sections with changed or added content.

An example of comparison spec mark up is presented below:

Comparison Mode

Comparison specifications can be created in two different modes.

· Full with Differences
In this mode, all specification content is included and changes are marked up. Sections that are identical are included in the specification.

· Changed Content Only
In this mode only sections that have added, changed, or removed content is included in the specification.

Options

When generating comparison specifications you have the option of showing deleted text or not. You also have the option to show added and changed requirements.

Show deleted text

With this option is selected, deleted text is marked up in green with strikethrough. When not selected, deleted text is omitted and a | character is placed wherever there is deleted text to indicate text has been deleted.

Show added & changed requirements

With this option checked, each section’s list of requirements is adorned to identify changes to the requirements list.


Controlling Formatting through Project Styles

The formatting of AppLife DNA documents can be controlled through the use of styles. Styles allow for setting the font, paragraph, borders, tabs and numbering properties of text. Styles are project scoped and you can create and use your own styles within your projects. Modifying the built-in styles allow you to completely change the appearance of generated specification documents. The following list of styles is used in generating specification documents.

· Normal
This style affects the appearance of content body text.

· Heading 1
This style affects the first level of section title formatting

· Heading 2
This style affects the second level of section title formatting

· Heading 3
This style affects the third level of section title formatting

· Heading 4
This style affects the fourth level of section title formatting

· Heading 5
This style affects the fifth and all lower levels of section title formatting

· TOC Entry
This style affects the formatting of table of contents entries

· TOC Number
This style affects the formatting of table of contents page numbers

· Hyperlink
This style affects the formatting of inserted hyperlinks between sections.

Editing Styles

The style editor is opened by clicking the Style ribbon group dialog launcher.

Select the style to edit from the styles list and select to open the style editor. From this dialog you can modify all of the properties of the style.

Saving a new style from selected text

A new style can be created from selected text by using the Save as new style ribbon command. This command is accessed from the ribbon style gallery drop down.


Snapshots

Snapshots in AppLife DNA provide a comparison point to use in creating comparison specifications. Snapshots intelligently copy project information as changes are made providing comparison operations without significant increases in project file size. When generating specifications, you can use snapshot content for the primary version as well as the comparison version.

Creating

Snapshots are created using the Create Snapshot ribbon command.

Snapshots can also be automatically created every time a specification is generated by checking the option to Create Automatically. When this option is checked a new snapshot is created with every generated specification.

Removing

Snapshots can be removed by opening the snapshots dialog

From the snapshot management dialog you can remove one or more snapshots. Removing snapshots cannot be undone.


Exporting

Specifications and reports generated in AppLife DNA can be exported to four popular formats for sharing with stakeholders. The supported formats are:

· Adobe Pdf
Adobe acrobat is a common format for sharing information. The adobe acrobat reader is available on most computing platforms.

· Microsoft Word
Most modern word processing applications support opening Microsoft Word documents.

· Rich Text

· Htm

To export an AppLife DNA specification use the Export ribbon commands in the viewer ribbon.


Glossary of Terms

AppLife DNA

Category

Comparison Specification

Effort

Evaluation period

Priority

Rank

Requirement

Requirements Report

Risk

Roadmap

Section

Snapshot

Specification

Working Version


Generating Specifications

More:

Specifications in AppLife DNA

Comparison Specifications

Controlling Formatting through Project Styles

Snapshots

Exporting


Getting Started

More:

Installation

License Management

Your First Project


AppLife DNA

A software application used to manage requirements and iteratively author software specifications.


Category

A division of categorization of requirements.


Comparison Specification

A document that is marked up to highlight the differences between two revisions of a specification.


Effort

A measure of the total work required to accomplish a task.


Evaluation period

The 30 time period after initial install that AppLife DNA will operate without a valid license. This time is used to evaluate the effectiveness of AppLife DNA.


Priority

The preferential rating of a requirement.


Rank

A quantified value that measures the overall priority of a requirement based on priority, effort, and risk.


Requirement

An essential feature or characteristic of a software application.


Requirements Report

A document that shares the details of requirements.


Risk

A measure of the chance that the investment in accomplishing a requirement will be lost or wasted.


Roadmap

The plan to implement requirements within software versions.


Section

A document that describes the details of one or more requirements. Sections are combined to generate software specifications.


Snapshot

A point in time for which specifications can be compared to or generated from.


Specification

A written descripton of a plan for the creation of a software application.


Working Version

The project version that is referrenced when performing actions such as versioning and defining.


Introduction

More:

What is AppLife DNA?

Why use AppLife DNA?

System Requirements

License Agreement


Managing Requirements

More:

Requirements in AppLife DNA

Entering Requirements

Custom Requirement Fields

Prioritizing

Requirement Categories

Viewing Requirements

Searching Requirements

The Requirements Report

Importing Requirements

Exporting Requirements


Using AppLife DNA

More:

Requirements and Specification Methodology

The Working Version

Defining Requirements

Generating Reports

Useful Keyboard Shortcuts

New Project Template


Versions

More:

About Versions

The Version Roadmap

Abstract

Versioning Requirements

Shipped Versions

Removing Requirements

The Version - Requirement - Section Relationship


Writing Specifications

More:

Sections