Product Detail Presentation

Requirement Summary Window

• The Requirement Summary window provides a high-level overview of the Project Requirements. Many users can work on the same Project simultaneously, so Requirements may apply to all parts of the Project.

• Requirement attribute fields can be displayed, filtered, and sorted. The window can display the Requirement Priority, Status, Primary Stakeholder, Milestone, Group, etc.

• Statistical information about each Requirement can also be displayed, such as the number of unresolved Issues, the number of unfinished Test Cases, and the number of Sub Requirements for each Requirement, etc.

to top

Requirement Detail Window

• The Requirement Detail window allows you to add, edit, and view the detail for each Requirement.

• All of the many Requirement Attributes can be accessed from the Requirement Detail window by clicking either the More button or selecting from the Requirement Attributes list displayed here.

to top

Requirement Detail Description Window

• The Description for each Requirement can be edited using this window. If the Requirement Detail window is not open then the Description can be quickly edited by double-clicking on the list in the Requirement Summary window.

to top

Sub Requirements

• Unlike the unique Requirement ID (ReqID), the Sub Requirement ID (SubID) can be sorted and modified to keep related Sub Requirements together.

• It is possible to change the format of the ReqID-SubID by clicking on the Options button and selecting the Identification tab.

to top

Requirement Issues

• Issues are specific concerns that are raised against each Requirement throughout the Project schedule.

• Issues cover a range of things: from identifying exceptions to the Requirement, to risks that threaten the fulfillment of the Requirement, to classifying the Requirement as ready for sign off.

to top

Requirement Test Cases

• Test Cases help engineers and developers understand exactly what is involved in each Requirement.

• The Status of each Test Case can help guarantee Project compliance.

• The Test Case description can be edited from the Detail View tab.

to top

Discussion Threads

• Threads can include any snippet of information (such as the body of an email or notes from a customer interview) that may be useful to you in the future.

• If you know that you will need to build a list of Requirements later, but you get some information now, then you should create a discussion Thread so you and your team can keep track of that information.

to top

Discussion Threads Display Preferences

• Threads are linked to individual Requirements. But Threads linked to other Requirements may be included in the display based upon the criteria in this tab. For example, all Threads attached Requirements of the same Group can be displayed together in the Requirements Detail window.

to top

Custom Lists of Project Specific Information

• Custom Lists encompass additional information specific to the Project, such as references to drawings and other external documents, public and private implementation notes, competitive insights, etc.

• The types of Custom Lists available can be modified by clicking on the Customize button. Custom Lists can be selectively included or excluded from Reports.

to top

Add New Requirement Wizard

• The Add New Requirement Wizard guides you through the fundamental steps of adding a new Requirement to the Project.

• After assigning the Requirement a unique identification number, the wizard helps assign the most common Attributes, including the Priority, Status, Primary Milestone, and Description.

to top

Stakeholder Email Wizard

• The Stakeholder Email Wizard allows the user to Email Reports to all of the Stakeholders that are linked to the Requirements listed in the Requirements Summary window.

to top

Microsoft Project Synchronization Wizard

• The Microsoft Project Synchronization Wizard allows the user to synchronize the Requirements Management Database with one or more Microsoft Projects.

• The user can copy Microsoft Project Attributes (such as additional Tasks, Schedules, Links, Resources, Assignments, Baselines, etc.) from one Microsoft Project to another - useful to compare the schedule impact from different project scopes.

to top

Priority Attribute Window

• All Requirement Attributes can be customized to fit into your existing project management process.

• Project Priorities, for example, can be expressed in a number of different ways. They can be based upon level of importance or urgency, or they can be described in Plain English as ranging from High to Low.

• You may also choose to Customize Requirement Attributes and create your own Project metrics.

to top

Project Stakeholders

Stakeholder List View

• Requirement Stakeholders are another type of Requirement Attribute. They are used to identify specific individuals that have a stake in the Requirement being met. These include the authors, the engineers and developers, the customers, and the end user personas.

• Many individual Stakeholders can be assigned to each Requirement. The Primary Stakeholder is listed at the top.

• Each Stakeholder can be assigned a different Action for each Requirement.

to top

Stakeholder Detail View

• Requirement Attributes can be viewed and edited in either List View or Detail View.

• Detail View provides you with more information about the Requirement Attribute, such as the Description, default values, and links to other Attributes.

to top

Stakeholder Attributes

• Stakeholders are classified by Stakeholder Type, including users of the Requirements Management Database (like you), other contributors to the Requirements, and end users.

• The Default Action Required is initially assigned to the Stakeholder whenever linked to a Requirement.

to top

Other Examples of Requirement Attributes

Sub Groups Attribute

• Groups typically describe the functional organization that each Requirement needs to be communicated to.

• In many cases the same Requirement needs to be conveyed to several different functional Groups.

to top

Tags Attribute

• Tags can be added to help you internally manage all the Requirements in a Project.

• Public Tags can be seen and filtered by all Database Users. Private Tags can only be seen by you. Baseline Tags can be used to identify Requirements that have been included together in a final or updated Report.

to top

Project Use Cases

• Use Cases provide a high-level perspective of the problem that the customer or end user is actually trying to solve.

• Use Cases should be linked to actual customers or to End User Profiles here before linking them to Requirements. Arrows convey the many-to-many relationship between Use Cases and Stakeholders.

• Alternatively, Use Cases can match Requirements against the capabilities of sub contractors and suppliers.

to top

Display Preferences

Requirement Summary Window Display Columns

• The Display Preferences window allows you to configure the rows and columns of the Summary Window - that is, what information to display and how to sort it.

• You can also configure the display of a host of other Attributes, including always hiding certain Requirements based upon their Status, and showing attributes that have been marked as Deleted.

• These same settings are used when generating Reports.

to top

Display Preferences Requirement Identification

• The complete identification number for each Requirement actually comprises of three parts:
  • the Requirement ID (ReqID),
  • the Sub Requirement ID (SubID), and
  • the decimal part of the Sub Requirement ID.

• Use this Display Preferences tab to choose how to format these three parts in order to best fit the management of Requirements into your existing process.

to top

Reports

• The Reports window allows you to generate a wide range of Reports based upon the set of filtered Requirements and the Requirement Attributes.

• The layout of each Report is very flexible. Reports follow the what-you-see-is-what-you-get (WYSIWYG) format by sorting and filtering in the same manner as you select in the view and edit windows.

• Reports can be printed or exported to another application such as Microsoft Word or Excel.

to top

Report Display Preferences

• Use this Report Display Preferences tab to select which lists of Requirement Attributes to include in the Detailed Report.

• Also use this tab to select inclusion of additional Attribute detail and descriptions in the Report.

to top

Example of a Detailed Report

• The Requirement Detail Report is the most comprehensive and flexible of all Reports. By clicking on the Options button you may select the Attribute lists and detail to include in the Report.

• The Report can be converted into an Adobe Acrobat PDF document or a Microsoft Office Document Image (MDI) when sharing with a group of people.

to top

Example of a Summary Report

• Summary Reports are laid out in list format. They are useful as an index to a Detailed Report, or to provide a summary of which Requirements have changed since the last baseline.

• The Requirement Summary Report displays up to six columns of data in landscape mode (10 inches wide) or portrait mode (7.4 inches wide) selected and sorted by the user from the Requirements Summary window. The user may select between displaying just Requirements, or both Requirements and Sub Requirements.

• Selectable columns include the following:
  • Requirement ID (and ReqID-SubID)
  • Requirement Name
  • Description
  • Priority
  • Status
  • Primary Milestone
  • Primary Group
  • Primary Sub Group
  • Primary Sub Group - Group
  • Primary Stakeholder Name
  • Primary Stakeholder Type
  • Primary Stakeholder Name - Type
  • First Created By
  • First Created Date
  • Last Updated By
  • Last Updated Date
  • Sub Requirement Count
  • Associate Requirement Count
  • Issue Count
  • Resolved Issue Count
  • Unresolved Issue Count
  • Test Cases Count
  • Finished Test Cases Count
  • Unfinished Test Cases Count
  • Tag Count
  • Private Tag Count
  • Public Tag Count
  • Baseline Tag Count
  • Thread Count
  • Flagged Thread Count

to top

Example of an Exportable Report

• All of the data held within the Requirements Management Database can be displayed in spreadsheet mode for the user to copy-and-paste to another application.

• The Exportable Report often also contains additional columns of sorting information that reflect how the user has chosen to sort the data.

to top

Filtering Requirements

Simple Filter

• The Simple Filter provides a quick way to filter the Requirements listed in the Summary Window based upon their Attributes.

• You may use a filter in order to focus on just those Requirements that need to be updated, or to select the Requirements needed for a Report.

• The logical AND operation between filter criteria is used by default. The Filter Preferences window allows you to change the logical operation and scope of the filter.

to top

Advanced Filter

• The Advanced Filter provides you with a more comprehensive choice of filtering options for the Summary Window.

• The results of the Advanced Filter and the Simple Filter can be logically combined through the Filter Preferences window.

• Filter criteria can also be saved and restored.

to top

Combination Filter

• Most of the time the user will be using the Simple Filter or the Advanced Filter to generate a subset of the Requirements in the Project for display in the Requirements Summary window or for one of the Reports. However it is also possible to combine the filter subsets from the Simple Filter and the Advanced Filter together in a Combination Filter.

• This window allows the user to define how the Simple Filter subset will be combined with the Advanced Filter subset.

• Note also the tab that allows the user to save and load Simple and Advanced Filter criteria.

to top

Filtering Sub Requirements

• The Sub Requirements tab of the Display Preferences window provides additional filtering capabilities. Here you may selectively choose which class of Sub Requirement to include in the Summary window or in a Report.

• For example, you may select to filter a particular range of Secondary Milestones, or filter on a keyword. The SubID may also be edited to keep related Sub Requirements together.

to top

Status Display Preferences

• In addition to the filtering capabilities offered in the Requirements Summary window, Requirements can be always hidden from display based upon their Status.

• For example, Deleted, Superseded and Rejected Requirements will be hidden by default. Use this Display Preferences tab to selectively modify which Status to display. You may also override all display settings.

to top

Requirement Change History Logging

Historic Events

• All Project updates are automatically tracked and can be reviewed in this History tab.

• You may generated a change report by filtering Historic Event dates from within the Requirement Summary window.

to top

Historic Snap Shots

• If a Requirement has been updated then an Historic Snap Shot of that Requirement, along with Attribute statistics, will be taken once per day.

• Historic Snap Shots and statistics can be reviewed in the History Detail View tab.

to top

Web Interface

• In addition to the Application Interface discussed above, there is an alternative Web Interface. The Web Interface is designed to provide the Consumers of Requirements (such as Development Engineers and Account Managers) with a simplified way to sort and filter just the information they need through a company Intranet.

• In general, the Web Interface provides just a way to view requirements – but with two exceptions: users may add, edit and delete requirement Issues and discussion Threads.

• The Web Interface is only available when running in Multi-User Mode.

• It will need to be specially configured on your company’s Intranet to point to the current Project file.

to top

Web Interface Groups

• Groups typically describe the functional organization that each Requirement needs to be communicated to.

• A Development Engineering team working in a functional group can use the simplified Web Interface to review just the requirements applicable to them.

to top

Web Interface Tags

• Requirements can be grouped by function or by a Baseline Tag that defines the product’s requirements.

• Collecting requirements together by Baseline and viewing them across the Intranet through the simplified Web Interface is another way to work effectively with the rest of the team.

to top

Custom Process Modules (Open Data Structure)

Blackblot Custom Process Module

• A Custom Process Module is part of the Open Data Structure in which the user can customize the Tables, Forms, Reports and Source Code through Microsoft Access.

• The Blackblot Procedural Requirements Management (PRM) process has been built into a Custom Process Module that is included in your Installation Directory.

• Data in a Custom Process Module is stored in the same Requirements Management Database Project file.

to top